WebRTC: Video telephony without a browser plugin

Opening a Peer-to-Peer Connection

The next example goes one step further and transmits the media stream via WebRTC. Before the transfer, the browsers involved exchange session descriptions in Session Description Protocol (SDP) format [11]. The descriptions include information about media streams to be transmitted and the IP addresses, ports, and protocols to use.

Figure 5 shows the steps that an application has to take to open a peer-to-peer connection. Initially, create(), top left in the figure, creates a peer object for the browser on the left, and stream() stores the local media stream in the local peer object. Next, offer() generates a session description, and keepLoc() stores it as a local session description, also in the local peer object. Then, send() transmits the information to the right-hand browser.

Figure 5: Before opening a peer-to-peer connection, the two browsers create session descriptions and exchange them.

When the session description reaches the right-hand browser, keepRem() stores it as information about the other party. Then, answer() generates a local session description for this browser, and keepLoc() stores it as a local session description. Finally, send() transmits it back to the left-hand browser, where the local keepRem() function stores it as a remote session description. This completes the handshake.

WebRTC in the Local Browser

Listings 4 to 6 transfer the media stream via a peer-to-peer connection, as shown in Figure 5. To remove the need for a signaling server in this preliminary study, two video elements just communicate in the Firefox browser on the local machine (Figure 6). Even locally, WebRTC uses a network connection.

Figure 6: Preliminary study for video chat: Two video elements communicating in the same browser window.

Listing 4 shows the HTML document with the example. As in Listing 2, it binds two JavaScript files in the header. Line 9 of the document body contains a video element for outputting the local media stream, whereas line 10 has one for outputting the media stream transmitted via WebRTC.

Listing 4

Local and Transmitted Media Stream

01 <html>
02 <head>
03   <link rel="stylesheet" href="css/styles.css"/>
04   <script src="js/core.js"></script>
05   <script src="js/localwebrtc.js"></script>
06 </head>
07 <body>
08   <p id="msg"></p>
09   <video id="local" autoplay></video>
10   <video id="remote" autoplay></video>
11 </body>
12 </html>

Listing 5 shows the JavaScript code of the sample application from the localwebrtc.js file. Querying and configuring the media stream is handled as in Listing 2, but with a different callback function in lines 5 to 19. In Listing 5, line 6, first connects the media stream with the video element. Line 7 generates the local peer object and stores it in the pcLocal variable, and line 8 creates the remote peer object in pcRemote. Line 9 stores the local media stream in the pcLocal peer object.

Listing 5

WebRTC in the Local Browser

01 document.addEventListener('DOMContentLoaded', function() {
02   var serv = null;
03   navigator.mozGetUserMedia(
04     {video:true, audio:true},
05     function(stream) {
06       connectStream(stream, "#local");
07       var pcLocal = new mozRTCPeerConnection(serv);
08       var pcRemote = new mozRTCPeerConnection(serv);
09       pcLocal.addStream(stream);
10       pcLocal.createOffer(function(desc) {
11         pcLocal.setLocalDescription(desc);
12         pcRemote.setRemoteDescription(desc);
13         pcRemote.createAnswer(function(desc) {
14           pcRemote.setLocalDescription(desc);
15           pcLocal.setRemoteDescription(desc);
16         })
17       });
18       pcRemote.onaddstream = onadd()
19     },
20     error
21   );
22 });

The asynchronous createOffer() method in line 10 creates the session description for the local context and passes it to the callback function in lines 10 to 17, as in the desc parameter. The setLocalDescription() method stores the content of desc as a local session description in the pcLocal peer object. As the application runs locally, the setRemoteDescription() method saves the content of desc in line 12 as a remote session description for the remote peer object, pcRemote.

The call to the asynchronous createAnswer() method in line 13 creates the local session description for the remote peer object, pcRemote, and passes it to the callback function in lines 13 to 16. Line 14 then stores the session description for the remote peer object, pcRemote, as a local session description, and line 15 stores it as a remote session description for the local peer object, pcLocal.

The onaddstream event for the remote peer object, pcRemote, is triggered in line 18 by calling the onadd() function from Listing 6, which returns a callback function. It combines all incoming media streams with the video element that has the ID remote (Listing 4, line 10). Local communication has now been established.

Listing 6


01 function onadd() {
02   return function(evt) {
03     connectStream(evt.stream, "#remote");
04   }
05 }

WebRTC via the Internet

The typical application scenario for WebRTC on the Internet requires a signaling server. The signaling server forwards the configuration data, as shown in Figure 1. The following example uses the JSON format for this data. Each message corresponds to a JavaScript object with two components: command describes the type of message; data stores the payload data.

The application uses three different types of messages: A message of the offer type (Listing 7) opens a peer-to-peer connection. To acknowledge opening the connection, the remote site sends a message of the answer type in return.

Listing 7

Offer in JSON Format

01 {
02   "command":"offer",
03   "data": {
04     "sdp":"v=0\r\no=- 3077950714 2 IN IP4 [...] \r\n",
05     "type":"offer"
06   }
07 }

The data fields of the two signals contain the respective local session description. When ICE sends a new candidate, it communicates this by sending an ICE-type message. In this example, data contains the candidate.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Post-PRISM Privacy

    Linux users didn't need the recent NSA eavesdropping scandal to convince them that securing communication was a good idea. Free software developers have been creating secure tools for years that offer similar functionalities to all of those popular but very leaky services with ridiculous names.

  • Streaming with Icecast

    For live Internet radio, you need a streaming server. We’ll show you how to get started with Icecast, an open source streaming alternative for Linux.

  • Web Cryptography API

    The controversial Web Cryptography API offers flexible encryption for web applications, but it also lays the groundwork for content providers to implement more powerful access restrictions through DRM.

  • Downloading Web Video

    With the right tools, you can store YouTube movies on your hard disk and view them when Internet access is unsatisfactory or unavailable.

  • MythTV

    MythTV and its extensive ecosystem of add-ons let you turn your Linux computer into a full-featured home media center.

comments powered by Disqus

Direct Download

Read full article as PDF:

Price $2.95