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

From: Christer Holmberg <[email-masked]>
Date: Thu, 4 Aug 2016 15:19:30 +0000

Hi Mirja,

I suggest the following modified text of the Introduction/3rd paragraph:

   "Some newer applications that do not require backward compatibility
   with peers that cannot multiplex RTCP might choose to not implement
   separation of RTP and RTCP.  Examples of such applications are W3C
   WEBRTC [W3C.WD-webrtc-20120209] applications, that are not required
   to interoperate with non-WEBRTC clients.  For such applications, this
   document defines an SDP attribute to signal intent to require
   multiplexing.  The use of this attribute in SDP offers [RFC3264] by
   entities that ever need to interoperate with peers that do not
   support RTC/RTCP multiplexing may harm interoperability.  Also, while
   the SDP answerer [RFC3264] might support, and prefer usage of,
   fallback to non-multiplex, the attribute indicates that fallback to
   non-multiplex cannot be enabled.  One example of where non-multiplex
   is preferred is where an endpoint is connected to a radio interface,
   and wants to use different bearers (possibly with different quality
   characteristics) for RTP and RTCP.  Another example is where the one
   endpoint is acting as a gateway to a network where RTP/RTCP
   multiplexing cannot be used.  In such case there endpoint may prefer
   non-multiplexing also towards the other network.  Otherwise the
   endpoint would have to perform de-multiplexing of RTP and RTCP."

Regards,

Christer

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]] 
Sent: 27 July 2016 20:37
To: Mirja Kuehlewind (IETF) <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Mirja Kühlewind's No Objection on draft-ietf-mmusic-mux-exclusive-09: (with COMMENT)

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).
>> 
>> Another reason is if a device wishes to handle RTP and RTCP on different interfaces/devices.
>
> Okay, now makes sense. Maybe add these examples to the draft?

I can do that.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 23 Aug 2016 13:41:34 +0000

>
>I've just realized I never answer to this mail. Thanks! Text looks good
>and 
>is helpful, I think!

Great! Thanks! :)

Regards,

Christer

>On 04.08.2016 17:19, Christer Holmberg wrote:
>> Hi Mirja,
>>
>> Cc: The IESG <[email-masked]>; [email-masked];
>>[email-masked]; [email-masked];
>>[email-masked]
>> Subject: RE: Mirja Kühlewind's No Objection on
>>draft-ietf-mmusic-mux-exclusive-09: (with COMMENT)
>>
>> Hi Mirja,
>>
>> ...
>>
>>>> attribute to indicate support of RTP/RTCP multiplexing mandates the
>>>>sender to be able to fall back to non-mux.

---

From: Mirja Kühlewind <[email-masked]>
Date: Tue, 23 Aug 2016 15:38:09 +0200

Hi Christer,

I've just realized I never answer to this mail. Thanks! Text looks good and 
is helpful, I think!

Mirja