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

"Schwarz, Albrecht (Albrecht)" <> Tue, 29 September 2015 08:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3BC591A3B9F for <>; Tue, 29 Sep 2015 01:24:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.31
X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZiAo8Fbt8B06 for <>; Tue, 29 Sep 2015 01:23:38 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E3CC21A3B9B for <>; Tue, 29 Sep 2015 01:23:35 -0700 (PDT)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id 49DD4F30E6BCE for <>; Tue, 29 Sep 2015 08:23:32 +0000 (GMT)
Received: from ( []) by (GMO) with ESMTP id t8T8NXUr005914 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Tue, 29 Sep 2015 10:23:33 +0200
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Tue, 29 Sep 2015 10:23:33 +0200
From: "Schwarz, Albrecht (Albrecht)" <>
To: "" <>
Thread-Topic: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?
Thread-Index: AdDx2gLCSWNnBQhESimZajIbwKOs+gIlWtiAAAgZAtA=
Date: Tue, 29 Sep 2015 08:23:33 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 08:24:54 -0000
X-List-Received-Date: Tue, 29 Sep 2015 08:24:54 -0000

Hello Christer,

there might be another approach by qualifying the "generic" attribute with protocol (stack) information.
Paul made a good proposal as far as I remember:

Re: [MMUSIC] SCTP-SDP: SDP connection attribute considerations 

=> a=setup ... and "And do the same thing for a=connection."


-----Original Message-----
From: mmusic [] On Behalf Of Christian Groves
Sent: Dienstag, 29. September 2015 08:29
Subject: Re: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?

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

mmusic mailing list