Subject: [rtcweb] BUNDLE with implicit rtcp-mux

From: Justin Uberti <[email-masked]>
Date: Mon, 10 Mar 2014 06:17:31 +0000

In my JSEP preso during the RTCWEB session last Wednesday, I discussed
adding a new BUNDLE policy to JSEP. This policy, which would be called
something like “force-bundle”, would force the use of the same ports for
BUNDLEd m-sections, as well as RTCP mux. When one knows a priori that the
other side supports BUNDLE, this would reduce candidate gathering even over
the currently defined “max-bundle” policy, since there would be no need to
gather RTCP ports at all, and also avoid the need for the BUNDLE fixup
offer (where the ports are updated to be the same for all BUNDLEd
m-sections).

To explain the differences here, here are some example offers for an
audio+video call:

Default bundle policy - separate ports for audio, video, RTP and RTCP:
m=audio 10000
a=rtcp:10001
a=rtcp-mux
m=video 11000
a=rtcp:11001
a=rtcp-mux

Existing "max-bundle" policy - video port is 0 because bundle-only, but
both RTP and RTCP ports allocated for audio:
m=audio 10000
a=rtcp:10001
a=rtcp-mux
m=video 0
a=bundle-only
a=rtcp-mux

The new “force-bundle” policy - only a single set of ports allocated -
audio, video, RTP, RTCP share the same port.
m=audio 10000
a=rtcp:10000
a=rtcp-mux
m=video 10000
a=rtcp:10000
a=rtcp-mux

During the discussion, the ability to avoid RTCP port gathering was seen as
valuable, but not the ability to avoid the fixup offer. However, after
thinking about it a bit, I don’t think that there is a viable solution that
avoids RTCP port gathering that *doesn’t* use a single set of ports. The
only other option would be to do something like this:

m=audio 10000
a=rtcp:10000 # same as m=audio port
a=rtcp-mux
m=video 0
a=bundle-only
a=rtcp-mux

but this will almost surely will result in a malfunction when talking to a
non-rtcp-mux client, due to the same port being used for RTP and RTCP, and
still requires the fixup offer, and as such is net worse than the
force-bundle approach indicated above.

So I think we the force-bundle approach is the one we want to minimize port
gathering. The only question is whether we should keep max-bundle as well.
To be specific, we need to decide between:

a) Keep max-bundle as it is (separate RTP and RTCP ports allocated), and
add a new force-bundle policy that creates an offer with a single port
shared between all m-sections (RTP and RTCP). max-bundle remains nominally
backwards compatible with non-BUNDLE/non-rtcp-mux endpoints, in that it
will still send a single audio stream. force-bundle is not backwards
compatible with non-BUNDLE endpoints.

b) Add force-bundle, but get rid of max-bundle.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Mar 2014 08:24:06 +0000

Hi,

Before I comment on your proposal, let’s take a few steps back (maybe it can even solve your issue).

BUNDLE currently mandates the usage of both the SDP rtcp-mux and rtcp attributes. I remember we had discussions about that, but I don’t remember the justification at the moment. But, I wonder whether that text is from before we made a decision that, unless both endpoints support BUNDLE, no endpoint will use a single address:port.

So, the question is: do we really need the SDP rtcp attribute?

Regards,

Christer

From: Justin Uberti [mailto:[email-masked]]
Sent: 10. maaliskuuta 2014 8:18
To: [email-masked]; Eric Rescorla; Christer Holmberg
Subject: BUNDLE with implicit rtcp-mux

In my JSEP preso during the RTCWEB session last Wednesday, I discussed adding a new BUNDLE policy to JSEP. This policy, which would be called something like “force-bundle”, would force the use of the same ports for BUNDLEd m-sections, as well as RTCP mux. When one knows a priori that the other side supports BUNDLE, this would reduce candidate gathering even over the currently defined “max-bundle” policy, since there would be no need to gather RTCP ports at all, and also avoid the need for the BUNDLE fixup offer (where the ports are updated to be the same for all BUNDLEd m-sections).
To explain the differences here, here are some example offers for an audio+video call:
Default bundle policy - separate ports for audio, video, RTP and RTCP:
m=audio 10000
a=rtcp:10001
a=rtcp-mux
m=video 11000
a=rtcp:11001
a=rtcp-mux
Existing "max-bundle" policy - video port is 0 because bundle-only, but both RTP and RTCP ports allocated for audio:
m=audio 10000
a=rtcp:10001
a=rtcp-mux
m=video 0
a=bundle-only
a=rtcp-mux
The new “force-bundle” policy - only a single set of ports allocated - audio, video, RTP, RTCP share the same port.
m=audio 10000
a=rtcp:10000
a=rtcp-mux
m=video 10000
a=rtcp:10000
a=rtcp-mux
During the discussion, the ability to avoid RTCP port gathering was seen as valuable, but not the ability to avoid the fixup offer. However, after thinking about it a bit, I don’t think that there is a viable solution that avoids RTCP port gathering that *doesn’t* use a single set of ports. The only other option would be to do something like this:
m=audio 10000
a=rtcp:10000 # same as m=audio port
a=rtcp-mux
m=video 0
a=bundle-only
a=rtcp-mux
but this will almost surely will result in a malfunction when talking to a non-rtcp-mux client, due to the same port being used for RTP and RTCP, and still requires the fixup offer, and as such is net worse than the force-bundle approach indicated above.
So I think we the force-bundle approach is the one we want to minimize port gathering. The only question is whether we should keep max-bundle as well. To be specific, we need to decide between:
a) Keep max-bundle as it is (separate RTP and RTCP ports allocated), and add a new force-bundle policy that creates an offer with a single port shared between all m-sections (RTP and RTCP). max-bundle remains nominally backwards compatible with non-BUNDLE/non-rtcp-mux endpoints, in that it will still send a single audio stream. force-bundle is not backwards compatible with non-BUNDLE endpoints.
b) Add force-bundle, but get rid of max-bundle.

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Mar 2014 14:59:07 +0100

On 2014-03-10 09:24, Christer Holmberg wrote:
> BUNDLE currently mandates the usage of both the SDP rtcp-mux and rtcp
> attributes. I remember we had discussions about that, but I don’t
> remember the justification at the moment. But, I wonder whether that
> text is from before we made a decision that, unless both endpoints
> support BUNDLE, no endpoint will use a single address:port.
> 
>  
> 

