Subject: [MMUSIC] BUNDLE and RTCP

From: Christer Holmberg <[email-masked]>
Date: Sun, 18 Oct 2015 17:46:49 +0000

Hi,

During the proto write-up process of BUNDLE, an issue came up.

Assume the following BUNDLE offer, with one non-bundle-only data channel m- line and one bundle-only RTP m- line:

m=data channel 10000
m=rtp 0
a=bundle-only

Now, if bundle is accepted, the RTP m- line will get port 10000, as defined in BUNDLE. So far so good.

Now, if bundle is accepted, the data channel m- line will be selected as the offerer BUNDLE address, and RTP will use port 1000.

So far so good.

Next, assume we want to negotiate an explicit RTCP port for RTP. As the non-bundle-only m- line is not RTP (and therefore cannot contain an rtcp attribute), we have to add the actual RTCP port value to the bundle-only m- line:

m=data channel 10000
m=rtp 0
a=bundle-only
a=rtcp: 20000

So far so good.

Now, assume we also have one non-bundle-only RTP m- line:

m=data channel 10000
m=rtp 11111
a=rtcp: 15000
m=rtp 0
a=bundle-only
a=rtcp: 20000

Now, assume the data channel m- line is selected as the offerer BUNDLE address. It means that port 10000 will also be used for RTP. But, which port will be used for RTCP? 15000 or 20000?

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 18 Oct 2015 17:53:15 +0000

Hi,

Note that the issue exists even without bundle-only m- lines:

m=data channel 10000
m=rtp 11111
a=rtcp: 15000
m=rtp 11222
a=rtcp: 20000

Again, if the data channel m-  line is selected as the offerer BUNDLE address, which port will be used for RTCP?

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 18 October 2015 20:47
To: [email-masked]
Subject: [MMUSIC] BUNDLE and RTCP

Hi,

m=data channel 10000
m=rtp 0
a=bundle-only

So far so good.

m=data channel 10000
m=rtp 0
a=bundle-only
a=rtcp: 20000

So far so good.

m=data channel 10000
m=rtp 11111
a=rtcp: 15000
m=rtp 0
a=bundle-only
a=rtcp: 20000

Regards,

Christer

---

From: Thomas Stach <[email-masked]>
Date: Mon, 19 Oct 2015 07:50:14 +0200

Christer,

of course there are many possibilities.
However it would be good to have some explicit signalling.
Without inventing new signalling elements, you could use the first RTP 
m-line that appears in the   a=group:BUNDLE attribute in the answer.

So if you have in the offer:

a=group:BUNDLE foo bar baz
m=data channel 10000
a=mid:foo
m=rtp 11111
a=mid:bar
a=rtcp: 15000
m=rtp 11222
a=mid:baz
a=rtcp: 20000

If you get back in the answer:

a=group:BUNDLE foo bar baz
...
then your RTCP port is 15000
If you get back a=group:BUNDLE foo baz bar then RTCP would go to 20000.

Although I haven't thought it through completely it too much this could 
also work reasonably well of the answerer accepts only a subset of the 
offered m-lines.

What do yo think?

Regards
Thomas

Am 18.10.2015 um 19:53 schrieb Christer Holmberg:
> Again, if the data channel m-  line is selected as the offerer BUNDLE 
> address, which port will be used for RTCP?
>
> Regards,
>
> Christer
>
> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *Christer 
> Holmberg
> *Sent:* 18 October 2015 20:47
> *To:* [email-masked]
> *Subject:* [MMUSIC] BUNDLE and RTCP
>
> Hi,
>
> Assume the following BUNDLE offer, with one non-bundle-only data 
> channel m- line and one bundle-only RTP m- line:
>
> m=data channel 10000
>
> m=rtp 0
>
> a=bundle-only
>
> Now, if bundle is accepted, the data channel m- line will be selected 
> as the offerer BUNDLE address, and RTP will use port 1000.
>
> So far so good.
>
> Next, assume we want to negotiate an explicit RTCP port for RTP. As 
> the non-bundle-only m- line is not RTP (and therefore cannot contain 
> an rtcp attribute), we have to add the actual RTCP port value to the 
> bundle-only m- line:
>
> m=data channel 10000
>
> m=rtp 0
>
> a=bundle-only
>
> a=rtcp: 20000
>
> So far so good.
>
> Now, assume the data channel m- line is selected as the offerer BUNDLE 
> address. It means that port 10000 will also be used for RTP. But, 
> which port will be used for RTCP? 15000 or 20000?
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Oct 2015 06:41:48 +0000

Hi Thomas,

>Without inventing new signalling elements, you could use the first RTP m-line that appears in the   a=group:BUNDLE attribute in the answer.
>
>Although I haven't thought it through completely it too much this could also work reasonably well of the answerer accepts only a subset of the offered m-lines.
>
>What do yo think?

