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

[Christer Holmberg <[e-mail]>]

Hi,

>>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.
 
Is the usage of c=0.0.0.0 for basic ICE something we have actually agreed upon and documented?

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

But, does it hurt to include it? If the answerer supports ICE, it could simply ignore it.

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

Keep in mind that the rtcp attribute does not contain an address, only port.

>If ICE is used without legacy interop, endpoint will only include RTP candidates and no rtcp attribute.

See above.

Regards,

Christer