Subject: [MMUSIC] Draft new version: BUNDLE-25

From: Christer Holmberg <[email-masked]>
Date: Mon, 18 Jan 2016 20:01:45 +0000

Hi,

I've submitted a new version (-25) of draft-ietf-mmusic-sdp-bundle-negotiation.

I have added text regarding mux-exclusive to the RTP/RTCP multiplexing chapter.

However, as I wrote in another mail, I think we need to say whether support of mux-exclusive is mandated by bundle entities. Currently we only mandate support of RTP/RTCP multiplexing in general.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Jan 2016 16:29:42 +0000

Any opinions on whether BUNDLE should mandate support of mux-exclusive?

Keep in mind that we are about to ship BUNDLE to IESG for publication soon...

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 18 January 2016 22:02
To: [email-masked]
Cc: [email-masked]
Subject: [MMUSIC] Draft new version: BUNDLE-25

Hi,

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Jan 2016 13:53:09 -0500

On 1/20/16 11:29 AM, Christer Holmberg wrote:
> Keep in mind that we are about to ship BUNDLE to IESG for publication soon…

Are you asking if bundle should have a normative dependency on 
mux-exclusive?

If bundle itself mandates that multiplexing is required to be used for 
RTP, then it provides a parallel (separate but equal) mechanism for 
ensuring that fact, so a normative reference isn't required. Then there 
won't be a normative dependency between the drafts. Presumably you could 
still use the mux-exclusive mechanism with bundle if you wanted.

	Thanks,
	Paul

