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

Paul Kyzivat <> Thu, 01 October 2015 16:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 267111B2DCE for <>; Thu, 1 Oct 2015 09:20:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qjCbwTVC1THH for <>; Thu, 1 Oct 2015 09:20:32 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7C0CB1B2DCD for <>; Thu, 1 Oct 2015 09:20:32 -0700 (PDT)
Received: from ([]) by with comcast id PsLA1r0082Ka2Q501sLXLe; Thu, 01 Oct 2015 16:20:31 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id PsLX1r0043Ge9ey01sLX7X; Thu, 01 Oct 2015 16:20:31 +0000
To: Roman Shpount <>
References: <> <> <> <> <> <>
From: Paul Kyzivat <>
Message-ID: <>
Date: Thu, 01 Oct 2015 12:20:30 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1443716431; bh=AnwUUlFXnPQfsEHRXgFWQfUrXJH9bn+sTCLtX9xR3OE=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=iSvJQN4EI5Uf3Yj82eo4eIoZBTfoWRRi0KuTAGkCUd97YdGjACCax1Ug/5obNagQh QMBOwKdM0tJs0eX6N6wjNse0nUg1TDTIQMPvRero3mVmvGTK+VvUKo/qV2VcJqGm5H IgkB9aakRTsop4RCRuJc8ITIw0tHWMoCHQ101O3JFxTIG4jgruPiOnrQ2MCCAFOjNJ bYVHO0a3BixidfDyTzjRslgclfg+Z8s2cvYtkax+JHJZX/uHQ/N7+tvQIJaGUWELQ6 h42Xo0KMDdhWZt6ovj5mZCnEAlBS/95CWzYmkBZXCME7eD/HHlwP5LaQK2yCRTE4Ma 5y/1h+0upTvTg==
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 16:20:34 -0000


On 9/29/15 6:27 PM, Roman Shpount wrote:
> On Tue, Sep 29, 2015 at 5:26 PM, Paul Kyzivat <
> <>> wrote:
>         This proposal is good except that it is unclear how to deduce which
>         version of connection or setup attribute is supported by the
>         remote end
>         point. Without such indication there is a high chance that
>         remote end
>         point will not be able to correctly parse and process the
>         connection or
>         setup attribute with transport suffix.
>     Can you clarify what situation you are concerned about?
>     As long as we are defining behavior for cases that aren't currently
>     supported at all, then it is simply a matter of writing the specs
>     the way we want them.
>     Are you concerned with backward compatibility with implementations
>     in the wild?
> I am concerned about existing implementations which are currently in the
> wild. There are plenty of implementations that do support "setup"
> attribute for DTLS (including all the WebRTC enabled browsers). If
> existing "setup" attribute would be extended to include the protocol
> suffix it will not be properly handled by current implementations.

Yes, that is a potential issue with extending the syntax of an existing 
attribute that wasn't specified with a hook for extensions.

> 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.)

Once we get RFCs in place for this we can assume that those who conform 
to the RFCs will support whatever is specified. Those that don't support 
the rfc defining the new attribute should must it.

I do recognize that there are pre-rfc implementations in the field and 
we need to avoid breaking them. But I think that could be handled by 
having existing implementations start using *both* for awhile to handle 
the transition.

> On the other hand we can definitely use protocol attribute syntax for
> the connection attribute for DTLS, since this behavior is not defined
> anywhere yet.
> 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.