W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: Moving forward with SDP control

From: <piranna@gmail.com>
Date: Tue, 16 Jul 2013 20:17:30 +0200
Message-ID: <CAKfGGh2jpO_r_xcL9AzC8Pz2Wh6MZQgc-NNnZrCbhbTaEz7cqw@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
Cc: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
+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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC