March 2011 - RTC-Web - example.com

Fwd: Updated Charter for RTCWeb
by Harald Alvestrand 02 Apr '11

02 Apr '11

The revised charter, incorporating what we were able to remember from the BOF. This has now been sent to the IESG for their one-week review. Harald

3 3

Ad-hoc RTCWEB meeting (Fwd: [dispatch] DISPATCH Ad-HOC meetings about VIPR and RTCWeb at IETF 80)
by Harald Alvestrand 01 Apr '11

01 Apr '11

Friday 1415-1515 in the Grand Ballroom. -------- Original Message -------- Subject: [dispatch] DISPATCH Ad-HOC meetings about VIPR and RTCWeb at IETF 80 Date: Tue, 15 Mar 2011 11:45:13 -0600 From: Cullen Jennings <fluffy(a)cisco.com> To: DISPATCH list <dispatch(a)ietf.org> The dispatch WG will have two ad-hoc meeting. The first is discuss the technical content of the drafts related to the proposed VIPR WG. Tentative time: VIPR's is in Tyrolka on Thursday 1300-1400 The second is to discuss the technical contents of drafts related to the proposed RTCWeb WG. Tentative time: RTCWeb's is Friday 1415-1515 in the Grand Ballroom Send Agenda requests for time in either of these to Mary and I. Thanks, Mary& Cullen _______________________________________________ dispatch mailing list dispatch(a)ietf.org https://www.ietf.org/mailman/listinfo/dispatch

2 1

IETF#80: RTCWEB BoF notes
by Christer Holmberg 31 Mar '11

31 Mar '11

Hi, Below are my notes from the RTCWEB BoF. Regards, Christer --------------- Collaboration with W3C: -------------------------- - It was noted that while IETF has the network expertise, W3C has the API expertise, and that collaboration between the group is important. - It was indicated, as there are people active in both IETF and W3C, it is better to rely on active collaboration driven by individuals, rather than sending liaisons between the SDOs. - Is was questioned whether IETF and W3C have different IPR policies. - It was indicated that the security model also needs to be defined in collaboration with W3C, as there are web security aspects that IETF might not have good knowledge of. - There was a question whether document produced by IETF and W3C needs to be approved by both SDOs. It was indicated that hopefully there will not be a need for both groups to formally approve documents of the other group, but each SDO should follow and review the work of the other group. - It was commented that we might need to establish a collaboration also with the WHAT WG, rather than relying on W3C for the WHAT WG collaboration. Use-cases and requirements: ----------------------------- Presenter: Christer Holmberg - The presenter indicated that we need to, in order to produce API requirements, agree on the functional split between the browser and the web-app. - The presenter indicated that NAT/FW traversal also contains a mechanism to perform media fallback (e.g. HTTP fallback). RTC-Web Framework: ------------------------- Presenter: Jonathan Rosenberg - The presenter indicated that, as the browser and web-app in most cases are produced by different organizations, we should look at the API between the browser and web-app as a protocol. - It was commented that we need to be careful with terminology, as an API does not dictate a protocol. - It was commented that the API should not be too complex for web application. It was suggested that the API might have different levels of complexity. - It was indicated that the browser application itself might not implement the features it offers to the web-app. Some features might also be offered by the OS, where the broswer simply provides access to those features to the web-app. Web Security: --------------- Presenter: Eric Rescorla - The following security areas, related to rtc-web, were identified: -- Media remote peer verification. -- Access to local device. -- Communication security. - There was a comment that identity also needs to be covered. However, in all use-cases identity might not be needed, or even desired. - It was questioned how we can prevent an application, claiming to be a browser, from sending date before getting consent. It was indicated that such scenario is outside the scope of the WG. Negotiation and Extensibility ---------------------------- Presenter: Cullen Jennings - The presenter indicated that the solution must be extendible, and it must provide a mechanism which allows the negotiation of different features. - It was indicated that full legacy interoperability might not be possible, mostly due to security constraints, without intermediary functions on the media plane. - It was indicated that the WG needs to decide on the level on legacy interoperability. Charter: -------- - A large number of individuals had read the proposed charter text. - There was a question whether document produced by IETF and W3C needs to be approved by both SDOs. It was indicated that hopefully there will not be a need for both groups to formally approve documents of the other group, but each SDO should follow and review the work of the other group. - It was commented that the charter does not talk about legacy interoperability. - It was commented that none of the presentations have described the handling of non-RTP connections. It was indicated that the MG might want to consider sending also non-audio/video data over RTP. - It was commented that the charter should not contain a list of features that might be added to the charter at a later point. Poll: ----- - Willingness to review documents: approx 50-60 individuals. - Willingness to write and provide text to documents: approx 24 individuals.

1 0

My biggest concern
by Robin Raymond 31 Mar '11

31 Mar '11

