Re: Moving forward with SDP control

+1. Also, additionaly, by default the most common situation should be
solved without viewing the SDP at all.

2013/7/16 Roman Shpount <roman@telurix.com>:
> 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. 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. 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.
> _____________
> Roman Shpount
>



-- 
"Si quieres viajar alrededor del mundo y ser invitado a hablar en un
monton de sitios diferentes, simplemente escribe un sistema operativo
Unix."
– Linus Tordvals, creador del sistema operativo Linux

Received on Tuesday, 16 July 2013 18:18:17 UTC