Re: Moving forward with SDP control

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.

When, for instance, we discussed constraints on the GetUserMedia 
interface in the Boston interim, it became painfully obvious that the 
constituency in the WG for defining (for instance) an ISO number 
constraint was very, very small; it is concievable that there is a 
scenario where it might be useful, but it is not something this WG wants 
to pursue.

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

> We can rate the importance of different SDP components in this group 
> and only expose "the most important" ones, but I would think this 
> would be driven by personal preference of group members as much as 
> anything else.

I'd call it "technical judgment of skilled professionals who participate 
in the WG", which is how we decide everything else, but yes.

Received on Wednesday, 17 July 2013 09:52:33 UTC