> Regards,
>
> Christer
>
> *From:*mmusic [mailto:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* 18 January 2016 22:02
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [MMUSIC] Draft new version: BUNDLE-25
>
> Hi,
>
> I’ve submitted a new version (-25) of
> draft-ietf-mmusic-sdp-bundle-negotiation.
>
> However, as I wrote in another mail, I think we need to say whether
> support of mux-exclusive is mandated by bundle entities. Currently we
> only mandate support of RTP/RTCP multiplexing in general.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Jan 2016 20:01:00 +0000

Hi,

> Are you asking if bundle should have a normative dependency on mux-exclusive?

Yes.

> If bundle itself mandates that multiplexing is required to be used for RTP, then it provides a parallel (separate but equal) mechanism for
> ensuring that fact, so a normative reference isn't required. Then there won't be a normative dependency between the drafts. Presumably 
> you could still use the mux-exclusive mechanism with bundle if you wanted.

BUNDLE mandates multiplexing if the answerer keeps the m- line within the BUNDLE group, and it's true that you don't need mux-exclusive for that. 

But, mux-exclusive would mandate multiplexing even if the answerer moves the m- line out of the BUNDLE group, so the question is whether we want to mandate support for that by BUNDLE entities.

Regards,

Christer

> I've submitted a new version (-25) of

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Jan 2016 15:25:28 -0500

> But, mux-exclusive would mandate multiplexing even if the answerer moves the m- line out of the BUNDLE group, so the question is whether we want to mandate support for that by BUNDLE entities.

Hmm. While trying to figure out how to answer you I think I see a 
problem with mux-exclusive - it provides no way to discover whether it 
is requested, supported, or used. So it is only useful when the involved 
parties agree to it out-of-band, or when dependency upon it is coupled 
to some other feature that is signaled.

So coupling it to bundle would mean that it is negotiated along with bundle.

Note, even then, it could apply to m-lines moved out of a bundle group 
as long as support for bundle was still negotiated. But if bundle wasn't 
supported in the answer then it wouldn't apply.

So, I guess either it needs to be coupled to bundle, or else 
mux-exclusive should be updated to include some sort of signaling that 
it is supported.

What this is coming down to is that the only totally safe way to offer 
an rtp session without reserving port+1 for rtcp is to negotiate the 
address/port with ICE, and avoid putting any in m=/c=.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Jan 2016 21:15:01 +0000

Hi,

>>> If bundle itself mandates that multiplexing is required to be used 
>>> for RTP, then it provides a parallel (separate but equal) mechanism 
>>> for ensuring that fact, so a normative reference isn't required. Then there won't be a normative dependency between 
>>> the drafts. Presumably you could still use the mux-exclusive mechanism with bundle if you wanted.
>>
> Hmm. While trying to figure out how to answer you I think I see a problem with mux-exclusive - it provides no way to discover whether 
> it is requested, supported, or used. So it is only useful when the involved parties agree to it out-of-band, or when dependency upon it is 
> coupled to some other feature that is signaled.

The currently suggested mechanism is to use the SDP rtcp attribute, containing the same port value as for RTP, to indicate support.

> So coupling it to bundle would mean that it is negotiated along with bundle.

You can still use mux-exclusive without BUNDLE. The question is whether a BUNDLE entity should be required to support it.

> Note, even then, it could apply to m-lines moved out of a bundle group as long as support for bundle was still 
> negotiated. But if bundle wasn't supported in the answer then it wouldn't apply.

Not sure I follow. If the answerer doesn't support BUNDLE it could still support mux-exclusive. I am not suggesting that supporting mux-exclusive mandates supporting BUNDLE - I am asking whether supporting BUNDLE mandates supporting mux-exclusive :)

> So, I guess either it needs to be coupled to bundle, or else mux-exclusive should be updated to include some sort of signaling that it is supported.

The currently suggested mechanism is to use the SDP rtcp attribute, with a port value same as for RTP.

> What this is coming down to is that the only totally safe way to offer an rtp session without reserving port+1 for rtcp is to negotiate the address/port with ICE, and avoid putting any in m=/c=.

AFAIR both BUNDLE and ICE mandates support of the rtcp attribute.

The issue comes up if the answerer does not support the rtcp attribute. But, as we have discussed before, that issue already exists in RFC 3605. 

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Jan 2016 17:04:54 -0500

> The currently suggested mechanism is to use the SDP rtcp attribute, containing the same port value as for RTP, to indicate support.

The problem is, if you are doing this you haven't reserved port+1. If 
the answerer doesn't understand either bundle, or a=rtcp, then it will 
simply assume that rtcp will be on port+1. What is lacking is a way to 
signal mux-exclusive that doesn't result in rtcp being sent on an 
unassigned port.

AFAIK the only way to assure that right now is to use c=0. That would 
"work", but then another O/A would be needed once rtcp-mux has been 
negotiated.

> Not sure I follow. If the answerer doesn't support BUNDLE it could still support mux-exclusive. I am not suggesting that supporting mux-exclusive mandates supporting BUNDLE - I am asking whether su…

Yes, the answerer could support mux-exclusive and not bundle. But then 
you are in the position I just noted above: does the answerer support 
mux-exclusive? Or does the answerer not support either mux-excusive or 
the rtcp attribute? The signaling doesn't say.

> The issue comes up if the answerer does not support the rtcp attribute. But, as we have discussed before, that issue already exists in RFC 3605.

But that is the crux of the problem.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 20 Jan 2016 22:35:04 +0000

Hi,

....

>>>>> for ensuring that fact, so a normative reference isn't required. 
>>>>> Then there won't be a normative dependency between the drafts. Presumably you could still use the mux-exclusive mechanism with bundle if you wanted.
>>>>
>>>> But, mux-exclusive would mandate multiplexing even if the answerer moves the m- line out of the BUNDLE group, so the 
>>>> question is whether we want to mandate support for that by BUNDLE entities.
>>>
>>> problem with mux-exclusive - it provides no way to discover whether 
>>> it is requested, supported, or used. So it is only useful when the involved parties agree to it out-of-band, or when dependency upon it is coupled to some other feature that is signaled.
>>
> The problem is, if you are doing this you haven't reserved port+1. If the answerer doesn't understand either 
> bundle, or a=rtcp, then it will simply assume that rtcp will be on port+1. What is lacking is a way to signal mux-exclusive 
> that doesn't result in rtcp being sent on an unassigned port.

Yes.

But, you have the same problem even without mux-exclusive, if you want to use a non-port+1 for RTCP. There is no "Require header field" in SDP.

I think this is a case where vendors simply will have to realize that they need to support the SDP 'rtcp' attribute in order to make sure their stuff work. I don't think it's a big problem in deployments, and it will eventually go away.

> AFAIK the only way to assure that right now is to use c=0. That would "work", but then another O/A would be needed once rtcp-mux has been negotiated.

You can use c=0 if you want to be absolutely sure, but I don't think mux-exclusive should mandate it (in that case RFC3605 should mandate it). However, we can point out the problem, and describe mechanisms to avoid it.

>>> Note, even then, it could apply to m-lines moved out of a bundle 
>>> group as long as support for bundle was still negotiated. But if bundle wasn't supported in the answer then it wouldn't apply.
>>
>> Not sure I follow. If the answerer doesn't support BUNDLE it could 
>> still support mux-exclusive. I am not suggesting that supporting 
>> mux-exclusive mandates supporting BUNDLE - I am asking whether 
>> supporting BUNDLE mandates supporting mux-exclusive :)
>
> Yes, the answerer could support mux-exclusive and not bundle. But then you are in the position I just noted above: does the
> answerer support mux-exclusive? Or does the answerer not support either mux-excusive or the rtcp attribute? The signaling doesn't say.

