Subject: [rtcweb] Initial JSEP draft posted

From: Justin Uberti <[email-masked]>
Date: Tue, 24 Jan 2012 00:56:36 -0500

I've just submitted the -00 version of the JSEP signaling proposal at:

http://www.ietf.org/id/draft-uberti-rtcweb-jsep-00.txt

I've received a number of comments and questions that I'm still working
through, most of them listed in the open issues appendix of the document. I
expect to resolve many of them in a forthcoming -01 version, before the
interim meeting.

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 31 Jan 2012 06:22:26 +0000

Hi Justin,

My initial review comments are as follows:

1) Sec 1 (Introduction) Para 3 indicates the drawback with SDP blob from the browser is that determining offer/answer information in the browser. My reading from this statement is that browser needs offer/answer state machine. Also, Sec 2 (JSEP approach) Para 2 calls createOffer API in browser to set the offer in the browser ? So, JSEP  does not move offer/answer state machine to JavaScript but looks like the aim of JSEP is to move determining offer/answer out of browser and inform offer/answer whenever needed to the browser.  FSM is in JavaScript and action handler are in browser. Whether this understanding is correct or not?

2) My understanding of Sec 1 (Introduction) Para 4 is that offer/answer (RFC 3264) is not meeting the requirements of Jingle kind of signaling protocol. I agree that it is the problem statement to ROAP in the current form. But I'm not convinced that the solution for this requirement is to move offer/answer mechanism to the application (JavaScript). IMO, we need to understand more offer/answer requirement like Jingle and try to come up with the enhanced offer/answer mechanism for WebRTC rather than pushing the intelligence to application. Please note that even in case of SIP implementation, RFC 3261 & RFC 6337 has to be considered apart from RFC 3264 for smooth interop of basic session establishment.

3) It is not possible to maintain offer/answer state machine in browser (during browser reload) how it is possible to maintain ICE state machine

4) JavaScript library will never be the solution and it is just a workaround from the protocol standpoint. The problem with 3rd party JavaScript library is that dependency on the proprietary API rather than standard API like W3C. In case low level API like JSEP is the focus of WebRTC then at least it is preferred to provide the high level API like ROAP as well for novice WebRTC users.  My proposal is to have two level API’s instead of current one.

5) In case the target audience for the lower level API (JSEP) is power-user of WebRTC,  then JSEP shall provide still lower level API for SDP attributes which is a common practice in SIP and other VoIP deployment. It will not be too much API based on my implementation understanding. In the high level, SDP API shall be classified as

a)      Global attribute set/get API

b)      Media level attribute set/get API. Each media level attribute shall be identified by index of the ‘m’  line or label of “m” line.

Thanks
Partha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Tuesday, January 24, 2012 11:27 AM
To: [email-masked]; [email-masked]
Subject: [rtcweb] Initial JSEP draft posted

I've received a number of comments and questions that I'm still working through, most of them listed in the open issues appendix of the document. I expect to resolve many of them in a forthcoming -01 version, before the interim meeting.