[MMUSIC] Eric Rescorla's No Objection on draft-ietf-mmusic-sdp-simulcast-12: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-mmusic-sdp-simulcast-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?