Note: This ballot was opened for revision 12 and is now closed.
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.
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…?
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?
Recusing, as I am a contributor to this document. Thanks for addressing my earlier discuss and comments!