Re: [MMUSIC] FW: New Version Notification for draft-holmberg-mmusic-mux-exlusive-00.txt

[Roman Shpount <[e-mail]>]

On Fri, Nov 13, 2015 at 5:14 PM, Christer Holmberg <
[e-mail]> wrote:

> However, when the offerer sends the initial offer, it doesn't know whether
> the answerer supports ICE, so I think it would need to include the rtcp
> attribute in the offer just in case.
>

It can, however send an offer which will only work if remote side supports
ICE, i.e. put c=0.0.0.0 line and put actual IP addresses in candidates
only. What I do not want, is require support for rtcp attribute if end
point never intends to work without ICE.


> The second question is whether the mux-exclusive should define the ICE
> mechanism. Couldn't we in the ICE spec simply say that if an endpoint only
> supports mux then it only includes RTP candidates (component ID value 1).
> Then, in the mux-exclusive draft we would only say something like:
>
>         "As defined in ICE, if an endpoint only supports RTP/RTCP mux, the
> endpoint will only include RTP candidates in the offer".
>
> In the ICE WG, we have drafted text saying that an offerer can include
> only RTP candidates if it knows that the remote endpoint supports RTP/RTCP
> mux. We could simply extend that text, and include the case where the
> endpoint only supports RTP/RTCP mux.
>

This would be fine with me, as long as, rtcp attribute would not be
required when ICE is used and no legacy interop is expected.

So, if legacy interop is required, rtcp attribute set to the same value as
c= line address and m= line port would indicate rtcp-mux only. If ICE is
used without legacy interop, endpoint will only include RTP candidates and
no rtcp attribute.

Regards,
_____________
Roman Shpount