Re: [rtcweb] Meaning of SHOULD support/use interleaving

"Makaraju, Maridi Raju (Raju)" <> Tue, 28 October 2014 12:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 807DC1A7113 for <>; Tue, 28 Oct 2014 05:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q0XEttKgpfFY for <>; Tue, 28 Oct 2014 05:12:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 575711A1BED for <>; Tue, 28 Oct 2014 05:07:38 -0700 (PDT)
Received: from (unknown []) by Websense Email Security Gateway with ESMTPS id 8C1B18151070A; Tue, 28 Oct 2014 12:07:35 +0000 (GMT)
Received: from ( []) by (GMO) with ESMTP id s9SC7YYL010326 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 28 Oct 2014 08:07:37 -0400
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Tue, 28 Oct 2014 08:07:35 -0400
From: "Makaraju, Maridi Raju (Raju)" <>
To: Michael Tuexen <>
Thread-Topic: [rtcweb] Meaning of SHOULD support/use interleaving
Thread-Index: AQHP8e/nIllG4P1iiEigF/2tAwwrVZxEXbhogABFpgD//76eMIAAVKsAgACyvLA=
Date: Tue, 28 Oct 2014 12:07:34 +0000
Message-ID: <>
References: <> <> <> <> <>, <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [rtcweb] Meaning of SHOULD support/use interleaving
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Oct 2014 12:12:09 -0000

> > +1 to make N-DATA optional.
> >
> > Data channel provides a robust generic peer to peer communication channel.
> So, one can see that data channel may be used under non-webrtc contexts
> (like as in CLUE) as a general transport or as a replacement of native to
> SCTP to traverse firewalls. IMHO, majority of these use cases:
> > a. May just involve a single data channel (with possible multiplexing on
> top of it)
> > b. And may not use the DCEP either (both ends could assume same data
> channel stream id, this is similar to SCTP PPIDs).
> > We already made DCEP(b) as optional.
> >
> > If an app is using just a single data channel then there is no real
> benefit in using N-DATA. Then why not make it optional? Also, as already
> pointed out, making it optional won't break interop as it is still
> negotiated during SCTP setup time anyway.
> >
> > I would like to point out that there will be some webrtc applications
> which might just use one webrtc data channel for simplicity (and may use
> some multiplexing of different types of msgs/objects on top of it) or one is
> just sufficient as the app does not send/recv huge chunks of data. So, N-
> DATA isn't needed for such webrtc clients either. Then why add burden to
> such webrtc implementations!?
> Are you implementing this? I would say that adding N-DATA to an SCTP
> implementation with support
> for Stream Reconfiguration and PR-SCTP does not increase the complexity
> substantially...

I don't think the question is really about if NDATA adds complexity or not.
NDATA is a new capability to be added to SCTP stacks; and adding it takes
resources to develop, test, deliver, deploy/update.

As I just responded to Harald's post, we need to look at it from
data channel use in non-webrtc contexts and also data channel use
for non-browser webrtc clients. Just focusing on webrtc+browser alone
is not fair as not all the webrtc or non-webrtc data channel implementations
can keep up with the same pace as browsers do; also they don't have
resources like browser companies do!!