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

From: Eric Rescorla <[email-masked]>
Date: Mon, 18 Jun 2018 14:46:53 -0700

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?

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Jun 2018 14:10:33 +0200

Hi EKR,

See inline for response to your comment.

> https://datatracker.ietf.org/doc/draft-ietf-mmusic-sdp-simulcast/

Sure, but most systems doesn't do that. We could tweak the second 
sentence to make it even more clear that this is just a common 
implementation strategy, and not any requirement.

"Many conferencing systems do not send the active speaker's media back 
to the sender itself, which means there is some other participant's 
media that instead has to be forwarded to the active speaker; typically 
the previous active speaker."
> Do these need to be reversed in order in the answer?

You mean if the answer should be like this:

a=simulcast:send 4 recv 1;2

The ABNF allows both orders. It might be clearer if we swapped the order 
to keep send first.

> How does this interact with PERC?

So this is not a useful operation to perform in PERC context. This 
operation is primarily useful for RTP middleboxes that operates as RTP 
Mixers, while PERC Media Distributors needs to operate as SFUs. And the 
information of who is the originating source (SSRC) is always available 
in the PERC context as that is the index to the right End-to-End 
security context.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 20 Jun 2018 15:06:53 +0200

> media that instead has to be forwarded to the active speaker; 
> typically the previous active speaker."

An improved proposal:

Many conferencing systems do not send the active speaker's media back to 
the sender itself, which means there is some other participant's media 
that instead is forwarded to the active speaker; typically the previous 
active speaker.

> The ABNF allows both orders. It might be clearer if we swapped the 
> order to keep send first.
>
>
>>
>>
>> S 6.2.1.
> Mixers, while PERC Media Distributors needs to operate as SFUs. And 
> the information of who is the originating source (SSRC) is always 
> available in the PERC context as that is the index to the right 
> End-to-End security context.
>
> Cheers
>
> Magnus Westerlund
>

-- 

Magnus Westerlund

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Jun 2018 09:29:40 -0700

On Wed, Jun 20, 2018 at 5:10 AM, Magnus Westerlund <
[email-masked]> wrote:

> Sure, but most systems doesn't do that. We could tweak the second sentence
> to make it even more clear that this is just a common implementation
> strategy, and not any requirement.
>
> "Many conferencing systems do not send the active speaker's media back to
> the sender itself, which means there is some other participant's media that
> instead has to be forwarded to the active speaker; typically the previous
> active speaker."
>
>>
>>
>> S 4.
>>

I think the example would be clearer if you didn't reverse it, because
otherwise one wonders.

> information of who is the originating source (SSRC) is always available in
> the PERC context as that is the index to the right End-to-End security
> context.
>

OK.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 20 Jun 2018 09:29:46 -0700

Sure

On Wed, Jun 20, 2018 at 6:06 AM, Magnus Westerlund <
[email-masked]> wrote:

> instead is forwarded to the active speaker; typically the previous active
> speaker.
>
>
>
>
>
> S 4.
>
> Torshamnsgatan 23
> <https://maps.google.com/?q=Torshamnsgatan+23&entry=gmail&source=g>
> | Mobile +46 73 0949079
> Ericsson AB                 | Phone  +46 10 7148287Torshamnsgatan 23 <https://maps.google.com/?q=Torshamnsgatan+23&entry=gmail&source=g>           | Mobile +46 73 0949079