If the answerer supports the rtcp attribute, it will see that the port number is identical to the RTP port. So, either it will start sending RTCP on that port, or it will not accept the m- line.

People want to get away from reserving separate ports for RTP and RTCP, the support of ICE is increasing as we speak, so I think this is a problem that will be fixed by the market. We should not prevent it because of some endpoints that we don't even know if they exist... You have to support the rtcp attribute if you want to be able to communicate with an entity behind a NAT.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Jan 2016 17:57:47 -0500

> I think this is a case where vendors simply will have to realize that they need to support the SDP 'rtcp' attribute in order to make sure their stuff work. I don't think it's a big problem in deplo…
...
> People want to get away from reserving separate ports for RTP and RTCP, the support of ICE is increasing as we speak, so I think this is a problem that will be fixed by the market. We should not pr…

I'm not sure what the right path is here. If you don't reserve port+1, 
and the other end fails to support the rtcp attribute, then you have 
rtcp going to an unassigned port. You might get lucky, and then it won't 
hurt *you*. But maybe it is hitting some unrelated app on the same IP. 
With NAT boxes in the way it might end up hitting some other app on a 
different IP.

If the offerer detects that this has happened it could take a recovery 
action: either offer again with a port pair, or offer again disabling 
the media line in question. This assumes that the offerer can detect it.

Unfortunately 3605 didn't even define the O/A semantics, or provide a 
way to indicate that the answerer accepted the attribute. It need not be 
used symmetrically.

So I guess you are suggesting that support for 3605 for any user of sdp 
with rtp transport. And we will assume that is fully deployed.

If that is the path forward, then I think it needs some sort of 
extraordinary process to bless that. I don't know what it is. But I bet 
it involves the IESG.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Wed, 20 Jan 2016 18:53:47 -0500

On Wed, Jan 20, 2016 at 5:57 PM, Paul Kyzivat <[email-masked]> wrote:

> I'm not sure what the right path is here. If you don't reserve port+1, and
> the other end fails to support the rtcp attribute, then you have rtcp going
> to an unassigned port. You might get lucky, and then it won't hurt *you*.
> But maybe it is hitting some unrelated app on the same IP. With NAT boxes
> in the way it might end up hitting some other app on a different IP.
>
> action: either offer again with a port pair, or offer again disabling the
> media line in question. This assumes that the offerer can detect it.
>
> Unfortunately 3605 didn't even define the O/A semantics, or provide a way
> to indicate that the answerer accepted the attribute. It need not be used
> symmetrically.
>
> extraordinary process to bless that. I don't know what it is. But I bet it
> involves the IESG.
>
>
Another option is to support ICE only and drop support for non ICE end
points. ICE support by both end points is easily detected. In order to
prevent non-ICE end points from sending media to your end points, you can
create an offer with c=0 and no a=rtcp with valid ICE candidates. If remote
end point responds without ICE, the no media is sent and you can terminate
the media session (or do another offer/answer for legacy). This is not
legal according to the current ICE specification since it requires a valid
IP in c= line and a=rtcp attribute.  I think it would make sense to extend
ICE to allow this. This is how WebRTC works. It is also how any end point
on the publicly open IP network should work since this enables consent for
sending media.

So, the question I would ask, do we care about BUNDLE without ICE? If we do
not, then all the a=rtcp related problems can be easily solved.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Jan 2016 21:08:49 -0500

On 1/20/16 6:53 PM, Roman Shpount wrote:

> So, the question I would ask, do we care about BUNDLE without ICE? If we
> do not, then all the a=rtcp related problems can be easily solved.

Well, CLUE has no reason to couple those. CLUE wants to have the 
possibility to interoperate with legacy endpoints, but it also will 
often have many media streams and so want to offer BUNDLE.

In any case, this isn't really about bundle. The real issue is that 3605 
is broken, and has been. Pretty much any offerer that has a need to use 
a=rtcp will break if the answerer doesn't support it.

I expect that one action that could be taken is to file an errata 
against it.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Jan 2016 07:16:26 +0000

