Re: [MMUSIC] ICE and RTCP host components

[Harald Alvestrand <[e-mail]>]

On 10/22/2015 07:22 AM, Roman Shpount wrote:
> On Wed, Oct 21, 2015 at 12:50 AM, Paul Kyzivat <[e-mail]
> <mailto:[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]>
>         <mailto:[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.

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.

> _____________
> Roman Shpount
>  
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic


-- 
Surveillance is pervasive. Go Dark.