I think it is a question of how you want the fallback to work. In the
case of bundle only lines, a non  bundle supporting peer will reject
them, thus no issues with what is written around RTCP-mux and a=rtcp in
those m= blocks. However, the first one if you want that to support
fallback that makes sense then you will need both a=rtcp-mux and an
a=rtcp (with a different port) to handle that with optimal backwards
compatibility.

Regarding the motivation for a=rtcp-mux and a=rtcp, I think it is
reasonably straight forward. We want a=rtcp-mux to minimize port usage,
i.e. ports=1. Not supporting a=rtcp-mux with bundle that would mean two
ports (RTP and RTCP) for the bundle group. To get the backwards
compatibility the usage of a=rtcp would be required.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Mar 2014 14:13:31 +0000

Hi,

>> Before I comment on your proposal, let's take a few steps back (maybe 
>> it can even solve your issue).  
>> 
>> attributes. I remember we had discussions about that, but I don't 
> I think it is a question of how you want the fallback to work. In the case of bundle only lines, a non  bundle supporting peer will reject them, thus 
> no issues with what is written around RTCP-mux and a=rtcp in those m= blocks. However, the first one if you want that to support fallback that 
> makes sense then you will need both a=rtcp-mux and an a=rtcp (with a different port) to handle that with optimal backwards compatibility.
>
> Regarding the motivation for a=rtcp-mux and a=rtcp, I think it is reasonably straight forward. We want a=rtcp-mux to minimize port usage, 
> i.e. ports=1. Not supporting a=rtcp-mux with bundle that would mean two ports (RTP and RTCP) for the bundle group. To get the backwards 

Keep in mind that the offerer must always be prepared that the answerer does not support the rtcp-mux attribute (or the rtcp attribute).

So, at least my understanding is: no matter whether BUNDLE is used or not, if the answer does not contain a rtcp-mux (e.g. in case of fallback) attribute, the offerer must use the default "rtp+1" port.

Regards,

Christer

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Mar 2014 15:27:53 +0100

On 2014-03-10 15:13, Christer Holmberg wrote:
> Hi,
> 
>>> Before I comment on your proposal, let's take a few steps back
>>> (maybe it can even solve your issue).
>>> 
>>> BUNDLE currently mandates the usage of both the SDP rtcp-mux and
>>> rtcp attributes. I remember we had discussions about that, but I
>>> don't remember the justification at the moment. But, I wonder
>>> whether that text is from before we made a decision that, unless
>>> both endpoints support BUNDLE, no endpoint will use a single
>>> address:port.
>>> 
>>> 
>>> 
>> I think it is a question of how you want the fallback to work. In
>> the case of bundle only lines, a non  bundle supporting peer will
>> reject them, thus no issues with what is written around RTCP-mux
>> and a=rtcp in those m= blocks. However, the first one if you want
>> that to support fallback that makes sense then you will need both
>> a=rtcp-mux and an a=rtcp (with a different port) to handle that
>> with optimal backwards compatibility.
>> 
>> reasonably straight forward. We want a=rtcp-mux to minimize port
>> usage, i.e. ports=1. Not supporting a=rtcp-mux with bundle that
>> would mean two ports (RTP and RTCP) for the bundle group. To get
>> the backwards compatibility the usage of a=rtcp would be required.
> 
> Keep in mind that the offerer must always be prepared that the
> answerer does not support the rtcp-mux attribute (or the rtcp
> attribute).

Yes, that was what I meant with fallback in the above text. What you do
in case the peer doesn't support bundle.

> 
> So, at least my understanding is: no matter whether BUNDLE is used or
> not, if the answer does not contain a rtcp-mux (e.g. in case of
> fallback) attribute, the offerer must use the default "rtp+1" port.

I have a tendency to agree, which means that the first m= block in a
bunde-only group will be required to contain a=rtcp and if RTCP mux is
desired also that attribute.

I think a=rtcp could be skipped for a bound-only m= block due to the
requirement on supporting a=rtcp-mux if you do bundle.

Cheers

Magnus Westerlund

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Mar 2014 14:38:32 +0000

Hi,

>>> them, thus no issues with what is written around RTCP-mux and a=rtcp 
>>> in those m= blocks. However, the first one if you want that to 
>>> support fallback that makes sense then you will need both a=rtcp-mux 
>>> and an a=rtcp (with a different port) to handle that with optimal 
>>> backwards compatibility.
>>> 
>>> usage, i.e. ports=1. Not supporting a=rtcp-mux with bundle that would 
>>> mean two ports (RTP and RTCP) for the bundle group. To get the 
>>> backwards compatibility the usage of a=rtcp would be required.
>> 
> Yes, that was what I meant with fallback in the above text. What you do in case the peer doesn't support bundle.
> 
> I have a tendency to agree, which means that the first m= block in a bunde-only group will be required to contain a=rtcp and if RTCP mux is desired also that attribute.
>
> I think a=rtcp could be skipped for a bound-only m= block due to the requirement on supporting a=rtcp-mux if you do bundle.

For bundle-only, I actually think BOTH can be skipped, because bundle-only will by default use whatever address:port is negotiated - both for RTP and RTCP.

But, for non-bundle-only, I still ask whether we really need a=rtcp. Isn't a=rtcp-mux enough? If the answerer supports it, you will use it, otherwise you will use rtp+1.

Otherwise, assume that the answerer supports BOTH a=rtcp and a=rtcp-mux. Which has higher "priority"? How does the answerer knows whether the offerer wants to use rtcp-mux, or whether it wants to use whatever port is indicated in a=rtcp?

Regards,

Christer

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 10 Mar 2014 16:16:38 +0100

