Using Simulcast in SDP and RTP Sessions

Note: This ballot was opened for revision 12 and is now closed.

(Ben Campbell) Yes

Ignas Bagdonas No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Benjamin Kaduk No Objection

Comment (2018-06-19 for -12)
No email
send info
I have some questions, probably just due to confusion on my part, as well as some nit-leve comments.

Section 3

   There are two principle approaches for an RTP Mixer to provide this
   adapted view of the communication session to each receiving

I think this is more a case for "principal" than "principle", as
it's talking about the primary or main options.

Section 3.1

Expand QoE at first usage only (the fourth usage also has an

Section 5.1

   [...] Since pause capability specified via
   the "a=rtcp-fb" attribute and rid-id specified by "a=rid" can refer
   to common payload types, it is unfeasible to pause streams with rid-
   id where any of the related RTP payload type(s) do not have pause

My brain is having trouble reading this last sentence; maybe it's
trying to say there's a singular/plural disagreement between
"capability" and "payload types", but I think the second clause may
also be giving my brain trouble.  Am I parsing things properly as
this noting that some ("common"/"widely used") payload types do not
support pausing, and that trying to use SDP syntax to pause streams
using that payload type is not going to work well?

Section 5.2

   All RTP payload types related to such initially paused simulcast
   stream MUST be listed in the SDP as pause/resume capable as specified
   by [RFC7728], e.g. by using the "*" wildcard format for "a=rtcp-fb".

nit: I think "streams" plural is needed to be consistent with
"payload types" plural.

   If the endpoint sending the SDP includes an "recv" direction
   simulcast stream that is initially paused, then the remote RTP sender
   receiving the SDP SHOULD put its RTP stream in a unsolicited locally
   paused state.  However, this does not apply if there are other RTP
   stream receivers that do not mark the simulcast stream as initially

I'm not sure if I'm parsing this properly (probably due to ignorance
on my part).  Are the "other RTP stream receivers" other SDP
participants that are for some reason (multicast?) using the same
descriptions, or is this covering the case of things like dependent
streams where something else in the whole negotiated session
requires that stream?

I'm not entirely sure what concrete
information/recommendation/action I'm supposed to take from Section
6.2.2.  Maybe I just haven't had enough tea yet today.

Suresh Krishnan No Objection

Warren Kumari No Objection

Mirja Kühlewind No Objection

Comment (2018-06-18 for -12)
No email
send info
Two smallish comments/questions:

1) Maybe section 3 could/should also mention that sending multiple stream simultaneously from the source to a mixer has also the disadvantage of consuming more network resources..?

2) The intro says: 
"The media transport topologies considered are point to point RTP sessions as well as centralized multi-party RTP sessions..."
but then only middlebox scenarios are discussed and I actually cannot really imagine where a point-to-point scenario makes sense. Could you clarify…?

Alexey Melnikov No Objection

(Eric Rescorla) No Objection

Comment (2018-06-18 for -12)
No email
send info
Rich version of this review at:

It might be nice if you explained some of the basic concepts for how
to use this with offer/answer in the introduction. I found the
explanation kind of confusing until I got there.

S 3.2.
>      It is also common that a currently active speaker participant is
>      shown in larger size or higher quality than other participants (the
>      sampling or bitrate aspects of Section 3.1).  Not sending the active
>      speaker media back to itself means there is some other participant's
>      media that instead has to receive special handling towards the active
>      speaker; typically the previous active speaker.  This way, the

This isn't strictly true. You could *show* yourself big.

S 4.
>      With this SDP answer, the answerer indicates in the "recv" part that
>      it wants to receive the two simulcast RTP streams.  It has removed an
>      alternative that it doesn't support (rid-id 3).  The send part
>      confirms to the offerer that it will receive one stream for this
>      media source according to rid-id 4.  The corresponding, more complete
>      example SDP answer media description could look like:

Do these need to be reversed in order in the answer?

S 6.2.1.
>      The mixer may communicate the identity of the originating media
>      source to the receiver by including the CSRC field with the
>      originating media source's SSRC value.  Note that due to the
>      possibility that the RTP mixer switches between simulcast versions of
>      the media source, the CSRC value may change, even if the media source
>      is kept the same.

How does this interact with PERC?

Alvaro Retana No Objection

Martin Vigoureux No Objection

Adam Roach (was Discuss) Recuse

Comment (2018-07-06 for -13)
No email
send info
Recusing, as I am a contributor to this document. Thanks for addressing my earlier discuss and comments!