Real-Time Communication Without Plugins
WebRTC stands for Web Real-Time Communication, and it is a peer-to-peer communication technology for the browser, that enables video/audio calling and data sharing without additional plugins. WebRTC started as an effort by Google, to build a standard real-time Media Engine into all the available major browsers, and is now supported by Google, Mozilla and Opera. The API and underlying protocols are being developed jointly at the W3C and IETF. Similar attempts at implementing peer-to peer communications over the web have been made before by Adobe through their acquisition of Amicima in 2006 and subsequent Flash Player 10 (October 2008) and 10.1 (June 2010) releases. Somehow the peer-to-peer technology in Flash Player never took off.
Now you may say: “But we already have real-time communication technologies such as Flash Player (with AMS) and WebSockets , there is no need for WebRTC”.
The UDP Protocol Enabled in the Browser
WebRTC primarily uses the UDP protocol, which is a lot faster than TCP because it doesn’t worry about order or error correction. UDP is used in cases when only the latest piece of data has importance and there is no need to wait for other data in order to be received correctly. VoIP and multiplayer games are a very good example for applications that use the UDP protocol. WebRTC enables for the very first time the UDP protocol to be available in the browser without additional plugins, and because of this a lot of developers are excited to get their hands on it.
What is the potential for WebRTC use?
WebRTC is primarily known for being a video – audio call peer-to-peer technology between browsers, similar to Skype. But WebRTC can do more than that.
- Collaborative activities
- Multiplayer games (here WebRTC gives rise to a whole new type of games that do not need a server to be played in multiplayer)
- Peer-to-peer file sharing (BitTorrent in the browser ? – possible)
- Peer-to-peer CDN
- Remote control of devices from other devices (this is possible even without an internet connection. Theoretically this could work via the local network). Maybe smartphones could also be used as gamepads for TV consoles or Desktop games.
Currently WebRTC implements three APIs:
- MediaStream (aka getUserMedia)
getUserMedia like the name suggests gets the video and audio if available, from an input (ex web-cam), and outputs it in the browser via the HTML5 <video> tag. To see it in action take a look at this cross-browser demo.
RTCPeerConnection lets you make peer-to-peer connections and attach media streams like video and audio.The name of the Chrome implementation of the API is prefixed with webkit. Firefox Aurora/Nightly named it mozRTCPeerConnection. When the standards process has been stabilized the prefixes will be removed. Here’s a link to a demo of Chrome’s RTCPeerConnection. This is needed by video chat apps. Here is an example of this API in action: video-chat application.
RTCDataChannel lets you send arbitrary data across a peer-to-peer connection.
The 3 APIs are supported as followed:
- Google Chrome version 23
- Mozilla Firefox version 22
- Opera version 12 (only supports getUserMedia, no real peer-to-peer support)
- IE has no native support for WebRTC but it can be added using Chrome Frame (development for Chrome Frame is no longer active).
- Safari not supported
- Google Chrome OS
- WebRTC is also supported by the Ericsson Bowser browser which runs on Android and iOS.
For a detailed comparison between browsers you can access this link.
MediaStream in Detail
MediaStream aka getUserMedia represents the synchronized streams of media i.e. a stream taken from a web-cam has synchronized audio and video tracks. Each MediaStream has an input, that can be a LocalMediaStream generated by navigator.getUserMedia(), and an output which could be passed to a video element from HTML5 or an RTCPeerConnection.
The getUserMedia() method takes three parameters:
- A constraint object
- A success callback function that passes the LocalMediaStream
- A failure callback that passes an error object
RTCPeerConnection in Detail
RTCPeerConnection is the API used by WebRTC to communicate streaming data between browsers. This also needs a mechanism to coordinate communication and to send control messages, a process known as signaling. These signaling methods and protocols are not part of the RTCPeerConnection API. This way developers can choose what messaging protocol to use (ex: SIP or XMPP). Google provides the Channel API as a signaling mechanism. WebRTC has also been proven to work using WebSockets for signaling.
Signaling is used to exchange three types of information:
- Session control messages: to initialize or close communication and report errors.
- Network configuration: to the outside world, what’s my computers IP address and port.
- Media capabilities: what codecs and resolutions can be handled by my browser and the browser it wants to communicate with.
All of this information must be exchanged successfully before a peer-to-peer streaming can be established.
Here’s a code sample from the WebRTC W3C Working Draft, which shows the signaling process in action. (The code assumes the existence of some signaling mechanism, created in the
createSignalingChannel() method. Also note that on Chrome, RTCPeerConnection is currently prefixed.)
The code from the link above shows a simplified version of WebRTC from a signaling perspective. In the real world, WebRTC needs servers, however simple, in order to achieve the following:
- Users discover each other and exchange real world information.
- WebRTC client apps (peers) exchange network information.
- Peers exchange media capabilities such as video format and resolution.
- WebRTC client apps traverse NAT gateways and firewalls.
The requirements for building a server, NAT traversal and peer-to-peer networking exceed the scope of this article,however what is important to remember is the following: WebRTC uses the ICE protocol which in turn uses the STUN and it’s extension TURN protocol, to enable peer-to-peer communications (this is needed in order to enable peers behind a NAT, to find out the IP address and port). Google provides several STUN servers already.
WebRTC as currently implemented only supports one-to-one communication, but could be used in more complex network scenarios: for example, with multiple peers each communicating each other directly, peer-to-peer, or via a centralized server.
So as we can see, WebRTC also needs a middleman (some kind of server), similar to how the Flash Player uses Adobe Cirrus or Adobe Media Server Extended version (the former Enterprise version) with RTMFP, in order to achieve peer-to-peer communication.
One good example of an application that uses peer-to-peer technology and also needs servers in order to make user discovery and communication is Skype.
RTCDataChannel in Detail
The RTCDataChannel is a WebRTC API for high performance, low latency, peer-to-peer communication of arbitrary data. The API is simple—similar to WebSocket—but communication occurs directly between browsers, so RTCDataChannel can be much faster than WebSocket even if a relay (TURN) server is required when ‘hole punching’ to cope with firewalls and NATs fails.
Potential applications for the RTCDataChannel API are:
- File transfer
- Real-time text chat
- Remote desktop applications
- Decentralized networks
The API provides several features that make the most out RTCPeerConnection:
- Reliable and unreliable delivery semantics.
- Built-in security (DTLS) and congestion control.
- Multiple simultaneous channels with prioritization.
- Ability to use with or without audio and video.
- Leveraging of RTCPeerConnection session setup.
Video and Audio Codecs
As stated on the official webRTC FAQ the currently supported codecs are:
The codecs included in the WebRTC project are subject to change.
The huge dilemma right now is how will cross browser communication will actually work. Browsers will always differ in the optional codecs they will support. So for example if Chrome encodes the video with VP8 and sends it to Firefox, and Firefox does not know how to decode VP8, then communication would not be possible.
At this time there is a war going on between Google and Ericsson, on which codecs should be standardized for WebRTC.
Google’s side: VP8 for video and Opus for voice along with G.711. All are royalty free and provide high quality.
Ericsson’s side: H.264 for video with the prospect of H.265, G.719 or AMR-NB. Maybe even AMR-WB and EVS. ITU standards impose these codecs.
Microsoft is also pushing a proposal of their own for WebRTC called CU-RTC-Web, but for now this only remains a proposal.
Google comes from the Internet world. In it, royalty free is an asset, making VP8 a better option than H.264. The selection of Opus, which is a royalty free audio codec, comes from the fact that it was developed and standardized by the IETF (where the Internet lives) and is a “derivative work” of Skype’s SILK codec. It is considered a good codec, but for now it is not included in the WebRTC project.
Ericsson’s is coming from the mobile and the ITU standardization work. All codecs suggested by Ericsson come either from the ITU or mobile (3GPP), so it makes sense for them to support this angle. Ericsson also has patents in H.264, making it a benefactor of royalty payments from the use of this codec.
Microsoft? They’re on Ericsson’s side. They are looking for more options, power, flexibility. But by doing that, they are complicating the solution and probably running it to the ground.
If the IETF will settle on multiple codecs for voice and video as mandatory ones this is going to be bad for the industry: the simple solution should win – it will make it easier for companies to adopt and for disruption to appear. If we will end up with 4 or more voice codecs and 2 or more video codecs, then we are in for the same hurdles, of not having a standardized set of codecs, we have today with other VoIP standards.
For now it seems Google has the upper hand. Hope it stays this way, but if the multiple codecs approach will be adopted, transcoding will be needed for communications between browsers, and that is not a good thing at all, because transcoding adds latency, reduces quality, it is expensive and a trusted third-party will always have to be involved.
There are several ways a real-time communication application or plugin might compromise security. For example:
- Unencrypted media or data might be intercepted en route between browsers, or between a browser and a server.
- An application might record and distribute video or audio without the user knowing.
- Malware or viruses might be installed alongside an apparently innocuous plugin or application.
WebRTC provides the following solutions to avoid these problems:
- WebRTC implementations use secure protocols such as DTLS and SRTP.
- Encryption is mandatory for all WebRTC components, including signaling mechanisms.
- WebRTC is not a plugin: its components run in the browser sandbox and not in a separate process, components do not require separate installation, and are updated whenever the browser is updated.
- Camera and microphone access must be granted explicitly and, when the camera or microphone are running, this is clearly shown by the user interface.
WebRTC vs P2P implementation in Flash Player
Adobe Cirrus (formerly known as Adobe Stratus) enables peer assisted networking using the Real Time Media Flow Protocol (RTMFP) within the Adobe Flash Platform. In order to use RTMFP, Flash Player endpoints must connect to an RTMFP-capable server, such as the Cirrus service. Cirrus is a beta, hosted rendezvous service that aids establishing communications between Flash Player endpoints. This is a free service. The second solution is the purchasing of Adobe Media Server Extended edition, the only version that supports RTMFP.
Let’s see some comparison between Adobe’s approach and WebRTC.
P2P implementation in Flash Player
|Availability Date||May 2011||October 2008|
|Maturity Date||Not Yet||June 2010|
|Servers Needed||Service server and STUN/TURN servers||RTMFP enabled Servers (Adobe Media Server Extended which costs around 45000 $ or Adobe Cirrus Service which is free)|
|Encryption Technology||DTLS and SRTP||128-bit AES|
|NAT Traversal||ICE protocol and STUN/TURN protocols||TURN protocol|
|Famous Apps Using the Technology||None||None|
The standards and APIs of WebRTC are still in the working and the technology behind it is still not fully developed, fact that can be seen by not being fully supported yet across all platforms and browsers. Adobe also spent 2 to 4 years developing peer-to-peer communication technology, but it never really caught any real attention and that is because technology should walk in the steps of desire and need and not the other way around.