Re: [MMUSIC] ICE and RTCP host components

[Jonathan Lennox <[e-mail]>]

On Oct 20, 2015, at 8:28 AM, Christer Holmberg <[e-mail]<mailto:[e-mail]>> 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?

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.

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