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

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 22 October 2014 14:45 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 219971ACC81 for <mmusic@ietfa.amsl.com>; Wed, 22 Oct 2014 07:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 lKGi7pXRDOTJ for <mmusic@ietfa.amsl.com>; Wed, 22 Oct 2014 07:45:47 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C206E1ACCF0 for <mmusic@ietf.org>; Wed, 22 Oct 2014 07:45:46 -0700 (PDT)
X-AuditID: c1b4fb30-f79e66d000000ff1-5e-5447c3188ee4
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3A.83.04081.813C7445; Wed, 22 Oct 2014 16:45:44 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.163]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Wed, 22 Oct 2014 16:45:44 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments
Thread-Index: Ac/uBhWayoCnWLriRvenEjuW3EILDQ==
Date: Wed, 22 Oct 2014 14:45:43 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4C18A0@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.149]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCLMWRmVeSWpSXmKPExsUyM+Jvja7EYfcQg/UHzSymLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj74M+9oK90hX/ujYxNjD+EO1i5OSQEDCR mLl4HzOELSZx4d56ti5GLg4hgaOMEm0Ni9ghnCWMEh17HwM5HBxsAhYS3f+0QUwRAQ2JSVvV QHqZBVQkXp2+zApiCwvESbTPns0OYosIxEvs/bmFCcLWk1h/sw2shkVAVeLY3SNgcV4BX4m9 +x+AxRmBbvh+ag0TxExxiVtP5jNB3CYgsWTPeag7RSVePv7HCmErSaw9vJ0Fol5HYsHuT2wQ trbEsoWvmSHmC0qcnPmEZQKjyCwkY2chaZmFpGUWkpYFjCyrGEWLU4uTctONjPRSizKTi4vz 8/TyUks2MQKj4eCW3wY7GF8+dzzEKMDBqMTDu4DfPUSINbGsuDL3EKM0B4uSOO/Cc/OChQTS E0tSs1NTC1KL4otKc1KLDzEycXBKNTB6+014NSXNaduHJbFvvl2+O3meanNv2o0ElbLA/b+f GtkyzxBQ1dH7PYv5QZTEhLX3l6rUGPu/ZJUR48tf9zpGz/ek1w0hl6ZPmvNF93ld5D93/dDP pD0ct3xWnjqwTrXtQ1uYL8fPmzy1WzyqV/CpSnQffhlhmTIpVOOMlq745kXz6hZ0P7yixFKc kWioxVxUnAgA3Lru32cCAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/L3PIqNx3ozKTVTomitwawL_1CZk
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:45:50 -0000

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.

Currently we have the following text in the draft:

   "[RFC5764] does not describe how to identify different protocols
   transported on DTLS, only how to identify the DTLS protocol itself.
   If multiple protocols are transported on DTLS, there MUST exist a
   specification describing a mechanism for identify each individual
   protocol."

I guess we could e.g. extend that by saying that the document does not
describe how to associated DTLS data with an m- lines, and that a separate
specification is needed to define that (basically the third bullet you suggest).

I don't think we need to say that receiving packets that you haven't negotiated is an error, because that applies to any type of non-negotiated protocols.

Regards,

Christer