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

Christian Groves <Christian.Groves@nteczone.com> Mon, 06 October 2014 03:54 UTC

Return-Path: <Christian.Groves@nteczone.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 3640B1A1B0D for <mmusic@ietfa.amsl.com>; Sun, 5 Oct 2014 20:54:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.5
X-Spam-Level:
X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] 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 YBYPtxvx_WII for <mmusic@ietfa.amsl.com>; Sun, 5 Oct 2014 20:54:36 -0700 (PDT)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D237A1A01D5 for <mmusic@ietf.org>; Sun, 5 Oct 2014 20:54:35 -0700 (PDT)
Received: from ppp118-209-167-95.lns20.mel8.internode.on.net ([118.209.167.95]:57653 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Christian.Groves@nteczone.com>) id 1XazMm-0007kV-27 for mmusic@ietf.org; Mon, 06 Oct 2014 14:53:44 +1100
Message-ID: <54321279.2040905@nteczone.com>
Date: Mon, 06 Oct 2014 14:54:33 +1100
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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> <542D9FAA.2000609@alum.mit.edu>
In-Reply-To: <542D9FAA.2000609@alum.mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/go3blrPyh5d21wn5zCbFlSIlR_8
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 03:54:37 -0000

On 3/10/2014 4:55 AM, Paul Kyzivat wrote:
> 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.

[CNG] I've been talking about both, negotiating the SCTP association 
usage and/or the usage of the individual SCTP streams/data channels. 
Paul is correct in that I'm thinking of usages/protocols that have not 
yet been defined. I'm trying to understand the process on how these 
would be added in the future to situations where data channel is used 
and situations where data channel is not used.



>
>     Thanks,
>     Paul
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>