From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Date: Sat, 13 Oct 2012 10:48:40 +0200
Thread-Topic: [MMUSIC] Trickle ICE
Thread-Index: Ac2o5Q/RAOkJ55O0TpaitQ/uJId22AAOnrt6
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8F@ESESSCMS0356.eemea.ericsson.se>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>
 <5075864F.3030700@jitsi.org>
 <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>,
 <BLU401-EAS379CF77DAA2110D2875C06693730@phx.gbl>
In-Reply-To: <BLU401-EAS379CF77DAA2110D2875C06693730@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: MMUSIC IETF WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Trickle ICE
Precedence: list

Hi,

Q1: Remote endpoint support (SIP):
-------------------------------------

>> You say that, before the first offer is sent, one SHOULD determine wheth=
er the remote endpoint supports trickle ICE.
>>
>> For SIP, you give RFC 3840 as an example. I am not sure how that will wo=
rk. Yes, you can use 3840 to request that the
>> offer is sent to an entity which supports trickle ICE (for that, btw, yo=
u will also need to define an option tag, or something=20
>> similar), but you cannot use it to determine whether the remote endpoint=
 supports trickle ICE. In addition, you typically=20
>> 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=20
>> 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=20
> in a REGISTER request or OPTIONS response. Some of the scenarios mentione=
d there include gateway scenarios in Section 3.1.

Sure. SIP allows you to indicate support of features during registration, i=
t allows you to require support of features from the remote=20
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=