Hi, Thank you Cullen to expose openly the situation. I agree that discussion must go on on this topic and that the goal is to find a consensus between already in place solutions and programmability of the RTC web solution (from my personal analysis, this being reachable with lower enough APIs in the browser). Still I would like to raise another point which is somehow related to Henry's remark: The charter does not explicitly mention the compatibility with "legacy" VoIP networks/handsets. It is only suggested when saying that: the work will define a solution to "have interactive real time voice and video pairwise between browsers or other devices using RTP" Wherever the discussion on protocols (sig and media) goes, I suggest the working group to keep as a major objective to produce something which is compatible with voice and video systems that are not web based. This compatibility begins with RTP/RTCP usage...as already mentioned in the charter... but this should be stated more explicitly to avoid the group to design an incompatible or complex to interoperate with solution. Harald's proposal was clearer on this point with the mention of: [...] This working group will select and define a minimal set of protocols that will enable browsers to: [...] * interoperate with compatible voice and video systems that are not web based [...] PS: my 2 cents on group naming, +1 to RTCWEB Regards, Jean-François -----Message d'origine----- De : dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] De la part de Henry Sinnreich Envoyé : jeudi 27 janvier 2011 06:45 À : Cullen Jennings; MARJOU Xavier RD-CORE-LAN Cc : rtc-web@alvestrand.no; DISPATCH list; Kundan Singh Objet : Re: [dispatch] [RTW] The charter formerly know as RTC-WEB take 3 +1 I also don't think people will agree on either SIP or Jingle no matter how long the discussion may be. Humming is not a good metric here, since it will favor those who can attend the meeting. For what it is worth, please see our _outline_ for a SIP API targeted for compatibility with existing SIP VoIP networks. http://tools.ietf.org/html/draft-sinnreich-sip-web-apis-01.html Though the I-D focuses on the most basic 2-party call model, the API can be extended by developers familiar with SIP. Other parts of the I-D relating to SDP, RTP and NAT traversal have already been addressed here on the list, so please disregard. Maybe we should post a new version, if of interest. Thanks, Henry On 1/26/11 8:04 PM, "Cullen Jennings" <fluffy@cisco.com> wrote:
Clearly you could put a SIP and/or Jingle stack in a browser and have it control the RTP. Ignore any SIP vs Jingle issues for a second and just assume we had agreement on one or both of them. Some people think this is a good idea, some people think it is a bad idea. The charters were constructed such that the charter would not determine this and the working group could have that argument inside the working group. I really doubt that we could get consensus at this point in time to either rule it out of scope or say that the solutions had to do this. As people develop proposal around the details of the API and how this will all work, I think consensus could start to gather around if this is a good idea or not.
Perhaps the charter should explicitly say this but that is why it seems so mute on this topic, it is.
Cullen
On Jan 21, 2011, at 7:58 , Xavier Marjou wrote:
Hi,
Something strikes me. So far RTC-Web is known as "an effort to achieve a standardized infrastructure in Web browsers on which real-time interactive communication between users of the World Wide Web can be achieved." So what about the selection or definition of a protocol mechanism to establish a media session and negotiate media properties? Are they in scope or out of scope? (nothing is mentioned about it in the last proposal)
Cheers, Xavier
On Tue, Jan 18, 2011 at 5:58 AM, Cullen Jennings <fluffy@cisco.com> wrote:
In my dispatch co-chair role, I tried to take all the comments I had seen on the list about this charter and see if I could address them in a new version of the charter. I probably messed up in some places. There were some conversation that did not seem to be converging so I did not make any changes for theses. Have a read and if you think something needs to be changed, propose text changes along with the reasons why and we will keep the evolving this charter.
Thanks Cullen
---------------------------------------------------------------------------- ------
Version: 3
Possible Names:
RTCWEB WEBRTC STORM: Standardized Transport Oriented for Realtime Media BURN: Browsers Using Realtime Media WAVE: Web And Voice/Video Enablement WAVVE: Web And Voice Video Enablement REALTIME WEBCOMM WREALTIME WEBTIME WEBFLOWS BRAVO Browser Realtime Audio and VideO COBWEB COmmuication Between WEBclients WHEELTIME
Body:
Many implementations have been made that use a Web browser to support direct, interactive communications, including voice, video, collaboration, and gaming. In these implementations, the web server acts as the signaling path between these applications, using locally significant identifiers to set up the association. Up till now, such applications have typically required the installation of plugins or non-standard browser extensions. There is a desire to standardize this functionality, so that this type of application can be run in any compatible browser and allow for high-quality real-time communications experiences within the browser.
Traditionally, the W3C has defined API and markup languages such as HTML that work in conjunction with with the IETF over the wire protocols such as HTTP to allow web browsers to display media that does not have real time interactive constraints with another human.
The W3C and IETF plan to collaborate together in their traditional way to meet the evolving needs of browsers. Specifically the IETF will provide a set of on the wire protocols, including RTP, to meet the needs on interactive communications, and the W3C will define the API and markup to allow web application developers to control the on the wire protocols. This will allow application developers to write applications that run in a browser and facilitate interactive communications between users for voice and video communications, collaboration, and gaming.
This working group will select and define a minimal set of protocols that will enable browsers to:
* have interactive real time voice and video pairwise between browsers or other devices using RTP
* have interactive real time application data for collaboration and gaming pairwise between browsers
Fortunately very little development of new protocol at IETF is required for this, only selection of existing protocols and selection of minimum capabilities to ensure interoperability. The following protocols are candidates for including in the profile set:
1) RTP/ RTCP
2) a baseline audio codec for high quality interactive audio. Opus will be one of the codecs considered
3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be some of the codecs considered
4) a baseline video codec. H.264 and VP8 will be some of the codecs considered
5) Diffserv based QoS
6) NAT traversal using ICE
7) media based DTMF
8) support for identifying streams purpose using semantics labels mappable to the labels in RFC 4574
9) Secure RTP and keying
10) support for IPv4, IPv6 and dual stack browsers
Please note the above list is only a set of candidates that the WG may consider and is not list of things that will be in the profile the set.
The working group will cooperate closely with the W3C activity that specifies a semantic level API that allows the control and manipulation of all the functionality above. In addition, the API needs to communicate state information and events about what is happening in the browser that to applications running in the browser. These events and state need to include information such as: receiving DTMF in the RTP, RTP and RTCP statistics, and the state of DTLS/SRTP handshakes. The output of this WG will form input to the W3C group that specifies the API.
The working group will follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to use in web browsers.
The following topics will be out of scope for the initial phase of the WG but could be added after a recharter: RTSP, RSVP, NSIS, LOST, Geolocation, IM & Presence, NSIS, Resource Priority. RTP Payload formats will not be done in this WG.
Milestones:
May 2011 Main alternatives identified in drafts
Aug 2011 WG draft with text reflecting agreement of what the profile set should be
Sept 2011 Scenarios specification to IESG as Informational
Nov 2011 Documentation specifying mapping of protocol functionality to W3C-specified API produced. This is an input to W3C API work.
Dec 2011 Profile specification to IESG as PS
Apr 2012 Mapping W3C defied API to IETF protocols to IESG as Informational. This depends on the W3C API work.
_______________________________________________ RTC-Web mailing list RTC-Web@alvestrand.no http://www.alvestrand.no/mailman/listinfo/rtc-web
Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch