RE: Moving forward with SDP control

Doesn't fix offer/answer state machine inside the browser issue.

Doesn't fix that SDP (and this object) will mix transport, codec selection, and other settings that one might want to adjust separately without having to reset all of them in a single object.

Matthew Kaufman

________________________________
From: Kiran Kumar [g.kiranreddy4u@gmail.com]
Sent: Wednesday, July 17, 2013 11:49 PM
To: cowwoc
Cc: public-webrtc@w3.org
Subject: Re: Moving forward with SDP control


HI,

It would be better if PeerConnection::createOffer/createAnswer() returns a capability object, which should be easily extendable for future parameters.
This object should resumble the SDP, so that the application developer can easily create an SDP, based on the parameter in the capability object.
Probably this solves the drawbacks of the existing SDP.
With this approach, we can continuew mangling of SDP in the form of API if required.
the following are the identified problems/solutions for capability negotiation.

1. SIP capability  --  JS application prepares SDP in string format from the parameters in the capability object.
2. XMPP-JINGLE -- JS application prepares SDP in xml format from the parameters in the capability object.
3. Proprietory/Other      -- JS application prepares its own proprietory/Other format of capability  from the parameters in the capability object.

4. Future expected/invented properties/parameters can be easily extended to the capability object.
5. The application can prepare its own supported version of SDP/capabilities (example .. some legacy devices may not support the proposed features)
6. The object resumbling SDP will make the applications using legacy signaling protocols (expected major clients for webrtc) to easily prepare the SDP.
7. Provides abstraction to the lower level API.

Thanks,
Kiran.

On Wed, Jul 17, 2013 at 11:02 PM, cowwoc <cowwoc@bbs.darktech.org<mailto:cowwoc@bbs.darktech.org>> wrote:
On 17/07/2013 5:52 AM, Harald Alvestrand wrote:
On 07/16/2013 08:00 PM, Roman Shpount wrote:
Harald,

We can definitely start in this direction, but would not you think that we need to define what is available SDP before figuring out all the use cases that require SDP mangling? Otherwise, the only answer that I can think of is that we need to be able to modify pretty much everything available in SDP as long as it controls something (no one should care about the "t=" line). I can come up with use cases that require modification of almost all the SDP components, such as codecs, codec parameters, codec order, ptime, bandwidth, and ice candidates, may be with a few exceptions of things like DTLS fingerprints.

That's why I think we need to come up with the use cases and *discuss* them.

    I'm all for this, so long as this work is taking place against the backdrop of the design document I mentioned.


Even for the non-modifiable parameters I can come up with use cases when the application will need to read them. Bottom line, everything defined in SDP will need to be exposed in API. The only reason not to expose something in the API is that this SDP portion can be ignored.

That was the original rationale for exposing the SDP, actually; people with exotic needs could get satisfaction without complexifying the API interface, but in return, they had to do SDP munging.

    The problem is that typical use-cases currently require you to handle the SDP. Furthermore, it is much more user-friendly to expose this through an Object API than having anyone (even advanced users) do SDP munging. By exposing implementation details to end-users, you limit the specification's ability to modify (or even replace) SDP in the future. If you go with an Object API you will get a lot further.

Gili