Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive

[Christer Holmberg <[e-mail]>]

Hi,

>>When ICE is in usage and the Offer want to support a=rtcp-mux-only, it does the following
>>a) include a=rtcp-mux-only
>>b) include a=rtcp <rtp-port> <-- RTP port
>>c) include RTCP candidate with port information that matches RTP. No need to do new turn allocation for RTCP either.
>
>Note that suggested ICE text says that if an entity only supports mux there is no need to include RTCP candidates. Instead the entity will only include RTP candidates (there are other mechanisms to indicate whether the entity doesn't support/want to use RTCP to begin with).
>
>[Suhas] As an offerer you have no idea if the Answerer supports RTCP Mux. So it needs to include RTCP candidates.
>This is what RFC5245bis says
>
>"In the case of RTP, this would happen when one agent provides candidates for RTCP, and the other does not. As another example, the initiating agent can
> multiplex RTP and RTCP on the same port [RFC5761]. However, since the initiating agent doesn't know if the peer agent can perform such multiplexing, it includes 
> candidates for RTP and RTCP on separate ports. If the peer agent can perform such  multiplexing, it would include just a single component for each candidate -- for 
>the combined RTP/RTCP mux. ICE would end up acting as if there was just a single component for this candidate."

The following next text has been discussed on the ICE list:

"     When candidates are obtained, unless the agent knows for sure that
       RTP/RTCP multiplexing will be used (i.e. the agent knows that the
       other agent also supports, and is willing to use, RTP/RTCP
       multiplexing), or unless the agent only supports RTP/RTCP
       multiplexing, the agent MUST obtain a separate candidate for RTCP.
       If an agent has obtained a candidate for RTCP, and ends up using RTP/
       RTCP multiplexing, the agent does not need to perform connectivity
       checks on the RTCP candidate."

Regards,

Christer