Using Simulcast in Session Description Protocol (SDP) and RTP Sessions
RFC 8853
Yes
No Objection
Recuse
Note: This ballot was opened for revision 12 and is now closed.
Alvaro Retana No Objection
Warren Kumari No Objection
(Ben Campbell; former steering group member) Yes
(Alexey Melnikov; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Benjamin Kaduk; former steering group member) No Objection
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
participant:
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
expansion).
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
capability.
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
paused.
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.
(Deborah Brungard; former steering group member) No Objection
(Eric Rescorla; former steering group member) No Objection
Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D4629 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. COMMENTS 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?
(Ignas Bagdonas; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
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…?
(Spencer Dawkins; former steering group member) No Objection
(Suresh Krishnan; former steering group member) No Objection
(Adam Roach; former steering group member) (was Discuss) Recuse
Recusing, as I am a contributor to this document. Thanks for addressing my earlier discuss and comments!