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

[Christer Holmberg <[e-mail]>]

Hi,

If you have concerns with the text, please take it to the ICE list :)

Regards,

Christer

From: Suhas Nandakumar [mailto:[e-mail]]
Sent: 25. tammikuuta 2016 9:58
To: Christer Holmberg
Cc: Roman Shpount; [e-mail]; Paul Kyzivat
Subject: Re: [MMUSIC] Not fixing a=rtcp and rtcp-mux exclusive



On Sun, Jan 24, 2016 at 11:51 PM, Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:
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."

[Suhas]
I see .. however I am not sure about the below statement

" i.e. the agent knows that the other agent also supports, and is willing to use, RTP/RTCP multiplexing"

what mechanism is available to ensure the peer supports and is willing to use  RTCP multiplexing. At any point as a peer, I can support RTCP Mux but might decide not to use for a given session. These were the few reasons that i thought motivated for supporting mux-exclusive in the first place


Regards,

Christer