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