Re: [MMUSIC] Concerns about overloading PTs for simulcast, especially in relation to WebRTC RtpSenders

I thought that the grouping of PT values in a=simulcast line would be
sufficient for identifying groups.

I figure that the parsing is easy: if there is no attribute, the list has
exactly one entry. Otherwise, the set of encodings is defined by the values
in the answer. The only concern is the potential for options to remain,
from which a sender might dynamically choose. I don't have a concern with
removing that flexibilityif you find it onerous, and there isn't a strong
case made by someone to keep it.
On Mar 27, 2015 8:41 AM, "Peter Thatcher" <pthatcher@google.com> wrote:

> I was about to go to the mic at IETF 92, but the time was cut right when I
> was getting up, and they said take comments to the list.  Here are my
> comments :).
>
> I have a concerns about using PTs for simulcast in SDP, especially in
> relation to how they will be used in WebRTC for RtpSenders.    In the
> WebRTC API, we are working on adding multiple encodings to a single
> RtpSender object (via the RtpSender.getParameters() method which returns a
> value with a sequence of RtpEncodingParameters values). This is to allow,
> for example, applications to control per-encoding pause/resume or bandwidth
> without munging SDP.
>
> But this means that the browser needs to parse SDP from
> SetLocalDescription and SetRemoteDescription and identity what things in
> the SDP are encodings, and what their states are.  If encodings in SDP are
> done by overloading PTs, how do I parse the SDP and know which PTs are
> "normal" PTs and which PTs are encodings?    Or in other words, how do I
> extract the encoding information from the SDP?
>
> If this SDP is going to be used for WebRTC, I'd greatly prefer a format
> that makes the encodings explicit and easy to parse.  I think the current
> proposal of overloading PTs makes this information difficult to extract.  I
> have some ideas for how we could do that (with an explicit a=encoding line,
> for example), but it would probably be a significant change to the current
> draft.
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
>