Hi,

>>> the answerer doesn't understand either bundle, or a=rtcp, then it 
>>> will simply assume that rtcp will be on port+1. What is lacking is a way to signal mux-exclusive that doesn't result in rtcp being sent on an unassigned port.
>>
>> Yes.
>>
>> People want to get away from reserving separate ports for RTP and RTCP, the support of ICE is increasing as we speak, so I think this is a problem that will be 
>> fixed by the market. We should not prevent it because of some endpoints that we don't even know if they exist... You have to support the rtcp attribute if you want to be able to communicate with an entity behind a NAT.
>
> I'm not sure what the right path is here. If you don't reserve port+1, and the other end fails to support the rtcp attribute, then you have rtcp going to an unassigned port. You might get lucky, and 
> then it won't hurt *you*. But maybe it is hitting some unrelated app on the same IP. 
> With NAT boxes in the way it might end up hitting some other app on a different IP.

Yes.

> action: either offer again with a port pair, or offer again disabling the media line in question. This assumes that the offerer can detect it.

The offerer needs to be able to handle the scenario anyway, because malicious endpoints could send RTCP packets to whatever ports...

Keep in mind that, at the end of the day, mux-exclusive is nothing more than one single usage of RFC 3605.

> Unfortunately 3605 didn't even define the O/A semantics, or provide a way to indicate that the answerer accepted the attribute. It need not be used symmetrically.
>
> So I guess you are suggesting that support for 3605 for any user of sdp with rtp transport. And we will assume that is fully deployed.

Correct. 

But, I'd be interested in hearing if someone has a different view regarding what is deployed.

> If that is the path forward, then I think it needs some sort of extraordinary process to bless that. I don't know what it is. But I bet it involves the IESG.

I think we could document the assumption, and what can go wrong if the attribute is not supported, and then it's acceptable.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Jan 2016 07:20:04 +0000

Hi,

>> So, the question I would ask, do we care about BUNDLE without ICE? If 
>> we do not, then all the a=rtcp related problems can be easily solved.
>
> Well, CLUE has no reason to couple those. CLUE wants to have the possibility to interoperate with legacy endpoints, but it also will often have many media streams and so want to offer BUNDLE.
>
> In any case, this isn't really about bundle. The real issue is that 3605 is broken, and has been. Pretty much any offerer that has a need to use a=rtcp will break if the answerer doesn't support it.
>
> I expect that one action that could be taken is to file an errata against it.

Wouldn't the errata be against SDP or offer/answer, where we would mandate support of the rtcp attribute?

(Of course, maybe we want to fix something in 3605 too, but the mandate to support 3605 in the first place would have to be elsewhere.)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Jan 2016 11:13:44 -0500

> (Of course, maybe we want to fix something in 3605 too, but the mandate to support 3605 in the first place would have to be elsewhere.)

On further thought I doubt that an errata works for this. It isn't that 
anything in 3605 is *wrong*. Rather, it is simply incomplete.

By current standards it wouldn't be approved because it lacks a section 
describing how it works with O/A. Also, it failed to address backward 
compatibility.

Unfortunately, backward compatibility isn't something that can added 
later. :-(

I don't know the best way to handle this. Maybe the ADs have an idea.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Jan 2016 11:18:00 -0500

On 1/21/16 2:16 AM, Christer Holmberg wrote:
> I think we could document the assumption, and what can go wrong if the attribute is not supported,

Yes.

> and then it's acceptable.

It is?

It is better than *not* documenting it. But the potential problems 
remain. It is acceptable if those problems don't occur in practice. But 
if the do occur then it isn't acceptable, at least to me.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Jan 2016 17:29:26 +0000

Hi,

....

>>> I'm not sure what the right path is here. If you don't reserve 
>>> port+1, and the other end fails to support the rtcp attribute, then you have rtcp going to an 
>>> unassigned port. You might get lucky, and then it won't hurt *you*. But maybe it is hitting some 
>>> unrelated app on the same IP.

Sorry - it seems like I dropped some words :) It was meant to say "and then see if it's acceptable".

> It is better than *not* documenting it. But the potential problems remain. It is acceptable if those problems don't 
> occur in practice. But if the do occur then it isn't acceptable, at least to me.

If it would be an issue, I think we would be aware of it by now. 

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Jan 2016 17:33:08 +0000

Hi,

