January 2011 - RTC-Web

Re: [RTW] [dispatch] Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
by Peter Musgrave 12 Jan '11

12 Jan '11

Hi, I also think this is very useful work. I would really like have IETF side step the video codec choice vortex. There has been a long and impassioned CODEC dialog wrt the <video> tag in HTML5 (which I have only observed from afar) and I am not sure we are well served by having our own version of that. Is it necessary for the charter to specify a baseline CODEC choice? What are the implications of just saying that CODECs will be negotiated (as per usual in SIP)? There is lots of REALLY GOOD stuff this group can do to ensure anything you can put in RTP can go between web browsers (or from a web browser to a SIP endpoint) in a secure, NAT-tolerant way. Peter Musgrave On 2011-01-12, at 4:49 AM, Alex Eleftheriadis wrote: > I think this is an interesting and important activity, but I want to point out a few points of concern with the current proposal. > > Although the charter indicates that there will be a "selection", it fails to identify the criteria for this selection process. It is easy to see that this can lead to a shouting match. The only indication of a criterion for the codecs is: > >> * interoperate with compatible voice and video systems that are not web >> based > > > which, btw, you already re-interpreted to mean "brower-to-browser" in a later email. > > I would therefore recommend that, if a single baseline codec is to be selected, the criteria are stated in the charter. If the criteria are to be defined later by the group, then that should be stated in the charter, with at least some indication of what the group wants to accomplish here. > > Nit: Codecs are not protocols (cf. "The following protocols..."). > > Regards. > > Alex > > On Jan 6, 2011, at 1:53 PM, Harald Alvestrand wrote: > >> This is the first of 3 messages going to the DISPATCH list (in the hope >> of keeping discussions somewhat organized). >> >> This is the draft of a charter for an IETF working group to consider the >> subject area of "Real time communication in the Web browser platform". >> This is one of a paired set of activities, the other one being a W3C >> activity (either within an existing WG or in a new WG) that defines APIs >> to this functionality. >> >> The two other messages will contain the W3C proposed charter and a >> kickoff for what's usually the most distracting topic in any such >> discussion: The name of the group. >> Without further ado: >> >> ------------------------------------- >> >> Version: 2 >> >> Possible Names: >> <This space deliberately left blank for later discussion> >> >> Body: >> >> Many implementations have been made that use a Web browser to support >> interactive communications directly between users including voice, >> video, collaboration and gaming, but until now, such applications have >> required the installation of nonstandard plugins and browser extensions. >> There is a desire to standardize such functionality, so that this type >> of application can be run in any compatible 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 between users using RTP >> * interoperate with compatible voice and video systems that are not web >> based >> * support direct flows of non RTP application data between browsers for >> collaboration and gaming applications >> >> 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 considered as one of the candidates >> >> 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC >> will be considered >> >> 4) a baseline video codec. H.264 and VP8 will be considered >> >> 5) Diffserv based QoS >> >> 6) NAT traversal using ICE >> >> 7) RFC 4833 based DTMF transport >> >> 8) RFC 4574 based Label support for identifying streams purpose >> >> 9) Secure RTP and keying >> >> 10) support for IPv4, IPv6 and dual stack browsers >> >> 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 RFC 4833 DTMF, RTP >> and RTCP statistics, state of DTLS/SRTP, and signalling state. >> >> 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, >> >> Milestones: >> >> February 2011 Candidate "sample" documents circulated to DISPATCH >> >> March 2011 BOF at IETF Prague >> >> April 2011 WG charter approved by IESG. Chosen document sets adopted as >> WG documents >> >> May 2011 Functionality to include and main alternative protocols identified >> >> July 2011 IETF meeting >> >> Aug 2011 Draft with text reflecting agreement of what the protocol set >> should be >> >> Nov 2010 Documentation specifying mapping of protocol functionality to >> W3C-specified API produced >> >> Dec 2011 Protocol set specification to IESG >> >> April 2012 API mapping document to IESG >> >> _______________________________________________ >> dispatch mailing list >> dispatch(a)ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > _______________________________________________ > dispatch mailing list > dispatch(a)ietf.org > https://www.ietf.org/mailman/listinfo/dispatch

