Re: [rtcweb] *MUST* DCEP?

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 04 March 2014 16:38 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7436D1A017D for <rtcweb@ietfa.amsl.com>; Tue, 4 Mar 2014 08:38:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.565
X-Spam-Level:
X-Spam-Status: No, score=0.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, 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 m9vvLCFG8img for <rtcweb@ietfa.amsl.com>; Tue, 4 Mar 2014 08:38:51 -0800 (PST)
Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 57E601A0154 for <rtcweb@ietf.org>; Tue, 4 Mar 2014 08:38:51 -0800 (PST)
Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta13.westchester.pa.mail.comcast.net with comcast id ZQvq1n0040Fqzac5DUeoWE; Tue, 04 Mar 2014 16:38:48 +0000
Received: from dhcp-a663.meeting.ietf.org ([31.133.166.99]) by omta08.westchester.pa.mail.comcast.net with comcast id ZUcb1n00A2904qf3UUcdJi; Tue, 04 Mar 2014 16:36:46 +0000
Message-ID: <53160112.3080702@alum.mit.edu>
Date: Tue, 04 Mar 2014 16:36:34 +0000
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.3.0
MIME-Version: 1.0
To: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>, Ted Hardie <ted.ietf@gmail.com>
References: <5315B2E8.7010703@alum.mit.edu> <CA+9kkMAstUJHgMNRHE1EokqnNhyX0W+YPKvq7_=Miq4+Tbi5aw@mail.gmail.com> <E1FE4C082A89A246A11D7F32A95A17826E0069CB@US70UWXCHMBA02.zam.alcatel-lucent.com> <5315EA19.90401@alum.mit.edu> <E1FE4C082A89A246A11D7F32A95A17826E00715E@US70UWXCHMBA02.zam.alcatel-lucent.com>
In-Reply-To: <E1FE4C082A89A246A11D7F32A95A17826E00715E@US70UWXCHMBA02.zam.alcatel-lucent.com>
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=q20121106; t=1393951128; bh=hMRCjkht14bDQ+By1jKdxToayKc33I6B+Uh6vgQt9mM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ci0PC6ru2D/ImJOAgy44JUq2D9ocdyhnUC21qGEVNumSGKxcOdMegmunyMIiMIeiy XqC+7x6RlfdPG2R/MltDz9hHAPeMCkVD/ePYA3EOE0BPlot7BTu0Ivg61vvieQqIbm 4sq4k19mbsAGm+LKDzejeiu6jE5RniFLWzdLdxnAfbn064ehlOysLJdOTjUpLH2uKX AIpJdM5NhKQLeVCZgzvSaHsyW8zyYY/NpT9gxtk3gSxuth96UkviBy5cqg+WY9dwNT j1FSDu2zEjwdiwAKKDZEzoaFFexg30MymLut/nXrl07XAOSNd5rgYpgVqV5geQqJtG WMuwHy0obCXLA==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/VyjmFsDzJf4xEr0qAPWzzZ193HY
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] *MUST* DCEP?
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Mar 2014 16:38:52 -0000

On 3/4/14 3:39 PM, Makaraju, Maridi Raju (Raju) wrote:
>
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: Tuesday, March 04, 2014 8:59 AM
>> On 3/4/14 12:08 PM, Makaraju, Maridi Raju (Raju) wrote:
>>> While a=sctpmap assumes use of DCEP, indication of external negotiation
>>> (instead of DCEP) also requires subprotocol and it's parameters to be
>>> conveyed. This has to be done per data channel stream.
>>>
>>> Are you looking at more than what is documented in
>>> [I-D.ejzak-mmusic-data-channel-sdpneg]?
>>>
>>> Or are you looking for an indication of this (for all streams) directly
>>> in a=sctpmap?
>>
>> I'm ok as things currently stand, though the documents are confusing.
>> The 'a=sctpmap:nnn websocket-datachannel' means that DCEP is supported.
>>
>> My concern was a proposal I think I heard that would make support for
>> DCEP to be optional. In that case, IMO it is important that the O/A
>> exchange establish whether DCEP is supported or not.
>
> [Raju]
> That's the reason why I proposed to add 'protocol' parameter to a=dcmap.
> Having this parameter at a=sctmap level may not make that much sense due to:
> sctpmap is for entire association and protocol defaults to DCEP. To make use of external negotiation, which is per data channel stream, one would need additional a= line(s) (e.g. ejzak's draft) to convey subprotocol info. IMO adding data channel protocol option to a=dcamp, which is per subprotocol, makes sense.
> [/Raju]

I have no problem with a=dcmap.

It is the 'app' parameter of the sctpmap attribute that I am talking about.

If I want to use DCEP, the dcmap attribute is irrelevant to me. What is 
it that tells me that DCEP is supported. The only datum available that 
could imply that is the 'app' parameter of sctpmap.

Right now, if app is webrtc-datachannel, that implies DCEP is MTI. That 
serves the purpose.

But as of today there was a suggestion that you could have cases where 
there is an SCTP association that supports Data Channels, but not DCEP. 
I don't know how the two would be distinguishable. Possibly by a 
different 'app' value.

A related question is what is the applicability of a=dcmap. Surely it 
doesn't apply for all uses of SCTP - those that don't use data channels 
at all. Do you propose to couple this to particular 'app' values? Or is 
support for this negotiated independently of a=sctpmap?

	Thanks,
	Paul