IETF Logo Mail Archive

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

Justin Uberti <juberti@google.com> Wed, 01 May 2013 22:28 UTC

Return-Path: <juberti@google.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 4154621F8C38 for <mmusic@ietfa.amsl.com>; Wed, 1 May 2013 15:28:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.827
X-Spam-Level:
X-Spam-Status: No, score=-101.827 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
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 LsuaOo-zv+Lu for <mmusic@ietfa.amsl.com>; Wed, 1 May 2013 15:28:07 -0700 (PDT)
Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id F36EA21F9955 for <mmusic@ietf.org>; Wed, 1 May 2013 15:26:58 -0700 (PDT)
Received: by mail-ie0-f175.google.com with SMTP id a11so2499596iee.34 for <mmusic@ietf.org>; Wed, 01 May 2013 15:26:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=e8xHs03SWN42VJfhfJl8Gh29HXGkDkYrteT2GVpO+7w=; b=MYO0h52AUh6mfuKlvlQJQ7CoCrtGjMzHUCjLd9GPnKY4yiGzut+6ck1TN+kCrVWNEh slQxwKaTYMMMLH3lx8tTS/gV8AkMM3Z1JLNQLHhcNyr2yo+e8cSctrOKRzGYyqgY5SDf bCj9FWDv95R6lrC/XSSw1XsKvtldzF7isixJNSVDFAITkzx9I+n7AZZ6SsX0cS/w9P7X BqBm+RLucodPW+1bs6hPfYTuTMsikLyozRfD4UmVi2cnN+X13MK8/EKaAAj9S/1Inu0t qJ3M7vikF3TPYHfX1EouKezSsuaY4gvnqKDAfQ/0fT/aay5Ln85MKYVc/g3w1eDGr5kS F1bA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=e8xHs03SWN42VJfhfJl8Gh29HXGkDkYrteT2GVpO+7w=; b=Yno0wxCR7ETP1uPgbHl7dVMioxu+VooxOjFmwWova+H0beQeHDCrKF7qPJ6KglNYkA 6/RerMSNsyHuk3GeRFNCUOrA6gsRM2NiWQJu92Cm09xvR+fzoM2ZGQPPqXlA8Hn5JLAj 9vbgVKGx20kmLe9a9gpPmfpo6FKNEgoYSD2fX+dh3HY/5NMqCyr5GYIrqy9I4+abEtd+ F2aYEdQZxFIH4RY39VJDlNpD7ISHGJ2/QdodEEGak/tOWvQ2DXq583n4b6z4y5tOhxrF PWHJI/JRni2vQNIQ9tEnayBqYIoR4fVspf3OQg0+Au52PJwkBI9/XrCC7KWkhZo7s8Pb eQ6Q==
X-Received: by 10.50.32.4 with SMTP id e4mr13492338igi.95.1367447217991; Wed, 01 May 2013 15:26:57 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.193.201 with HTTP; Wed, 1 May 2013 15:26:37 -0700 (PDT)
In-Reply-To: <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com>
References: <E888F149-12FE-4F23-A270-F861123BAC7B@tokbox.com> <5181819B.5050107@alum.mit.edu> <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com>
From: Justin Uberti <juberti@google.com>
Date: Wed, 01 May 2013 15:26:37 -0700
Message-ID: <CAOJ7v-2XUzVr3kL=emR_7w49th3mowa_WQG4wVVmD7__uA8APw@mail.gmail.com>
To: Gustavo García <ggb@tokbox.com>
Content-Type: multipart/alternative; boundary="e89a8f3ba56dad8a0b04dbaf9dab"
X-Gm-Message-State: ALoCoQl6KIGvtqpnHqec138kzS8/kH4uiyY5fOK1OAzZvsvLtqu8BbjaWlbE4lTWApyVt+PaaQ14EGDwHDjXKxAgG0ECEgIs/EG0JwIWN3hGkVwTv3C54yQn8F5Op5GXZylEJZM9ryAKmH/0DtJ7PG9+Zhd2MsGXPmLvbw5BuGI6irVTgmWE9xuAsOv3YHcyYlzZ4a4uzIgt
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Paul Kyzivat <pkyzivat@alum.mit.edu>
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: Wed, 01 May 2013 22:28:08 -0000

I think Paul means the active/passive attributes in RFC 5763, but I'm still
not sure about how 3rd party call control would be handled in this case,
i.e. when both endpoints think they are offerers and set a=setup:actpass.

ICE has logic to determine roles in this scenario, as shows in RFC 5245,
B.11.


On Wed, May 1, 2013 at 2:10 PM, Gustavo García <ggb@tokbox.com> wrote:

> I saw it, but that is all about TCP client/server role and not DTLS
> client/server role.   Are we supposed to use the same "setup" attribute for
> dtls role negotiation even if it is over UDP?
>
> I think there is no reason to tie TCP and DTLS roles, but perhaps I'm
> misunderstanding something.
>
> On 01/05/2013, at 13:56, Paul Kyzivat wrote:
>
> > On 5/1/13 2:26 PM, Gustavo García wrote:
> >> RFC5764 (DTLS-SRTP) states that "Which side is the DTLS client and
> which side is the DTLS server must be established via some out-of-band
> mechanism such as SDP."
> >>
> >> What is the specification on how to signal that in SDP?
> >>
> >> Specifically in case of 3pcc where both endpoints are SDP offerers
> which one should take the client and server roles for DTLS?    Should we
> tie that role to ICE controlled/controlling roles or should we negotiate it
> in the SDP somehow?
> >
> > See RFC4145.
> >
> > _______________________________________________
> > mmusic mailing list
> > mmusic@ietf.org
> > https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

v2.23.0 | Report a Bug | By Email