Last January, Chrome was the first major browser to preview WebRTC, HTML5's new real time audio and video stack. Since then, we've been hard at work keeping up with the evolving specification, fixing bugs and listening to the web community’s feedback.

The main parts of the WebRTC specification are now stable and are coming soon to all 200M+ Chrome users. With this blog post, we want to help developers plan for what will be introduced in this first stable release later this year.

What's in:

JSEP
JSEP (Javascript Session Establishment Protocol) is an API for signaling that allows for much more powerful apps and flexibility in choice of signaling protocols. To abstract the complexity, we provide and maintain a Javascript lib that makes browser to browser calls a few lines of Javascript.

Topologies
Our implementation will support multiple independent PeerConnections, each capable of sending and receiving multiple independent media sources.

ICE / STUN / TURN
ICE and STUN are standardized methods for establishing a peer-to-peer connection on the Internet, even if the two end points are behind private network addresses (NAT). Chrome’s current stack deviates from the official current standards. We are working to fix this.

We will also support TURN servers to allow connections through tougher firewalls, where relaying and encapsulation are needed. Exactly what type of TURN will be supported is TBD.

DTLS-SRTP 
Encryption will be mandatory for all usage of WebRTC in Chrome. For our first stable release, we will implement DTLS-SRTP.

VP8, iSAC, iLBC, G.711
The video codec support by Chrome will be VP8. We've made several major improvements inside and around VP8 to ensure it can deliver a great real time experience. On the audio side, we will initially support iSAC, iLBC, G.711, and DTMF, with iSAC being the default. It is a royalty free wideband codec optimized for speech, open sourced at webrtc.org.

What’s next?

More functionality and features will appear in future versions of Chrome. We’ll work on prioritizing them once we get the basics right:

• Data API. Implementation will start once the network stack is ready. 
• Screen sharing. 
• PeerConnection proxying. The ability to relay a stream to a third party will not make our first version. 
• Recording. MediaRecorder specification work has not been completed yet.

Comments, questions, kudos or tomatoes? Let us know on our discussion list.

Posted by Serge Lachapelle, Product Manager