IETF Logo Mail Archive

Re: [MMUSIC] DTLS-SRTP client/server role negotiation

Martin Thomson <martin.thomson@gmail.com> Fri, 03 May 2013 17:40 UTC

Return-Path: <martin.thomson@gmail.com>
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 5D34221F92F7 for <mmusic@ietfa.amsl.com>; Fri, 3 May 2013 10:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.599
X-Spam-Level:
X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[J_CHICKENPOX_15=0.6, 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 jQ5TgM+I4u4t for <mmusic@ietfa.amsl.com>; Fri, 3 May 2013 10:40:12 -0700 (PDT)
Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id E040121F901A for <mmusic@ietf.org>; Fri, 3 May 2013 10:29:56 -0700 (PDT)
Received: by mail-wi0-f176.google.com with SMTP id hq12so844832wib.15 for <mmusic@ietf.org>; Fri, 03 May 2013 10:29:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lp3/ZGS4vLgjSjaTFm6KJkXkpnVgjOQFXkS/Gu0/gKY=; b=Pt7ytQVeWJ/Z5I2sMEVXa+zCQH5SerN5f4FucSUZ/9/qmF3yPBkxpIR2gelTHDF/Lt RmgnVaAZlKUvHT/hzRQ7ur+Hf3fV6Ba7wLiQDZGcwQ8KnS6XP/oLzKcASLmOhUu4i3VV CxoLcujXnXhjPCs9/9nxi2Jkc/RlWZz51HaeOzd6MNk7hTlVMzD1qx69Dj2Qg/jA8DER hWL1rK6W+ptFCoS3upD49+bAYYSON1Y8s8lWXr/RK7V7Ye4X9S4EoBrbbDSBc/vUFOFa Uz2+36E3J7K9vgcP157PMOgcH++fBXREdYP8vMuoOhgLfnPjYNuoWUXN5vB6UCpEDAUu cOIw==
MIME-Version: 1.0
X-Received: by 10.180.183.133 with SMTP id em5mr14484700wic.26.1367602196090; Fri, 03 May 2013 10:29:56 -0700 (PDT)
Received: by 10.194.33.102 with HTTP; Fri, 3 May 2013 10:29:55 -0700 (PDT)
In-Reply-To: <CAOJ7v-1rt2RA17oC0kCxC2wD310ghp2pwLF1jit6ikLfCSCiQA@mail.gmail.com>
References: <E888F149-12FE-4F23-A270-F861123BAC7B@tokbox.com> <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com> <CAOJ7v-2XUzVr3kL=emR_7w49th3mowa_WQG4wVVmD7__uA8APw@mail.gmail.com> <7984C671-D3FF-4CC3-AC4A-9965087DD07E@cisco.com> <786615F3A85DF44AA2A76164A71FE1AC0305AA@FR711WXCHMBA03.zeu.alcatel-lucent.com> <CAKhHsXGEiNLod6fXbOSP3HvVYtFi4iBQEUBe2x-5YQdwz8LAOQ@mail.gmail.com> <F72A5B11-D5D4-41D1-8118-C5BCBBAAE567@tokbox.com> <CAOJ7v-1rt2RA17oC0kCxC2wD310ghp2pwLF1jit6ikLfCSCiQA@mail.gmail.com>
Date: Fri, 03 May 2013 10:29:55 -0700
Message-ID: <CABkgnnX_fy77UthxAJxen=Eoam0CABdAMvCiTZSt0NoG=s3M7Q@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Justin Uberti <juberti@google.com>
Content-Type: text/plain; charset="UTF-8"
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>, Alan Johnston <alan.b.johnston@gmail.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation
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, 03 May 2013 17:40:12 -0000

On 2 May 2013 22:53, Justin Uberti <juberti@google.com> wrote:
> This is where the OP's question came from - the differing policy between
> Chrome and Firefox. I (regarding Chrome) had figured that if ICE had made a
> determination regarding which side was in charge, the other layers in the
> stack should do the same, but it sounds like there are already established
> rules on how to do this.
>
> From this thread, it sounds like the recommendation is to use
> a=setup:actpass in the offer, and then the answerer can use a=setup:active
> to choose the client role. In 3pcc cases, the B2BUA can select a=setup
> appropriately to avoid any issue.
>
> Is that an accurate summary, and is there consensus on this?

The answer should probably be a=setup:passive, so that you don't have
any disconnect on what candidate pair is nominated.  And you don't pay
an extra half-RTT.  But otherwise, yes.

v2.23.0 | Report a Bug | By Email