Re: [rtcweb] *MUST* DCEP?

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Tue, 04 March 2014 12:08 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 9E5A21A0644 for <rtcweb@ietfa.amsl.com>; Tue, 4 Mar 2014 04:08:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.299
X-Spam-Level:
X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 6ihSSXwxHhyV for <rtcweb@ietfa.amsl.com>; Tue, 4 Mar 2014 04:08:24 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 379031A0758 for <rtcweb@ietf.org>; Tue, 4 Mar 2014 04:08: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 s24C8Ijj019416 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 4 Mar 2014 06:08:19 -0600 (CST)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s24C8GO9031321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 4 Mar 2014 07:08:18 -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 07:08:18 -0500
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: Ted Hardie <ted.ietf@gmail.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Thread-Topic: [rtcweb] *MUST* DCEP?
Thread-Index: AQHPN5mmFhBjN/7IlE2x2iXE8FJgd5rRGzIA//+4iTA=
Date: Tue, 4 Mar 2014 12:08:18 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17826E0069CB@US70UWXCHMBA02.zam.alcatel-lucent.com>
References: <5315B2E8.7010703@alum.mit.edu> <CA+9kkMAstUJHgMNRHE1EokqnNhyX0W+YPKvq7_=Miq4+Tbi5aw@mail.gmail.com>
In-Reply-To: <CA+9kkMAstUJHgMNRHE1EokqnNhyX0W+YPKvq7_=Miq4+Tbi5aw@mail.gmail.com>
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: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17826E0069CBUS70UWXCHMBA02z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/qXa6C_UIIeYLbF6KyiZI9vLuQfc
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 12:08:27 -0000

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?

How about item 3 of the following proposal?
http://www.ietf.org/mail-archive/web/mmusic/current/msg13155.html

-Raju


From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Tuesday, March 04, 2014 5:17 AM
To: Paul Kyzivat
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] *MUST* DCEP?

On Tue, Mar 4, 2014 at 11:03 AM, Paul Kyzivat <pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>> wrote:
Ted,

(I think this was open issue #8)

You closed discussion on this, saying that this should be specified in some rtcweb "system" document. IIUC, then I disagree.

This is important to others besides rtcweb. We want to use this mechanism, both with and without components that are implementing rtcweb. Certainly for non-browsers.

Help me understand why it wouldn't then be in their systems documents?

Ted



This ultimately comes down to what I can expect after having negotiated (in SDP) the establishment of an SCTP association. When doing so, I use a=sctpmap to negotiate the how the association will be used. If I intend to use data channels and DCEP then I want an assurance that the other end does too. (That is the purpose of the SDP negotiation.)

AFAIK, current when I specify 'a=sctpmap:webrtc-datachannel' (or 'a=sctp-datachannel' depending on where I look), that means the other side supports data channels *and* guarantees support for DCEP. There is no means to indicate support for data channels *without* DCEP.

I don't see any urgent need to have data channels without DCEP, as long as *use* of DCEP is optional.

IMO things would be less confusing if the two documents were merged into one, that defines the *Data Channel Protocol* (that runs over SCTP). This protocol runs over pairs of SCTP streams, has a small number of messages (open, ack, string-payload, binary-payload, close), and encodes them in SCTP using SCTP messages with particular payloads and SCTP stream reset. The open and ack messages would be optional.

        Thanks,
        Paul