Subject: [MMUSIC] ICE and RTCP host components

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Oct 2015 12:28:14 +0000

Hi,

ICEbis and ice-sip-sdp say that, when a separate port is used for RTCP, separate components are allocated for RTP and RTCP.

Assume the offerer uses a=rtcp to specify a port for RTCP, but the answerer doesn't support the attribute (and instead will use RTP port+1 for RTCP): Does that mean that the offerer needs to allocate RTCP host components both for the a=rtcp value and RTP port+1?

Section 5.1.3.1. of ICEbis talks about the rtcp-mux, when it is now known whether the answerer will support it, but this is about having two different ports for RTCP.

Regards,

Christer

---

From: Jonathan Lennox <[email-masked]>
Date: Tue, 20 Oct 2015 14:01:04 +0000

On Oct 20, 2015, at 8:28 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Assume the offerer uses a=rtcp to specify a port for RTCP, but the answerer doesn’t support the attribute (and instead will use RTP port+1 for RTCP): Does that mean that the offerer needs to allocate RTCP host components both for the a=rtcp value and RTP port+1?

I think it’s reasonable to say that any endpoint that supports ICE MUST also support a=rtcp.  Thus, the backward compatibility case only needs to worry about the RTP port+1 for the default candidate (the one in the m/c line).

If your default candidate is either your host candidate or your TURN candidate, this is easily achieved (using EVEN-PORT in the latter case).  It’s only server-reflexive candidates where the endpoint has no control over the RTCP port. (This was the motivation for the invention of a=rtcp, as I understand it.)

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 20 Oct 2015 12:18:28 -0400

On 10/20/15 8:28 AM, Christer Holmberg wrote:
> Hi,
>
> ICEbis and ice-sip-sdp say that, when a separate port is used for RTCP,
> separate components are allocated for RTP and RTCP.
>
> Assume the offerer uses a=rtcp to specify a port for RTCP, but the
> answerer doesn’t support the attribute (and instead will use RTP port+1
> for RTCP): Does that mean that the offerer needs to allocate RTCP host
> components both for the a=rtcp value and RTP port+1?

This has always been non-sensical to me. The reason to use a=rtcp is 
because you *can't* use the +1 rule. I don't see how this could ever 
work when the answerer doesn't support it. But neither do I have an idea 
how it could have been fixed.

(A better answer would have been to have rtcp-mux be the default, with 
an option to put it on a separate port. But this would have had to be 
defined when RTP was first specified.)

	Thanks,
	Paul

> Section 5.1.3.1. of ICEbis talks about the rtcp-mux, when it is now
> known whether the answerer will support it, but this is about having two
> different ports for RTCP.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Oct 2015 14:01:12 -0400

On Tue, Oct 20, 2015 at 12:18 PM, Paul Kyzivat <[email-masked]>
wrote:

> because you *can't* use the +1 rule. I don't see how this could ever work
> when the answerer doesn't support it. But neither do I have an idea how it
> could have been fixed.
>

I think originally a=rtcp was essentially best effort. If answerer did not
support rtcp attribute then sender will not get the RTCP. For legacy audio
flows that was good enough.

Also, if ICE is used without TURN with STUN server only, offer will need to
use rtcp attribute, since the candidate which ICE end point should put in
the m=line should be the server reflexive one, which will likely have the
RTCP port not being rtp+1. This, of cause, is only needed for legacy
interop with the end points that do no support ICE and will use only the
IP/ports from the m= line and rtcp attribute.

Bottom line, if you plan to support end points which do no implement ICE
and end points which are behind NAT at the same time, and you do not make
rtcp-mux required, you must support rtcp attribute.

I almost feel like making ICE required for anything that implements BUNDLE
is the simplest solution.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Oct 2015 18:03:21 +0000

Hi Roman,

…

>I almost feel like making ICE required for anything that implements BUNDLE is the simplest >solution.

Note that this is not a BUNDLE specific issue.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 20 Oct 2015 15:41:14 -0400

> Note that this is not a BUNDLE specific issue.
I know this is not BUNDLE specific. This is something that has been broken
for a long time. Essentially anything that needs to interoperate with end
points behind NAT MUST support SDP rtcp attribute and, ideally, ICE.
Otherwise RTCP flow will not be established in a large number of cases.
There is no workaround for this issue. SDP rtcp attribute was the
workaround designed to deal with this issue.

