Re: Moving forward with SDP control

Dear Gili,
Thanks for the comment.

The suggested video is good.

             I just want to explain that, in future, SDP mangling may not
be used that much, which can be achieved by constraints API.  I am not
mapping SDP and Constraints API, but generally constraints will modify SDP
internally inside the webrtc platform.

             I don't even support to expose the low level API and
implementation detail. For signalling purpose, we have to share some
information, regarding capabilities, with the other peer. And this
information should be exposed to the application. Currently  SDP with
getLocalDescription() is also exposing the same in the form of string. I
suggest that, the proposed object should contain only that details required
for peer-to-peer signaling communication. and will be exposed in the form
of API instead of string. This object should be an outcome of the
implementation but not the internal implementation (for remote
descriptions, the same will act as input for the implementation).

               Also from the video you specified ( gegarding this
http://lcsd05.cs.tamu.edu/slides/keynote.pdf) slide 31, it is suggested to
provide an Programmatic access to all data, even though, that is also
available in the form of string. So the approach to implement the
capabilities in the form of API seems to be good even according that video.


Thanks,
Kiran.


On Fri, Jul 19, 2013 at 12:08 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

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