Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: "Olle E. Johansson" <oej@edvina.net>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8F@ESESSCMS0356.eemea.ericsson.se>
Date: Sat, 13 Oct 2012 11:05:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3EEA0674-8791-4A7B-AF07-086584E2A18E@edvina.net>
References: <20121010141600.30314.22528.idtracker@ietfa.amsl.com>
 <5075864F.3030700@jitsi.org>
 <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA6E@ESESSCMS0356.eemea.ericsson.se>,
 <BLU401-EAS379CF77DAA2110D2875C06693730@phx.gbl>
 <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8F@ESESSCMS0356.eemea.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: MMUSIC IETF WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Trickle ICE
Precedence: list

13 okt 2012 kl. 10:48 skrev Christer Holmberg =
<christer.holmberg@ericsson.com>:

> Hi,
>=20
> 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
>>> 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=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.
>>=20
>> 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 =
mentioned there include gateway scenarios in Section 3.1.
>=20
> Sure. SIP allows you to indicate support of features during =
registration, it 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.
>=20
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,=20
even though it's been a requirement in SIP since day one.

/O