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

Roman Shpount <> Tue, 29 September 2015 22:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A83F31B54CF for <>; Tue, 29 Sep 2015 15:27:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id t5Wafn0xyLTh for <>; Tue, 29 Sep 2015 15:27:36 -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 577611B54CE for <>; Tue, 29 Sep 2015 15:27:36 -0700 (PDT)
Received: by ioii196 with SMTP id i196so27674441ioi.3 for <>; Tue, 29 Sep 2015 15:27:35 -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=A/tbtS8BwCA80yVBLGXcwmVYsmzGuLblNP0tAEX2oSA=; b=PgKdOxtbVbJOrWTvOpLYS4KcVONCJjWA/qIHlTtO4j8YaB8MoO14XD0dgAMkO1fTo3 nmNjy92OJsu5cKJtx+SrTMoTbfB/QSg2Qm/F9qt+kGFUYd29dWXPIWdEXYCRliehySQI y1BaPhaK65QP3q1wS/9/m0T2yhxQ1Fh45u14gvReImjF0+MgyhUVwqIUe5idrGvyt9rq hrZ90toShNh/jtL20ufSRgz+wDmG8/5uhGoLo5JowWU9dEvTI/iqoiMcdP7V1QdNmekR C0BnvCrFelnSZYnhNpFgb9tcG5aVXT9KjAANKYFQSTjaKaF8aHvWM0odGzrxHh8GZ5YO uiXg==
X-Gm-Message-State: ALoCoQmZ+cGi3EZ4SWoevcnsz1EwusQMNE0341ksqiaPjTZ8N+WjlzAnKt8RR4RLAb0WX8zsgYIs
X-Received: by with SMTP id 81mr1184345ioj.191.1443565655593; Tue, 29 Sep 2015 15:27:35 -0700 (PDT)
Received: from ( []) by with ESMTPSA id n68sm12122595ion.26.2015. for <> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Sep 2015 15:27:34 -0700 (PDT)
Received: by igbkq10 with SMTP id kq10so88267057igb.0 for <>; Tue, 29 Sep 2015 15:27:34 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id k2mr25777488igv.96.1443565654151; Tue, 29 Sep 2015 15:27:34 -0700 (PDT)
Received: by with HTTP; Tue, 29 Sep 2015 15:27:34 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Tue, 29 Sep 2015 18:27:34 -0400
Message-ID: <>
From: Roman Shpount <>
To: Paul Kyzivat <>
Content-Type: multipart/alternative; boundary="089e01184e1a06bd240520ea5272"
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: Tue, 29 Sep 2015 22:27:37 -0000

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. If setup attribute is used
with protocol prefix, it is unclear if it will be correctly recognized by
the remote party.

On the other hand we can definitely use protocol attribute syntax for the
connection attribute for DTLS, since this behavior is not defined anywhere

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.

Roman Shpount