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

Iñaki Baz Castillo <> Thu, 31 July 2014 10:51 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4F6E31A01A5 for <>; Thu, 31 Jul 2014 03:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.678
X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7_nIxqjXHQvX for <>; Thu, 31 Jul 2014 03:51:12 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 232151A004E for <>; Thu, 31 Jul 2014 03:51:12 -0700 (PDT)
Received: by with SMTP id k15so2282539qaq.24 for <>; Thu, 31 Jul 2014 03:51:11 -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:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=D1PeiRiF4MxUSQNFtDnH3Jn2XLGN9J/9MJfFxqSxaGA=; b=K8PvmuB8o+JRiLMl028Cm4ITOjEy9cUEXxfztpB2+IyNSLFk+mtpH3fjGMh9mxydpv +SfCaqLMu3VRnahzus2Uhyk2wtigM5Z37WMqSOMH5MaoGSe0ZuV+fpc/sJjpOXU2UT+h 1zHX5ATC0gT2YCUfj+V7CFMC2iaHIZ9J6Lo6vZB0XdWhwYSpy5DI4a1Qi6RVCmIb2o1d V/KySOu8OY/+DNYXkQ6G6I+iJEX1qFQRsfuGNuSa6hJLFRwappikperH8gCP2lEWgyvT WtHxSlOELEqMM21V8A4f+T7vsuFCQU7i81YHmvzd9sn9wbHNEmwKkqLTAUoLpBmV8IjJ DhpA==
X-Gm-Message-State: ALoCoQmjnv3Tl+ux3i8UyttEPdgDp31a4JQoDscb4n5pKT7QUBOg6o9fAemVyNxgJBHrn2PI5MNT
X-Received: by with SMTP id i9mr17331493qas.50.1406803871239; Thu, 31 Jul 2014 03:51:11 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 31 Jul 2014 03:50:51 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
Date: Thu, 31 Jul 2014 12:50:51 +0200
Message-ID: <>
To: Emil Ivov <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Jonathan Lennox <>, 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: Thu, 31 Jul 2014 10:51:13 -0000

2014-07-30 23:48 GMT+02:00 Emil Ivov <>rg>:
> 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
> suggested.


IMHO we need a way for ICE (all the flavors) to fully determine which
is the *only* pair in which media or DTLS can be sent, so a peer can
safely discard any RTP or DTLS packet coming from a source address
that does not match the selected/paired/confirmed address tuple.

And IMHO we also need that a ICE-Lite server implementation does not
need to keep a list of valid pairs or source addresses but just one
(chosen via ICE by the controlling peer).

Iñaki Baz Castillo