1 0

Charter proposal: The activity hitherto known as "RTC-WEB at IETF"
by Harald Alvestrand 12 Jan '11

12 Jan '11

This is the first of 3 messages going to the DISPATCH list (in the hope of keeping discussions somewhat organized). This is the draft of a charter for an IETF working group to consider the subject area of "Real time communication in the Web browser platform". This is one of a paired set of activities, the other one being a W3C activity (either within an existing WG or in a new WG) that defines APIs to this functionality. The two other messages will contain the W3C proposed charter and a kickoff for what's usually the most distracting topic in any such discussion: The name of the group. Without further ado: ------------------------------------- Version: 2 Possible Names: <This space deliberately left blank for later discussion> Body: Many implementations have been made that use a Web browser to support interactive communications directly between users including voice, video, collaboration and gaming, but until now, such applications have required the installation of nonstandard plugins and browser extensions. There is a desire to standardize such functionality, so that this type of application can be run in any compatible 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 between users using RTP * interoperate with compatible voice and video systems that are not web based * support direct flows of non RTP application data between browsers for collaboration and gaming applications 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 considered as one of the candidates 3) a baseline audio codec for PSTN interoperability. G.711 and iLBC will be considered 4) a baseline video codec. H.264 and VP8 will be considered 5) Diffserv based QoS 6) NAT traversal using ICE 7) RFC 4833 based DTMF transport 8) RFC 4574 based Label support for identifying streams purpose 9) Secure RTP and keying 10) support for IPv4, IPv6 and dual stack browsers 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 RFC 4833 DTMF, RTP and RTCP statistics, state of DTLS/SRTP, and signalling state. 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, Milestones: February 2011 Candidate "sample" documents circulated to DISPATCH March 2011 BOF at IETF Prague April 2011 WG charter approved by IESG. Chosen document sets adopted as WG documents May 2011 Functionality to include and main alternative protocols identified July 2011 IETF meeting Aug 2011 Draft with text reflecting agreement of what the protocol set should be Nov 2010 Documentation specifying mapping of protocol functionality to W3C-specified API produced Dec 2011 Protocol set specification to IESG April 2012 API mapping document to IESG

11 24

Re: [RTW] [dispatch] Codec standardization (Re: Fwd: New Version Notification for draft-alvestrand-dispatch-rtcweb-protocols-00)
by Heinrich Sinnreich 12 Jan '11

12 Jan '11

>I think we should consider the balance > between cost, risk, quality, and existing adoption, and it would be foolish to > omit cost-bearing codecs from that analysis, as H.264 is widely used already. I am not sure where this discussion is going, though it reminds us of the discussions when arguing about SIP vs. H.323 in the IETF. "Everybody" was shipping H.323 in overwhelming quantity, but somehow the IETF did not buy it. As an hopeless optimist; maybe H.264 will have the same fate since at least it's considerable IP baggage is so well known... It is hard to imagine the IETF and indeed the market will ignore the creativity of all the codec developers out there and the evolving technology that empowers them. Plain self interest should motivate embracing new IP-free a/v codecs for the RTC Web. They will arrive anyway one way or another. [Well deployed technology has a proven way to make it over the threshold into history :-)] Henry On 12/22/10 5:46 PM, "David Singer" <singer(a)apple.com> wrote: > I should say that I am perfectly happy to have the discussion about whether, > and what, to mandate codec(s). If the placeholder is there to spark the > discussion, you succeeded! > > For me, significant IPR risk is worse than a payment -- free but risky is not > an improvement on costs-but-low-risk. But others may differ, of course. > > I do think we should be looking carefully at layered design. Ideally, we > define the missing technology bits -- HTML, Javascript/DOM, and so on; and > then, perhaps, we write an umbrella specification that uses those, and other > technology pieces, to achieve an interoperable end. But the pieces should > 'make sense' by themselves, and be usable with other assemblages, I think, if > the specs are to have 'legs' and survive over years. The pieces are ideally > stable standards/publications in their own right (and I agree, sometimes, > rarely, something is stable and well-known enough, such as ZIP or ID3 tags, > without being a 'standard'). > > I also agree that RF codecs are happening and are here to stay. Those of you > who know me from MPEG will have heard this before. They will exist, and they > will have a place. MPEG is working (slowly) on RF codecs as well. > > As to what MPEG-LA is doing, I am afraid I don't actually know. We'd have to > ask them, and they tend not to reply. The silence is strange, but I don't > think that mitigates the possibility that there is an IPR entanglement. > > Despite Henry's position (that mentioning VP8 results in no rat-holes and > flames, and that mentioning H.264 will) I think we should consider the balance > between cost, risk, quality, and existing adoption, and it would be foolish to > omit cost-bearing codecs from that analysis, as H.264 is widely used already. > > The link between open-source and royalty-free is not perfect; there are > quality open-source implementations of non-free codecs, for a start, and there > are companies who license proprietary systems royalty-free. Let's not confuse > the two, even if they often occur together. > > David Singer > Multimedia and Software Standards, Apple Inc. > > _______________________________________________ > dispatch mailing list > dispatch(a)ietf.org > https://www.ietf.org/mailman/listinfo/dispatch

