Re: [rtcweb] JSEP/WebRTC API Datachannel question
Randell Jesup <randell-ietf@jesup.org> Mon, 19 May 2014 06:35 UTC
Return-Path: <randell-ietf@jesup.org>
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 EC7821A02F6 for <rtcweb@ietfa.amsl.com>; Sun, 18 May 2014 23:35:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.2
X-Spam-Level: *
X-Spam-Status: No, score=1.2 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 L7nkK9JhWjdp for <rtcweb@ietfa.amsl.com>; Sun, 18 May 2014 23:35:33 -0700 (PDT)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8252B1A00B6 for <rtcweb@ietf.org>; Sun, 18 May 2014 23:35:33 -0700 (PDT)
Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:4648 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <randell-ietf@jesup.org>) id 1WmHAa-0003Fa-PC for rtcweb@ietf.org; Mon, 19 May 2014 01:35:33 -0500
Message-ID: <5379A5D3.5090209@jesup.org>
Date: Mon, 19 May 2014 02:33:55 -0400
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <534616DC.7090800@nteczone.com> <534CC016.3020901@nteczone.com> <A20898FE-B144-482D-BEF4-AC8AEBE90F9C@cisco.com> <CAOJ7v-2YTyOQGd0=V-K=awx+XoMAVvO4ZQA2yNwg7AZSyFRz9A@mail.gmail.com>
In-Reply-To: <CAOJ7v-2YTyOQGd0=V-K=awx+XoMAVvO4ZQA2yNwg7AZSyFRz9A@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------050502010504070901060005"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/liMrkIzh3LYTYFITlDG2ncAqL7I
Subject: Re: [rtcweb] JSEP/WebRTC API Datachannel question
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: Mon, 19 May 2014 06:35:35 -0000
On 5/19/2014 12:17 AM, Justin Uberti wrote: > Agree it would be good to make it clear that there is only ever one > m=data section; the text you suggest is a good start. Agree. And agree we should specify the first createDataChannel() can cause a negotiationneeded event. > > I don't think we want to add a=recvonly on the data line; it's not > clear that that attribute is well-defined for non-RTP media sections. Agree > > > On Sat, May 17, 2014 at 2:08 PM, Cullen Jennings (fluffy) > <fluffy@cisco.com <mailto:fluffy@cisco.com>> wrote: > > > On Apr 15, 2014, at 12:13 AM, Christian Groves > <Christian.Groves@nteczone.com > <mailto:Christian.Groves@nteczone.com>> wrote: > > > I'll take a punt that people were thinking about 2 below when > data channel was added. In order to clarify that I propose to add > the following text to the JSEP draft to clarify this. > > > > http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#section-5.2.1 > > Replace: > > "Lastly, if a data channel has been created, a m= section MUST be > > generated for data. The <media> field MUST be set to > "application" and the <proto> field MUST be set to "DTLS/SCTP", as > specified in [I-D.ietf-mmusic-sctp-sdp], Section 3; the "fmt" > value MUST be set to the SCTP port number, as specified in Section > 4.1." > > > > With: > > / "Lastly, if createDataChannel has been called a m= section > MUST be generated for data. In the case of multiple > createDataChannel calls only one m= section is generated. The > <media> field MUST be set to "application" and the <proto> field > MUST be set to "DTLS/SCTP", as specified in > [I-D.ietf-mmusic-sctp-sdp], Section 3; the "fmt" value MUST be set > to the SCTP port number, as specified in Section 4.1."/ > > > > New text in > http://tools.ietf.org/html/draft-ietf-rtcweb-jsep-06#section-5.2.2: > > (above last paragraph) > > / "If createDataChannel has been called and a m= section has not > previously been generated, a m= section MUST be generated for > data. In the case of multiple createDataChannel calls only one m= > section is generated. The <media> field MUST be set to > "application" and the <proto> field MUST be set to "DTLS/SCTP", as > specified in [I-D.ietf-mmusic-sctp-sdp], Section 3; the "fmt" > value MUST be set to the SCTP port number, as specified in Section > 4.1.// > > // > > //If all data channels have been closed, the m= section related > to the data channels MUST be marked as recvonly by changing the > value of the [RFC3264] directional attribute to "a=recvonly".//"/ > > > > It would also be good to add some text regarding the > relationship between a createDataChannel and DCEP > DATA_CHANNEL_OPEN I'm not sure if the JSEP draft is the place? > > > > Also the W3C draft could be updated to indicate the interaction > of a createDataChannel with the negotiationneeded event in section > 5.2 something along the lines of: > > /7. For the first creation of a RTCDataChannel object fire a > negotiationneeded event at connection./ > > > > > > Regards, > > Christian > > I probably need to think about this more but I think that sounds > like a pretty reasonable change. One way or another, JSEP needs to > be clear about what needs to happen here. > -- Randell Jesup -- rjesup a t mozilla d o t com
- [rtcweb] JSEP/WebRTC API Datachannel question Christian Groves
- Re: [rtcweb] JSEP/WebRTC API Datachannel question Christian Groves
- Re: [rtcweb] JSEP/WebRTC API Datachannel question Cullen Jennings (fluffy)
- Re: [rtcweb] JSEP/WebRTC API Datachannel question Justin Uberti
- Re: [rtcweb] JSEP/WebRTC API Datachannel question Randell Jesup