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

[Christer Holmberg <[e-mail]>]

Hi,

>>> One option could perhaps be to use ICE if supported, but the rtcp attribute, with it's shortcomings, would be a fallback mechanism.
>>
>> Because, the more mandatory dependencies we add, the more difficult it will be to deploy (mandating ICE for mux 
>> would also indirectly mandate ICE for BUNDLE) and I am pretty sure non-mux is something that also non-WebRTC folks want.
>
> I would be fine if draft described the ICE only solution together with no ICE or ICE with fallback for legacy solution. This 
> way we do not mandate mechanisms that are completely unnecessary in the modern networks, such as WebRTC.

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.

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.

Regards,

Christer