Re: [MMUSIC] Draft new version: DTLS-SDP-01

Paul Kyzivat <> Mon, 19 October 2015 21:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6AC3C1B2D1F for <>; Mon, 19 Oct 2015 14:41:42 -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 GNO9Q383JFye for <>; Mon, 19 Oct 2015 14:41:41 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D5FA1B2CFB for <>; Mon, 19 Oct 2015 14:41:12 -0700 (PDT)
Received: from ([]) by with comcast id X9h81r0062VvR6D019hCbe; Mon, 19 Oct 2015 21:41:12 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id X9hB1r00U3Ge9ey019hC1u; Mon, 19 Oct 2015 21:41:12 +0000
References: <>
From: Paul Kyzivat <>
Message-ID: <>
Date: Mon, 19 Oct 2015 17:41:10 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1445290872; bh=z919HjaBWgawShqxFulY+PH2vc9QOWlHyLsSAipcU+w=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=gtCsIH65rWTKBHcGCdytY+iHN0QJP9KyK+Ce9Pp5wiF78jKuZaLrkoH4+xVO/ZH2i ACHCnt1+NNLRRCyz4iCMgeIqrqqwjZ/uY75r1lgsEyLiZAozrZZR7UC4CRy6RIv2Ay +x5/QQPx/3JFfzEyjRU+cqmCYNIFjMcJHozWVBYk6+E48H4CzVQ2agONvcYCmyWLe8 oGokzxIWlT6rfbSTyXYVQTwzAglHrBeU3+cYQOFRvfazFvCgf1p4AvSQrlSTrH/06V C8WNBNsx33R8cGNdU0yPH4kSbv5RT5jajbAa8yJCy8ZdJF0ZqlonQs7rggkUaqPsNj F9xmuP54YMHlw==
Archived-At: <>
Subject: Re: [MMUSIC] Draft new version: DTLS-SDP-01
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: Mon, 19 Oct 2015 21:41:42 -0000

A few comments while reading it:

* Section 5.1 vs. 6.2:

For the initial offer of a DTLS m-line there isn't any option whether to 
establish a DTLS association - one is going to be established. Section 
5.1 says use of dtls-connection is optional, but 6.2 says it is 
required. Which is it?

* Section 6.3:

There seems to be an bug in this text:

    If an answerer receives an offer that contains an SDP 'dtls-
    connection' attribute with a 'new' value, the answerer MUST insert a
    'new' value in the associated answer.  The same applies if the
    answerer receives an offer that contains an SDP 'dtls-connection'
    attribute with a 'new' value, but the answerer determines (based on
    the criteria for establishing a new DTLS association) that a new DTLS
    association is to be established.

IIUC, in "The same applies ... with a 'new' value" the 'new' should be 
'existing'. Otherwise it simply reiterates the prior sentence. This 
particularly includes the case when the answerer has no existing 

    If a new DTLS association is to be established, and if the answerer
    becomes DTLS client, the answerer MUST initiate the procedures for
    establishing the DTLS association.  If the answerer becomes DTLS
    server, it MUST wait for the offerer to establish the DTLS

Isn't there a timing problem here? What if this case applies, but the 
offerer won't know it until receiving the answer? (I.e., when the offer 
contained 'existing'.) In that case the messages to initiate might 
outrun the answer, and arrive before the offerer is ready for them.

In section 8:

    It is possible to send an INVITE request which does not contain an
    SDP offer.  Such INVITE request is often referred to as an 'empty
    INVITE', or an 'offerless INVITE'.  The receiving endpoint will
    include the SDP offer in a response associated with the response.
    When the endpoint generates such SDP offer, it MUST assign an SDP
    connection attribute, with a 'new' value, to each 'm-' line that
    describes DTLS protected media.  If ICE is used, the endpoint MUST
    allocate a new set of ICE candidates, in order to ensure that two
    DTLS association would not be running over the same transport.

Can you explain your thinking here? This makes sense if the response is 
the initial offer. But if there has been a prior O/A in the dialog, then 
this doesn't seem right to me.