Re: [MMUSIC] Draft new version: DTLS-SDP-01
Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 19 October 2015 21:41 UTC
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AC3C1B2D1F for <mmusic@ietfa.amsl.com>; Mon, 19 Oct 2015 14:41:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GNO9Q383JFye for <mmusic@ietfa.amsl.com>; Mon, 19 Oct 2015 14:41:41 -0700 (PDT)
Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [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 ietfa.amsl.com (Postfix) with ESMTPS id 0D5FA1B2CFB for <mmusic@ietf.org>; Mon, 19 Oct 2015 14:41:12 -0700 (PDT)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-07v.sys.comcast.net with comcast id X9h81r0062VvR6D019hCbe; Mon, 19 Oct 2015 21:41:12 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-19v.sys.comcast.net with comcast id X9hB1r00U3Ge9ey019hC1u; Mon, 19 Oct 2015 21:41:12 +0000
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B37B6FFE9@ESESSMB209.ericsson.se>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56256376.1080602@alum.mit.edu>
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: <7594FB04B1934943A5C02806D1A2204B37B6FFE9@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; 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: <http://mailarchive.ietf.org/arch/msg/mmusic/13Xt3ZJM5Q-RnJu5MWwUAF_h_b4>
Subject: Re: [MMUSIC] Draft new version: DTLS-SDP-01
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=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 association. 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 association. 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. Thanks, Paul
- [MMUSIC] Draft new version: DTLS-SDP-01 Christer Holmberg
- Re: [MMUSIC] Draft new version: DTLS-SDP-01 Paul Kyzivat
- Re: [MMUSIC] Draft new version: DTLS-SDP-01 Roman Shpount