Re: [MMUSIC] ICE and RTCP host components

[Roman Shpount <[e-mail]>]

On Wed, Oct 21, 2015 at 12:50 AM, Paul Kyzivat <[e-mail]>
wrote:

> On 10/20/15 2:01 PM, Roman Shpount wrote:
>
>> On Tue, Oct 20, 2015 at 12:18 PM, Paul Kyzivat <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>         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.
>>
>>
>> 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.
>
>
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