On 2014-03-10 15:38, Christer Holmberg wrote:
> Hi,
> 
>>>>> Before I comment on your proposal, let's take a few steps
>>>>> back (maybe it can even solve your issue).
>>>>> 
>>>>> BUNDLE currently mandates the usage of both the SDP rtcp-mux
>>>>> and rtcp attributes. I remember we had discussions about
>>>>> that, but I don't remember the justification at the moment.
>>>>> But, I wonder whether that text is from before we made a
>>>>> decision that, unless both endpoints support BUNDLE, no
>>>>> endpoint will use a single address:port.
>>>>> 
>>>>> 
>>>>> 
>>>> I think it is a question of how you want the fallback to work.
>>>> In the case of bundle only lines, a non  bundle supporting peer
>>>> will reject them, thus no issues with what is written around
>>>> RTCP-mux and a=rtcp in those m= blocks. However, the first one
>>>> if you want that to support fallback that makes sense then you
>>>> will need both a=rtcp-mux and an a=rtcp (with a different port)
>>>> to handle that with optimal backwards compatibility.
>>>> 
>>>> Regarding the motivation for a=rtcp-mux and a=rtcp, I think it
>>>> is reasonably straight forward. We want a=rtcp-mux to minimize
>>>> port usage, i.e. ports=1. Not supporting a=rtcp-mux with bundle
>>>> that would mean two ports (RTP and RTCP) for the bundle group.
>>>> To get the backwards compatibility the usage of a=rtcp would be
>>>> required.
>>> 
>> Yes, that was what I meant with fallback in the above text. What
>> you do in case the peer doesn't support bundle.
>> 
>>> So, at least my understanding is: no matter whether BUNDLE is
>>> used or not, if the answer does not contain a rtcp-mux (e.g. in
>>> case of fallback) attribute, the offerer must use the default
>>> "rtp+1" port.
>> 
>> I have a tendency to agree, which means that the first m= block in
>> a bunde-only group will be required to contain a=rtcp and if RTCP
>> mux is desired also that attribute.
>> 
>> I think a=rtcp could be skipped for a bound-only m= block due to
>> the requirement on supporting a=rtcp-mux if you do bundle.
> 
> For bundle-only, I actually think BOTH can be skipped, because
> bundle-only will by default use whatever address:port is negotiated -
> both for RTP and RTCP.

No, I see a path of grief to not explicitly signal things when you use
them. I also thought the a=rtcp-mux is a MUST to implement, not a MUST use.

> 
> But, for non-bundle-only, I still ask whether we really need a=rtcp.
> Isn't a=rtcp-mux enough? If the answerer supports it, you will use
> it, otherwise you will use rtp+1.

My understanding is that a=rtcp has been required in any non-private
network deployments due to NATs for the last 10 years. Thus, I don't see
how you can remove them and expect it to work, unless you are doing
a=rtcp-mux. Thus, my view would be that you can remove a=rtcp if you
know that the peer supprots a=rtcp-mux.

> 
> Otherwise, assume that the answerer supports BOTH a=rtcp and
> a=rtcp-mux. Which has higher "priority"? How does the answerer knows
> whether the offerer wants to use rtcp-mux, or whether it wants to use
> whatever port is indicated in a=rtcp?

That is a=rtcp-mux per RFC 5761 that has higher priority, please see
Section 5.1.1.

cheers

Magnus Westerlund

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Mar 2014 20:09:20 +0000

Hi,

>>>>>> don't remember the justification at the moment.
>>>>>> But, I wonder whether that text is from before we made a decision 
>>>>>> that, unless both endpoints support BUNDLE, no endpoint will use a 
>>>>>> single address:port.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> RTCP-mux and a=rtcp in those m= blocks. However, the first one if 
>>>>> you want that to support fallback that makes sense then you will 
>>>>> need both a=rtcp-mux and an a=rtcp (with a different port) to 
>>>>> handle that with optimal backwards compatibility.
>>>>> 
>>>>> would mean two ports (RTP and RTCP) for the bundle group.
>>> Yes, that was what I meant with fallback in the above text. What you 
>>> do in case the peer doesn't support bundle.
>>> 
>>>> So, at least my understanding is: no matter whether BUNDLE is used 
>>>> or not, if the answer does not contain a rtcp-mux (e.g. in case of 
>>> bunde-only group will be required to contain a=rtcp and if RTCP mux 
>>> is desired also that attribute.
>>> 
> No, I see a path of grief to not explicitly signal things when you use them. 

But, the whole idea of using port zero in bundle-only was that, if the answerer supports BUNDLE, port zero will be replaced with the negotiated address:port.

When you send the offer, you don't yet know which address:port will be selected, so there is no idea to insert a=rtcp. Inserting a=rtcp-mux probably doesn't harm, though, so I won't argue about it :)

>I also thought the a=rtcp-mux is a MUST to implement, not a MUST use.

Currently the draft says MUST use. But, that may be a mistake, or a leftover from previous procedures. I agree that one should be able to use BUNDLE also without rtcp-mux (i.e. using separate BUNDLE ports for the RTP traffic and the RTCP traffic).
 
>> Isn't a=rtcp-mux enough? If the answerer supports it, you will use it, 
>> otherwise you will use rtp+1.
>
>My understanding is that a=rtcp has been required in any non-private network deployments due to >NATs for the last 10 years. Thus, I don't see how you can remove them and expect it to work, unless >you are doing a=rtcp-mux. Thus, my view would be that you can remove a=rtcp if you know that the >peer supprots a=rtcp-mux.

Are you saying that we should use a=rtcp ONLY to indicate the RTP port, in case the answerer does not support a=rtcp-mux?
 
> That is a=rtcp-mux per RFC 5761 that has higher priority, please see Section 5.1.1.

You are right - my mistake.

But, never the less, if the offerer sends both a=rtcp-mux and a=rtcp, unless a=rtcp points to the rtp port, the offerer needs to be prepared to use 3 different ports for RTCP (rtp+1 port, rtp port and rtp+<a=rtcp value>), because it does not know which attribute (if any) the answerer supports, and which (if any) the answerer is willing to use.

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 10 Mar 2014 21:43:35 -0700

Christer said:

"BUNDLE currently mandates the usage of both the SDP rtcp-mux and rtcp
attributes. I remember we had discussions about that, but I don't remember
the justification at the moment."

[BA] The justification was that an implementation interested in
multiplexing A/V would almost certainly also want to multiplex RTP and
RTCP, because the motivation for both is minimizing port usage.

On Mon, Mar 10, 2014 at 1:24 AM, Christer Holmberg <
[email-masked]> wrote:

>  Hi,
>
>
>
> Before I comment on your proposal, let's take a few steps back (maybe it
> can even solve your issue).
>
>
>
> attributes. I remember we had discussions about that, but I don't remember
> the justification at the moment. But, I wonder whether that text is from
> before we made a decision that, unless both endpoints support BUNDLE, no
> *From:* Justin Uberti [mailto:[email-masked]]
> *Sent:* 10. maaliskuuta 2014 8:18
> *To:* [email-masked]; Eric Rescorla; Christer Holmberg
> *Subject:* BUNDLE with implicit rtcp-mux
>
>
>
> something like "force-bundle", would force the use of the same ports for
> the currently defined "max-bundle" policy, since there would be no need to
> The new "force-bundle" policy - only a single set of ports allocated -
> During the discussion, the ability to avoid RTCP port gathering was seen
> as valuable, but not the ability to avoid the fixup offer. However, after
> thinking about it a bit, I don't think that there is a viable solution that
> avoids RTCP port gathering that *doesn't* use a single set of ports. The
> So I think we the force-bundle approach is the one we want to minimize
> port gathering. The only question is whether we should keep max-bundle as
> well. To be specific, we need to decide between:
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: "Stach, Thomas" <[email-masked]>
Date: Tue, 11 Mar 2014 07:33:37 +0000