I am sure we COULD do something like that. I also have some ideas, but I think they are all too hacky and/or complex for what we would gain.
HOWEVER, we could make it SIMPLE and either:

1)      Mandate usage of rtcp-mux with BUNDLE. I.e. if BUNDLE is negotiated, rtcp-mux MUST be used.
This was already suggested in the past, but Paul(?) said we should not make such restriction without a good reason. I think the current issue is a good reason :)
             m=data channel 10000
m=rtp 11111
a=rtcp-mux
m=rtp 11222
a=rtcp-mux

2)      Mandate usage of either rtcp-mux OR the default "+1" port with BUNDLE. I.e. if BUNDLE is negotiated, rtcp-mux or "+1" MUST be used. The selection is based on whether the rtcp-mux attribute was included in the offer/answer or not.
m=data channel 10000             // rtcp-mux
m=rtp 11111
a=rtcp-mux
m=rtp 11222
a=rtcp-mux

m=data channel 10000             // "+1"
m=rtp 11111
m=rtp 11222

The solutions above would not allow explicit negotiation of an RTCP port when BUNDLE is used, but maybe we could live with that?
Now, if we can agree on a way forward before Yokohama, you won't have to sit listening to me talking about BUNDLE at the meeting :)
Regards,
Christer

m=data channel 10000
m=rtp 11111
a=rtcp: 15000
m=rtp 11222
a=rtcp: 20000

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 18 October 2015 20:47
To: [email-masked]<mailto:[email-masked]>
Subject: [MMUSIC] BUNDLE and RTCP

Hi,

m=data channel 10000
m=rtp 0
a=bundle-only

So far so good.

m=data channel 10000
m=rtp 0
a=bundle-only
a=rtcp: 20000

So far so good.

m=data channel 10000
m=rtp 11111
a=rtcp: 15000
m=rtp 0
a=bundle-only
a=rtcp: 20000

Regards,

Christer

mmusic mailing list

[email-masked]<mailto:[email-masked]>

---

From: Thomas Stach <[email-masked]>
Date: Mon, 19 Oct 2015 09:04:29 +0200

Christer,

Am 19.10.2015 um 08:41 schrieb Christer Holmberg:
> >Although I haven't thought it through completely it too much this 
> could also work reasonably well of the answerer accepts only a subset 
> of the offered m-lines.
> >
> >What do yo think?
>
> I am sure we COULD do something like that. I also have some ideas, but 
> I think they are all too hacky and/or complex for what we would gain.
>
> 1)*Mandate usage of rtcp-mux with BUNDLE*. I.e. if BUNDLE is 
> negotiated, rtcp-mux MUST be used.
>
> This was already suggested in the past, but Paul(?) said we should not 
> make such restriction without a good reason. I think the current issue 
> is a good reason :)
>
> m=data channel 10000
>
> m=rtp 11111
>
> a=rtcp-mux
>
> m=rtp 11222
>
> a=rtcp-mux
>
> 2)*Mandate usage of either rtcp-mux OR the default “+1” port with 
> BUNDLE*. I.e. if BUNDLE is negotiated, rtcp-mux or “+1” MUST be used. 
> The selection is based on whether the rtcp-mux attribute was included 
> in the offer/answer or not.
>
> m=data channel 10000             // “+1”
>
> m=rtp 11111
>
> m=rtp 11222
>
> The solutions above would not allow explicit negotiation of an RTCP 
> port when BUNDLE is used, but maybe we could live with that?
>
Well, I could live with both of your suggestions, but I thought you 
wanted a solution that can also negotiate which a=rtcp attribute to use.
If nobody really needs something like that , I would prefer 1) as it 
removes the needs for several implementation option that would only be 
needed to cover full backwards compatibility but would hardly be used.
>
> Now, if we can agree on a way forward before Yokohama, you won’t have 
> to sit listening to me talking about BUNDLE at the meeting :)
>
Well, I wouldn't be sitting there anyhow but understand that your 
motivation to speak there about BUNDLE again is probably limited.
Regards
Thomas
>     Again, if the data channel m-  line is selected as the offerer
>     BUNDLE address, which port will be used for RTCP?
>
>     Regards,
>
>     Christer
>
>     *From:*mmusic [mailto:[email-masked]] *On Behalf Of
>     *Christer Holmberg
>     *To:* [email-masked] <mailto:[email-masked]>
>     Now, if bundle is accepted, the data channel m- line will be
>     selected as the offerer BUNDLE address, and RTP will use port 1000.
>
>     So far so good.
>
>     Next, assume we want to negotiate an explicit RTCP port for RTP.
>     As the non-bundle-only m- line is not RTP (and therefore cannot
>     contain an rtcp attribute), we have to add the actual RTCP port
>     value to the bundle-only m- line:
>
>     m=data channel 10000
>
>     m=rtp 0
>
>     a=bundle-only
>
>     a=rtcp: 20000
>
>     So far so good.
>
>     Now, assume the data channel m- line is selected as the offerer
>     BUNDLE address. It means that port 10000 will also be used for
>     RTP. But, which port will be used for RTCP? 15000 or 20000?
>
>     Regards,
>
>     Christer
>
>
>
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Oct 2015 07:35:12 +0000

