Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED4211E81C1 for ; Tue, 22 Oct 2013 11:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.812 X-Spam-Level: X-Spam-Status: No, score=-3.812 tagged_above=-999 required=5 tests=[AWL=-1.214, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND+d9bdohrgZ for ; Tue, 22 Oct 2013 11:04:40 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 480FA11E810C for ; Tue, 22 Oct 2013 11:04:40 -0700 (PDT) X-AuditID: c1b4fb38-b7fcf8e0000062b8-4e-5266be37fdcc Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 01.30.25272.73EB6625; Tue, 22 Oct 2013 20:04:39 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Tue, 22 Oct 2013 20:04:38 +0200 From: Christer Holmberg To: Emil Ivov , Parthasarathi R Thread-Topic: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-01 Thread-Index: Ac7Oi3Z+e3UP57hvROCS8x6y31/feAAJw8IAACFHcIAAAcFGAAAEeh/hAAAm54o= Date: Tue, 22 Oct 2013 18:04:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4EBB51@ESESSMB209.ericsson.se> References: <00a401cece8b$7b00f780$7102e680$@co.in> <00ce01cecf48$6c0b5500$4421ff00$@co.in>, <5266BB46.4070305@jitsi.org> In-Reply-To: <5266BB46.4070305@jitsi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4EBB51ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3Rtd8X1qQwflmEYs1OyewWLTc8bKY uvwxi8XkT32sDiweS5b8ZPL4/ybQ48P8L+weLed62QNYorhsUlJzMstSi/TtErgy1tw7x1pw KLrizO9T7A2Mk3y6GDk5JARMJNasXcoIYYtJXLi3nq2LkYtDSOAoo8TW4/sZIZwljBKH780E cjg42AQsJLr/aYM0iAj4Stze3soMYjMLxEns37ESzBYWSJR48vMvK0RNksT7xd/ZQVpFBPwk Ns+MAAmzCKhKnLk1hQXE5gUa09w3BaxVSOAgo0Tvn2yQck4BTYntX4NAwoxAp30/tYYJYpO4 xK0n85kgThaQWLLnPDOELSrx8vE/VpBWCQEliWlb0yDK8yWWP9rFBrFJUOLkzCcsExhFZyGZ NAtJ2SwkZRBxPYkbU6ewQdjaEssWvmaGsHUlZvw7BFVjLbHi0j4WZDULGDlWMXIUpxYn5aYb GWxiBMbiwS2/LXYwXv5rc4hRmoNFSZz341vnICGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M 3ls/3+/NKNhuIPzZ5fHZqNhv0zaZi22czvTKSOVQzDSOnUUBN91vzZruJjDp34rz6Y5Fuo/m phnN65+6dxtbtphf5IbEd1mzjX7reXD8cbOZLWTOmTR17juetX07crrtlPwv7vzGf2lpUntb i6658nTdgut1bVrr77rP3nmu2T6g+xyDkqSREktxRqKhFnNRcSIA4jblD5MCAAA= Cc: 'mmusic' Subject: Re: [MMUSIC] UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusic-trickle-ice-sip-01 X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 18:04:46 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4EBB51ESESSMB209erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, IF we consider trickle candidates as being identical to server reflexive ca= ndidates, I am not sure whether there is a risk of an O/A glare. Because, w= e don't signal server reflexive candidates in O/A either, do we? If so, then I assume that Offers and Answers would have no impact on trickl= e candidates (unless, of course, there is an ICE restart). Or? Regards, Christer ________________________________ From: Emil Ivov [emcho@jitsi.org] Sent: Tuesday, 22 October 2013 8:52 PM To: Parthasarathi R Cc: Christer Holmberg; 'Enrico Marocco (TiLab)'; 'mmusic' Subject: Re: UPDATE mechanism for Trickle ICE - Comment on draft-ivov-mmusi= c-trickle-ice-sip-01 On 22.10.13, 19:01, Parthasarathi R wrote: > Emil, > > In case of ICE Trickle handling in SIP (based on RFC 3261), glare is > unavoidable I don't think this is true. > as per RFC 3264 offer/answer mechanism. The glare handling has > to be done by SIP provided mechanism like 491 handling in UPDATE/RE-INVIT= E. > draft-partha-rtcweb-jsep-sip-01 callflow works for UPDATE & ICE compliant > SIP UA and no need of extra extension. Yes, there is a well defined mechanism for handling glare with 3264. With that I agree. (Adoption and implementation levels are a different story but let's not worry about that right now.) The thing is that this mechanism would be hugely inefficient for trickle. The likelihood of glare occurring even more than once there is extremely high when using UPDATEs. You are actually quite likely to make the whole process even longer than Vanilla ICE so unless your purpose is to make Trickle pointless, I don't think this is a good idea. > INFO based mechanism fails to identify the actual glare situation in > offer/answer. I think you might have misunderstood the way trickle ICE works with INFO. Once the initial offer/answer is complete (and those rely on the regular glare handling, independently of trickle or ICE) there are no additional offers and answers. INFO requests transport asynchronous signalling between ICE agents (NOT offers and answers) and it is perfectly fine for either party to be sending them at any point in time. There's no possibility of glare here. Does this help clarify things? Emil > Of course, it is possible to reduce the trickle ICE glare handling with > special SDP handling (enhanced offer/answer) within RE-INVITE/UPDATE in c= ase > both endpoints supports the mechanism. > > Please read inline for more comments. > > Thanks > Partha > > > >> -----Original Message----- >> From: Emil Ivov [mailto:emcho@jitsi.org] >> Sent: Tuesday, October 22, 2013 6:39 AM >> To: Parthasarathi R >> Cc: Christer Holmberg; Enrico Marocco (TiLab); mmusic >> Subject: Re: UPDATE mechanism for Trickle ICE - Comment on draft-ivov- >> mmusic-trickle-ice-sip-01 >> >> On Mon, Oct 21, 2013 at 8:29 PM, Parthasarathi R >> wrote: >>> Hi all, >>> >>> I have mailed earlier why SIP INFO is not the right choice for >> Trickle ICE >>> in >>> http://www.ietf.org/mail-archive/web/mmusic/current/msg11964.html. >> >> I remember. Have you noticed my answer? >> >> http://www.ietf.org/mail-archive/web/mmusic/current/msg11932.html >> > > Please note that my question is after your answer (msg11964 > > msg11932). > >>> The main >>> reason is the glare handling. I have added the callflow in Sec 6.4 of >>> draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE handling will >> look for >>> Trickle ICE handling in SIP w.r.t JSEP mapping. >> >> I am confused. You say that your main issue is glare handling and yet >> your draft proposes a solution that *introduces* glare (through >> crossing UPDATEs) and then doesn't say anything about handling it. Is >> this intentional? Am I missing something? >> > > 491 is the only known glare handling. We shall work and further > enhance glare handling in UPDATE/RE-INVITE as it is obvious glare situati= on. > I wish to confirm that INFO mechanism does not work for this situation > before deep diving. > >>> Could you please explain how >>> glare with Trickle ICE Info package will be handled. >> >> That's simple. Glare does NOT occur when trickling through INFO. > > The actual glare situation will be missed in INFO > >> >> Emil >> >> -- >> https://jitsi.org > > -- https://jitsi.org --_000_7594FB04B1934943A5C02806D1A2204B1C4EBB51ESESSMB209erics_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <164E0BE3209F4F4780A6CD0732B7F623@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

 

IF we consider trickle candidates as being identical to server refl= exive candidates, I am not sure whether there is a risk of an O/A glare. Be= cause, we don't signal server reflexive candidates in O/A either, do we?

 

If so, then I assume that Offers and Answers would have no impact on tri= ckle candidates (unless, of course, there is an ICE restart). Or?

 

Regards,

 

Christer

 

 

From: Emil Ivov [emcho@jitsi.org]
Sent: Tuesday, 22 October 2013 8:52 PM
To: Parthasarathi R
Cc: Christer Holmberg; 'Enrico Marocco (TiLab)'; 'mmusic'
Subject: Re: UPDATE mechanism for Trickle ICE - Comment on draft-ivo= v-mmusic-trickle-ice-sip-01

On 22.10.13, 19:01, Parthasarathi R wrote:
> Emil,
>
> In case of ICE Trickle handling in SIP (based on RFC 3261), glare is > unavoidable

I don't think this is true.

> as per RFC 3264 offer/answer mechanism. The glare handling has
> to be done by SIP provided mechanism like 491 handling in UPDATE/RE-IN= VITE.
> draft-partha-rtcweb-jsep-sip-01 callflow works for UPDATE & ICE co= mpliant
> SIP UA and no need of extra extension.

Yes, there is a well defined mechanism for handling glare with 3264.
With that I agree. (Adoption and implementation levels are a different
story but let's not worry about that right now.)

The thing is that this mechanism would be hugely inefficient for
trickle. The likelihood of glare occurring even more than once there is extremely high when using UPDATEs.

You are actually quite likely to make the whole process even longer than Vanilla ICE so unless your purpose is to make Trickle pointless, I don't think this is a good idea.

> INFO based mechanism fails to identify the actual glare situation in > offer/answer.

I think you might have misunderstood the way trickle ICE works with INFO.
Once the initial offer/answer is complete (and those rely on the regular glare handling, independently of trickle or ICE) there are no additional offers and answers.

INFO requests transport asynchronous signalling between ICE agents (NOT offers and answers) and it is perfectly fine for either party to be
sending them at any point in time. There's no possibility of glare here.
Does this help clarify things?

Emil


> Of course,  it is possible to reduce the trickle ICE glare handli= ng with
> special SDP handling (enhanced offer/answer) within RE-INVITE/UPDATE i= n case
> both endpoints supports the mechanism.
>
> Please read inline for more comments.
>
> Thanks
> Partha
>
>
>
>> -----Original Message-----
>> From: Emil Ivov [mailto:emcho@jitsi.org]
>> Sent: Tuesday, October 22, 2013 6:39 AM
>> To: Parthasarathi R
>> Cc: Christer Holmberg; Enrico Marocco (TiLab); mmusic
>> Subject: Re: UPDATE mechanism for Trickle ICE - Comment on draft-i= vov-
>> mmusic-trickle-ice-sip-01
>>
>> On Mon, Oct 21, 2013 at 8:29 PM, Parthasarathi R
>> <partha@parthasarathi.co.in> wrote:
>>> Hi all,
>>>
>>> I have mailed earlier why SIP INFO is not the right choice for=
>> Trickle ICE
>>> in
>>> http://www.ietf.org/mail-archive/web/mmusic/current/msg11964.html.
>>
>> I remember. Have you noticed my answer?
>>
>> http://www.ietf.org/mail-archive/web/mmusic/current/msg11932.html
>>
>
> <Partha> Please note that my question is after your answer (msg1= 1964 >
> msg11932). </Partha>
>
>>> The main
>>> reason is the glare handling. I have added the callflow in Sec= 6.4 of
>>> draft-partha-rtcweb-jsep-sip-01 to explain how UPDATE handling= will
>> look for
>>> Trickle ICE handling in SIP w.r.t JSEP mapping.
>>
>> I am confused. You say that your main issue is glare handling and = yet
>> your draft proposes a solution that *introduces* glare (through >> crossing UPDATEs) and then doesn't say anything about handling it.= Is
>> this intentional? Am I missing something?
>>
>
> <Partha> 491 is the only known glare handling. We shall work and= further
> enhance glare handling in UPDATE/RE-INVITE as it is obvious glare situ= ation.
> I wish to confirm that INFO mechanism does not work for this situation=
> before deep diving. </Partha>
>
>>> Could you please explain how
>>> glare with Trickle ICE Info package will be handled.
>>
>> That's simple. Glare does NOT occur when trickling through INFO. >
> <Partha> The actual glare situation will be missed in INFO </= Partha>
>
>>
>> Emil
>>
>> --
>> https://jitsi.org=
>
>

--
https://jitsi.org
--_000_7594FB04B1934943A5C02806D1A2204B1C4EBB51ESESSMB209erics_--