14 27

VP8 hardware acceleration available
by Harald Alvestrand 11 Jan '11

11 Jan '11

This came out yesterday: http://blog.webmproject.org/2011/01/availability-of-webm-vp8-video-hardware… Main points: * VP8 (the video codec used in WebM) hardware decoder IP is available from Google for semiconductor companies who want to support high-quality WebM playback in their chipsets. * The Oulu team will release the first VP8 video hardware encoder IP in the first quarter of 2011. Details in the blog post. Harald

1 0

peer-to-peer connection API thoughts
by Matthew Kaufman 10 Jan '11

10 Jan '11

I spent the holidays thinking about various ways of dealing with the connection API problem, and I thought I might put those thoughts out for some discussion rather than trying to pick one and write it up as a draft specification. There's obviously a few models one might build upon for how to represent the peer-to-peer connections and bring them to life. The WebSockets API ( http://dev.w3.org/html5/websockets/ ) is a solution to the client-server connection problem, and the way Flash Player extended its NetConnection and NetStream objects to support peer-to-peer connectivity over RTMFP ( http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/ne… ) is another model. And of course draft-alvestrand-dispatch-rtcweb-datagram ( http://tools.ietf.org/html/draft-alvestrand-dispatch-rtcweb-datagram-00 ) hints at how a URL scheme might be applied to some of this problem. I believe the following items are givens, though feedback is of course welcome on these points as well: 1. When it is possible to establish a peer-to-peer connection for media, that should be supported (and is probably preferred) 2. Supporting peer-to-peer connections for media in the face of NA(P)T and firewalls will require UDP, and UDP hole-punching techniques (UDP is also preferable for delay-sensitive media) 3. Enabling a browser to send UDP datagrams to script- or server-designated IP addresses and ports is unsafe unless a handshake is used to verify that the other end is a willing participant 4. STUN Connectivity Check probes and responses (with short-term credentials) are a sufficiently strong handshake for the above (and this then suggests that ICE or a variant thereof is a good approach for the NAT traversal) 5. Given NAT and firewalls, it will also be necessary to support relayed UDP traffic; that is to say, a traffic flow which is peer-relay server-peer 6. Given NAT and firewalls, it will further be necessary to support transporting the same media traffic over a TCP connection, for cases where UDP is blocked. This could be a TCP tunnel of the UDP datagrams, WebSockets, or something else. ----- A few possible programming models to support this then present themselves, though this is by no means an exhaustive list... A. A single connection object which can magically make everything work In this scenario the API is essentially "var connection = new PeerConnection(destinationSpecifier);". The destinationSpecifier would contain enough information for the PeerConnection object's implementation to: use ICE to attempt to open a direct or relayed connection over UDP, or failing that, TCP. It would contain the information necessary to communicate with an intermediary server as the ICE negotiation proceeds as well (a "low bandwidth" signaling channel is required between a pair of peers in many cases for exchange of pertinent information before the media connection can be established). B. A single connection object which does most of the magic, but with the low-bandwidth signaling made external though events In this case, the API is the same as above, but rather than providing in the destiniationSpecifier some sort of server address for the "low bandwidth signaling" the connection object would instead fire events containing (essentially opaque to the channel, but in an agreed format) the data which needed to be transported to the other side. A corresponding API on the far end's "listening" connection object would allow for the data to be injected at the far end. The script implementer would simply need to wire the event up to an existing transport mechanism (HTTP, WebSockets). C. A connection object which does most of the magic, but with a parent object that is the connection to the signaling mechanism This is the approach Flash Player has taken. The NetConnection is opened to the rendezvous-handling server (which can also act as a media relay), NetStreams are then opened either to that relaying server or directly to other peers. These peer-to-peer NetStreams use the open NetConnection for the peer setup signaling (determining the far IP addresses, requesting NAT hole-punching, etc.) D. Multiple connection objects In this case, the API is similar to case A for the UDP peer-to-peer channel but a *different* API and connection object (perhaps an extension of the existing WebSocket API) is used for the client-server fallback cases. This requires the script to determine when a direct connection cannot be made (which sometimes cannot be determined without trying it out). Makes the programming model more complex, but avoids duplication, as existing client-server models can be used for all relayed (and server-based) media cases without there being two (or more) different ways to move real-time media from a server to a browser (and vice versa). E. Script-intensive (but flexible) components In this model, an API exists which exposes a nearly bare UDP socket, but with permissions restricted such that traffic may not be sent unless handshake probes are sent and received. Maximum flexibility, at some significant cost in script complexity (though this could be encapsulated into well-known, even open-source, libraries). An example API for this is would be: var connection = new PeerConnection(ICEusernameString, ICEpasswordString); opens the local UDP port, nothing is permitted at this point PeerConnection.testConnectivity(farSockaddrString, farUsernameString, farPasswordString); sends STUN connectivity checks PeerConnection.onConnectivityTest(receivedSockaddrString, usenameString); event that fires when a connectivity test is received with valid credentials. Browser also automatically generates the transaction response. PeerConnection.onConnectivitySuccess(receivedSockaddrString, reflexiveAddrString, usernameString); event that fires when the connectivity test transaction response arrives... Browser then adds this destination to a whitelist of addresses that media streams may be sent to PeerConnection.openMediaSession(sockaddrString) fails immediately if the address isn't on the whitelist, otherwise starts a DTLS handshake with the specified address ---- Hopefully this will stimulate discussion and/or additional ideas from other folks who are working on designing and/or implementing solutions to this problem. Matthew Kaufman matthew.kaufman(a)skype.net Skype: atmatthewat