I've been quiet on the list and perhaps this has already been discussed. My primary concern has to do with the way users interact with their browsers and tying the lifetime of the streaming sessions to the javascript on a webpage. Given the proposals, javascript will likely be used to setup streaming sessions and thus there will need to be automatic clean-up of these sessions when the related javascript objects are closed when a website page is "closed". This in my opinion can cause major issues with users. In my own situation, I have a list of common viewed websites at the top of my browser and a simple accidental click will go to those new pages. I frequently click on those pages accidentally. If I'm simply viewing email, no big deal, I hit the back and while I'm annoyed I can easily recover. With a call in progress this will no longer be the case. The entire session state will be destroyed, the calls will tear down immediately as a result of the lifetime of streams being tied to the lifetime of the javascript objects on the page. I think practically speaking this will happen often. Users will be in a call with each other and say "have you seen that new cool video", and most non tech savvy users will simply type the search into their browser window and their search bar and the browser javascript will be torn down and bring down all the RTP streams thus ending any active communication as a result. How annoying it would be to have established calls torn up/down based on typical browser usage by a user! Expecting users not to navigate while calling is impractical and expecting users will open new browser tabs will be unworkable, especially to anyone like me has had to support family members confusion over browser tabs and accidentally closing what they are working on... I think the depth of this issue is unique to RTC-WEB proposal. Of course, I've seen this issue with videos and other places - where you are in the middle of watching a video, click to a new page and then come back to have the video start over and if it doesn't index itself properly will have to download and play from the beginning. Youtube has done a lot to solve those usability issues by doing many intelligent work arounds and keeping currently locations pretty accurate when going "back". But I fear no such work arounds will be easy or possible with RTC-WEB and solutions could open up new cans of security worms. For example, reopening a closed page with the "back button" could cause re-open a previously accidentally closed media sessions but could also open an intentionally closed sessions. Re-opening the connection automatically based on going "back" to a previous page could be embarrassing if you did actually intend to end the call and then the microphone was re-opened automatically broadcasting to the previous person you were connected. To keep media sessions alive even as users click around implies the lifetime of the call exists outside the active browser page. But this opens up other issues. For example, when does the call get automatically torn down if they leave the site? Or where are the controls for the call going to exist outside the site if the page with the controls is closed? (and the browser would have no understanding of what controls should be presented when navigating off the page since every website will have their own call control definitions). So maybe I'm missing something important like other browser future technologies introduced in conjunction with RTC-WEB (e.g. application based web sites) but I don't understand how RTC-WEB is going to get around these javascript-tied-to-a-webpage lifetime issues... Regards, Robin Raymond hookflash

9 13

New proposed charter text. Please review before the BoF.
by Ted Hardie 29 Mar '11

29 Mar '11

Name: Real-Time Communication in WEB-browsers (RTCWeb) There are a number of proprietary implementations that provide direct interactive rich communication using audio, video, collaboration, games, etc. between two peers' web-browsers. These are not interoperable, as they require non-standard extensions or plugins to work. There is a desire to standardize the basis for such communication so that interoperable communication can be established between any compatible browsers. The goal is to enable innovation on top of a set of basic components. One core component is to enable real-time media like audio and video, a second is to enable datagram and byte stream data transfer directly between clients. This work will be done in collaboration with the W3C. The IETF WG will produce architecture and requirements for selection and profiling of the on the wire protocols. The architecture needs to be coordinated with W3C. The IETF WG work will identity state information and events that need to be exposed in the APIs as input to W3C. The W3C will be responsible for defining APIs to ensure that application developers can control the components. The security goals and requirements will be developed by the WG. The security model needs to be coordinated with the W3C. The work will also consider where support for extensibility is needed. RTP functionalities, media formats, security algorithms are example of things that commonly needs extensions, additions or replacement, and thus some support for negotiation between clients is required. The WG will perform the following work: 1. Define the communication model in detail, including how session management is to occur within the model. 2. Define a security model that describes the security goals and how the communication model can achieve these goals. 3. Define how NAT and Firewall traversal is to occur. 4. Define which RTP functions and extensions that shall be supported in the client and their usage for real-time media, including media adaptation to ensure congestion safe usage. 5. Define what functionalities in the solution, such as media codecs, security algorithms, etc., that can be extended and how the extensibility mechanisms works. 6. Define a set of media formats that must or should be supported by a client to improve interoperability. 7. Define how non RTP datagram and byte stream data communication between the clients can be done securely and in a congestion safe way. 8. Provide W3C input for the APIs that comes from the communication model and the selected components and protocols that are part of the solution. This work will be done primarily by using already defined protocols or functionalities. If there is identification of missing protocols or functionalities, such work can be requested to be done in another working group with a suitable charter or by requests for chartering it in this WG or another WG. 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, Location services, IM & Presence, Resource Priority. The products of the working group will support security and keying as required by BCP 61 and be defined for IPv4, IPv6, and dual stack deployments. The Working Group will consider the possibility of defining a browser component that implements an existing session negotiation and management protocol. 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. Milestones: Aug 2011 Architecture and Security and Threat Model sent to W3C Aug 2011 Use cases and Scenarios document sent to W3C Sept 2011 Architecture and Security and Threat Model to IESG as Informational Sept 2011 Use cases and Scenarios for RTCWeb document sent to IESG as Informational Dec 2011 RTCWeb and Media format specification(s) to IESG as PS Dec 2011 Information elements and events APIs Input to W3C Apr 2012 API to Protocol mapping document submitted to the IESG as Informational (if needed)

