Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional?

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 Apr 2017 10:46:20 +0000

Hi,

RFC 5761 has been updated in RFC 8035 (https://tools.ietf.org/rfc/rfc8035.txt), where we clarify that negotiated mux is always bidirectional.

   "This document updates RFC 5761 [RFC5761] by clarifying that an
   answerer can only include an "a=rtcp-mux" attribute in an answer if
   the associated offer contained the attribute.  It also clarifies that
   the negotiation of RTP and RTCP multiplexing is for usage in both
   directions."

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Tolga Asveren <[email-masked]<mailto:[email-masked]>>
Date: Monday 24 April 2017 at 13:24
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional?

It seems draft-ietf-mmusic-mux-exclusive-11 assumes that mux support will be always bidirectional. OTOH, I think RFC5761 allows unidirectional semantics:

5.1.1. SDP Signaling
…

   When SDP is used in a declarative manner, the presence of an "a=rtcp-
   mux" attribute signals that the sender will multiplex RTP and RTCP on
   the same port.  The receiver MUST be prepared to receive RTCP packets
   on the RTP port, and any resource reservation needs to be made
   including the RTCP bandwidth.

Actually this part of RFC5761 sounds a bit odd as in declarative mode I thought an attribute would convey information about the “receipt properties” therefore “rtcp-mux” would mean that the sender wants to receive RTP/RTCP multiplexed on the same port.

It could be good to explicitly state in draft-ietf-mmusic-mux-exclusive that unidirectional multiplexing with declarative mode is not supported.

Example scenario:
A sends rtcp-mux/rtcp-mux-only
B does not support rtcp-mux-only and ignores it. It interprets rtcp-mux in declarative mode and is ready to receive RTP/RTCP on the same port. OTOH, it does not want to send multiplexed RTP/RTCP hence does not include rtcp-mux in the reply.
A terminates the session because the answer does not contain rtcp-mux. It can’t determine whether multiplexing is not supported at all or whether B wants to use it in a unidirectional way.

Thanks,
Tolga

---

From: "Asveren, Tolga" <[email-masked]>
Date: Mon, 24 Apr 2017 18:29:19 +0000

Thanks for pointing this out. The issue still would be applicable for already deployed RFC5761 compliant/RFC8035 non-compliant entities. Therefore IMHO it could be a good idea to explicitly mention that "rtcp-mux-only" is bidirectional as "rtcp-mux" per RFC8035.

Thanks,
Tolga

From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, April 24, 2017 6:46 AM
To: Asveren, Tolga <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional?

Hi,

   directions."

Regards,

Christer

5.1.1. SDP Signaling
...

Actually this part of RFC5761 sounds a bit odd as in declarative mode I thought an attribute would convey information about the "receipt properties" therefore "rtcp-mux" would mean that the sender wants to receive RTP/RTCP multiplexed on the same port.

Example scenario:
A sends rtcp-mux/rtcp-mux-only
B does not support rtcp-mux-only and ignores it. It interprets rtcp-mux in declarative mode and is ready to receive RTP/RTCP on the same port. OTOH, it does not want to send multiplexed RTP/RTCP hence does not include rtcp-mux in the reply.
A terminates the session because the answer does not contain rtcp-mux. It can't determine whether multiplexing is not supported at all or whether B wants to use it in a unidirectional way.

Thanks,
Tolga

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Apr 2017 06:34:12 +0000

Hi,

When taking a look, I realised that both RFC8035 and draft-mux-exclusive update the same text in RFC5761, which causes confusion.

So, as RFC 8035 updates the whole section 5.1.1 of RFC5671, I assume that whatever updates need to be done in draft-mix-exclusive should be done based on the text in RFC8035.

Regards,

Christer

From: Tolga Asveren <[email-masked]<mailto:[email-masked]>>
Date: Monday 24 April 2017 at 21:29
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional?

Thanks for pointing this out. The issue still would be applicable for already deployed RFC5761 compliant/RFC8035 non-compliant entities. Therefore IMHO it could be a good idea to explicitly mention that “rtcp-mux-only” is bidirectional as “rtcp-mux” per RFC8035.

Thanks,
Tolga

From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, April 24, 2017 6:46 AM
To: Asveren, Tolga <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional?

Hi,

   directions."

Regards,

Christer

5.1.1. SDP Signaling
…

Example scenario:

Thanks,
Tolga