Re: [rtcweb] Open data channel issues

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Tue, 04 March 2014 11:39 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 B78D61A0431 for <rtcweb@ietfa.amsl.com>; Tue, 4 Mar 2014 03:39:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 DlylqIbK5MAW for <rtcweb@ietfa.amsl.com>; Tue, 4 Mar 2014 03:39:58 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id DAAB61A02CE for <rtcweb@ietf.org>; Tue, 4 Mar 2014 03:39:57 -0800 (PST)
Received: from us70tusmtp2.zam.alcatel-lucent.com (h135-5-2-64.lucent.com [135.5.2.64]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s24BdsIA010357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 05:39:54 -0600 (CST)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id s24BdrQR031418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 06:39:53 -0500
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.212]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Tue, 4 Mar 2014 06:39:53 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Open data channel issues
Thread-Index: AQHPN1stdPPAuXGnm0CBoOmgEn8ul5rQ0+gAgAAIWoCAAAcMgIAAEjqA///SoEA=
Date: Tue, 4 Mar 2014 11:39:53 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17826E0068BF@US70UWXCHMBA02.zam.alcatel-lucent.com>
References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530D9CC5.5080508@ericsson.com> <5312FBBC.5080006@jesup.org> <CAOJ7v-2GHt37u8raWDKquNFLCjSv-ptP0YGojPwuLv02da_m1Q@mail.gmail.com> <5313EC0D.9030808@jesup.org> <CAOJ7v-3L5_V2wuwVLKpz61VHey7yx3LnG_xrPLb5W+6DOLiEJw@mail.gmail.com> <53146B2C.8080008@jesup.org> <CABkgnnV1BdAMvFqGq8xiL0Zu28aZBCAdPwZB8whpMeXrCD7AHQ@mail.gmail.com> <53149F0C.6070001@jesup.org> <CAOJ7v-0xSq2xvF_5Do-R4SG6yAVNdqELwRvt_VBU69ir6nHhGQ@mail.gmail.com> <53154AA8.4000202@jesup.org> <CABkgnnVWESeVgrPjYnxuhB5w1QTjbXNW+zBLfYRwUL059Q0_hw@mail.gmail.com> <53158103.4000809@jesup.org> <1D3890D9-AF14-4648-820D-7586134D56DA@lurchi.franken.de> <53159637.8050909@jesup.org>
In-Reply-To: <53159637.8050909@jesup.org>
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/p28-QWmU2QH39qpnCqjdHCyQfrM
Subject: Re: [rtcweb] Open data channel issues
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 11:39:59 -0000

> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Randell Jesup
> Sent: Tuesday, March 04, 2014 3:01 AM
> On 3/4/2014 2:55 AM, Michael Tuexen wrote:
> > On 04 Mar 2014, at 07:30, Randell Jesup <randell-ietf@jesup.org> wrote:
> >
> >> On 3/4/2014 2:00 AM, Martin Thomson wrote:
> >>> On 4 March 2014 03:38, Randell Jesup <randell-ietf@jesup.org> wrote:
> >>>> To take your suggestion:
> >>>> a) applications assume 16KB if ndata wasn't negotiated (per the current
> >>>> suggestion)
> >>>> b) implement ndata and EOR support in the browsers, and drop the 16KB
> limit
> >>>> when ndata is negotiated.
> >>>> All this needs is "is ndata supported by this association" exposed to
> the
> >>>> app; no sdp changes needed.  (One less dependency!)
> >>> Or, to avoid vestigal crap in the API in the end state, when you
> >>> install the 16K limitation, add an indicator that applications can
> >>> check.  Once you remove the cap, remove the indicator.
> >>>
> >>> if (dataChannel.isNotVeryGood) {
> >>>    chunkMessage(message);
> >>> } else {
> >>>    dataChannel.send(message);
> >>> }
> 
> 
> Wait, the reason why we had it be 16K as a default was that current
> impls don't have the property.  So datachannel.isntFixed (ok, better
> names can be found - but that's W3 anyways.

[Raju] 
NDATA requires support from both the ends. Is browser going to update datachannel.isntFixed/ndata after SCTP is up? Per my reading of PeerConnection onopen() won't be called before SCTP is up (however may be called before DCEP, if used, is done). So, app knows NDATA support before sending first message.

Thanks
Raju