Re: Moving forward with SDP control

+1, seems a nice API scheme.
El 18/07/2013 08:51, "Kiran Kumar" <g.kiranreddy4u@gmail.com> escribió:

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