As far as ICE implementations are concerned, offerer should allocate for
RTCP rtp+1 port on the same address as RTP and use this port in host RTCP
candidate.

If TURN server is configured, get relay and reflexive candidates for RTP
and RTCP. Put relay candidate for RTP in the m= and c= lines, relay
candidate for RTCP in SDP rtcp attribute. Keep in mind that in this case
rtcp SDP attribute would have port+1 compared to port in m= line and,
optionally the same address as c= line. Even though such SDP rtcp
attribute is required by ICE RFC, it is really optional for call setup.

If only STUN server is configured, get a reflexive candidates, and put the
reflexive candidate for RTP in the m= and c= lines, reflexive candidate for
RTCP in SDP rtcp attribute. In this case port in SDP rtcp candidate is most
likely not going to be port+1 from the m= line and address in SDP rtpc
candidate can be different from address in c= line. Without SDP rtcp
attribute no RTCP flow will be established if remote party does not support
ICE. If remote party does not support SDP rtcp attribute or ICE, no RTCP
flow will be established. There is no workaround for this issue.

Finally, if neither TURN or STUN server are configured, offerer should put
host address in the c= line, host port in m= line, and rtp+1 and optionally
host address in the SDP rtcp attribute. Once again, even though such SDP
rtcp attribute is required by ICE RFC, it is really optional for call
setup..

It might make sense to explain that there is a use case which will never
work (no TURN server and remote end point which does not support either ICE
or rtcp attribute). In practice, without TURN server, there are a lot of
call flows which do not work (restricted NAT, TCP only firewalls), so this
is not really a problem.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Oct 2015 00:50:17 -0400

On 10/20/15 2:01 PM, Roman Shpount wrote:
> On Tue, Oct 20, 2015 at 12:18 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     work when the answerer doesn't support it. But neither do I have an
>     idea how it could have been fixed.
>
>
> I think originally a=rtcp was essentially best effort. If answerer did
> not support rtcp attribute then sender will not get the RTCP. For legacy
> audio flows that was good enough.

The thing is - the sender *will* get the RTCP, at port+1, even if it 
doesn't have port+1 allocated!

It would be better if RTCP wasn't sent in this case. But the other end 
simply didn't understand the a=rtcp, so it will assume default behavior.

	Thanks,
	Paul

> Also, if ICE is used without TURN with STUN server only, offer will need
> to use rtcp attribute, since the candidate which ICE end point should
> put in the m=line should be the server reflexive one, which will likely
> have the RTCP port not being rtp+1. This, of cause, is only needed for
> legacy interop with the end points that do no support ICE and will use
> only the IP/ports from the m= line and rtcp attribute.
>
> and end points which are behind NAT at the same time, and you do not
> make rtcp-mux required, you must support rtcp attribute.
>
> I almost feel like making ICE required for anything that implements
> BUNDLE is the simplest solution.
> _____________
> Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 22 Oct 2015 01:22:34 -0400

> simply didn't understand the a=rtcp, so it will assume default behavior.
It is actually worse, since RTCP port not being rtp+1 is normally due to
NAT. This means RTCP traffic will got to the NAT router and then NAT router
will forward this traffic to some random end-point. There is no way to stop
RTCP in such case either, since there is no standard way to negotiate no
RTCP.

Basically, end points must implement ICE and be deployed with TURN servers
to play well with other end points. If you implement ICE with STUN servers
only, one would need to make sure to set up connections only to end points
they control, which implement ICE or at least SDP rtcp attribute.
Everything else breaks in interesting and unpleasant ways. Building
anything new now without ICE, and consent to send traffic which is part of
ICE, would be highly dangerous and can be used for DOS attacks. So, I think
it might be safer to remove interop with legacy.from anything that supports
ICE, and require that remote party implements at least ice-lite, or no
media flow will be established.
_____________
Roman Shpount

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 23 Oct 2015 18:48:15 +0200

