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

[Suhas Nandakumar <[e-mail]>]

On Sun, Jan 24, 2016 at 11:51 PM, Christer Holmberg <
[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
>
>