Re: [MMUSIC] Trickle ICE

["Olle E. Johansson" <[e-mail]>]

13 okt 2012 kl. 10:48 skrev 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.

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.

/O