WebRTC: APIs, Protocols and Security Considerations - Part I

The RTCWEB protocol suite and the WebRTC API specification, currently under draft, outline a standard for peer-to-peer, real-time communication over the web. This standard is aimed at simplifying the development and use of interoperable web-based applications for peer-to-peer media and data exchange such as live video communication, Content Delivery Networks, screen casting and others without the need for third-party plugins. Implementations of the API specification are available in the current versions of Google Chrome, Mozilla Firefox and Opera.

 

The WebRTC technology leverages two popular modes of content transfer: peer-to-peer and real-time communication. Each of these have unique security requirements. Misbehaving peers, routing integrity, location privacy are some of the challenges faced by any peer-to-peer implementation. On the other hand, insecure real-time communication could suffer from eavesdropping and loss of transmission integrity via Man-in-the-Middle attacks or congestion control deficiencies. Does WebRTC address these challenges?

 

To answer this question, we’ll first review the API specification, its usage and the protocol stack as defined in the standard. In a follow-up post, we’ll analyze the security provisions built into the specification and comment on the requirements that must be addressed by the application developer.

 

Figure 1 shows the events involved in establishing a peer-to-peer multimedia channel using WebRTC

 

Fig 1.jpg

                                                                                                         Figure 1

 

The following code snippets illustrate the core APIs defined in the WebRTC specification (and as implemented in Google Chrome):

 

1.    Capture and access the media streams from local devices.

 

/* Capture media from local devices */
navigator.webkitGetUserMedia( { audio:true, video:true }, 
		onUserMediaSuccess, onUserMediaError );

/* Attach the media stream to a video element */
function onUserMediaSuccess(stream) {
	localStream = stream;
	document.getElementById('localVideo').src=
webkitURL.createObjectURL(stream); }

 

2.    The core functionality outlined in the WebRTC specification is communication of media streams across multimedia sessions between two browsers. To enable the multimedia session establishment and the eventual media exchange, the peers must exchange with each other their IP address and port information. If a peer is situated behind network components such as Network Address Translators (NAT) or firewalls, it may not possess enough information to determine a path to the remote peer. To address this challenge, the WebRTC specification includes support for the Interactive Connection Establishment (ICE) protocol, which further relies on the Session Traversal Utilities for NAT (STUN) and Traversal Using Relay NAT (TURN) protocols, to allow a peer to gather enough information for establishing a path to the remote peer.


The RTCPeerConnection API offers support for specifying the STUN/TURN server information when initializing an RTCPeerConnection object.

 

/* Initiate a Peer Connection */
peerConn = new RTCPeerConnection(
	{'iceServers':
		[{ 'url': 'stun:stun.example.com'}, 
		 { 'url': 'turn:user@turn.example.org', 
				'credential': <password>}]
	},
	{'mandatory': 
		[{'OfferToReceiveAudio': true},
		 {'OfferToReceiveVideo': true},
		 {'VoiceActivityDetection': false}]
	}
);

/* Gather transport addresses to establish a P2P media path */
peerConn.onicecandidate = function(event) {

/* Send ICE candidates to the remote peer */
signalingChannel.send(
	JSON.stringigy({“candidate”: event.candidate.candidate}));
}

/* Add ICE candidate to the peer connection on the receiving end*/
peerConn.addIceCandidate(
	new RTCIceCandidate(msg.candidate));

 

The onicecandidate event fires every time a valid ICE candidate is discovered. The candidate contains information about the type of transport as well as the transport addresses.

 

3.    The addStream API can be used to attach the media stream captured using the webkitGetUserMedia to the RTCPeerConnection object.

 

 

peerConn.addStream(stream);

 

4.    Before exchanging any media or data, the peers must negotiate a set of configuration items for the media streams or data channels as well the transport details. The configuration parameters include any media constraints set using the webkitGetUserMedia, peer connection constraints specified in the RTCPeerConnection constructor as well as the transport information obtained via ICE candidates. To exchange such configuration information, all the parameters must be encapsulated in a session description packet as specified by the Session Description Protocol (SDP). WebRTC support SDP primarily to maintain compatibility with various signaling protocols for multimedia communication such as the Session Initiation Protocol (SIP).


The WebRTC specification uses the offer/answer model for the exchange of session descriptions between peers as specified by the JavaScript Session Exchange Protocol (JSEP). Any peer interested in initiating a real-time P2P multimedia exchange, generates and sends an offer to a remote peer of interest to communicate the session parameters.


The signaling mechanism used to communicate the session descriptions between peers is not defined by the WebRTC specification. Each application is responsible for incorporating an appropriate mechanism for exchanging the session descriptions. This may include the Session Initiation Protocol (SIP) or the Extensible Messaging and Presence Protocol (XMPP) extension Jingle using XMLHttpRequest or over websockets or via the Server-Sent Events mechanism.

 

/* Peer1 sends an offer */
peerConn.createOffer(
	function(sessionDescription) {
		peerConn.setLocalDescription(sessionDescription);
		signalingChannel.send(
			JSON.stringify({“sdp”: sessionDescription}));
	}
);

/* Peer2 receives the offer */
peerConn.setRemoteDescription(
	new RTCSessionDescription(message));

/* Peer2 sends an answer */
peerConn.createAnswer(
	function(sessionDescription) {
		peerConn.setLocalDescription(sessionDescription);
		signalingChannel.send(
			JSON.stringify({“sdp”: sessionDescription}));
	}
);

/* Peer1 receives an answer */
peerConn.setRemoteDescription(
	new RTCSessionDescription(message));

/* End of Offer/Answer exchange */

  

5.    The P2P multimedia exchange will commence over the Secure Real-time Transport Protocol (SRTP) as soon as the remote peer adds a media strem to the established multimedia session.

 

function onStreamAdded(event) {
	document.getElementById(“remoteVideo”).src=
webkitURL.createObjectURL(event.stream); }

 

Part 2 of this series will cover the protocol stack and the security provisions offered by them.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation