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

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 02 October 2014 18:55 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 E91BC1A1AAC for <mmusic@ietfa.amsl.com>; Thu, 2 Oct 2014 11:55:40 -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 OZAJFTAXp-B9 for <mmusic@ietfa.amsl.com>; Thu, 2 Oct 2014 11:55:40 -0700 (PDT)
Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBCBA1A1AA4 for <mmusic@ietf.org>; Thu, 2 Oct 2014 11:55:39 -0700 (PDT)
Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-08v.sys.comcast.net with comcast id yJvP1o00A4xDoy801Jvf6j; Thu, 02 Oct 2014 18:55:39 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-05v.sys.comcast.net with comcast id yJve1o00F3Ge9ey01JvedE; Thu, 02 Oct 2014 18:55:39 +0000
Message-ID: <542D9FAA.2000609@alum.mit.edu>
Date: Thu, 02 Oct 2014 14:55:38 -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: 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> <542D9850.6050807@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D4645E4@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4645E4@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=1412276139; bh=rh9mP4IiUUCY6a18AhODQSbBDxukyEF5+THx00KPPHo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=cduGq8P8p3ZQxv/DMEdeLvfQcTaWGSeP3Do1A7EB7dir3kGM+x4DS5EEerK9RaOmu O29XcPPEZuajtJWOY5x+KmZ7hyWKma+RZHvCoKhNEAZMvCTDUdycRCGRCcBrhX/M7w j6lo+ihIYLZwsDNZsO/c09AMHPJXHG1VHTIi9kekKOY3wqzDwnO/y3Wm7tDv+h+rVH qRNr4qASnewnbWLnyxrkR/NUgBHhBm+h07/W2DpG3QoyTNEsz2FlqJZc25TQFlxH8j VdtzEab0wccHZ3CUlgiK9m72xvWyROWOgkmArb5di1IAgl7X9EVysljK89wOTo415k Dv8J5wvsWqiPg==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/IEK0TDrhMA8EgQKqzXT6fTp87z8
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:55:41 -0000

On 10/2/14 2:31 PM, 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.
>
> Correct. But, it is not used to negotiate the SCTP association usage, which I think is what Christian has been talking about. It assumes that the SCTP association is used for data channels.

Yes. But for the most part Christian is talking about stream/channel 
usages that have not yet been defined. When the are defined, they could 
be done so using channels or something else. The main constraint here is 
enabling this stuff to work with webrtc.

I think that constraint is effectively forcing the use of the data 
channel association usage.

And this is all hypothetical because draft-ejak is far from complete. 
So, if it goes forward at all it may end up different from what it is now.

	Thanks,
	Paul