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 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.

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.

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.

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.