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

[Christer Holmberg <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>>
Date: Monday 24 April 2017 at 21:29
To: Christer Holmberg <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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:[e-mail]]
Sent: Monday, April 24, 2017 6:46 AM
To: Asveren, Tolga <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional?

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 <[e-mail]<mailto:[e-mail]>> on behalf of Tolga Asveren <[e-mail]<mailto:[e-mail]>>
Date: Monday 24 April 2017 at 13:24
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
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