- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Wed, 17 Jul 2013 13:32:18 -0400
- To: public-webrtc@w3.org
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
Received on Wednesday, 17 July 2013 17:32:58 UTC