Some thoughts/proposal about the fixup inline.

In my JSEP preso during the RTCWEB session last Wednesday, I discussed adding a new BUNDLE policy to JSEP. This policy, which would be called something like “force-bundle”, would force the use of the same ports for BUNDLEd m-sections, as well as RTCP mux. When one knows a priori that the other side supports BUNDLE, this would reduce candidate gathering even over the currently defined “max-bundle” policy, since there would be no need to gather RTCP ports at all, and also avoid the need for the BUNDLE fixup offer (where the ports are updated to be the same for all BUNDLEd m-sections).
To explain the differences here, here are some example offers for an audio+video call:
Default bundle policy - separate ports for audio, video, RTP and RTCP:
m=audio 10000
a=rtcp:10001
a=rtcp-mux
m=video 11000
a=rtcp:11001
a=rtcp-mux
Existing "max-bundle" policy - video port is 0 because bundle-only, but both RTP and RTCP ports allocated for audio:
m=audio 10000
a=rtcp:10001
a=rtcp-mux
m=video 0
a=bundle-only
a=rtcp-mux
The new “force-bundle” policy - only a single set of ports allocated - audio, video, RTP, RTCP share the same port.
m=audio 10000
a=rtcp:10000
a=rtcp-mux
m=video 10000
a=rtcp:10000
a=rtcp-mux
During the discussion, the ability to avoid RTCP port gathering was seen as valuable, but not the ability to avoid the fixup offer.
[TS] The fixup is only introduced to accommodate a certain variety of middleboxes that want to see the used ports also  in the SDP offer/answer. The fixup offer is not technically necessary for the two bundle clients. They already know after the first offer/anwer cycle that usage of bundle is successfully negotiated and which port to use.
However, there is also exist situations and another variety of middleboxes for which the fixup offer/answer exchange does harm. Some of the related issues are described in draft-elwell-mmusic-ice-updated-offer, but there are more. I think that having the possibility to avoid the fixup offer/answer is a good thing. Since both scenarios mutually exclude themselves, this behavior needs to be configurable, dependent on the network environment.
Independent of the fixup being used or not,  both cases could use the same offer. With that a  new JSEP policy is not needed and things could be kept backwardcompatible. It might however be beneficial, to use an explicit indicator in the SDP that fixup is done/must be done/must not be done…
Regards
Thomas
BTW: Althought this discussion is about a new policy for JSEP, the details  are deep in the SDP territory of MMUSIC. Should it be moved there or MMUsIC made aware?
However, after thinking about it a bit, I don’t think that there is a viable solution that avoids RTCP port gathering that *doesn’t* use a single set of ports. The only other option would be to do something like this:
m=audio 10000
a=rtcp:10000 # same as m=audio port
a=rtcp-mux
m=video 0
a=bundle-only
a=rtcp-mux
but this will almost surely will result in a malfunction when talking to a non-rtcp-mux client, due to the same port being used for RTP and RTCP, and still requires the fixup offer, and as such is net worse than the force-bundle approach indicated above.
So I think we the force-bundle approach is the one we want to minimize port gathering. The only question is whether we should keep max-bundle as well. To be specific, we need to decide between:
a) Keep max-bundle as it is (separate RTP and RTCP ports allocated), and add a new force-bundle policy that creates an offer with a single port shared between all m-sections (RTP and RTCP). max-bundle remains nominally backwards compatible with non-BUNDLE/non-rtcp-mux endpoints, in that it will still send a single audio stream. force-bundle is not backwards compatible with non-BUNDLE endpoints.
b) Add force-bundle, but get rid of max-bundle.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Mar 2014 07:51:01 +0000

Hi,

"BUNDLE currently mandates the usage of both the SDP rtcp-mux and rtcp attributes. I remember we had discussions about that, but I don’t remember the justification at the moment."

[BA] The justification was that an implementation interested in multiplexing A/V would almost certainly also want to multiplex RTP and RTCP, because the motivation for both is minimizing port usage.

[Christer] So, again, the idea is to use a=rtcp to indicate the *same* port as a=rtcp-mux indicates, and hope that the receiver supports at least either a=rtcp or a=rtcp-mux?

Regards,

Christer

On Mon, Mar 10, 2014 at 1:24 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: Justin Uberti [mailto:[email-masked]<mailto:[email-masked]>]
Sent: 10. maaliskuuta 2014 8:18
To: [email-masked]<mailto:[email-masked]>; Eric Rescorla; Christer Holmberg
Subject: BUNDLE with implicit rtcp-mux

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

---

From: Justin Uberti <[email-masked]>
Date: Tue, 11 Mar 2014 21:37:33 -0700

Sort of. The idea is whether JSEP should have a mode which _gathers_ only a
single set of ports, in effect assuming the other side supports rtcp-mux.
The use of a=rtcp is incidental here, and only used to point out that the
RTP and RTCP ports that are offered will be identical.

On Tue, Mar 11, 2014 at 12:51 AM, Christer Holmberg <
[email-masked]> wrote:

> attributes. I remember we had discussions about that, but I don’t remember
> [Christer] So, again, the idea is to use a=rtcp to indicate the *same*
> port as a=rtcp-mux indicates, and hope that the receiver supports at least
> either a=rtcp or a=rtcp-mux?
>
> Regards,
>
> Christer
>
>
>
>> attributes. I remember we had discussions about that, but I don’t remember
>> but this will almost surely will result in a malfunction when talking to
>> a non-rtcp-mux client, due to the same port being used for RTP and RTCP,
>> and still requires the fixup offer, and as such is net worse than the

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Mar 2014 09:16:29 +0100

