Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question

Christer Holmberg <christer.holmberg@ericsson.com> Mon, 06 October 2014 07:09 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 CBE191A1B43 for <mmusic@ietfa.amsl.com>; Mon, 6 Oct 2014 00:09:48 -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 6I9lo8ZpJnjK for <mmusic@ietfa.amsl.com>; Mon, 6 Oct 2014 00:09:45 -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 2122C1A1B40 for <mmusic@ietf.org>; Mon, 6 Oct 2014 00:09:44 -0700 (PDT)
X-AuditID: c1b4fb30-f79736d0000053b8-89-54324036fefd
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A6.38.21432.63042345; Mon, 6 Oct 2014 09:09:42 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.136]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0174.001; Mon, 6 Oct 2014 09:09:42 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Christian Groves <Christian.Groves@nteczone.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question
Thread-Index: AQHP3Kfo2bDak4IaK0OoRO9p0kjlCJwZfrEAgAE5WgCAAARMgIAAYywg///wCgCAACI0IIAAhosAgAAFFYCAANFFoIAFyIGAgABUJqA=
Date: Mon, 6 Oct 2014 07:09:41 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1D4692C9@ESESSMB209.ericsson.se>
References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <7594FB04B1934943A5C02806D1A2204B1D46209F@ESESSMB209.ericsson.se> <786615F3A85DF44AA2A76164A71FE1AC337882@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D462276@ESESSMB209.ericsson.se> <542C8452.1030206@nteczone.com> <542C8895.6080408@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4634D8@ESESSMB209.ericsson.se> <54321211.2010804@nteczone.com>
In-Reply-To: <54321211.2010804@nteczone.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.147]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvja6Zg1GIwZejJhZf3jeyWExd/pjF gcljyZKfTB4rzs9kCWCK4rJJSc3JLEst0rdL4Mpo25JWsDqgYuaDg8wNjB8duxg5OCQETCT+ vdbuYuQEMsUkLtxbz9bFyMUhJHCUUeLKgx4WCGcxo0THulvsIA1sAhYS3f/AGkQEoiUmLWxm A7GFBXwk/px8yA4R95VY1XuVEcIuk+jcORHMZhFQkVjx+jGYzQtUc+/yWaj5S1gk1m9pZgZJ cAroSGzpnA5WxAh00fdTa5hAbGYBcYlbT+YzQVwqILFkz3lmCFtU4uXjf6wQzyhJTNuaBlGu I7Fg9yc2CFtbYtnC18wQewUlTs58wjKBUXQWkqmzkLTMQtIyC0nLAkaWVYyixanFSbnpRkZ6 qUWZycXF+Xl6eaklmxiBMXJwy2+DHYwvnzseYhTgYFTi4U3YbxgixJpYVlyZe4hRmoNFSZx3 4bl5wUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYJ3ScjXtTejK0IHh/nusH4UN8S1ikDgod +Fm3+Nnry09LFTcvW3D02FaOLNHHC5oEXXovlnZOZev3W9q9Lutc5ubv6Tus9B9qX3rdUmml 8y33UtC9v0s/J60TSBP33lATfaB4lbDRMvmtPILfayfMfhaduI2JtZzbI+XlpMP9iwS/iX0r m9mySImlOCPRUIu5qDgRAJUBr/xyAgAA
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/33HssYxYTp__AcVTe1e3GdfS-k8
Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question
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: Mon, 06 Oct 2014 07:09:49 -0000

Hi,

>>>> I'm happy to use to m-lines. I think it would be good to have 
>>>> something in the draft describing the usage of multiple DTLS/SCTP 
>>>> m-lines (with the same port) so that its clear that's the intention.
>>> The thing is - it would be bad to give an example using bundle while 
>>> there is no definition of how bundle works for that. (It is not 
>>> included in the bundle spec.)
>>>
>>> That would mean adding the interaction with bundle into this draft, or in a new draft. While that is possible, do we want to take that on now?
>>>
>>> This would be a good time for Christer to chime in. :-)
>> As Paul said, BUNDLE does not specify the usage of multiple DTLS m- lines within a BUNDLE group, and explicitly says that such usage would have to be defined in another specification.
>>
>> Personally, I'd be quite surprised if people started to transport BFCP, MSRP etc over DTLS/SCTP. People haven't used SCTP for that in the past, so why would they suddenly start now?
> [CNG] It seems now people are being forced to use to SCTP due to interoperation with WebRTC. They may want to run over a secure association etc. There will be new protocols that will be defined.

