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

Roman Shpount <> Thu, 01 October 2015 19:32 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1BDB31B2EB4 for <>; Thu, 1 Oct 2015 12:32:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_24=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jwcTy_cAEQAh for <>; Thu, 1 Oct 2015 12:32:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ACA8B1B2EB3 for <>; Thu, 1 Oct 2015 12:32:05 -0700 (PDT)
Received: by iofh134 with SMTP id h134so97713358iof.0 for <>; Thu, 01 Oct 2015 12:32:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=F//8EnFena5WOAKQEinJ8RyZDNiAO76hdbWeGPcnmlE=; b=OgmU0szKnf/VsGkBtzINj7Z2KNNhZP/AkFWudF0eRvi8fcFmbRCTpWvTqSLWS/+kKb xxAfO0zO65lSg5jP0hkUQoALAjHYPiDfpQ855wMCSUVrFibGKMxps+OpnIsdcAQ16n4Y WHYmnZ5x/XJj8e+b4iHS7G4u6RgAV7cSDPq/HtUchWPIGc43bABOR3Q+u0XHN+CcsvB2 LniJj6UTr1OJKgAG9uOqKZ1csrSEJmFRdNsF+w0ybFof3pbZVxWeC5YDKKi/lY+59sUR f02HORWP1fV7GNazZSGTLRmwkLaJLs/HpgT2lQWCp+K9FGZ90GWhRhvvZojCvjU3I756 VXVQ==
X-Gm-Message-State: ALoCoQlELl4d8qmr7P4ZGy60G7FDlDudI5GW8JfwgcnI28clZlQ9ZqxWAXDHLDhx8UrUpQQjVZ40
X-Received: by with SMTP id h38mr9491950iod.1.1443727924857; Thu, 01 Oct 2015 12:32:04 -0700 (PDT)
Received: from ( []) by with ESMTPSA id 92sm3366608ioq.3.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Oct 2015 12:32:03 -0700 (PDT)
Received: by ioiz6 with SMTP id z6so97267737ioi.2 for <>; Thu, 01 Oct 2015 12:32:03 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id l89mr12430387iod.38.1443727923264; Thu, 01 Oct 2015 12:32:03 -0700 (PDT)
Received: by with HTTP; Thu, 1 Oct 2015 12:32:03 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Thu, 01 Oct 2015 15:32:03 -0400
Message-ID: <>
From: Roman Shpount <>
To: Paul Kyzivat <>
Content-Type: multipart/alternative; boundary="001a113ebdb404d60c0521101a92"
Archived-At: <>
Cc: "" <>
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: Thu, 01 Oct 2015 19:32:13 -0000

On Thu, Oct 1, 2015 at 12:20 PM, Paul Kyzivat <> wrote:

> If
>> setup attribute is used with protocol prefix, it is unclear if it will
>> be correctly recognized by the remote party.
> Am I right that there is no rfc specifying use of the setup attribute with
> dtls? (The IANA registry only has rfc4145 covering TCP.)

RFC 5763 seciont 5 (
specifies how SDP setup attribute is used when DTLS association is
established. So, we are dealing with existing, standard compliant

> Also, please let me know if you need a more detailed explanation of
>> dtls_ufrag option and its rational or if you simply need more time to
>> get it sorted out.
> I haven't seen a clear explanation - just a couple of sentences in an
> email.
> But as best I understand it, I find it disturbing. It entangles dtls with
> ICE, even though the two are separate layers.

Let me try to explain this again:

The "dtls-ufrag" has little to do with ICE and exists in a completely
different layer. We can call this attribute "dtls-connection-id" if this
will makes it less spooky. The problem that I am trying to resolve with new
attribute is related to when new DTLS association needs to be established.
I would argue that original intent was, that new DTLS association needs to
be established on change of one of the end points or DTLS association setup
attributes (setup role or fingerprint).

Originally, end point change was detected based on transport 5-tuple
change. This, of cause, does not work for ICE, where 5-tuple is not known
in advance and all 5-tuples associated with the same ICE component should
be treated as the same connection. One option was to detect end point
change when ICE is used based on ICE ufrag change, but this does not work
either since ufrag can change due to ICE restart, but the same end points
will continue to communicate.

I would also argue that setting up new DTLS association on 5-tuple change
does not always work for non-ICE case either, since we can have an end
point which can initiate a re-INVITE when it detects the local IP changes
due to DHCP lease expiration or any other reason. This transport change
does not necessarily require DTLS association change, and new DTLS
handshake is undesirable since it will delay the media flow
re-establishment but several network round trips.

So, we need to detect when two new end-points are communicating and new
DTLS association needs to be setup. What we originally proposed is that end
point will simply tell that it is setting up a new session by using SDP
connection attribute or some renamed version of it.

What I am saying here is that end point cannot always identify if it needs
to setup a new DTLS association. The problem arises when new offer is
generated in response to an offerless INVITE. In such case, an end point
does not know if it is continuing to communicate with the same end-point or
if this offer is intended to be sent to a new end point.

There are two solution possible to this:

1. We specify that if an end points generates an offer in response to an
offer-less INVITE it should always assume it is communicating with a new
end point, it MUST add "connection:new" and MUST make sure that none of the
existing transports can be possibly reused for this new DTLS association by
allocating new IP:port for non ICE or a complete new set of ICE candidates
in case of ICE. This will work, but it is wasteful when offer-less INVITE
re-establishes connection between two existing end points. In such cases
additional ports will be consumed, TURN tunnels will be allocated, and time
spent on creating a DTLS session when all of this can be simply reused.

2. Instead of asking the end point which generates the offer to determine
if it is establishing a new DTLS association, we will ask the end point to
identify itself. So, instead of SDP connection attribute, an end point will
provide some sort of randomly generated end point identifier in the new
attribute (dtls-ufrag or dtls-connection-id). When the connection ID pair
stays the same, the existing DTLS association continues to run over the
negotiated transport. If one of the connection IDs changes, this would mean
new DTLS association would need to be established. This nicely uncouples
end point change identification from transport and makes negotiation follow
the original intent.

In case of response to an offer-less INVITE, an offer with the existing
connection ID will be generated. If this offer is sent to a new end point,
both end points will detect that new DTLS association is required due to
connection ID change of the answering end point. If this offer will be sent
to an end point which is already a part of the existing DTLS association,
no new DTLS association will be necessary, since both connection IDs will
stay the same.

This also gives us path to a more "strategic" solution in the future. DTLS
handshake can be extended to include the connection ID. Each DTLS handshake
can negotiate a association identifier similar to SSRC which can be used in
the all subsequent DTLS messages for this association. This way multiple
DTLS associations can be multiplexed over the single transport and each of
them can be tied to an m= line in offer/answer. This, of cause, is not part
of the current draft and is outside of MMUSIC chapter, but does provide a
natural extension path for DTLS in the future.

In general Christer and I are trying to understand if there is interest in
formalizing the dtls-connection-id option (more complex) or if we should
stick with SDP connection:new/existing attribute and force new DTLS
association always be established in response to offer-less INVITE (simpler
option but can waste resources).

Please let us know if these options need further clarification or if you
have any additional questions or opinions.
Roman Shpount