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

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic