Re: [MMUSIC] ICE and RTCP host components

[Paul Kyzivat <[e-mail]>]

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.

	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.
>
> 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