Subject: [MMUSIC] rtcp-mux in SDP mux

From: Cullen Jennings <[email-masked]>
Date: Sat, 8 Oct 2016 11:52:38 -0700

Question came up if this morning if rtcp-mux should be TRANSPORT instead of IDENTICAL. Anyone remember why it is not TRANSPORT.

---

From: Suhas Nandakumar <[email-masked]>
Date: Sat, 8 Oct 2016 12:01:58 -0700

Hello Cullen

   The reasoning for IDENTICAL category for a=rtcp-mux was to handle the
case of  Initial Offers ( pre bundle address selection) so as to enable the
Offerer to multiplex RTP/RTCP even in the case of BUNDLE semantics being
rejected in the Answer.

So,  In the initial Offer, if the Offerer wants to multiplex RTP/RTCP it
needs to include it in all the m=lines (as defined by the IDENTICAL
category). This is because, if the BUNDLE semantics gets rejected the
offerer can still do  RTP/RTCP multiplexing on those m=lines.
OTOH, if a=rtcp-mux was included only in the m=line whose mid was listed as
the first in the a=group:BUNDLE line (TRANSPORT) and the BUNDLE semantics
gets rejected, there is no way for the Software to imply RTCP Mux or not to.

However once BUNDLE gets accepted and shared address is chosen, the
eventual Offers/Answers can have IDENTICAL category attributes included in
just the bundled m=line than repeatng ( as defined in Section 8.1 of the
BUNDLE spec)

Hope this answers the question

Cheers
Suhas

On Sat, Oct 8, 2016 at 11:52 AM, Cullen Jennings <[email-masked]> wrote:

>
> Question came up if this morning if rtcp-mux should be TRANSPORT instead
> of IDENTICAL. Anyone remember why it is not TRANSPORT.
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Taylor Brandstetter <[email-masked]>
Date: Sat, 8 Oct 2016 12:57:02 -0700

If the offerer wants to multiplex RTP/RTCP regardless of whether or not
bundling is enabled, it can do this even if rtcp-mux is in the TRANSPORT
category, correct? TRANSPORT doesn't seem to prevent putting the same
attribute in every media description.

So, what exactly does being in the IDENTICAL category protect against?
That's what I'm having a hard time understanding.

On Sat, Oct 8, 2016 at 12:01 PM, Suhas Nandakumar <[email-masked]>
wrote:

> OTOH, if a=rtcp-mux was included only in the m=line whose mid was listed
> as the first in the a=group:BUNDLE line (TRANSPORT) and the BUNDLE
> semantics gets rejected, there is no way for the Software to imply RTCP Mux
> or not to.
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 8 Oct 2016 20:32:21 +0000

Hi,

Note that when the initial offer is sent, it is yet not known which m- line will become the BUNDLE m- line. For that reason a=rtcp-mux needs to be associated with every m- line.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Taylor Brandstetter<mailto:[email-masked]>
Sent: ‎08/‎10/‎2016 22:57
To: Suhas Nandakumar<mailto:[email-masked]>
Cc: mmusic<mailto:[email-masked]>; Cullen Jennings<mailto:[email-masked]>; Suhas Nandakumar<mailto:[email-masked]>
Subject: Re: [MMUSIC] rtcp-mux in SDP mux

If the offerer wants to multiplex RTP/RTCP regardless of whether or not bundling is enabled, it can do this even if rtcp-mux is in the TRANSPORT category, correct? TRANSPORT doesn't seem to prevent putting the same attribute in every media description.

So, what exactly does being in the IDENTICAL category protect against? That's what I'm having a hard time understanding.

On Sat, Oct 8, 2016 at 12:01 PM, Suhas Nandakumar <[email-masked]<mailto:[email-masked]>> wrote:
Hello Cullen

   The reasoning for IDENTICAL category for a=rtcp-mux was to handle the case of  Initial Offers ( pre bundle address selection) so as to enable the Offerer to multiplex RTP/RTCP even in the case of BUNDLE semantics being rejected in the Answer.

