Subject: [MMUSIC] mux-exclusive: a=mux-exclusive and a=rtcp-mux in the same m- line?

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Feb 2016 08:57:13 +0000

Hi,

One issue is whether it's allowed to include both a=mux-exclusive (or whatever we will end up calling it) and a=rtcp-mux in the same m- line, as a=rtcp-mux means support of fallback to non-mux.

OPTION #1:

If one includes a=mux-exclusive, one must also include a=rtcp-mux

OPTION #2:

If one includes a=mux-exclusive, one must not include a=rtcp-mux.

Now, assuming we'd go for option #2, we would need to change the following text in BUNDLE:

   "When an offerer generates an initial offer, the offerer MUST
   associate an SDP 'rtcp-mux' attribute [RFC5761] with each bundled
   RTP-based "m=" line (including any bundle-only "m=" line) in the
   offer."

So, we'd have to modify that text, and say that the offerer must include either a=rtcp-mux and a=mux-exclusive (in bundle-only m- line it would always be a=mux-exclusive).

Also, if we go for option #2, the question is whether different attributes can be used for different m- lines within a BUNDLE group. If so, it would impact draft-ietf-mmusic-sdp-mux-attributes, which currently assigns a=rtcp-mux to IDENTICAL.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Wed, 3 Feb 2016 11:43:23 -0500

On Wed, Feb 3, 2016 at 3:57 AM, Christer Holmberg <
[email-masked]> wrote:

> One issue is whether it’s allowed to include both a=mux-exclusive (or
> whatever we will end up calling it) and a=rtcp-mux in the same m- line, as
> a=rtcp-mux means support of fallback to non-mux.
>
>
>
> OPTION #1:
>
>
>
Do we allow to setup a media session if end point sends an offer with
a=mux-exclusive and a=rtcp-mux and gets the answer back with a=rtcp-mux
only?

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 3 Feb 2016 17:38:34 +0000

Hi,

>>One issue is whether it’s allowed to include both a=mux-exclusive (or whatever we will end up calling it) and a=rtcp-mux in the same m- line, as a=rtcp-mux means support of fallback to non-mux.
>>
>>OPTION #1:
>>
> Do we allow to setup a media session if end point sends an offer with a=mux-exclusive and a=rtcp-mux and gets the answer back with a=rtcp-mux only?

I think we should - because that means that the answerer agrees to do mux.

And, that is perhaps a good justification for option #1, because it allows to negotiate mux even if the answerer does not support a=mux-exclusive. Because, no matter if we include a=rtcp-mux or not, if the answerer doesn't indicate mux in the answer the offerer will have to take actions.

Regards,

Christer