12 21

Non-IETF work: Coming up with a high level API spec
by Harald Alvestrand 24 Mar '11

24 Mar '11

Despite the fact that it's getting very close to our BOF session, other things are happening.... I've been working with some other people on getting together a specification for a very-high-level Javascript API for media control. This is intended as an "easy to use" API for those who do not wish to put detailed control in Javascript, and allows to build applications without getting into signalling protocols - those can be handled at server side if needed, or by other libraries if needed / possible. It's roughly at the same level as the just published WHATWG PeerConnection API or the now-gone ConnectionPeer API, and many functions are identical, but there are some differences. The spec is here: https://docs.google.com/a/google.com/document/pub?id=1_lFKBgjNMVy98TMZT0kZ6… It does not specify a format for sending data, since I believe we do not have consensus on even the design constraints for this - there are also other parts that are not fully fleshed out. Feedback welcome. If people want edit permission, so that they can enter comments directly into the document, pass me your google account info. Harald

1 1

BOF agenda, latest version
by Harald Alvestrand 23 Mar '11

23 Mar '11

I've uploaded a new version of the BOF agenda to the IETF toolserver: http://www.ietf.org/proceedings/80/agenda/rtcweb.txt It is also pasted below. All who need to use slides: Please have them ready by Sunday, so that the BOF chairs and attendees can review them before the meeting! RTCWEB, March 29, 2011 0900-1130 (Real Time Communication on the World Wide Web) Chairs: Harald Alvestrand, Ted Hardie Mailing list: rtcweb(a)alvestrand.no Reading list: draft-alvestrand-dispatch-rtcweb-datagram-01 draft-alvestrand-dispatch-rtcweb-protocols-01 draft-marjou-dispatch-rtcweb-sip-rtp-interwk-reqs-00 draft-rosenberg-rtcweb-framework-00 draft-holmberg-rtcweb-ucreqs-01 draft-perkins-rtcweb-rtp-usage-00 draft-jennings-rtcweb-api-00 Charter: http://rtc-web.alvestrand.com/ietf-activity This BoF proposes the creation of a group which will identify or produce the technology required to provide interactive communications between two or more web applications. While existing methods for accomplishing this are available, they are not interoperable, largely because they use different plug-in platforms as substrates. The set of components identified by this group will enable interopable communications among browsers and web application frameworks in which they are implemented. Enabling real-time audio and video streams is the primary target. A secondary target is enabling byte stream data transfer, so as to enable gaming, collaboration, and similar web applications to send data directly to peers. This work is intended to closely collaborate with a related effort at the W3C: http://www.w3.org/2010/12/webrtc-charter. Agenda: Stage-setting: 09:00 Agenda bashing, blue sheets, scribe selection, and note well 09:05 Brief introduction of the problem space and scope limitations 09:15 Summary of proposed IETF deliverables and relationship to W3C work on APIs and related issues Technology discussion: 09:45 Requirements and scenarios 10:00 Frameworks 10:20 Security work in web applications, browsers, and gateways 10:35 Negotiation methods and criteria for mandatory to implement capabilities Charter review: 10:50 Clarifying questions on charter text 11:05 Discussion of scope, deliverables, and timelines 11:20 Call for volunteers for specific work items 11:25 Charter hum 11:30 Adjourn

1 0

Relationship of the proposed W3C RTC group with WHATWG
by Rich Tibbett 23 Mar '11

23 Mar '11

Hi, There is currently a whole lot of ongoing work in the WHATWG around real-time web communications [whatwg-spec#rtc] [html-tracker]. What is the relationship between the proposed W3C activity [w3c-rtc-charter] and the work currently being done in the WHATWG? While there is an obvious need for IETF activity on underlying protocols, codecs and formats I'm unsure as to how a W3C RTC group is going to effectively manage any overlaps here. Any clarifications would be helpful. - Rich [whatwg-spec#rtc] http://www.whatwg.org/specs/web-apps/current-work/complete/video-conferenci… [html-tracker] http://html5.org/tools/web-apps-tracker [w3c-rtc-charter] http://www.w3.org/2010/12/webrtc-charter.html

3 3

Draft new: draft-holmberg-rtcweb-ucreqs-00 (Web Real-Time Communication Use-cases and Requirements)
by Christer Holmberg 23 Mar '11

23 Mar '11

Hi browser lovers, We've submitted a use-case/requirement draft, draft-holmberg-rtcweb-ucreqs-00.txt, that we think could be used as a base when those discussions start. The document describes some use-cases, and based on those proposes browser requirement, and application-browser API requirements. It focues on media related issue. Ie issues related to privacy, signalling between the browser and web server etc, are currenly not considered. Best regards, Christer

13 39

New draft on WebRTC API draft-jennings-rtcweb-api
by Cullen Jennings 22 Mar '11

22 Mar '11

I wrote up the start of a draft on requirements and a sketch of an API proposal. It is at http://tools.ietf.org/html/draft-jennings-rtcweb-api-00 I view this as very early but starts to list some of the issues and an evolving sketch of how the API might look. Cullen

4 5