On 2014-03-10 21:09, Christer Holmberg wrote:
>>>>>>> BUNDLE currently mandates the usage of both the SDP
>>>>>>> rtcp-mux and rtcp attributes. I remember we had
>>>>>>> discussions about that, but I don't remember the
>>>>>>> justification at the moment. But, I wonder whether that
>>>>>>> text is from before we made a decision that, unless both
>>>>>>> endpoints support BUNDLE, no endpoint will use a single
>>>>>>> address:port.
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> I think it is a question of how you want the fallback to
>>>>>> work. In the case of bundle only lines, a non  bundle
>>>>>> supporting peer will reject them, thus no issues with what
>>>>>> is written around RTCP-mux and a=rtcp in those m= blocks.
>>>>>> However, the first one if you want that to support fallback
>>>>>> that makes sense then you will need both a=rtcp-mux and an
>>>>>> a=rtcp (with a different port) to handle that with optimal
>>>>>> backwards compatibility.
>>>>>> 
>>>>>> Regarding the motivation for a=rtcp-mux and a=rtcp, I think
>>>>>> it is reasonably straight forward. We want a=rtcp-mux to
>>>>>> minimize port usage, i.e. ports=1. Not supporting
>>>>>> a=rtcp-mux with bundle that would mean two ports (RTP and
>>>>>> RTCP) for the bundle group. To get the backwards
>>>>> Keep in mind that the offerer must always be prepared that
>>>>> the answerer does not support the rtcp-mux attribute (or the
>>>>> rtcp attribute).
>>>> 
>>>> Yes, that was what I meant with fallback in the above text.
>>>> What you do in case the peer doesn't support bundle.
>>>> 
>>>>> used or not, if the answer does not contain a rtcp-mux (e.g.
>>>>> in case of fallback) attribute, the offerer must use the
>>>>> default "rtp+1" port.
>>>> 
>>>> I have a tendency to agree, which means that the first m= block
>>>> in a bunde-only group will be required to contain a=rtcp and if
>>>> RTCP mux is desired also that attribute.
>>>> 
>>>> I think a=rtcp could be skipped for a bound-only m= block due
>>>> to the requirement on supporting a=rtcp-mux if you do bundle.
>>> 
>>> bundle-only will by default use whatever address:port is
>>> negotiated - both for RTP and RTCP.
>> 
> But, the whole idea of using port zero in bundle-only was that, if
> the answerer supports BUNDLE, port zero will be replaced with the
> negotiated address:port.
> 
> When you send the offer, you don't yet know which address:port will
> be selected, so there is no idea to insert a=rtcp. Inserting
> a=rtcp-mux probably doesn't harm, though, so I won't argue about it
> :)

Well, if you can't insert the port, the same applies to a=rtcp as to the
port in the m= line.

Because in the bundle-only case we are assuming and that assumption
needs to apply also for a=rtcp. And for a bundle-only case I think the
appropriate thing is to assume that a=rtcp-mux will be honored. To have
it being honored you need explicit signal it. The a=rtcp can be
considered redundant in this case, but I am sensitive to removing it as
that would create a special case for a=bundle-only lines. I think it is
better to simply include it, even if it will say a=rtcp:0

> Currently the draft says MUST use. But, that may be a mistake, or a
> leftover from previous procedures. I agree that one should be able to
> use BUNDLE also without rtcp-mux (i.e. using separate BUNDLE ports
> for the RTP traffic and the RTCP traffic).

I hope if people disagree that they shout now.

> 
>>> But, for non-bundle-only, I still ask whether we really need
>>> a=rtcp. Isn't a=rtcp-mux enough? If the answerer supports it, you
>>> will use it, otherwise you will use rtp+1.
>> 
>> My understanding is that a=rtcp has been required in any
>> non-private network deployments due to >NATs for the last 10 years.
>> Thus, I don't see how you can remove them and expect it to work,
>> unless >you are doing a=rtcp-mux. Thus, my view would be that you
>> can remove a=rtcp if you know that the >peer supprots a=rtcp-mux.
> 
> Are you saying that we should use a=rtcp ONLY to indicate the RTP
> port, in case the answerer does not support a=rtcp-mux?

It has its normal usage, i.e. RTCP port in cases when a=rtcp-mux is not
agreed on. In a bundle-only offer, I think the only reasonable approach
is to handle it identically to the m= line port number.

>>> a=rtcp-mux. Which has higher "priority"? How does the answerer
>>> knows whether the offerer wants to use rtcp-mux, or whether it
>>> wants to use whatever port is indicated in a=rtcp?
>> 
> But, never the less, if the offerer sends both a=rtcp-mux and a=rtcp,
> unless a=rtcp points to the rtp port, the offerer needs to be
> prepared to use 3 different ports for RTCP (rtp+1 port, rtp port and
> rtp+<a=rtcp value>), because it does not know which attribute (if
> any) the answerer supports, and which (if any) the answerer is
> willing to use.

This is actually not necessary, if one can get the rtp+1 port for RTCP,
then include that in the a=rtcp line and everything is fine.

I was under the impression that almost all SIP SDP O/A was using a=rtcp.
But if that is a misunderstanding from my perspective, I still think the
rules will hold. If you don't include the a=rtcp attribute, then the
rtp+1 port is the equivalent of the a=rtcp value.

>From a bundle perspective, I think what needs to be considered is the
actual or implied values on the m= blocks for the rtcp port when using
bundle-only as well as the other case.

Cheers

Magnus Westerlund
(As individual)

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Mar 2014 08:47:10 +0000

Hi,

>> But, the whole idea of using port zero in bundle-only was that, if the 
>> answerer supports BUNDLE, port zero will be replaced with the 
>> negotiated address:port.
>> 
>> When you send the offer, you don't yet know which address:port will be 
>> selected, so there is no idea to insert a=rtcp. Inserting a=rtcp-mux 
>> probably doesn't harm, though, so I won't argue about it
>> :)
>
> Well, if you can't insert the port, the same applies to a=rtcp as to the port in the m= line.

Exactly. 

The bundle-only m- lines will "inherit" the port that is selected for the whole BUNDLE group.

> Because in the bundle-only case we are assuming and that assumption needs to apply also for a=rtcp. And for a bundle-only case 
> I think the appropriate thing is to assume that a=rtcp-mux will be honored. To have it being honored you need explicit signal it. 

Sure. But, the important thing is to include a=rtcp-mux in the m- line that will be used for selecting the BUNDLE address. That will determine whether rtcp-mux will be used or not.

