Re: [rtcweb] DataChannels API and external negotiation
"MARCON, JEROME (JEROME)" <jerome.marcon@alcatel-lucent.com> Wed, 10 April 2013 13:35 UTC
Return-Path: <jerome.marcon@alcatel-lucent.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D21421F97AF for <rtcweb@ietfa.amsl.com>; Wed, 10 Apr 2013 06:35:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMcV5KNvS-Wd for <rtcweb@ietfa.amsl.com>; Wed, 10 Apr 2013 06:35:09 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 9F93321F97A8 for <rtcweb@ietf.org>; Wed, 10 Apr 2013 06:35:09 -0700 (PDT)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r3ADZ5mq017434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 Apr 2013 08:35:06 -0500 (CDT)
Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r3ADYtoC031192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 10 Apr 2013 09:35:03 -0400
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 10 Apr 2013 09:34:58 -0400
Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.26]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Wed, 10 Apr 2013 15:34:30 +0200
From: "MARCON, JEROME (JEROME)" <jerome.marcon@alcatel-lucent.com>
To: Randell Jesup <randell-ietf@jesup.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Thread-Topic: [rtcweb] DataChannels API and external negotiation
Thread-Index: AQHOLoD2pU1/VCicR0uMGNwaeZcf8JjPgwYA
Date: Wed, 10 Apr 2013 13:34:30 +0000
Message-ID: <39821B4C400EC14DAD4DB25330A9271A02B56F@FR711WXCHMBA02.zeu.alcatel-lucent.com>
References: <5158F0FC.3070104@jesup.org>
In-Reply-To: <5158F0FC.3070104@jesup.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] DataChannels API and external negotiation
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 10 Apr 2013 13:35:10 -0000
Randell, What about data channel priority ? Jerome > -----Message d'origine----- > De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] > De la part de Randell Jesup > Envoyé : lundi 1 avril 2013 04:29 > À : public-webrtc@w3.org > Cc : rtcweb@ietf.org > Objet : [rtcweb] DataChannels API and external negotiation > > Here's a proposed API for DataChannels with external > negotiation, per the recent Interim and IETF meeting (most of > this was in my previous W3 email, but I've added info on when > 'stream' is valid to read, and how even/odd roles are > assigned for the IETF protocol). I'll note for the IETF folks > that 'protocol' is in a JS dictionary object in this update, > which avoids breaking any current experimental applications > (and avoids them having any incentive to UA-sniff). Also, I > think it works better in the dictionary. > > channel = peerconnection.createDataChannel(label, > dictionary_object); > > /* If either maxRetransmitTime or maxRetransmitNum are set, it's > unreliable, else it's a reliable channel. If both are set it's an > error. outOfOrderAllowed can be used with any type of > channel. The > equivalent of UDP is { outOfOrderAllowed: true, > maxRetransmitNum: 0 }. > The TCP equivalent is {}. > > preset is set to true if the channel is being externally > negotiated, and > no wireline OpenRequest message should be sent. If > preset is true, stream > can be optionally used to set a specific SCTP stream to > use. If it's > not set but preset is true, then the application should > read the 'stream' > attribute from the returned DataChannel after onopen and > convey it to the > other end to pass in via the DataChannelInit dictionary. > */ > > dictionary DataChannelInit { > boolean outOfOrderAllowed; > unsigned short maxRetransmitTime; > unsigned short maxRetransmitNum; > DOMString protocol; > boolean preset; > unsigned short stream; > }; > > And I added to the DataChannel object webidl: > > readonly attribute DOMString protocol; > /* the 'stream' attribute is not valid until after onopen > has fired */ > readonly attribute unsigned short stream; > > > Even/odd roles for the underlying DataChannel protocol are > tied to the DTLS roles on the DTLS connection. These are > only available after the DTLS connection is established, and > so we will set the even/odd roles when the initial > association is established (which is when onconnection fires, > and then any queued DataChannels would have onopen fire). > > -- > Randell Jesup > randell-ietf@jesup.org > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >
- [rtcweb] DataChannels API and external negotiation Randell Jesup
- Re: [rtcweb] DataChannels API and external negoti… Michael Tuexen
- Re: [rtcweb] DataChannels API and external negoti… piranna@gmail.com
- Re: [rtcweb] DataChannels API and external negoti… piranna@gmail.com
- Re: [rtcweb] DataChannels API and external negoti… Martin Thomson
- Re: [rtcweb] DataChannels API and external negoti… Randell Jesup
- Re: [rtcweb] DataChannels API and external negoti… Martin Thomson
- Re: [rtcweb] DataChannels API and external negoti… Peter Thatcher
- Re: [rtcweb] DataChannels API and external negoti… Randell Jesup
- Re: [rtcweb] DataChannels API and external negoti… Randell Jesup
- Re: [rtcweb] DataChannels API and external negoti… Michael Tuexen
- Re: [rtcweb] DataChannels API and external negoti… piranna@gmail.com
- Re: [rtcweb] DataChannels API and external negoti… Peter Thatcher
- Re: [rtcweb] DataChannels API and external negoti… MARCON, JEROME (JEROME)
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Adrian Georgescu
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Matthew Jordan
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Martin Thomson
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Gustavo Garcia Bernardo
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Gustavo García
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Martin Thomson
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Peter Thatcher
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Marc Abrams
- Re: [rtcweb] Requesting "SDP or not SDP" debate t… Alexandre GOUAILLARD