IETF Logo Mail Archive

Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)

Emil Ivov <emcho@jitsi.org> Sat, 02 August 2014 22:29 UTC

Return-Path: <emcho@sip-communicator.org>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245B51B2A0B for <mmusic@ietfa.amsl.com>; Sat, 2 Aug 2014 15:29:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Level:
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M16XmEaq9rQa for <mmusic@ietfa.amsl.com>; Sat, 2 Aug 2014 15:29:50 -0700 (PDT)
Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6CF1B2A0A for <mmusic@ietf.org>; Sat, 2 Aug 2014 15:29:49 -0700 (PDT)
Received: by mail-vc0-f175.google.com with SMTP id ik5so8958989vcb.34 for <mmusic@ietf.org>; Sat, 02 Aug 2014 15:29:48 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1xHKSZ3vK0wMbkgxHrO/ZsrF6wEYNDH0cyo+Gsw4IqM=; b=c2lkuw4zIqP+Gk3urFEkcvIuc0zeENo3U59IgvadRzuBfmueDcotM3Tad2tA+nO9mw z4RtXBbgpNip0bIFB7cZluSMH/Gr1JOSK/SX3kREyTOXS7SnqJByBaTGsMVywZcSZA58 wYtfHF6FOMpvQdXmW1HFjPTmWQqtJWEIWQhnnKLtRhX0bsl0uSqSf4Sis2Z4x0wWklmR JtQCr/hZaVASb2jZQmzg/J2AGy2VEzqEoa6BqJ+sMI6B8n8jr5hbeT/TIAupQZv5Ol6+ Okru7cvd84mGvND9ylBS2UkkcEoGw/JDrfzlVwbKj9p8+eHYfHtiuPPWUQLW0F4QXhyo 2wXw==
X-Gm-Message-State: ALoCoQndrTL15tLwonZ62V3HKRsi+zh7e1iO4DmeA23diEH+CxcqrWIeIKUEhscJ8Pw9kuVHlCzx
X-Received: by 10.52.232.200 with SMTP id tq8mr4156012vdc.32.1407018588878; Sat, 02 Aug 2014 15:29:48 -0700 (PDT)
Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by mx.google.com with ESMTPSA id mw6sm9871657vec.0.2014.08.02.15.29.47 for <mmusic@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 02 Aug 2014 15:29:47 -0700 (PDT)
Received: by mail-vc0-f169.google.com with SMTP id le20so8935580vcb.28 for <mmusic@ietf.org>; Sat, 02 Aug 2014 15:29:47 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.52.244.81 with SMTP id xe17mr12755942vdc.24.1407018587719; Sat, 02 Aug 2014 15:29:47 -0700 (PDT)
Received: by 10.221.2.199 with HTTP; Sat, 2 Aug 2014 15:29:47 -0700 (PDT)
Received: by 10.221.2.199 with HTTP; Sat, 2 Aug 2014 15:29:47 -0700 (PDT)
In-Reply-To: <CALiegfnn0Vs-TeTn29fhC4Hb9RFVZOAzx7ZQHRCVBDp=VF+ObQ@mail.gmail.com>
References: <0DA61D09-6491-4DA4-8B6F-CFED70584A76@vidyo.com> <CAOJ7v-1jLK7dWDkWHKwHJ6qXicZWDNrAqOtw9R=6zAcWzkh5+g@mail.gmail.com> <53D796E5.9040009@jive.com> <2AF26344-DF5D-493C-96BC-80AD7DF35444@vidyo.com> <CAOJ7v-0HEjQQ+j0cAVc5r3Y4LxaoGF7EN2twGG6vTuMmEeragQ@mail.gmail.com> <8D2E9E91-B0B7-4081-B65B-EDAEC4D23A97@vidyo.com> <CAOJ7v-1HzGoUNXjvXph0-8WfpM6-vFJ+yDWhVw1_1grfrVD1Vw@mail.gmail.com> <B2794643-ADB5-4B66-98DC-841990C85437@vidyo.com> <CAOJ7v-2O3TwNcsKqp48PjDRu+Yu_+jEurecbO2GctD4Hsuu+NA@mail.gmail.com> <48776423-8594-4133-BD23-3EA561EC2A9D@vidyo.com> <CAOJ7v-13UZi4w7Vfr2dkghaosrwVYkTw5G2shq0JUvLPy30vTw@mail.gmail.com> <CAOJ7v-0s6EVa4KxQY99wB-BaDGr5EZwVunxrW4BBgVJLEuWhiQ@mail.gmail.com> <CAPvvaa+sKWtGSaWvo6Vx=vhMbbhmLQKr2o9Z3Wjkm2-5TXDjHw@mail.gmail.com> <CAPvvaaJDT0cgWhNkeKMKWUnHvRgZaEb9VXjV3+wHCx15_Z6+wg@mail.gmail.com> <CAPvvaaLNjZr-3NmdJOAV-Ov6qQ1gZoEOF1dk4W52gEOUq4214g@mail.gmail.com> <CALiegf=QASGR2+FuY7TKoJYrdvqbDxyUyKxvMQ13do5YX4GUyw@mail.gmail.com> <CABkgnnXvs_7fjQfCjeXMn4_RZExc8mYAQzqvq_fznc+kwGkKqA@mail.gmail.com> <CALiegfmp5YJwO62+fUN8AB=-A8rbenko_P7r35jo_CdUT6MWbA@mail.gmail.com> <CABkgnnXzNVgrYK6gjWmdyBoJ1Cog45XTP7F3yzaqOmm=GTypzA@mail.gmail.com> <CAOJ7v-1wzU0yMs21XYOpersa9f8u0=1n-mJ1BNrO-rEu3x9K5w@mail.gmail.com> <CALiegf=DJVZgEruEEGY4J7YiQk1jpzcDkztrT+Nosyrbjn0q5g@mail.gmail.com> <CABkgnnV0mBKgPj+9zNPcmTTLAGsz42eTMuAo14bnneSOowmR8w@mail.gmail.com> <CALiegfnn0Vs-TeTn29fhC4Hb9RFVZOAzx7ZQHRCVBDp=VF+ObQ@mail.gmail.com>
Date: Sun, 3 Aug 2014 00:29:47 +0200
Message-ID: <CAPvvaaLQwrxO9VcsjFNd+Mon49iC=jqREY3HOorbRW=EY7a=hQ@mail.gmail.com>
From: Emil Ivov <emcho@jitsi.org>
To: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
Content-Type: multipart/alternative; boundary=001a11c2c34a1d276804ffad0bc6
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/nVnnEuTLmLiPAD-r3skVIIjI5Ew
Cc: Jonathan Lennox <jonathan@vidyo.com>, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 02 Aug 2014 22:29:52 -0000

