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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 02 October 2014 18:24 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 6DFB41A1A7C for <mmusic@ietfa.amsl.com>; Thu, 2 Oct 2014 11:24:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.035
X-Spam-Level:
X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_111=0.6, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_NONE=-0.0001, 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 HSyf4CfeSaad for <mmusic@ietfa.amsl.com>; Thu, 2 Oct 2014 11:24:18 -0700 (PDT)
Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [96.114.154.164]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C46DD1A1A79 for <mmusic@ietf.org>; Thu, 2 Oct 2014 11:24:18 -0700 (PDT)
Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-05v.sys.comcast.net with comcast id yJPA1o0045FMDhs01JQHVZ; Thu, 02 Oct 2014 18:24:17 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-19v.sys.comcast.net with comcast id yJQG1o00A3Ge9ey01JQG5f; Thu, 02 Oct 2014 18:24:17 +0000
Message-ID: <542D9850.6050807@alum.mit.edu>
Date: Thu, 02 Oct 2014 14:24:16 -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>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542BB0F7.3090608@nteczone.com> <542C0C31.70506@alum.mit.edu> <542C94CE.50600@nteczone.com> <542CAC38.5020708@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4637E9@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4637E9@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=1412274258; bh=v36ttnEMfBOojUSzlz14Z5ewqsqiS1y9n19fcV4aL/0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=pb/4o5O4+pl8F+jIbadxk5R/wjtrGVpHHPCDO+JnivXVffdTGQG9U9cUCKPM+6M5c XQlb1cJfCpRy8wZLpJhWn23Mgjoy+B4Zq/W495lC/1+M9qN43ixefGvLYsYl9ktKvn WTnZ2hwQPJ9WpqhBTfeyPTfMLaoTSLrN+NKadVgz9lQFWD2xUUrGVa2pdQVRFgJFSP nxvUz/6CsQxaA/SrUIGbrxD/EvfsEHe5g2jPxWFb+j9eGNns2IG2QlbBgYy9EeYxXh /feTveQOcDcz2hcty6khYtX63OM+uN97teOEWBixMkFSmwdFMHZnCEutKjA9NuAtbP z4hrVArMiLCAw==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/kBcL1c0GW-uNoLsnegl9DM7NYp0
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: Thu, 02 Oct 2014 18:24:20 -0000

On 10/2/14 7:59 AM, Christer Holmberg wrote:
> Hi,
>
> Keep in mind that the purpose of draft-ejzak-mmusic-data-channel-sdpneg is NOT to negotiate the usage of the SCTP association.
>
> It is assumed that the usage of the SCTP association is data channel, and the draft defines a mechanism to negotiate data channels on that SCTP association.

The purpose is to negotiate the use of channels, which is almost the 
same as negotiating the use of individual SCTP streams within an SCTP 
association.

The reason it was tied to data channels was so that it would be usable 
from webrtc browser apps.

	Thanks,
	Paul

> Regards,
>
> Christer
>
>
>
>
>
> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
> Sent: 2. lokakuuta 2014 4:37
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question
>
> On 10/1/14 7:57 PM, Christian Groves wrote:
>> What is the status of the draft-ejzak-mmusic-data-channel-sdpneg-00?
>
> I don't know the status. The thought Keith Drage had indicated that he was picking up responsibility for it.
>
> 	Thanks,
> 	Paul
>
>> It has expired and is based on the old SDP SCTP syntax. Particularly
>> the example in cl.4:
>>
>>      m=application 54111 DTLS/SCTP 5000 5001 5002
>>      c=IN IP4 79.97.215.79
>>      a=sctpmap:5000 webrtc-datachannel
>>      a=sctpmap:5001 bfcp
>>      a=sctpmap:5002 t38
>>
>> Wouldn't apply if we're saying to use multiple m-lines.
>>
>> I guess cl.5.1.1.3 would use the same Websocket subprotocol name
>> registry as data channel does?
>>
>> Regards, Christian
>>
>> On 2/10/2014 12:14 AM, Paul Kyzivat wrote:
>>> On 10/1/14 3:44 AM, Christian Groves wrote:
>>>
>>>>> <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?
>>>
>>> To have two different SCTP associations over the same DTLS
>>> connection, they would have to be distinguished by sctp-port. To
>>> achieve that you could write two m-lines. They would share the same
>>> ip address and port, and would have different "a=sctp-port" lines.
>>> Then they would have to be bundled.
>>>
>>> Doing that would require extending the definition of bundle to cover
>>> that case. (There is no *technical* problem in doing this.)
>>>
>>> OTOH, in principle they don't need their own SCTP association. AFAIK
>>> they each only use one sctp stream-pair (channel). If they could
>>> agree on how to choose channels then they could share an SCTP association.
>>> That is where draft-ejzak... comes in.
>>>
>>>      Thanks,
>>>      Paul
>>>
>>> _______________________________________________
>>> 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
>