Using Simulcast in Session Description Protocol (SDP) and RTP Sessions
draft-ietf-mmusic-sdp-simulcast-14

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.

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?

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…?