Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 21 October 2014 17:09 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 916AF1A03AB for <mmusic@ietfa.amsl.com>; Tue, 21 Oct 2014 10:09:16 -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 fBBUQB1WvQOp for <mmusic@ietfa.amsl.com>; Tue, 21 Oct 2014 10:09:13 -0700 (PDT)
Received: from resqmta-po-03v.sys.comcast.net (resqmta-po-03v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:162]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2178C1A03FF for <mmusic@ietf.org>; Tue, 21 Oct 2014 10:09:06 -0700 (PDT)
Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-03v.sys.comcast.net with comcast id 5t8d1p0044yXVJQ01t96ka; Tue, 21 Oct 2014 17:09:06 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-06v.sys.comcast.net with comcast id 5t951p00R3Ge9ey01t954z; Tue, 21 Oct 2014 17:09:06 +0000
Message-ID: <54469331.4080307@alum.mit.edu>
Date: Tue, 21 Oct 2014 13:09:05 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <7594FB04B1934943A5C02806D1A2204B1D4A6DEB@ESESSMB209.ericsson.se> <54453FD1.9070207@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4BB448@ESESSMB209.ericsson.se> <5446803D.80405@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4BFA92@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4BFA92@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1413911346; bh=iBfTmw6ylZOeTF2QxXHcjbf1E3UPyd3Fo9oj7a8gsD0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eNWr0k6gdcvvkyZ4ayfwOX0wLOLFr1ypCa23GURQbiFzCcJflVprD06tQgy+i/Uzd +3JZr5iY95GhOrFZn6b8o/U3T/YVxcUzmGiKJ4I0gxGaEl2Bto37GY5wXEG71AmDIM tAExU4eOsQMjr5WZtq1LlN7kVdjFA6rnYPprhcuyoDixlbriD1EOYK+LWu1quRV5vP RTERMsEBdRg5Y/TLQE8LHAM/FvbVBxx4eedlXnVnhERCv2/p63UGazOAXUcrKCnBda szeUlC1kiElBFYv5rCNlbTJ7xejTK4PfdPpXZJVD8qgbVUixj48xwDe+KD1Z+7jhMm C1+G5GAebyRiA==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/f7CJFoXgQGTfZjnU7Fl0p92CNbY
Cc: IETF MMUSIC WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments
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: <http://www.ietf.org/mail-archive/web/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: Tue, 21 Oct 2014 17:09:17 -0000

On 10/21/14 12:29 PM, Christer Holmberg wrote:

>>>>> What would you like to mention about SCTP?
>>>>>
>>>>>> IIUC, DTLS/SRTP uses DTLS packets to do key exchange, but doesn't
>>>>>> use DTLS payload packets. So *one* m-line with a protocol that uses
>>>>>> DTLS payload packets (e.g., >DTLS/SCTP) can coexist with STUN and
>>>>>> SRTP. If there is more than one such m-line then some other specification is required to associate those packets with m-lines.
>>>>>
>>>>> I think that is covered, as SRTP is distinguished from DTLS.
>>>>>
>>>>> But, if you think that needs to be more clear, maybe the following modified sentence:
>>>>>
>>>>> 	"[RFC5764] does not describe how to identify different protocols transported on DTLS (i.e. using DTLS payload packets), only how to..."
>>>>
>>>> I think this document should bite the bullet and define how SCTP coexists with SRTP in a bundle.
>>>
>>> Personally, I would not want to do that at this stage. We decided earlier that the draft will cover
>>> DTLS, SRTP and STUN, and that any other protocols/combinations have to be defined elsewhere.
>>
>> If it isn't here, then it needs to be somewhere else. Where?
>
> In a separate draft.
>
>> It shouldn't be hard.
>
> Who is asking for it? RTCWEB will not support SCTP transport (they will support SCTP over DTLS).

I'll be satisfied if it covers SCTP over DTLS. That is the case where it 
needs to be able to coexist with RTP.

	Thanks,
	Paul