So,  In the initial Offer, if the Offerer wants to multiplex RTP/RTCP it needs to include it in all the m=lines (as defined by the IDENTICAL category). This is because, if the BUNDLE semantics gets rejected the offerer can still do  RTP/RTCP multiplexing on those m=lines.
OTOH, if a=rtcp-mux was included only in the m=line whose mid was listed as the first in the a=group:BUNDLE line (TRANSPORT) and the BUNDLE semantics gets rejected, there is no way for the Software to imply RTCP Mux or not to.

However once BUNDLE gets accepted and shared address is chosen, the eventual Offers/Answers can have IDENTICAL category attributes included in just the bundled m=line than repeatng ( as defined in Section 8.1 of the BUNDLE spec)

Cheers
Suhas

On Sat, Oct 8, 2016 at 11:52 AM, Cullen Jennings <[email-masked]<mailto:[email-masked]>> wrote:

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Taylor Brandstetter <[email-masked]>
Date: Sun, 9 Oct 2016 00:00:37 -0700

Can you elaborate more? What negative outcome would occur if the IDENTICAL
rule wasn't followed? Even if RTCP mux negotiation depended on which m=
line was selected for bundling, the offerer would still always have enough
information to demux RTCP, correct?

Is this just to prevent implementations from doing something they probably
didn't intend to do, or to simplify implementations? If so, I can accept
that argument, I just want to clearly understand the motivation. I've
noticed at least one attribute move from "IDENTICAL" to "TRANSPORT", so it
would be useful to know where the line is being drawn.

On Oct 8, 2016 1:32 PM, "Christer Holmberg" <[email-masked]>
wrote:

> Hi,
>
> Note that when the initial offer is sent, it is yet not known which m-
> line will become the BUNDLE m- line. For that reason a=rtcp-mux needs to be
> associated with every m- line.
>
> Regards,
>
> Christer
>
> ------------------------------
> From: Taylor Brandstetter <[email-masked]>
> To: Suhas Nandakumar <[email-masked]>
> Cc: mmusic <[email-masked]>; Cullen Jennings <[email-masked]>; Suhas
> Nandakumar <[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 9 Oct 2016 08:30:32 +0000

Hi,

>Can you elaborate more? What negative outcome would occur if the IDENTICAL rule
>wasn't followed? Even if RTCP mux negotiation depended on which m= line was selected 
>for bundling, the offerer would still always have enough information to demux RTCP, correct?
>
>Is this just to prevent implementations from doing something they probably didn't intend to
>do, or to simplify implementations? If so, I can accept that argument, I just want to clearly
>understand the motivation. I've noticed at least one attribute move from "IDENTICAL" to
>"TRANSPORT", so it would be useful to know where the line is being drawn.

The bundle m- line shall explicitly contain all common information associated with the BUNDLE group. That means IDENTICAL category SDP attributes. Endpoints shall not have to look in other m- lines within the BUNDLE group to find the common information.

Now, in the case of RTP/RTCP mux, one could of course say that it doesn't matter if a=rtcp-mux is present in the bundle m= line or not, as RTP/RTCP by default must be used within the BUNDLE group (per agreement at IETF#94). But, I think it is better to be consistent.

Regards,

Christer

On Oct 8, 2016 1:32 PM, "Christer Holmberg" <[email-masked]> wrote:
Hi,

Regards,

Christer

Sent from my Windows Phone
________________________________________
From: Taylor Brandstetter
Sent: ‎08/‎10/‎2016 22:57
To: Suhas Nandakumar
Cc: mmusic; Cullen Jennings; Suhas Nandakumar
Subject: Re: [MMUSIC] rtcp-mux in SDP mux
If the offerer wants to multiplex RTP/RTCP regardless of whether or not bundling is enabled, it can do this even if rtcp-mux is in the TRANSPORT category, correct? TRANSPORT doesn't seem to prevent putting the same attribute in every media description. 

On Sat, Oct 8, 2016 at 12:01 PM, Suhas Nandakumar <[email-masked]> wrote:
Hello Cullen 

Cheers
Suhas