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

"Mo Zanaty (mzanaty)" <> Thu, 02 May 2013 04:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BAAC21F85CE for <>; Wed, 1 May 2013 21:04:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1GZTwrmMRXYd for <>; Wed, 1 May 2013 21:04:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9A17A21F867B for <>; Wed, 1 May 2013 21:04:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=7267; q=dns/txt; s=iport; t=1367467448; x=1368677048; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4Pv/QGLaebriOssEbl9F/4MNBYY41kVzVP5qOsijqAE=; b=fFt6mYdOGJAd21RbQK7PkTcmmat/Ww9pq5dACBhfJgPrf5bLjLtzPr1F 5F+mPTAD69c5ccFQl7tXkP6kQPye4aLRKjL0Bp0413YrpDlRSbgBPMo7v bz4QBgAIojfNIrzGbUe0X1t2QFSuMZ0c/EY2GPXIwsb+BiAmR3gzZScXy 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="4.87,593,1363132800"; d="scan'208,217"; a="205244460"
Received: from ([]) by with ESMTP; 02 May 2013 04:04:08 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r42448lZ015494 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 May 2013 04:04:08 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.004; Wed, 1 May 2013 23:04:07 -0500
From: "Mo Zanaty (mzanaty)" <>
To: Justin Uberti <>
Thread-Topic: [MMUSIC] DTLS-SRTP client/server role negotiation
Thread-Index: AQHORq6jUvZFEriikUyEO6sxlAqo8pjxJyYAgAAVMYCAAAp7+g==
Date: Thu, 2 May 2013 04:04:07 +0000
Message-ID: <>
References: <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative; boundary="_000_7984C671D3FF4CC3AC4A9965087DD07Eciscocom_"
MIME-Version: 1.0
Cc: Paul Kyzivat <>, "" <>
Subject: Re: [MMUSIC] DTLS-SRTP client/server role negotiation
X-Mailman-Version: 2.1.12
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, 02 May 2013 04:04:19 -0000

A simple 3PCC/B2BUA only delays offers toward one leg like RFC3725, so the other leg will answer with active or passive but not actpass.

A complex 3PCC/B2BUA delays offers toward both legs, so it must analyze and alter SDP in complex ways to generate two answers from two offers, part of which is deciding which answer should become active and which should become passive.

The flow in RFC 5245 B.11 is oversimplified. SDP can't be forwarded unaltered by a B2BUA which delays offers on both legs. Generating two answers from two offers is much more complex than simply forwarding the offers as answers.

DTLS-SRTP is actually an easy case since RFC 5763 requires offers to be actpass. TCP is harder since RFC 4145 allows offers to be active, passive, or actpass, causing more complex reinvites to resolve active/active or passive/passive conflicts.


On May 1, 2013, at 6:28 PM, "Justin Uberti" <<>> wrote:

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 <<>> 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 mailing list<>

mmusic mailing list<>