Re: [MMUSIC] Trickle ICE

[Christer Holmberg <[e-mail]>]

Hi,

Q1: Remote endpoint support (SIP):
-------------------------------------

>> You say that, before the first offer is sent, one SHOULD determine whether the remote endpoint supports trickle ICE.
>>
>> For SIP, you give RFC 3840 as an example. I am not sure how that will work. Yes, you can use 3840 to request that the
>> offer is sent to an entity which supports trickle ICE (for that, btw, you will also need to define an option tag, or something 
>> similar), but you cannot use it to determine whether the remote endpoint supports trickle ICE. In addition, you typically 
>> use 3840 at the same time when you send the initial offer.
>> Of course, you could use SIP OPTIONS. But, there are a number of issues related to that, and I don't think we want to 
>> define a mechanism which relies on the usage of OPTIONS.
>
> I think the idea originated from the RFC 5768 use of sip.ice, such as in a Require header in an INVITE request, Contact header 
> in a REGISTER request or OPTIONS response. Some of the scenarios mentioned there include gateway scenarios in Section 3.1.

Sure. SIP allows you to indicate support of features during registration, it allows you to require support of features from the remote 
peer when you send the INVITE, and it allows you to request that the INVITE is routed towards a remote peer entity that supports
certain features.

Regards,

Christer