Currently WebRTC only defines the usage of SCTP for the data channel.

>> I think DTLS/SCTP is going to be used mainly for data channel usage, and one can then define data channels to transport whatever (including BFCP and MSRP).
> [CNG] Mainly or only? If its mainly then there's a possibility to run something else in another SCTP association. If this "something else" 
> runs in across a separate SCTP association on a seperate DTLS port then its no issue. If this "something else" is a separate SCTP association on the same DTLS port then it is an issue. 
> There has been a suggestion to use bundle, but bundle doesn't cover this. 

The core BUNDLE spec doesn't cover it, but someone can write an extension which defines how it is done. 

> I think the draft should offer some guidance or at least highlight the issues with respect to this.

I do agree that some words about why only a single SCTP association usage is allowed would be good.

>With regards to the data channels if I do as you say and use datachannels for bfcp and msrp in the one DTLS/SCTP association. How would I go about signalling that via SDP?
>
>Do I use the same method as CLUE and define a group for each of these? Do I use ejzak? Do I use both? CLUE decided that it didn't need to consider other protocols. 
>However shouldn't the scope of the mmusic work be to look at the scenarios where you could have multiple protocols?

Currently, there is no generic way to signal the datachannel usage in SDP. The ejzak draft defines SDP attributes for doing that, but the draft hasn't taken off. 

Regards,

Christer



