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

Martin Thomson <> Wed, 30 July 2014 22:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3562B1A0659 for <>; Wed, 30 Jul 2014 15:01:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id INJN3wU4OFcm for <>; Wed, 30 Jul 2014 15:01:31 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58C881A0654 for <>; Wed, 30 Jul 2014 15:01:31 -0700 (PDT)
Received: by with SMTP id k48so1899272wev.12 for <>; Wed, 30 Jul 2014 15:01:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=3RWgDUdtuX27eZ4ozQhsJfh8s0eKsmtCtJYS+1wwJeU=; b=AbXyd0An8ulExrAdB5LtKdCEzUyOjuRYtjr/l8PBHBVCZHUuJo5g/oCDKawzMM0Xve d4y5itKxwTxBzMrlDv/QS/xIj43OQnoecLMjvQ/AJ5y55kuRsV2tAgenEGXX4yfXhEAu G87y9JBxk+Uz5rEN+mYxPNhOtAugosrjJ5+c3AISJt7yK0Lrz+Ts3yEqMfu6gpRHwJN0 viQc1tYPbJNoqigCT1N658Tstkbv50CsYAaFl8zQIK6ZvGNdLcfd1A0jmXfJ08x4AIvX UMx3UCv6R3BHrSYx7PJaS0opWfk9L2c/zGsVfbWxZizSrq/yUD5uec1TbmX61F3lTncN WCEA==
MIME-Version: 1.0
X-Received: by with SMTP id fu5mr11019376wic.64.1406757689760; Wed, 30 Jul 2014 15:01:29 -0700 (PDT)
Received: by with HTTP; Wed, 30 Jul 2014 15:01:29 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Wed, 30 Jul 2014 15:01:29 -0700
Message-ID: <>
From: Martin Thomson <>
To: Emil Ivov <>
Content-Type: text/plain; charset=UTF-8
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: Wed, 30 Jul 2014 22:01:34 -0000

On 30 July 2014 14:48, Emil Ivov <> wrote:
> 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?

RFC 5764 says this:
   A single DTLS-SRTP session only protects data carried over
   a single UDP source and destination port pair.

But I'll postulate that this is only because the alternative (a
shifting substrate) was not yet conceived.  There is nothing in (D)TLS
that requires anything of the underlying transport protocol,
intentionally.  (c.f., tcpinc wg)

Firefox code seems to be OK (at least superficially) with the idea
that packets can arrive from anywhere.  However, I can see why some
implementations might get sad if things shift around.