> The a=rtcp can be considered redundant in this case, but I am sensitive to removing it as that would create a special case for a=bundle-only lines. I think it is better to simply include it, even if it will say a=rtcp:0

We can do that, if people think it's a good idea.

>> use BUNDLE also without rtcp-mux (i.e. using separate BUNDLE ports for 
>> the RTP traffic and the RTCP traffic).
>

And shout loud :)

>>> network deployments due to >NATs for the last 10 years.
>>> unless >you are doing a=rtcp-mux. Thus, my view would be that you can 
>>> remove a=rtcp if you know that the >peer supprots a=rtcp-mux.
>> 
> It has its normal usage, i.e. RTCP port in cases when a=rtcp-mux is not agreed on. In a bundle-only offer, I think the only reasonable approach is to handle it identically to the m= line port number.

I don't know what you mean by "bundle-only offer". There must exist at least one non-bundle-only m- line in an offer, in order to indicate the port value. And, whatever a=rtcp value is used in that m- line will also be applied to the bundle-only m- lines is the BUNDLE group is accepted.
 
>>>> whether the offerer wants to use rtcp-mux, or whether it wants to 
>>>> use whatever port is indicated in a=rtcp?
>>> 
>> unless a=rtcp points to the rtp port, the offerer needs to be prepared 
>> to use 3 different ports for RTCP (rtp+1 port, rtp port and
>> any) the answerer supports, and which (if any) the answerer is willing 
>> to use.
>
> This is actually not necessary, if one can get the rtp+1 port for RTCP, then include that in the a=rtcp line and everything is fine.
>
> But if that is a misunderstanding from my perspective, I still think the rules will hold. If you don't include the a=rtcp attribute, then the
> From a bundle perspective, I think what needs to be considered is the actual or implied values on the m= blocks for the rtcp port when using bundle-only as well as the other case.

It may be that we agree, but talk past each other :)

My understanding of bundle-only has been that it is a mechanism to ensure that the m- line is accepted only if the BUNDLE group is accepted, e.g. in order to avoid having to reserve extra ports. BUT, the bundle-only m- lines are NOT used to negotiate the actual BUNDLE address - they will inherit the selected BUNDLE address, negotiated using non-bundle-only m- lines.

Regards,

Christer

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 12 Mar 2014 10:04:27 +0100

On 2014-03-12 09:47, Christer Holmberg wrote:
> My understanding of bundle-only has been that it is a mechanism to
> ensure that the m- line is accepted only if the BUNDLE group is
> accepted, e.g. in order to avoid having to reserve extra ports. BUT,
> the bundle-only m- lines are NOT used to negotiate the actual BUNDLE
> address - they will inherit the selected BUNDLE address, negotiated
> using non-bundle-only m- lines.
> 

I think we are agreeing. I think my main point is that the m= blocks
that contains bundle-only needs to contain the attribute a=rtcp-mux if
that is included in the first m= block for the bundle group that
contains the actual addresses. Similar with the a=rtcp attribute. Simply
to be explicit that they are configured similarly. This I think implies
that we need a "to be replaced" value also for a=rtcp in the bundle only
m= blocks.

Cheers

Magnus Westerlund

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 12 Mar 2014 09:13:45 +0000

Hi,

> I think we are agreeing. I think my main point is that the m= blocks that contains bundle-only needs to contain the attribute a=rtcp-mux if that is included in the first m= block for the bundle group that contains the actual addresses. 
> Similar with the a=rtcp attribute. Simply to be explicit that they are configured similarly. 

Correct.

> This I think implies that we need a "to be replaced" value also for a=rtcp in the bundle only m= blocks.

Yes.

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Wed, 12 Mar 2014 09:13:54 -0700

> I hope if people disagree that they shout now.

I think rtcp-mux has to be a MUST use when BUNDLE is used between the two
endpoints. (If the endpoint doesn't support BUNDLE, rtcp-mux is not
required.)

Otherwise, you get into weird edge cases, such as where you have a data
channel (no RTCP component), and then want to add audio (with RTP and RTCP
components). You could bundle the audio RTP over the existing data channel
transport, but it's not clear what you should do with the RTCP component.
Mandating rtcp-mux avoids this issue completely.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Mar 2014 19:14:30 -0400

> Currently the draft says MUST use. But, that may be a mistake, or a leftover from previous procedures. I agree that one should be able to use BUNDLE also without rtcp-mux (i.e. using separate BUNDL…

Now that I look carefully, I think you have been a little over zealous 
about this.

Remember, at least in principle, there can be non-RTP m-lines in the 
bundle. You don't want to require using rtcp-mux with those. (And, at 
least in principle, bundle can be used even when there are *no* RTP 
m-lines.)

So I think the draft must at least limit these requirements to RTP 
m-lines. (But finding a clean way to do that may be tricky, since there 
is a potentially open ended set of <proto> values that relate to RTP.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Mar 2014 07:38:34 +0000

Hi,

>> Currently the draft says MUST use. But, that may be a mistake, or a leftover from previous procedures. I agree that one should be 
>> able to use BUNDLE also without rtcp-mux (i.e. using separate BUNDLE ports for the RTP traffic and the RTCP traffic).
>
> Now that I look carefully, I think you have been a little over zealous about this.
>
> Remember, at least in principle, there can be non-RTP m-lines in the bundle. You don't want to require using rtcp-mux with 
> those. (And, at least in principle, bundle can be used even when there are *no* RTP
> m-lines.)
>
> So I think the draft must at least limit these requirements to RTP m-lines. (But finding a clean way to do that may be tricky, since there is a potentially open ended set of <proto> values that relate to RTP.)

I think it is enough if we limit it to protocols for which the rtcp-mux attribute has been defined. I don't think it's up to BUNDLE to generally define for which type of m- lines rtcp-mux can be used, only the (if any) BUNDLE specific aspects.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 13 Mar 2014 12:52:39 +0000

Hi Justin,

> I think rtcp-mux has to be a MUST use when BUNDLE is used between the two endpoints. (If the endpoint doesn't support 
> BUNDLE, rtcp-mux is not required.)
>
> Otherwise, you get into weird edge cases, such as where you have a data channel (no RTCP component), and then want 
> to add audio (with RTP and RTCP components). You could bundle the audio RTP over the existing data channel transport, 
> but it's not clear what you should do with the RTCP component. Mandating rtcp-mux avoids this issue completely.

According to section 4 in RFC 5761, if you multiplex RTP and RTCP on the same port, you need to assign dedicated PT values to the RTCP packets, which means that at least PT values 64-95 cannot be used for RTP.

As you have been one of those talking about the risk of running out of PT values, I just want to make sure you have taken this into consideration :)

