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.
>>
> Using that would require a failure, then a backoff to something that interoperates.

Exactly.

> Using some sort of multipart/alternative attachment would be faster - but I am afraid that a lot of applications doesn't support it,
> even though it's been a requirement in SIP since day one.

Not sure how multipart would help. The idea of trickle is that, when you send the offer, you only have the host candidates, so you can't send one "trickle" offer, and an alternative "non-trickle" offer, because you don't have any additional candidates to put into the non-trickle offer :)

Of course, the alternative could be without candidates all together, but then we would have to assume that the remote legacy peer still includes candidates in the answer, and start listening for STUN checks from the offerer. I think that would be a very unlikely scenario :)

Regards,

Christer