4 5

Fwd: I-D ACTION:draft-bankoski-vp8-bitstream-00.txt
by Harald Alvestrand 07 Jan '11

07 Jan '11

This might be of interest to our codec discussions... This is part of the work we're undertaking to make sure VP8 has a stable referenceable specification. A request has been sent to the RFC Editor to consider this for publication as an Independent, Informational RFC. Harald -------- Original Message -------- Subject: I-D ACTION:draft-bankoski-vp8-bitstream-00.txt Date: Thu, 06 Jan 2011 14:30:01 -0800 From: Internet-Drafts(a)ietf.org Reply-To: internet-drafts(a)ietf.org To: i-d-announce(a)ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : VP8 Data Format and Decoding Guide Author(s) : J. Bankoski, P. Wilkins, Y. Xu Filename : draft-bankoski-vp8-bitstream-00.txt Pages : 150 Date : 2011-1-6 This document describes the VP8 compressed video data format created by Google On2, together with a discussion of the decoding procedure for this format. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bankoski-vp8-bitstream-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

1 0

Name discussion: What is the name of the WG that does the RTC-Web stuff?
by Harald Alvestrand 06 Jan '11

06 Jan '11

This activity remains nameless. The requirements for a name are: - It should be cute - It should be easy to remember - It should be easy to associate with the activity If it's also somewhat meaningful, that's a nice benefit. The boring choices include: - RTCWEB - WEBRTC There are many others out there. I'll try to keep track of suggestions on a page at the RTCWeb website (rtc-web.alvestrand.no), and we'll find a way to decide after a few suggestions have been made. Let the creativity flow! Harald

