Re: [MMUSIC] ICE and RTCP host components

[Roman Shpount <[e-mail]>]

On Tue, Oct 20, 2015 at 12:18 PM, Paul Kyzivat <[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.

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