From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "Olle E. Johansson" <oej@edvina.net>
Date: Sat, 13 Oct 2012 11:51:24 +0200
Thread-Topic: [MMUSIC] Trickle ICE
Thread-Index: Ac2pIdg5eqRDfzgBQ5OXcqaq8E3ICQABnZHP
Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA91@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>
 <7F2072F1E0DE894DA4B517B93C6A0585340BAFAA8F@ESESSCMS0356.eemea.ericsson.se>,
 <3EEA0674-8791-4A7B-AF07-086584E2A18E@edvina.net>
In-Reply-To: <3EEA0674-8791-4A7B-AF07-086584E2A18E@edvina.net>
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 whe=
ther 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 endpoi=
nt 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 issue=
s 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 i=
n a Require header in an INVITE request, Contact header
>>> in a REGISTER request or OPTIONS response. Some of the scenarios mentio=
ned 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 INV=
ITE is routed towards a remote peer entity that supports
>> certain features.
>>
> Using that would require a failure, then a backoff to something that inte=
roperates.

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 se=
nd the offer, you only have the host candidates, so you can't send one "tri=
ckle" 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 th=
en we would have to assume that the remote legacy peer still includes candi=
dates in the answer, and start listening for STUN checks from the offerer. =
I think that would be a very unlikely scenario :)

Regards,

Christer=