13 15

Re: [RTW] [dispatch] Name discussion: What is the name of the WG that does the RTC-Web stuff?
by Peter Musgrave 06 Jan '11

06 Jan '11

Here, here. Let's just pick rtcweb (since that what has been used so far) and spare mail buffers all over the planet.... Peter On 2011-01-06, at 8:49 AM, DRAGE, Keith (Keith) wrote: > Please stick to boring. > > I have the greatest difficulty in remembering what some current RAI WG are about when starting from the acronym. > > So I would place your requirements in reverse order for a prioritised list. > > Keith > >> -----Original Message----- >> From: dispatch-bounces(a)ietf.org >> [mailto:dispatch-bounces@ietf.org] On Behalf Of Harald Alvestrand >> Sent: Thursday, January 06, 2011 11:58 AM >> To: 'dispatch(a)ietf.org'; rtc-web(a)alvestrand.no >> Subject: [dispatch] Name discussion: What is the name of the >> WG that does the RTC-Web stuff? >> >> This activity remains nameless. >> The requirements for a name are: >> >> - It should be cute >> - It should be easy to remember >> - It should be easy to associate with the activity >> >> If it's also somewhat meaningful, that's a nice benefit. >> The boring choices include: >> >> - RTCWEB >> - WEBRTC >> >> There are many others out there. I'll try to keep track of >> suggestions on a page at the RTCWeb website >> (rtc-web.alvestrand.no), and we'll find a way to decide after >> a few suggestions have been made. >> Let the creativity flow! >> >> Harald >> >> _______________________________________________ >> dispatch mailing list >> dispatch(a)ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch(a)ietf.org > https://www.ietf.org/mailman/listinfo/dispatch

1 0

Fwd: [dispatch] Reminder: Deadlines for DISPATCH @ IETF-80
by Harald Alvestrand 06 Jan '11

06 Jan '11

FYI. -------- Original Message -------- Subject: [dispatch] Reminder: Deadlines for DISPATCH @ IETF-80 Date: Wed, 5 Jan 2011 15:53:37 -0600 From: Mary Barnes <mary.ietf.barnes(a)gmail.com> To: DISPATCH <dispatch(a)ietf.org> Per the note below, the deadlines for BoF proposals is January 31st. The DISPATCH WG topic deadlines for IETF-80, per http://trac.tools.ietf.org/wg/dispatch/trac/wiki, are set based on that deadline as summarized below. So, there is less than two weeks left to notify the chairs of topics targeted for discussion leading up to and during the IETF-80 DISPATCH WG session. Regards, Mary. DISPATCH WG co-chair * *Jan 17th, 2011*. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. [/Two weeks prior to BoF proposal deadline/, 7 weeks before -00 deadline] * *Jan 24th, 2011*. Cutoff for charter proposals for topics. [/One week prior to BoF proposal deadline/, two weeks before announcement of topics] * *Feb 7th, 2011*. Topics that are to be the focus of IETF-79 are announced. [/Typically one week before AD BoF approval and deadline to request WG slot/, 4 weeks before -00 deadline] * *March 6th, 2011*. -00 draft deadline. * *March 13th, 2011*. Draft deadline. ---------- Forwarded message ---------- From: *Jari Arkko* <jari.arkko(a)piuha.net <mailto:jari.arkko@piuha.net>> Date: Wed, Jan 5, 2011 at 3:29 PM Subject: time to act on IETF-80 BOFs To: IETF Discussion <ietf(a)ietf.org <mailto:ietf@ietf.org>>, Working Group Chairs <wgchairs(a)ietf.org <mailto:wgchairs@ietf.org>> Just as a reminder, if any of you are thinking of proposing new IETF work: the deadline for BOF proposals for the next meeting is January 31st. But if you have something in mind, please talk to your ADs as soon as possible. More information at http://www.ietf.org/meeting/cutoff-dates-2011.html#IETF80 Jari _______________________________________________ Ietf mailing list Ietf(a)ietf.org <mailto:Ietf@ietf.org> https://www.ietf.org/mailman/listinfo/ietf

1 0