Hi,

...
...
...

>Well, I could live with both of your suggestions, but I thought you wanted a solution that can also negotiate which a=rtcp attribute to use.

>If nobody really needs something like that , I would prefer 1) as it removes the needs for several implementation option that would only be needed to cover full backwards compatibility but would hardly be used.

Personally I don't have a strong preference, but as far as I know there may be environments where separate ports for RTP and RTCP are desired - even if BUNDLE is used.

>Well, I wouldn't be sitting there anyhow but understand that your motivation to speak there about BUNDLE again is probably limited.
I don't mind talking about BUNDLE - but I'd like to talk about it in the context of the great RFC that we have published :)
Regards,
Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Oct 2015 10:22:20 -0400

Good discussion.

How about the following:

If there is an RTP m-line in the bundle, and rtcp-mux is *not* 
negotiated, then the rtcp port is determined according to the rules for 
the first m-line selected in the bundle group. If *that* line has, and 
allows, an a=rtcp, then that is used. If that line doesn't have a=rtcp, 
then port+1 is used, even if this isn't an rtp m-line.

(Right now there isn't any way to have a bundle group with more than one 
non-rtp m-line, but that might not always be so.)

	Thanks,
	Paul

On 10/19/15 3:35 AM, Christer Holmberg wrote:
>     This was already suggested in the past, but Paul(?) said we should
>     not make such restriction without a good reason. I think the current
>     issue is a good reason :)
>
>     m=data channel 10000
>
>     m=rtp 11111
>
>     a=rtcp-mux
>
>     m=rtp 11222
>
>     a=rtcp-mux
>
>     BUNDLE*. I.e. if BUNDLE is negotiated, rtcp-mux or “+1” MUST be
>     used. The selection is based on whether the rtcp-mux attribute was
>     included in the offer/answer or not.
>
> Personally I don’t have a strong preference, but as far as I know there
> may be environments where separate ports for RTP and RTCP are desired –
> even if BUNDLE is used.
>
>>>Now, if we can agree on a way forward before Yokohama, you won’t have to
> sit listening to me talking about BUNDLE at the meeting :)
>>
> I don’t mind talking about BUNDLE – but I’d like to talk about it in the
> context of the great RFC that we have published :)
>
> Regards,
>
> Christer
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Oct 2015 16:40:43 +0000

Hi,

> Good discussion.
>
> How about the following:
>
> If there is an RTP m-line in the bundle, and rtcp-mux is *not* negotiated, then the rtcp port is determined according to the rules
> for the first m-line selected in the bundle group. If *that* line has, and allows, an a=rtcp, then that is used. If that line doesn't have 
> a=rtcp, then port+1 is used, even if this isn't an rtp m-line.

Sure. But, as the offerer doesn't know for sure which m- line will be selected, it always has to be prepared to use port+1, so why not use port+1 to begin with? 

I guess my question is whether someone really needs a=rtcp with BUNDLE? As far as I know, most current implementations do rtcp-mux, and for those that don't/can't there is always port+1. 

> (Right now there isn't any way to have a bundle group with more than one non-rtp m-line, but that might not always be so.)

Correct.

Regards,

Christer

On 10/19/15 3:35 AM, Christer Holmberg wrote:
>     2)*Mandate usage of either rtcp-mux OR the default "+1" port with
>     BUNDLE*. I.e. if BUNDLE is negotiated, rtcp-mux or "+1" MUST be
> Personally I don't have a strong preference, but as far as I know 
> there may be environments where separate ports for RTP and RTCP are 
> desired - even if BUNDLE is used.
>
>>>Now, if we can agree on a way forward before Yokohama, you won't have 
>>>to
> I don't mind talking about BUNDLE - but I'd like to talk about it in 
> the context of the great RFC that we have published :)
>
> Regards,
>
> Christer
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Oct 2015 13:06:03 -0400

> I guess my question is whether someone really needs a=rtcp with BUNDLE? As far as I know, most current implementations do rtcp-mux, and for those that don't/can't there is always port+1.

IIRC the original reason for a=rtcp was because there are cases when it 
is hard to get an even/odd pair of ports. If the offerer is in that 
situation, then mandating port+1 isn't going to work.

I am coming around to agree with just requiring rtcp-mux with bundle.
I don't unsderstand why RTCP was *ever* defined to run on a separate 
port. Maybe it was just a mistake.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 19 Oct 2015 17:48:42 +0000