>>>> So, the question I would ask, do we care about BUNDLE without ICE? 
>>>> If we do not, then all the a=rtcp related problems can be easily solved.
>>>
>> (Of course, maybe we want to fix something in 3605 too, but the 
>> mandate to support 3605 in the first place would have to be 
>> elsewhere.)
>
> On further thought I doubt that an errata works for this. It isn't that anything in 3605 is *wrong*. Rather, it is simply incomplete.
>
> By current standards it wouldn't be approved because it lacks a section describing how it works with O/A. Also, it failed to address backward compatibility.
>
> Unfortunately, backward compatibility isn't something that can added later. :-(
>

As this hasn't caused any major problem (at least nobody has raised any issues in IETF), the question is whether we really need to do something. We know that, in theory, problems can occur, but as those problem don't seem to occur in deployments we could just leave it like that.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Thu, 21 Jan 2016 13:02:56 -0500

On Thu, Jan 21, 2016 at 12:33 PM, Christer Holmberg <
[email-masked]> wrote:

>
> As this hasn't caused any major problem (at least nobody has raised any
> issues in IETF), the question is whether we really need to do something. We
> know that, in theory, problems can occur, but as those problem don't seem
> to occur in deployments we could just leave it like that.
>
>
The reason no issues were reported so far is likely related to the fact
that a=rtcp attribute, despite being widely implemented, is virtually
useless and almost never used. In cases when end points are placed behind
NAT most current solutions implement either host based NAT traversal or
ICE. In case of host based NAT traversal one end point is placed on the
public IP and will send RTP and RTCP to address/port from which it receives
media from the end point behind NAT. This solution ignores a=rtcp
attribute. ICE obviously ignores a=rtcp attribute and uses addresses in
candidates. Only place where a=rtcp attribute is used are solutions based
on STUN based local address discovery. From my experience such solutions
are so fragile that they are almost never deployed.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Jan 2016 18:14:06 +0000

Hi Roman,

Thanks for your input. So, do you agree that we don’t need to “fix” a=rtcp?

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 21 January 2016 20:03
To: Christer Holmberg <[email-masked]>
Cc: Paul Kyzivat <[email-masked]>; [email-masked]
Subject: Re: [MMUSIC] Draft new version: BUNDLE-25

On Thu, Jan 21, 2016 at 12:33 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

The reason no issues were reported so far is likely related to the fact that a=rtcp attribute, despite being widely implemented, is virtually useless and almost never used. In cases when end points are placed behind NAT most current solutions implement either host based NAT traversal or ICE. In case of host based NAT traversal one end point is placed on the public IP and will send RTP and RTCP to address/port from which it receives media from the end point behind NAT. This solution ignores a=rtcp attribute. ICE obviously ignores a=rtcp attribute and uses addresses in candidates. Only place where a=rtcp attribute is used are solutions based on STUN based local address discovery. From my experience such solutions are so fragile that they are almost never deployed.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 21 Jan 2016 13:22:47 -0500

> Thanks for your input. So, do you agree that we don’t need to “fix” a=rtcp?
I think I would agree we don't need to "fix" a=rtcp if we did not plan on
re-using for new purposes. I think technology moved on since the time
"a=rtcp" was designed and new NAT traversal solutions should be ICE based.
If you are looking at a=rtcp attribute as a way to signal new functionality
such as rtcp-mux required in the backwards inter-operable manner, a=rtcp
might be more trouble then it is worth, since it never worked quite well.
It might be better to define a new SDP attribute for rtcp-mux-required with
well defined offer/answer behavior which would allow to determine if both
sides support it.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 21 Jan 2016 18:29:05 +0000

Hi,

I don’t think using a=rtcp for signalling mux-exclusive is new functionality. We still use it to signal the RTCP port, which in the case of mux-exclusive happens to be same as the RTP port.

Regards,

Christer

Sent: 21 January 2016 20:23

On Thu, Jan 21, 2016 at 1:14 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Thanks for your input. So, do you agree that we don’t need to “fix” a=rtcp?

I think I would agree we don't need to "fix" a=rtcp if we did not plan on re-using for new purposes. I think technology moved on since the time "a=rtcp" was designed and new NAT traversal solutions should be ICE based. If you are looking at a=rtcp attribute as a way to signal new functionality such as rtcp-mux required in the backwards inter-operable manner, a=rtcp might be more trouble then it is worth, since it never worked quite well. It might be better to define a new SDP attribute for rtcp-mux-required with well defined offer/answer behavior which would allow to determine if both sides support it.
_____________
Roman Shpount