Re: Moving forward with SDP control

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> 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]
> *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> 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
>>
>>
>