Hi,

>>> negotiated, then the rtcp port is determined according to the rules 
>>> for the first m-line selected in the bundle group. If *that* line has, and allows, an a=rtcp, then that is used. If that line doesn't have a=rtcp, then port+1 is used, even if this isn't an rtp m-line.
>>
> IIRC the original reason for a=rtcp was because there are cases when it is hard to get an even/odd pair of ports. If the offerer is in that situation, then mandating port+1 isn't going to work.

Ok. So, I guess one question is whether such situations still can occur.

> I don't unsderstand why RTCP was *ever* defined to run on a separate port. Maybe it was just a mistake.

As far as I know, some people still wish to be able to use separate ports for RTP and RTCP, even when using BUNDLE. I'd like to know whether port+1 works for them.

Regards,

Christer

>> (Right now there isn't any way to have a bundle group with more than 
>> one non-rtp m-line, but that might not always be so.)
>
> Correct.
>
> Regards,
>
> Christer
>
>
>
>> removes the needs for several implementation option that would only 
>> be needed to cover full backwards compatibility but would hardly be used.
>>
>>>> Now, if we can agree on a way forward before Yokohama, you won't 
>>>> have to

---

From: Roman Shpount <[email-masked]>
Date: Mon, 19 Oct 2015 14:13:33 -0400

> Ok. So, I guess one question is whether such situations still can occur.

This situation will occur if you are using BUNDLE with server reflexive
ports from behind NAT without ICE and rtcp-mux. Typically client allocates
two subsequent ports for RTP/RTCP, does STUN requests to determine the
server reflexive address/port and ends up with two non-sequential ports.

> As far as I know, some people still wish to be able to use separate ports
> for RTP and RTCP, even when using BUNDLE. I'd like to know whether port+1
> works for them.

I think some people really wanted non-rtcp-mux together with BUNDLE to
simplify implementation of RTP forwarders that bridge BUNDLE and non-BUNDLE
implementations for cases when RTP payload collides with RTCP.

<sarcasm>Having a non-ICE device behind NAT which is doing non-BUNDLE to
BUNDLE RTP forwarding would be fairly strange, but I am sure someone would
eventually decide that they need a corporate SBC which works exactly like
this.</sarcasm>
______________
Roman Shpount

---

From: "Wyss, Felix" <[email-masked]>
Date: Mon, 19 Oct 2015 18:31:29 +0000

IMHO having a separate port for RTCP is such a pain in general and with ICE in particular that we really should just mandate RTP/RTCP muxing for any new RFCs.  In particular anything that legacy equipment won't ever support anyway.  As a separate port for RTCP does involve considerable additional complexity and cost in development and testing to support, there has to be tangible ROI for it as a feature.  I'd say those who want to keep the separate port (be it RTP+1 or through a=rtcp) need to justify why the added complexity is worth it.  I also agree with Paul that the separate port for RTCP was a mistake in the original design--at least in hindsight :-)

Thanks,
--Felix

________________________________________
From: mmusic <[email-masked]> on behalf of Christer Holmberg <[email-masked]>
Sent: Monday, October 19, 2015 13:48
To: Paul Kyzivat; [email-masked]
Subject: Re: [MMUSIC] BUNDLE and RTCP

Hi,

Regards,

Christer

---

From: Jonathan Lennox <[email-masked]>
Date: Mon, 19 Oct 2015 18:41:12 +0000

On Oct 19, 2015, at 3:35 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

2)      Mandate usage of either rtcp-mux OR the default “+1” port with BUNDLE. I.e. if BUNDLE is negotiated, rtcp-mux or “+1” MUST be used. The selection is based on whether the rtcp-mux attribute was included in the offer/answer or not.
The solutions above would not allow explicit negotiation of an RTCP port when BUNDLE is used, but maybe we could live with that?

Would using ICE also solve the problem?  ICE candidates for component 2 are RTCP candidates. It might mean putting ICE candidates for component 2 in an m-line that doesn’t “naturally” use two candidates, but that might be cleaner than a=rtcp.

The “+1” technique, by contrast, doesn’t work in any scenario where you’re trying to advertise port numbers on the outside of a NAT, because the endpoint has no control over the mapping of its ports through the NAT.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Oct 2015 06:47:17 +0000

Hi,

> Would using ICE also solve the problem?  ICE candidates for component 2 are RTCP candidates. It might mean putting ICE candidates for component 2 in an m-line that doesn’t “naturally” use two candi…

When using ICE, that is one possibility. But, then we would have to specify that, when BUNDLE is used, component 2 is always for RTCP – no matter what type of m- line it is associated with it.

But, would that mean that, when ICE is NOT used, we would include a=rtcp in non-RTP m- lines?

Correct.

Regards,

Christer