>> On 1/10/2014 10:45 PM, Christer Holmberg wrote:
>>> My mistake: I meant SCTP association, which then can contains 
>>> multiple SCTP streams.
>>>
>>> Sorry for the confusion.
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> -----Original Message-----
>>> From: Schwarz, Albrecht (Albrecht)
>>> [mailto:albrecht.schwarz@alcatel-lucent.com]
>>> Sent: 1. lokakuuta 2014 15:43
>>> To: Christer Holmberg; Christian Groves; Salvatore Loreto
>>> Cc: <mmusic@ietf.org>
>>> Subject: RE: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax 
>>> question
>>>
>>>> I think we need to be careful with the terminology.
>>>> As far as I understand, the m- lines describes an SCTP connection - 
>>>> not an SCTP association - and the sctp-fmt defines the usage of 
>>>> that SCTP connection.
>>> Christer,
>>> there isn't any concept of an "SCTP connection" (see RFC 4960)!
>>> Rather SCTP association, SCTP path, SCTP stream.
>>>
>>> If you are refering implicitly to the OSI concept of a 
>>> (N)-connection (ITU-T X.200), then an OSI (SCTP)-connection would be 
>>> mapped to the IETF SCTP association in my understanding.
>>>
>>> Regards,
>>> Albrecht
>>>
>>> PS
>>> Perhaps you mean sth like, ".. the m- lines describes an IP 
>>> transport connection for SCTP, which relates to an SCTP association ..."
>>>
>>>
>>> -----Original Message-----
>>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christer 
>>> Holmberg
>>> Sent: Mittwoch, 1. Oktober 2014 13:43
>>> To: Christian Groves; Salvatore Loreto
>>> Cc: <mmusic@ietf.org>
>>> Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax 
>>> question
>>>
>>> Hi,
>>>
>>> I think we need to be careful with the terminology.
>>>
>>> As far as I understand, the m- lines describes an SCTP connection - 
>>> not an SCTP association - and the sctp-fmt defines the usage of that 
>>> SCTP connection.
>>>
>>> Depending on the usage, there may then be multiple SCTP associations
>>> - for example as in the case of a data-channel connection usage, 
>>> where the number of SCTP associations will depend on the number of 
>>> data channels.
>>>
>>> So, if you want to use BFCP and MSRP, my understanding is that you 
>>> would need two m- lines (unless, of course, you transport BFCP and 
>>> MSRP within data channels).
>>>
>>> Regards,
>>>
>>> Christer
>>>
>>> -----Original Message-----
>>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian 
>>> Groves
>>> Sent: 1. lokakuuta 2014 10:45
>>> To: Salvatore Loreto
>>> Cc: <mmusic@ietf.org>
>>> Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax 
>>> question
>>>
>>> Hello Salvatore,
>>>
>>> Thanks for the replies. Please see some comments below.
>>>
>>> Regards, Christian
>>>
>>> On 1/10/2014 5:29 PM, Salvatore Loreto wrote:
>>>> Hi Christian,
>>>>
>>>> thanks a lot for reading and reviewing the draft see more in line
>>>>
>>>> On Sep 30, 2014, at 3:48 PM, Christian Groves 
>>>> <Christian.Groves@nteczone.com> wrote:
>>>>
>>>>> I seemed to have got cut and paste happy in 1) below. The "1*(SP 
>>>>> sctp-fmt)" should only apply to "DTLS/SCTP".
>>>>>
>>>>> Christian
>>>>>
>>>>> On 30/09/2014 10:12 PM, Christian Groves wrote:
>>>>>> Hello Salvatore,
>>>>>>
>>>>>> There seems to be several issues with the updated syntax:
>>>>>>
>>>>>> 1) Cl.4.1 Media Description: With the updated syntax the ability 
>>>>>> to have more than one usage of the SCTP association has been lost 
>>>>>> as "sctp-fmt" is a single value.
>>>> <Sal>
>>>> there have been several discussion about the ability to have more 
>>>> than one usage of the SCTP association, and has been agreed not to allow it.
>>>> So each 'm' line describes a single SCTP association;  each 
>>>> association has only one single specify usage.
>>>> </Sal>
>>> [CNG] So how would I specify in SDP a scenario where BFCP uses a 
>>> DTLS/SCTP association and MSRP uses a DTLS/SCTP association where 
>>> they both use the same DTLS connection? Are these to be separate m-lines?
>>>> ..snip..
>>>>>> 3) Cl.4.1.2: There appears to be a formal space (SP) missing from 
>>>>>> the syntax between association-usage and max-message-size.
>>>>>>
>>>>>> sctpmap-attr = "a=fmtp:" association-usage [max-message-size]
>>>>>>
>>>>>> should be:
>>>>>> sctpmap-attr = "a=fmtp:" association-usage [SP max-message-size]
>>>>>>
>>>>>> The current syntax allows an fmtp usage with no max-message-size 
>>>>>> parameter, e.g. "a=fmtp:bfcp". Should this be allowed?
>>>> <Sal>
>>>> this has been discussed back in April or May. It has been decided 
>>>> that the max-message-size parameter is optional.
>>>> In the case it is not present the default value is 64K </Sal>
>>> [CNG] I agree that the max-message-size parameter is optional, in 
>>> that case an endpoint wouldn't specify the whole a=ftmp: line. It 
>>> seems strange to allow the endpoint to specify half a line?
>>>
>>>>>> 5) Cl.4.1.2: "If the parameter is not present, the implementation 
>>>>>> should provide a default, with a suggested value of 64K." Is this
>>>>>> 64,000 or is 65,535 bytes?
>>> [CNG] I think you skipped this?
>>>
>>>>>> 7) Cl.10: How will this registry relate to the "WebSocket 
>>>>>> Subprotocol Name Registry"
>>>>>> (http://www.iana.org/assignments/websocket/websocket.xml#subprotocol-name)?
>>>>>>
>>>> <Sal>
>>>> It is not related. The 'association-usage' specifies how the SCTP 
>>>> association will be used.
>>>> For example in the case of webrtc-datachannel value it would 
>>>> indicate how to pair certain streams, how to consider specific stream etc.
>>>> as described in
>>>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08 and 
>>>> in http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data-channel/
>>>>
>>>> the WebSocket Subprotocol Name Registry is used to populate the 
>>>> protocol field in the protocol field in 
>>>> https://tools.ietf.org/html/draft-ietf-rtcweb-data-protocol-08#sect
>>>> i
>>>> on
>>>> -5
>>>>
>>>> </Sal>
>>> [CNG] So if I use the SCTP association for "bfcp" then i'd need to 
>>> document this in the new registry associated with the draft? and if 
>>> I then used "bfcp" for webrtc-datachannel then i'd need to update 
>>> the websocket registry. Two places for the same protocol?
>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www.ietf.org/mailman/listinfo/mmusic