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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 22 October 2014 14:30 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 65D791ACC88 for <mmusic@ietfa.amsl.com>; Wed, 22 Oct 2014 07:30:35 -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 JzbepAwZoU6y for <mmusic@ietfa.amsl.com>; Wed, 22 Oct 2014 07:30:34 -0700 (PDT)
Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0C31ACCE3 for <mmusic@ietf.org>; Wed, 22 Oct 2014 07:30:30 -0700 (PDT)
Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-07v.sys.comcast.net with comcast id 6EVl1p0065Clt1L01EWW08; Wed, 22 Oct 2014 14:30:30 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-17v.sys.comcast.net with comcast id 6EWU1p00V3Ge9ey01EWUaB; Wed, 22 Oct 2014 14:30:30 +0000
Message-ID: <5447BF84.6030902@alum.mit.edu>
Date: Wed, 22 Oct 2014 10:30:28 -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> <54469331.4080307@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4C14AB@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4C14AB@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=1413988230; bh=CBmxa16lUJ+KDcDq5KJPglSPkM3OpebRTY3fCN+UNdY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=T3U/rV+ZAmTkjh3iehmBkMl/mLiecZIpBOqvcw9v0YBvCEfBo3t82aw+a4TEgE0pv vZKo1vbbsTsC7N/D6it1XeKTigcfCk5RzYOPqd0SG/d2W4y6Cftv0knW6KJfKSwTTH AU6J4TUWqtC9jMCWFt1WLrK8yn685WVJAB4vJoMateRi73PEi82TNEaVCwcIfTCXYH mW1uBk821mqs+o6kTUVdOlJzVqyDDNVzMgNiXc/GAwKG9hOc+lE0a1Nr2kLQB7Ipok coFYM6zfVtPwT/9WLtJwid4dBh27WDelzNWo4iUluwTKDaB6pkl9xUIFnyKlxLaJe7 7O8wVgTf+Z5hw==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/kK6-_uK15p1tU1_eGbrqzWZ0wXw
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: Wed, 22 Oct 2014 14:30:35 -0000

On 10/22/14 5:56 AM, Christer Holmberg wrote:
> Hi,
>
>>>>>>> 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.
>
> The draft describes how you distinguish between DTLS and SRTP, so that also covers SCTP over DTLS (SCTP is the "application protocol" carried on DTLS).
>
> How you differentiate different protocols carried over DTLS need to be described elsewhere, but if you only have SCTP carried over DTLS nothing else is needed.
>
> In addition, if you want to define how to separate SCTP from something else, you would need to know what that something else is.

The draft describes how to distinguish DTLS and SRTP packets. It doesn't 
describe how to associate the DTLS packets with m-lines.

Rather than single SCTP over DTLS out as special, this draft could 
simply say that:

- if the bundle contains *no* m-lines for protocols that utilize DTLS
   payload packets then DTLS payload packets are erroneous.

- if the bundle contains *one* m-line for a protocol that utilizes
   DTLS payload packets then all the payload packets are to be
   associated with it.

- if the bundle contains *more than one* m-line for protocols that
   utilize payload packets then some other specification is needed
   to define how the packets are associated with m-lines.

	Thanks,
	Paul