Re: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?

Christian Groves <> Tue, 29 September 2015 06:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1B17B1A1B11 for <>; Mon, 28 Sep 2015 23:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f-9mZaLdtV7D for <>; Mon, 28 Sep 2015 23:29:36 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9CBBD1A1B0D for <>; Mon, 28 Sep 2015 23:29:36 -0700 (PDT)
Received: from ([]:51941 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from <>) id 1ZgoPr-0017wG-TK for; Tue, 29 Sep 2015 16:29:32 +1000
References: <>
From: Christian Groves <>
Message-ID: <>
Date: Tue, 29 Sep 2015 16:29:29 +1000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?
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: Tue, 29 Sep 2015 06:29:39 -0000

Hello Christer,

I'm for keeping it simple and having a specific dtls_connection attribute.

Regards, Christian

On 18/09/2015 4:48 PM, Christer Holmberg wrote:
> Hi,
> Currently the draft-ietf-mmusic-dtls-sdp defines the usage of existing 
> SDP "connection" attribute for DTLS. The attribute is used to 
> explicitly indicate whether a new DTLS association shall be created or 
> not.
> One of the open questions is whether we should use existing 
> "connection" attribute for this purpose, define a new attribute 
> (working name: "dtls_connection") with similar semantics, or design a 
> new usage which is more robust in cases of 3PCC.
> Why would we use a different attribute?
> In most cases (e.g. UDP/DTLS) existing "connection" attribute works 
> well. However, if you layer other connection oriented protocols over 
> DTLS (e.g. ‘SCTP/DTLS’ or ‘UDP/DTLS/SCTP’) "connection" attribute 
> would apply to both the SCTP *and* DTLS layer. This might be an 
> acceptable usage, but are there use cases when DTLS connection would 
> need to be re-established, but SCTP connection still maintained?
> There are also more exotic use cases, when DTLS is layered over 
> connection oriented protocols (e.g. ‘TCP/DTLS/SCTP’). In such cases 
> "connection" attribute would apply to the SCTP *AND* the DTLS *AND* 
> the TCP layer.
> Having a dedicated attribute would allow separate control over the 
> DTLS layer. E.g. in the case of ‘UDP/DTLS/SCTP’ it would be possible 
> to re-establish the SCTP association without touching the DTLS 
> association.
> Another option is to define a "ufrag" which identifies an end point in 
> DTLS association (working name: "dtls_ufrag"). Each endpoint in the 
> offer/answer exchange would generate its own "dtls-ufrag". If either 
> "dtls-ufrag" values changed, then new DTLS association would need to 
> be established.
> Why would we need something like this?
> ICE and 3PCC and oferless INVITEs. When ICE end point responds to an 
> offer-less INVITE, it will allocate new ufrag, collects the full set 
> of ICE candidates, but would still like to keep the existing DTLS 
> connection and local ICE candidates which it is currently using. It 
> will send the response with the generated answer with all this 
> information, but the value for old style "connection" SDP attribute is 
> unclear. If value "connection:new" is specified, none of the existing 
> ICE candidates can be used, complete new set would need to be 
> allocated to prevent transport pair reuse for multiple DTLS 
> associations, and new DTLS association would need to be created even 
> if the same two end-points get reconnected. If value 
> "connection:existing" is used, then existing DTLS association and 
> candidates can be used, but the generated offer cannot be used as an 
> initial offer to the new end point.
> If "dtls_ufrag" value is used, then in response to offer-less invite 
> the existing value of this attribute will be provided in the generated 
> offer. The answering party, if it is an end point which is already 
> communicating with the current end-point can respond with its current 
> "dtls_ufrag" value and the existing DTLS association will be re-used. 
> If answering party is a new end point which was not part of the 
> existing DTLS association, it will reply with new value of 
> "dtls_ufrag". Since one of the values changed, a new DTLS association 
> will be established. There is no risk of transport re-use for several 
> DTLS associations, since answering party will allocate a complete new 
> set of ICE candidates.
> What do you prefer, wasting resource in response to offer-less invite 
> and allocating a complete new set of ICE candidates every time such 
> INVITE is receive or dealing with a more complex attribute semantics?
> Comments? Preferences?
> Regards,
> Christer
> _______________________________________________
> mmusic mailing list