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

Emil Ivov <> Wed, 30 July 2014 21:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9F0F21A0113 for <>; Wed, 30 Jul 2014 14:49:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JpM0fdyuKhUK for <>; Wed, 30 Jul 2014 14:48:58 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F04731A005D for <>; Wed, 30 Jul 2014 14:48:57 -0700 (PDT)
Received: by with SMTP id hq11so2907507vcb.30 for <>; Wed, 30 Jul 2014 14:48:57 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=u490RRUSqPvra/btkGDYc1qODI93xwrk63lsul15W6I=; b=cotkU4A9l5CDUcnDLQaOIAKa26LphtIhT+1VlqRrJ09P7fyR0YqHtDpD2HBvi2kFw6 6oRFDMhtIKfeuWLKaEdlEhtG5dBvHV+9KWBHndWiFnCa2rwACuGsThbMjJyxPnPqwAlF CaqXSGC99zgFF6l9NdoHagf8buzrgOB1jlJjdBQRLQPdXOZXijHP+0/ihm6sh/25xt3W v3AUun1Lhoeejcg5uFye+oA3qEJDXl2j0Zt6mIchHnqkRIOcsx38sbXhYWqovozzlOqB e2GSS7Nv10JAh82ESipcVwJylrHXjhUf55OeIGW349ipeMLKvNPoAOVACGeHlIIRA4KH xP7w==
X-Gm-Message-State: ALoCoQmBB29EjJcpNFsbKnscgsVXuISQQ7Fo5m03FxKIoEQAzO0q8CQPKFUHVQ+pxnLDcAi1HWVm
X-Received: by with SMTP id xe17mr11127522vdc.24.1406756936945; Wed, 30 Jul 2014 14:48:56 -0700 (PDT)
Received: from ( []) by with ESMTPSA id td9sm1851341veb.8.2014. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 14:48:56 -0700 (PDT)
Received: by with SMTP id ik5so2900261vcb.34 for <>; Wed, 30 Jul 2014 14:48:56 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id ax9mr5568713vdc.76.1406756936164; Wed, 30 Jul 2014 14:48:56 -0700 (PDT)
Received: by with HTTP; Wed, 30 Jul 2014 14:48:56 -0700 (PDT)
Received: by with HTTP; Wed, 30 Jul 2014 14:48:56 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Wed, 30 Jul 2014 23:48:56 +0200
Message-ID: <>
From: Emil Ivov <>
To: Jonathan Lennox <>
Content-Type: multipart/alternative; boundary=089e0158ca7e7749b104ff701f76
Cc: mmusic <>
Subject: Re: [MMUSIC] Merging ICE aggressive and regular nomination (was Re: [tram] Comment on draft-williams-peer-redirect-01: might it not converge?)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Jul 2014 21:49:01 -0000

The main problem with the aggressive version of regular nomination is stuff
like DTLS/SRTP (that's actually already kind of an issue with today's
aggressive nomination).

When it's RTP you don't care where you get it from as long as you do. If
it's a DTLS client halo then what do you do exactly?

Can the controlling agent simply respond on a different valid pair than the
one on which it received it? (This is what Chrome currently does but its
frowned upon by the DTLS/SRTP draft which binds the context to a specific
address:port). Does the controlled agent need to resend it on the new pair
after it gets the USE-CANDIDATE?

What about other protocols? Do they all need to say how they are to be used
with ICE? I hope not and I hope we can find a generic approach for all of
them. For example: all early non-acknowledged reliable data has to be
resent on the nominated pair. This would imply a DTLS neg restart as Martin

--sent from my mobile
On 30 Jul 2014 11:14 PM, "Jonathan Lennox" <> wrote:

>  On Jul 30, 2014, at 4:59 PM, Justin Uberti <> wrote:
>   On Wed, Jul 30, 2014 at 8:10 AM, Jonathan Lennox <>
> wrote:
>> On Jul 29, 2014, at 1:57 PM, Justin Uberti <> wrote:
>> >
>> > The one thing we need to do is update ICE to allow the CONTROLLING side
>> to make dynamic decisions about which pair to use, instead of being forced
>> to use PRIORITY (which is what 5245 says). I am going to try to write this
>> up before Hawaii.
>> This is equivalent to using regular nomination, but saying that an
>> endpoint can send media on any Confirmed candidate pair, not just the
>> Selected one, right?
>  It's a bit more than that - the controlled endpoint has to also
> synchronize on the candidate pair, which means that it needs to know what
> its selected pair should be, using logic other than what is outlined in
> (which says use the
> highest priority nominated pair).
>  So it becomes:
> - controlling side can pick any nominated candidate pair it wants to be
> its selected pair
> - controlled side should use presence of media from controlling side to
> decide selected pair (for secure media), or some TBD attribute (for
> non-secure media)
> - controlling side can tell controlled side when it is OK to discard
> candidate pairs that it has nominated (so that the controlling side can
> still safely do the switch to a new pair). This is probably done by having
> the controlled side keep all candidates alive that have received a check
> from the controlling side in the past XX seconds.
>  You’ve just reinvented regular nomination — your “TBD attribute” is
> regular nomination’s USE-CANDIDATE.
>  Thus the suggestion I’m making — do regular nomination, but allow media
> to be sent on any valid pair prior to selection.  (Yes, re-reading 5245, I
> should have said “Valid” rather than “Confirmed”.  I mis-remembered the
> terminology.)
>    5245 says that an ICE endpoint MUST be prepared to receive media on
>> any candidate, but only sends on the Selected candidate pair.  I don’t know
>> if this means, in practice, that ICE-bis could change to the behavior I’ve
>> described above and still be backward compatible, or if there’d need to be
>> some sort of ice-option negotiation to indicate that this early media (oh,
>> dread phrase) is acceptable.
>  Yes, I think we need a new ICE option, or else old ICE impls in the
> controlled role will be surprised when they think the selected pair is A
> but media arrives on B. We've already seen a number of implementations have
> issues with this.
>  Do they have issues receiving media if there is no selected pair yet?
>  This would be nonconformant with 5245, but nevertheless wouldn’t surprise
> me.
> _______________________________________________
> mmusic mailing list