On 10/22/2015 07:22 AM, Roman Shpount wrote:
> On Wed, Oct 21, 2015 at 12:50 AM, Paul Kyzivat <[email-masked]
>         On Tue, Oct 20, 2015 at 12:18 PM, Paul Kyzivat
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>         wrote:
>
>                 answerer doesn’t support the attribute (and instead
>         will use RTP
>                 port+1
>                 for RTCP): Does that mean that the offerer needs to
>         allocate
>                 RTCP host
>     The thing is - the sender *will* get the RTCP, at port+1, even if
>     it doesn't have port+1 allocated!
>
>     It would be better if RTCP wasn't sent in this case. But the other
>     end simply didn't understand the a=rtcp, so it will assume default
>     behavior.
>
>
> It is actually worse, since RTCP port not being rtp+1 is normally due
> to NAT. This means RTCP traffic will got to the NAT router and then
> NAT router will forward this traffic to some random end-point. There
> is no way to stop RTCP in such case either, since there is no standard
> way to negotiate no RTCP.
>
> Basically, end points must implement ICE and be deployed with TURN
> servers to play well with other end points. If you implement ICE with
> STUN servers only, one would need to make sure to set up connections
> only to end points they control, which implement ICE or at least SDP
> rtcp attribute. Everything else breaks in interesting and unpleasant
> ways. Building anything new now without ICE, and consent to send
> traffic which is part of ICE, would be highly dangerous and can be
> used for DOS attacks. So, I think it might be safer to remove interop
> with legacy.from anything that supports ICE, and require that remote
> party implements at least ice-lite, or no media flow will be established.

RTCP/RTP multiplexing works for all cases where anything works at all.

Legacy (RTCP port = RTP port + 1) doesn't.

Time to give up on legacy.

-- 
Surveillance is pervasive. Go Dark.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 23 Oct 2015 13:18:53 -0400

> Time to give up on legacy.

Can we also give up on legacy interop for ICE? Let's make ICE work iwth ICE
enabled end points only and stop worrying what goes into c= line address,
m= line port, and SDP rtcp attribute. If anybody needs to support legacy,
put the media proxy on the RTP path.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Oct 2015 13:48:18 -0400

Ignoring legacy is a bad idea. It takes a long time for all of it to go 
away. In the meantime there must be some way of interworking with it.

	Thanks,
	Paul

On 10/23/15 1:18 PM, Roman Shpount wrote:
> On Fri, Oct 23, 2015 at 12:48 PM, Harald Alvestrand
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     servers to play well with other end points. If you implement ICE
>>     with STUN servers only, one would need to make sure to set up
>>     connections only to end points they control, which implement ICE
>>     or at least SDP rtcp attribute. Everything else breaks in
>>     interesting and unpleasant ways. Building anything new now without
>>     ICE, and consent to send traffic which is part of ICE, would be
>>     highly dangerous and can be used for DOS attacks. So, I think it
>>     might be safer to remove interop with legacy.from anything that
>>     supports ICE, and require that remote party implements at least
>>     ice-lite, or no media flow will be established.
>
> Can we also give up on legacy interop for ICE? Let's make ICE work iwth
> ICE enabled end points only and stop worrying what goes into c= line
> address, m= line port, and SDP rtcp attribute. If anybody needs to
> support legacy, put the media proxy on the RTP path.
> _____________
> Roman Shpount
>
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 23 Oct 2015 14:29:54 -0400

The normal use case for ICE are large numbers of end points deployed behind
NAT sending media directly to each other. Deploying a lot of end points
without some sort of consent to send media mechanism creates a perfect
platform for denial of service attacks. ICE solves this issue if legacy
support is disabled. Furthermore, legacy end points without SDP rtcp
attribute support end up sending RTCP to completely wrong place. Best
solution for anything ICE enabled is to set c= line address to IP4 0.0.0.0
and provide real RTP and RTCP in ICE candidates. Legacy will not work, but
no traffic to unexpected destinations will be generated.

Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 23 Oct 2015 15:00:46 -0400

On 10/23/15 2:25 PM, Roman Shpount wrote:
> The normal use case for ICE are large numbers of end points deployed
> behind NAT sending media directly to each other.

"Normal" changes over time. I think what you mean here is "current".

As ICE becomes more mature and people understand it better, it will be 
used more broadly, for things that have legacy components.

In any case, I think there will be much use of webrtc as one end of a 
session with the other end being a legacy sip device.

> Deploying a lot of end
> points without some sort of consent to send media mechanism creates a
> perfect platform for denial of service attacks. ICE solves this issue if
> legacy support is disabled. Furthermore, legacy end points without SDP
> rtcp attribute support end up sending RTCP to completely wrong place.
> Best solution for anything ICE enabled is to set c= line address to IP4
> 0.0.0.0 and provide real RTP and RTCP in ICE candidates. Legacy will not
> work, but no traffic to unexpected destinations will be generated.

