IETF Logo Mail Archive

Re: [rtcweb] *MUST* DCEP?

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Tue, 04 March 2014 15:40 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.com>
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 2A1E81A01F9 for <rtcweb@ietfa.amsl.com>; Tue, 4 Mar 2014 07:40:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.1
X-Spam-Level:
X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_16=0.6, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_HI=-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 IPsxqL_zZOmu for <rtcweb@ietfa.amsl.com>; Tue, 4 Mar 2014 07:40:24 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id B46F91A005E for <rtcweb@ietf.org>; Tue, 4 Mar 2014 07:40:24 -0800 (PST)
Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s24FeHbU005736 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 09:40:17 -0600 (CST)
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s24FeEIw027433 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 10:40:16 -0500
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 4 Mar 2014 10:39:54 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Ted Hardie <ted.ietf@gmail.com>
Thread-Topic: [rtcweb] *MUST* DCEP?
Thread-Index: AQHPN5mmFhBjN/7IlE2x2iXE8FJgd5rRGzIA//+4iTCAAIVPgP//tvcg
Date: Tue, 04 Mar 2014 15:39:54 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17826E00715E@US70UWXCHMBA02.zam.alcatel-lucent.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>
In-Reply-To: <5315EA19.90401@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.16]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XBQlCLYRdHw2dTM_xx_4Ft0mSw4
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 15:40:27 -0000

> -----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] 

Best Regards
Raju

v2.23.0 | Report a Bug | By Email