Re: [MMUSIC] Trickle ICE for SIP Questions
Marc Petit-Huguenin <petithug@acm.org> Fri, 05 July 2013 17:28 UTC
Return-Path: <petithug@acm.org>
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 389C911E8135 for <mmusic@ietfa.amsl.com>; Fri, 5 Jul 2013 10:28:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-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 Gi+PgkiaPOeJ for <mmusic@ietfa.amsl.com>; Fri, 5 Jul 2013 10:28:28 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC1611E80F3 for <mmusic@ietf.org>; Fri, 5 Jul 2013 10:28:28 -0700 (PDT)
Received: from [IPv6:2601:9:4b80:4a:68a3:ec9a:408:988c] (unknown [IPv6:2601:9:4b80:4a:68a3:ec9a:408:988c]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id B3A57204D3; Fri, 5 Jul 2013 19:28:25 +0200 (CEST)
Message-ID: <51D70236.5070508@acm.org>
Date: Fri, 05 Jul 2013 10:28:22 -0700
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130630 Icedove/17.0.7
MIME-Version: 1.0
To: Emil Ivov <emcho@jitsi.org>
References: <51D43186.2010907@jitsi.org>
In-Reply-To: <51D43186.2010907@jitsi.org>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: MMUSIC IETF WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jul 2013 17:28:29 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I did not receive much comments on my proposal to use STUN packets to carry the new ICE candidates. To summarize, instead of using the SDP in an INFO and or UPDATE transaction, the new candidates can be sent on the same path that the media will use by default (i.e. using the candidate that is copied in the m= and c= line). Because this candidate is chosen to always succeed (using a TURN server), the candidate will always reach their destination. This will remove any problem in the signaling path, because it is no longer used to update the candidates. Thanks. On 07/03/2013 07:13 AM, Emil Ivov wrote: > Hey all, > > Christer, Enrico and I are preparing the next version of Trickle ICE for > SIP. Now that discussions on BUNDLE and the plans seem to be winding down, > we wanted to run a few questions by the working group. > > Q1: Making reliable provisional responses and PRACK mandatory. Obviously > this would be nice to avoid, so the question is: is there a reasonable > mechanism to achieve this (and by reasonable, we mean something that > wouldn't be harder than implementing support for PRACK). > > There was some discussion about this back in April and there was a > suggestion for implementing a 5245-style hack where the answerer basically > resends the 180 until it knows that it has been received. > > 5245 uses connectivity checks for this (i.e. it stops 180 retransmissions > when the first connectivity check is received) but we don't have that > option here since the 180 may contain either none or only host candidates > so there are strong chances that no binding request would be received on > them. > > Thomas also suggested a second option which would be to also use INFO > requests with trickled candidates as an indication that 180 was received. > This however wouldn't work with half trickle so we are basically back to > vanilla ICE for all (non-re) INVITEs. > > Another option would be to mandate an INFO request with "end-of-candidates" > in response to the 180, but that would be just the same as mandating PRACK > support. > > Thomas also suggested that the answerer can start sending INFOs right after > it sends its answer in the 180 and then it can just resend the 180 if the > INFOs result in a 481 response. > > Personally I think this could potentially be made to work, but it would > imply a level of complexity that considerably exceeds PRACK support. > > Opinions? > > Q2: How do we send INFOs? Are they blocking or do we just send them in > parallel? If the latter, then what happens when an INFO fails because it is > received out of order? Do we just tell the application to resend the > candidates asap? > > This also leads to the following question: > > Q3: What exactly do we send in INFOs? Just the latest batch of freshly > learned candidates or all candidates we've learned so far? Dale suggested > that if we do this cumulatively we wouldn't need to worry about the case > with the out-of-order INFOs from Q2 since the information gets resent > anyway. A drawback here would obviously be that this adds more complexity > for trickle ICE users (WebRTC applications specifically) > > A third option would be to allow both and leave it to the application. > > Comments are most welcome! > > Emil > - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJR1wI1AAoJECnERZXWan7EpOUQAIEFAeuFxkj0IJoWhiPXBb/L ulHURlg00WoK9RJFxLFWHP36lmaQ2y0v7LaFgX1hFoG9TMmMCbyxIfnva+5QFYzx LkiOZcgM5XuXjk6Ruke2/vrgByCPPYiCc7+K01+7NMO6tQL8rKxKr1Hq5PPRkUHY V6PO+XQd+KK8dm2W1qsR9s16goxqqQzeYJsEOX9mTGjqQdaju75FY88FdFE2rhib pdNrr+crC+gqdz/LKMS9so+dKtMMl3KNT39umDQuFkN9Gt+xorbKkvARCbB24xO3 jPX7koQ0v/eJd1lZwmgkrzMiBDnr/RHigIX3OIuNhL5xilf0Daps5jIkvIJT31gJ CUsfR78ykrWp3wJJ7Ck+PQpAyUrCpcctCUR6kEZ4g1gaKRAEWfw1MgieETqtLE8x Dwsy2c3Qw7XPi1VRMfc6BmCbrd59hQtIsF07yHZEJuHz8zuJoWN9mKLMsGJn4E4G ipIQwruOde7B23YUI0kqBzldRnw5sQ5XDi//rNnd2/KaMhSdxB5+A+g+yy2yQIyN m7It4KZ1+BiyOrgK2w8JHkkmbclSV5j3hEEv0pfgt3OoXWwuUqF2rjdQ4NfsXRj4 D05DUrhrgP7HKp+wxsIi2yyxFaZhkIBnooV/AhyDEh4Lk1KbKPPrSaEUyo6/5CmQ CtZLNHXi/Xv3Y3PjrpJF =DFTv -----END PGP SIGNATURE-----
- Re: [MMUSIC] Trickle ICE for SIP Questions Stach, Thomas
- [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Dan Wing
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Stach, Thomas
- Re: [MMUSIC] Trickle ICE for SIP Questions Stach, Thomas
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Paul Kyzivat
- Re: [MMUSIC] Trickle ICE for SIP Questions Marc Petit-Huguenin
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Marc Petit-Huguenin
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Marc Petit-Huguenin
- Re: [MMUSIC] Trickle ICE for SIP Questions Paul Kyzivat
- Re: [MMUSIC] Trickle ICE for SIP Questions Paul Kyzivat
- Re: [MMUSIC] Trickle ICE for SIP Questions Stach, Thomas
- Re: [MMUSIC] Trickle ICE for SIP Questions Stach, Thomas
- Re: [MMUSIC] Trickle ICE for SIP Questions Paul Kyzivat
- Re: [MMUSIC] Trickle ICE for SIP Questions Paul Kyzivat
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Cullen Jennings (fluffy)
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Paul Kyzivat
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Alan Johnston
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Parthasarathi R
- Re: [MMUSIC] Trickle ICE for SIP Questions Vijaya Mandava (vimandav)
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Cullen Jennings (fluffy)
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Parthasarathi R
- Re: [MMUSIC] Trickle ICE for SIP Questions Parthasarathi R
- Re: [MMUSIC] Trickle ICE for SIP Questions Emil Ivov
- Re: [MMUSIC] Trickle ICE for SIP Questions Paul Kyzivat
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Vijaya Mandava (vimandav)
- Re: [MMUSIC] Trickle ICE for SIP Questions Parthasarathi R
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Christer Holmberg
- Re: [MMUSIC] Trickle ICE for SIP Questions Stach, Thomas
- [MMUSIC] UPDATE vs INFO for SIP Trickle ICE [was … Parthasarathi R