Don't break interworking. Certainly this will require at least a 
signaling gateway. In general that will require a media gateway too. But 
anything that can be done to reduce the load on such a media gateway is 
good. It may need to do ICE. It may need to do the consent on behalf of 
the ultimate device.

	Thanks,
	Paul

> On Oct 23, 2015 1:48 PM, "Paul Kyzivat" <[email-masked]
>     Ignoring legacy is a bad idea. It takes a long time for all of it to
>     go away. In the meantime there must be some way of interworking with it.
>
>              Thanks,
>              Paul
>
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 24 Oct 2015 14:00:56 +0200

On 10/23/2015 09:00 PM, Paul Kyzivat wrote:
> signaling gateway. In general that will require a media gateway too.
> But anything that can be done to reduce the load on such a media
> gateway is good. It may need to do ICE. It may need to do the consent
> on behalf of the ultimate device. 
If "legacy" = "does not support ICE": Not "may". "will".

RTCWEB is designed to not start working unless ICE is present, and to
stop working if consent (which also requires ICE) isn't performed.

If the problem is "interwork with WebRTC devices", there's a class of
legacy devices that is "someone else's problem".

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 24 Oct 2015 10:33:46 -0400

Note that on a separate thread we are concluding that if you do bundle 
you must to rtcp-mux.

If we don't already have a problem with legacy ICE, I think it might 
also make sense to require that if you do ICE you must to rtcp-mux.

For compatibility with non-ICE, it would be ok to offer ICE and and 
rtp-mux, or ICE and a=rtcp, as fallbacks for answers that refuse ICE.

I think that would provide as much legacy compatibility as is feasible.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 24 Oct 2015 16:05:28 +0000

Hi,

>Note that on a separate thread we are concluding that if you do bundle you must to rtcp-mux.
>
>If we don't already have a problem with legacy ICE, I think it might also make sense to require that if you do ICE you must to rtcp-mux.

I would not like to take that step yet. There ARE deployments that do ICE (or, at least ICE lite), but that do NOT do rtcp-mux.

Regards,

Christer

On 10/24/15 8:00 AM, Harald Alvestrand wrote:
>> As ICE becomes more mature and people understand it better, it will 
>> be used more broadly, for things that have legacy components.
>>
>>> points without some sort of consent to send media mechanism creates 
>>> a perfect platform for denial of service attacks. ICE solves this 
>>> issue if legacy support is disabled. Furthermore, legacy end points 
>>> without SDP rtcp attribute support end up sending RTCP to completely wrong place.
>>> 0.0.0.0 and provide real RTP and RTCP in ICE candidates. Legacy will 
>>> not work, but no traffic to unexpected destinations will be generated.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 24 Oct 2015 19:22:02 -0400

> I would not like to take that step yet. There ARE deployments that do ICE (or, at least ICE lite), but that do NOT do rtcp-mux.

Fine. Can you find another way out of this problem?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 25 Oct 2015 06:17:07 +0000

Hi Paul,

I did notice your conversation after I had posted my reply. I will post any further comments there.

Sorry for the mess.

Regards,

Christer

Sent from my Windows Phone
________________________________
From: Paul Kyzivat<mailto:[email-masked]>
Sent: ‎24/‎10/‎2015 17:33
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] ICE and RTCP host components

        Thanks,
        Paul

---

From: Roman Shpount <[email-masked]>
Date: Sun, 25 Oct 2015 10:27:24 -0400

On Sat, Oct 24, 2015 at 7:22 PM, Paul Kyzivat <[email-masked]> wrote:

>> I would not like to take that step yet. There ARE deployments that do ICE
>> (or, at least ICE lite), but that do NOT do rtcp-mux.
>>
>
Original question was if originating end point needs to listen on two ports
-- the answer is, it does not. It is supposed to allocate port rtp+1 for
RTCP and put it in the SDP rtcp attribute. The only time you end up with
port and address not being rtp+1 is if you need to use server reflexive
candidates. If you need to interop with non-ICE legacy end points, your
best solution is not to use server reflexive candidates and use relay. So
make sure to deploy TURN servers and everything will work. If you want to
make sure end point will only communicate with ICE enabled end points
(disable legacy support), put IN IP4 0.0.0.0 in the c= line. No new
problems here, but some language to clarify this might be necessary.

In general I consider SDP rtcp attribute in case of ICE unnecessary. It is
only used when TURN servers are not used where things break often anyway.
_____________
Roman Shpount