Message-ID: <BLU401-EAS379CF77DAA2110D2875C06693730@phx.gbl>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>
 <5075864F.3030700@jitsi.org>
 <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>
From: Bernard Aboba <bernard_aboba@hotmail.com>
MIME-Version: 1.0 (1.0)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>
Date: Fri, 12 Oct 2012 18:50:44 -0700
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: MMUSIC IETF WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Trickle ICE
Precedence: list

On Oct 10, 2012, at 11:18, "Christer Holmberg" <christer.holmberg@ericsson.c=
om> wrote:

Q1: Remote endpoint support (SIP):
> --------------------------------------------
>=20
> You say that, before the first offer is sent, one SHOULD determine whether=
 the remote endpoint supports trickle ICE.=20
>=20
> 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 r=
emote endpoint supports trickle ICE. In addition, you typically use 3840 at t=
he same time when you send the initial offer.
> Of course, you could use SIP OPTIONS. But, there are a number of issues re=
lated to that, and I don't think we want to define a mechanism which relies o=
n the usage of OPTIONS.

I think the idea originated from the RFC 5768 use of sip.ice, such as in a R=
equire header in an INVITE request, Contact header in a REGISTER request or O=
PTIONS response. Some of the scenarios mentioned there include gateway scena=
rios in Section 3.1.=