Re: Moving forward with SDP control

     One comment: this is too low level.

     SDP is an implementation detail. Creating a one-to-one mapping 
between SDP and the Constraints API is a mistake (it's a small 
improvement on SDP itself). Instead, you should be mapping use-cases to 
the Constraint API as if SDP did not exist. You will still need to be 
able to convert Constraints to SDP, but at least your conceptual model 
will no longer be polluted with implementation details.

http://lcsd05.cs.tamu.edu/slides/keynote.pdf slide 15. Josh elaborates 
on this in more detail in the video (Google it).

Gili

On 19/07/2013 1:40 AM, Kiran Kumar wrote:
> Hi Mathew,
> Thanks for your comments,
>
>          In case of modifying one or two parameters, it is not 
> required to reset the complete object. In existing design, application 
> can mangle the SDP before setLocalDescription(). Similar to existing 
> design, application can get capabilities/description object with 
> localCapabilities()/localDescription() method, modify only the 
> required parameters and insert the complete object. This will abstract 
> the low level API and reduces exposing/maintaining multiple API to 
> application. The application can modify the required features using a 
> single API call, at high level. It abstracts the API/methods which are 
> not supposed to be modified by the application.
>
>          If consensus approves the proposal, to do all the 
> modifications using constraints object, mangling of individual 
> parameters can be done using constraints object. For now we are 
> passing the constraints at session initiation (while creating peer 
> connection object). Later to support this new proposal, PeerConnection 
> may support one more method (like setConstraints()), which will apply 
> constraints to existing/ongoing session.
>
>          This object is supposed to resemble SDP, such that the 
> application can create the SDP object easily, but it is not a pure SDP 
> object. So no need to maintain the offer/answer state machine inside 
> the browser. Probably that will be maintained by the application (if 
> it is a SIP application, if application using a proprietory mechanism 
> then its own state machine). Browser has to maintain few states, to 
> handle the exceptions. Currently I am working on that state machine 
> and will propose it soon.
>
>          Suggestions/Comments welcome.
>
> Thanks,
> Kiran.
>
>
> On Thu, Jul 18, 2013 at 8:19 PM, Matthew Kaufman (SKYPE) 
> <matthew.kaufman@skype.net <mailto:matthew.kaufman@skype.net>> wrote:
>
>     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
>     <mailto:g.kiranreddy4u@gmail.com>]
>     *Sent:* Wednesday, July 17, 2013 11:49 PM
>     *To:* cowwoc
>     *Cc:* public-webrtc@w3.org <mailto: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
>
>
>