Regards,

Christer

---

From: Justin Uberti <[email-masked]>
Date: Thu, 13 Mar 2014 09:16:57 -0700

On Thu, Mar 13, 2014 at 5:52 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi Justin,
>
> > I think rtcp-mux has to be a MUST use when BUNDLE is used between the
> two endpoints. (If the endpoint doesn't support
> channel (no RTCP component), and then want
> > to add audio (with RTP and RTCP components). You could bundle the audio
> RTP over the existing data channel transport,
> According to section 4 in RFC 5761, if you multiplex RTP and RTCP on the
> same port, you need to assign dedicated PT values to the RTCP packets,
> which means that at least PT values 64-95 cannot be used for RTP.
>
> As you have been one of those talking about the risk of running out of PT
> values, I just want to make sure you have taken this into consideration :)
>
>
Yes. The upside of rtcp-mux far outweighs this minor limitation.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Mar 2014 05:56:38 +0000

Hi,

Just to clarify: you would still use the a=rtcp-mux attribute, right?

It is e.g. needed to inform intermediaries (that may not understand BUNDLE) about the usage of RTCP mux.

Regards,

Christer

Sent from my Sony Ericsson Xperia arc S

Justin Uberti <[email-masked]> wrote:

On Thu, Mar 13, 2014 at 5:52 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Justin,

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 14 Mar 2014 09:57:25 +0100

Hi,
(as individual)

Although this discussion really should be on MMUSIC, I am still
following up here. Anything we come to conclude here really need to go
to MMUSIC for confirmation.

Justin, I do agree that it appear unnecessarily of having to include an
RTCP transport in an OFFER when the offerer know the answerer is BUNDLE
capable. I am fine with that and think the rule needed here is something
along the line of the below:

A BUNDLE supporting endpoint MUST implement a=rtcp-mux (that is already
required). In any answer by a BUNDLE capable endpoint, it MUST NOT
change the usage of a=rtcp-mux. If it is present in the offer, it must
be confirmed to be used in the answer, and if not present in the offer,
it MUST NOT be added in the answer. An BUNDLE capable endpoint is
RECOMMENDED to use a=rtcp-mux whenever suitable. Cases when it might not
be suitable include, lack RTP payload types, or cases when RTCP traffic
is needed to be on its own transport flow (5-tuple) to enable QoS or
other traffic handling functionalities.

The reason for writing the rule like the above, is that then an endpoint
can choose when creating an offer to renegotiate the use of a=rtcp-mux.
For example due to it running out of available PTs.

Feedback on this proposal?

Cheers

Magnus Westerlund

---

From: Justin Uberti <[email-masked]>
Date: Fri, 14 Mar 2014 09:26:10 -0700

> Feedback on this proposal?

I am not OK with this. It just gets too complicated to deal with all the
cases, especially if with the provision that rtcp-mux can change during the
session.

I think Christer's current language is what we want - if you are going to
BUNDLE, you MUST also use rtcp-mux for any RTP m-lines. If the answerer
cannot do that, it needs to reject the BUNDLE.

I agree with your initial point though - if you know that both sides are
going to BUNDLE and rtcp-mux, it makes sense to allow them to do that from
the outset, i.e. no need to include a RTCP transport in the offer.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Mar 2014 16:30:36 +0000

Hi Justin,

What do you mean by "RTCP transport in the offer"? Are you referring to the a=rtcp attribute, or?

Even if we mandate rtcp-mux within a BUNDLE group, the a=rtcp-mux attribute must still always be present - even if you know the remote endpoint supports rtcp-mux (or, even if you have already negotiated usage of rtcp-mux).

Regards,

Christer
________________________________________
From: Justin Uberti [[email-masked]]
Sent: Friday, 14 March 2014 6:26 PM
To: Magnus Westerlund
Cc: Christer Holmberg; [email-masked]; Eric Rescorla
Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux

On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
(as individual)

I am not OK with this. It just gets too complicated to deal with all the cases, especially if with the provision that rtcp-mux can change during the session.

I think Christer's current language is what we want - if you are going to BUNDLE, you MUST also use rtcp-mux for any RTP m-lines. If the answerer cannot do that, it needs to reject the BUNDLE.

I agree with your initial point though - if you know that both sides are going to BUNDLE and rtcp-mux, it makes sense to allow them to do that from the outset, i.e. no need to include a RTCP transport in the offer.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 14 Mar 2014 09:46:27 -0700

By "RTCP transport in the offer", I mean separate ICE candidates generated
for a RTCP ICE component, the original problem that I was proposing to
solve.

I agree the rtcp-mux attribute must always be present if you are going to
do rtcp-mux.

On Fri, Mar 14, 2014 at 9:30 AM, Christer Holmberg <
[email-masked]> wrote:

> Even if we mandate rtcp-mux within a BUNDLE group, the a=rtcp-mux
> attribute must still always be present - even if you know the remote
> endpoint supports rtcp-mux (or, even if you have already negotiated usage
> of rtcp-mux).
>
> Regards,
>
> Christer
> [email-masked]<mailto:[email-masked]>>
> wrote:
> Hi,
> (as individual)
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Mar 2014 17:40:28 +0000

Hi,

> By "RTCP transport in the offer", I mean separate ICE candidates generated for a RTCP ICE component, the original problem that I was proposing to solve.

Ok.

But, again, we do have a decision that we are not going to specify procedures based on pre-knoweldge of BUNDLE support by the answerer. Or, at least that was the outcome in London, I guess it still has to be verified on the list.

> I agree the rtcp-mux attribute must always be present if you are going to do rtcp-mux.

Good :)

Regards,

Christer

On Fri, Mar 14, 2014 at 9:30 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi Justin,

Regards,

Christer
________________________________________
From: Justin Uberti [[email-masked]<mailto:[email-masked]>]
Sent: Friday, 14 March 2014 6:26 PM
To: Magnus Westerlund
Cc: Christer Holmberg; [email-masked]<mailto:[email-masked]>; Eric Rescorla
Subject: Re: [rtcweb] BUNDLE with implicit rtcp-mux

On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund <[email-masked]<mailto:[email-masked]><mailto:[email-masked]<mailto:[email-masked]>>> wrote:
Hi,
(as individual)

---

