Subject: [MMUSIC] Mirja Kühlewind's No Objection on draft-ietf-mmusic-mux-exclusive-09: (with COMMENT)

From: "Mirja Kuehlewind" <[email-masked]>
Date: Mon, 25 Jul 2016 08:04:21 -0700

Mirja Kühlewind has entered the following ballot position for
draft-ietf-mmusic-mux-exclusive-09: 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-mux-exclusive/

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

Quick question: 
My initial understanding was that newer systems usually support RTP/RTCP
multiplexing, while older systems that do not support RTP/RTCP
multiplexing will also not be able to understand this new attribut.  So I
guess that's not the use case. That means the use case if for newer
system that do know about  RTP/RTCP multiplexing as well as the
'rtcp-mux-only' attribute but don't support it for some reason. What are
these reasons? Maybe you can provide some more background about the
intended usage here!

Minor: 
Some sentences are a little hard to pharse as they are quite long, e.g.

OLD:
"When an offerer sends the initial offer, if the offerer wants to
   indicate exclusive RTP/RTCP multiplexing for RTP-based media, the
   offerer MUST associate an SDP 'rtcp-mux-only' attribute with the
   associated SDP media description ("m=" line)."

MAYBE:
"If the offerer wants to
   indicate exclusive RTP/RTCP multiplexing for RTP-based media, the
   offerer MUST send the initial offer with an associated SDP
'rtcp-mux-only' attribute and the
   associated SDP media description ("m=" line)."

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 26 Jul 2016 13:18:03 +0000

Hi Mirja,

Thanks for Your comments! Please see inline.

Quick question: 
> My initial understanding was that newer systems usually support RTP/RTCP multiplexing, while
> older systems that do not support RTP/RTCP multiplexing will also not be able to understand this 
> new attribute.  So I guess that's not the use case. That means the use case if for newer system that 
> do know about  RTP/RTCP multiplexing as well as the 'rtcp-mux-only' attribute but don't support it 
> for some reason. What are these reasons? Maybe you can provide some more background about the 
> intended usage here!

There are newer systems that ONLY support RTP/RTCP multiplexing - without being able to fall back to non-mux. However, the existing SDP attribute to indicate support of RTP/RTCP multiplexing mandates the sender to be able to fall back to non-mux. The new SDP attribute is used to indicate that you can do RTP/RTCP multiplexing ONLY.

One reason why the receiver may support mux, but prefers to do non-mux is because it is connected to a radio interface and wants to use different bearers (possible with different quality characteristics) for RTP and RTCP.

Another reason is if the receiver is a gateway connected to a network where RTP/RTCP multiplexing is not used. In such case the gateway may prefer to not use RTP/RTCP mux on either "side". Otherwise it would have to perform RTP/RTCP demuxing (between the endpoint that uses mux and the endpoint that doesn't).

Another reason is if a device wishes to handle RTP and RTCP on different interfaces/devices.

Minor: 
>   "If the offerer wants to indicate exclusive RTP/RTCP multiplexing for RTP-based media, the
>   offerer MUST send the initial offer with an associated SDP 'rtcp-mux-only' attribute and the

I don't have anything the suggested new text (I assume you meant "attribute *in* the associated...") as such, but as the original text follows the structure I've also used in other drafts I'd like to keep it :)

Regards,

Christer

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Tue, 26 Jul 2016 15:45:26 +0200

Hi Christer,

see below.

> Am 26.07.2016 um 15:18 schrieb Christer Holmberg <[email-masked]>:
> 
> Hi Mirja,
> 

Okay, now makes sense. Maybe add these examples to the draft?

> I don't have anything the suggested new text (I assume you meant "attribute *in* the associated...") as such, but as the original text follows the structure I've also used in other drafts I'd like…

Yes, I’ve seen this construct a couple of time in the doc and I found it always hard to read. It’s on you, however, improving readability is usually a win.

Mirja

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 27 Jul 2016 17:36:47 +0000

Hi Mirja,

...

>> There are newer systems that ONLY support RTP/RTCP multiplexing - without being 
>> able to fall back to non-mux. However, the existing SDP attribute to indicate support 
>> of RTP/RTCP multiplexing mandates the sender to be able to fall back to non-mux. 
>> The new SDP attribute is used to indicate that you can do RTP/RTCP multiplexing ONLY.
>> 
>> One reason why the receiver may support mux, but prefers to do non-mux is because it
>> is connected to a radio interface and wants to use different bearers (possible with different 
>> quality characteristics) for RTP and RTCP.
>> 
>> Another reason is if the receiver is a gateway connected to a network where RTP/RTCP 
>> multiplexing is not used. In such case the gateway may prefer to not use RTP/RTCP mux on
>> either "side". Otherwise it would have to perform RTP/RTCP demuxing (between the 
>> endpoint that uses mux and the endpoint that doesn't).
>> 

I can do that.

Regards,

Christer