Well, that is exactly the case we set out to resolve for aggressive
nomination before we decided to have ourselves a new version of ICE :-).

If I understand correctly though, with the new ICE version (the one where
regular is the new aggressive) you should be prepared to handle this case
until you get a USE-CANDIDATE. From then on this would be your only pair.

--sent from my mobile
On 03 Aug 2014 12:06 AM, "Iñaki Baz Castillo" <ibc@aliax.net> wrote:

> 2014-08-01 18:04 GMT+02:00 Martin Thomson <martin.thomson@gmail.com>om>:
> > On 1 August 2014 01:15, Iñaki Baz Castillo <ibc@aliax.net> wrote:
> >> PS: In the text above I'm assuming that peerA initiates two different
> >> DTLS handshakes over pair1 and pair2. In case bullet 2) is the way to
> >> go, may we assume/mandate at least that peerA MUST perform a *single*
> >> DTLS handshake (regardless packets are sent and received via pair1 or
> >> pair2 or via both of them)?
> >
> > You can only have one DTLS connection, however...
> >
> > Sending two ClientHellos is OK, because DTLS requires retransmission
> > of ClientHello to deal with packet loss.  The server should treat
> > those as duplicates (and if they don't carry the same information, you
> > are setting yourself up for failure when it comes to generating the
> > Finished message).
>
> OK, that's clear. If a single DTLS handshake is allowed then things
> become easier.
>
> Just a question: how to determine the remote address for sending data?
> Theoretically that is determined by the "selected ICE pair", but what
> about if, at some point, the remote peer sends a valid SRTP packet
> from a different address (let's imagine it is an address from which a
> valid ICE Binding request with USE-CANDIDATE was previously received
> assuming the remote peer uses aggressive nomination)?. Should the
> local peer change its sending address?
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

v2.8.10 | Report a Bug | By Email