Re: Moving forward with SDP control

+1
El 17/07/2013 19:33, "cowwoc" <cowwoc@bbs.darktech.org> escribió:

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