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

["Asveren, Tolga" <[e-mail]>]

Yes agreed. All I am asking for is a sentence to prevent confusion:

"It should be noted that both rtcp-mux (per updates in RFC8035) and rtcp-mux-only have bidirectional semantics. They are either accepted and used by both sides or not at all."

Thanks,
Tolga

From: Christer Holmberg [mailto:[e-mail]]
Sent: Tuesday, May 2, 2017 7:58 AM
To: Asveren, Tolga <[e-mail]>; [e-mail]
Subject: Re: [MMUSIC] draft-ietf-mmusic-mux-exclusive-11 / always bidirectional?

Hi,

I took a look at this again. I am not sure I understand what it meant by rtcp-mux-only being bidirectional.

If rtp/rtcp-mux is negotiated, it will be bidirectional according to RFC8035. Note that, with rtcp-mux-only, you still need to include a=rtcp-mux, so the bidirectional rules associated with rtcp-mux still apply.

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