From: Justin Uberti <[email-masked]>
Date: Fri, 14 Mar 2014 11:14:23 -0700

On Fri, Mar 14, 2014 at 10:40 AM, Christer Holmberg <
[email-masked]> wrote:

>
> Hi,
>
> > By "RTCP transport in the offer", I mean separate ICE candidates
> generated for a RTCP ICE component, the original problem that I was
> proposing to solve.
>
> Ok.
>
> But, again, we do have a decision that we are not going to specify
> procedures based on pre-knoweldge of BUNDLE support by the answerer. Or, at
> least that was the outcome in London, I guess it still has to be verified
> on the list.
>

???

I was there and I don't recall this decision; I spent half an hour
discussing this exact point in rtcweb based on a scenario you suggested
(namely, a new PC created from a fork). The discussion ended with some
interest but no consensus, which is why we are discussing it here in
email...

For sanity's sake, can you make it clear that you support this proposal?

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 14 Mar 2014 18:34:23 +0000

Hi,

> I was there and I don't recall this decision; I spent half an hour discussing this exact point in rtcweb based on a scenario you suggested (namely, a new PC created from a fork). The discussion ended with some interest but no consensus, which is why we are discussing it here in email...

Ok. My recall was that there was no support to do the "optimization" forking, i.e. allowing identical port values (and, in this case, also rtcp-mux) already in the initial offer for a PC, and therefor we were not going to do it. 

I'm glad if I'm wrong :)

> For sanity's sake, can you make it clear that you support this proposal?

Yes, I do.

Regards,

Christer

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 17 Mar 2014 14:23:30 +0100

On 2014-03-14 17:26, Justin Uberti wrote:
> 
> 
> 
> On Fri, Mar 14, 2014 at 1:57 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
>     Hi,
>     (as individual)
> 
> cases, especially if with the provision that rtcp-mux can change during
> the session.

(still as individual)

Lets be clear what we are discussing here. I don't think this is lot of
cases. And if you don't want to implement this in your code generating
offer, that is fine. What this describes is that your code handling
reception of offers and generating answers must be able to handle the
lack of a=rtcp-mux in any offer, rather than just the initial one.

I would question if even that assumption holds considering what happens
if people start implementing session resumption or session mobility
between devices using rehydration style establishment procedures. What
one sides consider an initial offer might not be the state the answering
party is in. Thus, I am worried about cases that are first offer/answer
exchange related.

To my understanding you will have code to handle the following cases
when offers contains:

1) No bundle, no a=rtcp-mux
2) No bundle, with a=rtcp-mux
3) Bundle, with a=rtcp-mux

Considering that you support bundle, and you support usage or not of
a=rtcp-mux. Then I don't see how the code handling the SDP logic for
Bundle, without a=rtcp-mux is that significant.

First of all, to be robust, you have to be capable of handling
significant reconfigurations of the Peer Connection session in an Offer.
If someone moves the peer of one peer connection to another device
anything can happen, and everything can change.

Secondly, to be able to turn off a=rtcp-mux is one method which can free
up PTs if one run out. The other would be first unbundle the media
types, then to completely unbundle the media sources. The later would be
far worse when it comes to requiring providing ICE candidates and
dealing with new transports. I however think unbundling the media types
is likely to resolve many of the PT shortage situations.

Just to confirm, you are also against allowing any initial offer request
with bundle but without a=rtcp-mux within that bundle-group?

This, I would question, as it prevents anyone from treating the RTCP
packets differently from the RTP packets within one RTP session. I know
that this has been done in some cases, including IMS.

>From a principal point of view I think this should be either be use of
BUNDLE groups results in MUST use a=rtcp-mux with RTP or that any offer
may change the usage of a=rtcp-mux. Anything else depending on initial
offer appears very messy and prone to errors.

I would appreciate if someone else would provide their input and views
here!

First on the question if they need to separate the RTP and RTCP at all
within a BUNDLE group?

Secondly if they see that splitting a bundle group into different groups
if one runs into issue is a sufficient and more preferred method for
dealing with any PT exhaustion issue?

Cheers

Magnus Westerlund

---

From: Justin Uberti <[email-masked]>
Date: Wed, 19 Mar 2014 17:21:05 -0700

> Bundle, without a=rtcp-mux is that significant.

It is significant because you always know you can rtcp-mux. And you always
know you can BUNDLE when rtcp-muxing. But I think trying to BUNDLE a
no-rtcp-mux m= line into a rtcp-mux m= line is asking for problems.

> with bundle but without a=rtcp-mux within that bundle-group?

I am against _any_ offer request with bundle and without a=rtcp-mux (as
indicated in the current bundle draft).

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 20 Mar 2014 10:36:37 +0100

Please see inline.

This is as an individual!

On 2014-03-20 01:21, Justin Uberti wrote:

> On Mon, Mar 17, 2014 at 6:23 AM, Magnus Westerlund

> It is significant because you always know you can rtcp-mux. And you
> always know you can BUNDLE when rtcp-muxing. But I think trying to
> BUNDLE a no-rtcp-mux m= line into a rtcp-mux m= line is asking for
> problems. 

To be clear, I am arguing for consistent behavior and usage across the
whole bundle group. Certainly you MUST NOT be allowed to have some m=
line for RTP to use a=rtcp-mux and some other m= line in the same bundle
group to not use it.

What I am considering is the possibility to have a bundle group with
multiple m= RTP lines that do not use a=rtcp-mux and instead have RTCP
over a separate port.

I started arguing that this was important for being able to recover PT
space. But there is actually another reason for this. In cases when you
have QoS, for example in cellular environment, mandating the use of
rtcp-mux forces one to send the RTCP over the expensive QoS bearer. The
amount of RTCP to support adaptation as well as codec control means that
it is still likely that you want to spend at least 5% of the Video
bandwidth on RTCP. If the cost associated with providing QoS for video
can be reduced by 3-5% we in the cellular business definitely like to be
able to utilize it.

I would also like to stress that we are discussing what BUNDLE enables.
RTCWEB is the first user of bundle, but likely not the only one. We have
to be careful to apply all WebRTC context specific limitations on a
general mechanism.

First of all I really like to see that BUNDLE does not restrict ones
choices if one like to multiplex RTP or RTCP when doing BUNDLE. As a
general IETF SDP Signaling mechanism we need this generality.

Secondly, I would strongly prefer that also RTCWEB's specifications do
support this mode of operation.

Cheers

Magnus Westerlund