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

From: Peter Thatcher <[email-masked]>
Date: Fri, 27 Mar 2015 08:40:15 -0700

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.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 28 Mar 2015 12:22:56 -0700

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" <[email-masked]> wrote:

> 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?
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>