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

Gustavo García <ggb@tokbox.com> Wed, 01 May 2013 21:11 UTC

Return-Path: <ggb@tokbox.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 F264F21F9B20 for <mmusic@ietfa.amsl.com>; Wed, 1 May 2013 14:11:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 yA7hgJmrDfsN for <mmusic@ietfa.amsl.com>; Wed, 1 May 2013 14:10:54 -0700 (PDT)
Received: from na3sys010aog112.obsmtp.com (na3sys010aog112.obsmtp.com [74.125.245.92]) by ietfa.amsl.com (Postfix) with SMTP id 1101221F9B34 for <mmusic@ietf.org>; Wed, 1 May 2013 14:10:54 -0700 (PDT)
Received: from mail-da0-f70.google.com ([209.85.210.70]) (using TLSv1) by na3sys010aob112.postini.com ([74.125.244.12]) with SMTP ID DSNKUYGE2dMPltMQ2+pfegS/KeRTkwPDAbST@postini.com; Wed, 01 May 2013 14:10:54 PDT
Received: by mail-da0-f70.google.com with SMTP id i30so2222346dad.1 for <mmusic@ietf.org>; Wed, 01 May 2013 14:10:49 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=xwfDdEuk6fJNv9jqUxOIWzw5STvCH8EOxx9UuV907WY=; b=YqIzw6sXk7D4gKb3TOxEe/6yKKo+LnYJ/zPpn6ossoV/3NlHfhARakHlZAxrfUmeRf g1SjwQCSDYxTVn8rGIfGj8u1hGGu3UNvrwRqR1S73G+/VVJ4oE3Piqv804BT0Cwn2LrX /xWO0Z4jDbhVb80lhG0MrcfodrhhHTrIk6Qo73Emm7Tgq1M9bivn/Rt++KFo9lpsdlSP Sz8wWtBwQKxsTLGCFd+M+Why6Kg8abJnstjXBgk3bGX64ImM4cv1LpGNZGuQlosaDDtV Z1m0ShdpKKco5JWPfp2tpQ30JHFVWIFDQZ62PgrKYNW4f7ddBz6udAlLXoz3IL6/ep2T qi9g==
X-Received: by 10.68.20.74 with SMTP id l10mr5912273pbe.150.1367442649327; Wed, 01 May 2013 14:10:49 -0700 (PDT)
X-Received: by 10.68.20.74 with SMTP id l10mr5912264pbe.150.1367442649272; Wed, 01 May 2013 14:10:49 -0700 (PDT)
Received: from [192.168.10.114] (ginger.tokbox.com. [216.38.134.117]) by mx.google.com with ESMTPSA id ze11sm5045104pab.22.2013.05.01.14.10.47 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 01 May 2013 14:10:48 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Gustavo_Garc=EDa?= <ggb@tokbox.com>
In-Reply-To: <5181819B.5050107@alum.mit.edu>
Date: Wed, 1 May 2013 14:10:46 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <18B3B548-95DC-43D2-BB05-619EC8EBDA70@tokbox.com>
References: <E888F149-12FE-4F23-A270-F861123BAC7B@tokbox.com> <5181819B.5050107@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1283)
X-Gm-Message-State: ALoCoQngubhWJdBllJ1CRNxaLxTOQKclc4PYmeRlv3Yb7AwXTMoo1CHGlF7ANcE0PfhT/i4zkk8xQYQLHcIMzVJY/RzuvGZZItjshxLgR2GV72lQjxjRqw9Kafd4F3rDyYra3PzrUPjpUovI5bkeN9n8aalBplgkLw==
Cc: 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: Wed, 01 May 2013 21:11:04 -0000

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