Welcome to the final installment of Writing Your First WebRTC Application. I covered quite a bit of ground in my first three articles and it’s time to wrap this up with some examples of useable WebRTC code. I applaud those of you that stayed with me as I’ve dug into some pretty complicated stuff. This isn’t rocket science, but it’s not intuitively obvious, either.
I highly recommend that you read the following before tackling this article:
Writing Your First WebRTC Application: Part One
Writing Your First WebRTC Application: Part Two
Writing Your First WebRTC Application: Part Three
In Part Three, I walked you through the basic flow from the standpoints of the WebRTC called and called parties. You may recall that a lot of what is required to set-up a call is similar for both sides. In summary, the following steps are performed by caller and called:
- Start signaling
- Exchange contact information
- Negotiate media sessions
- Start RTCPeerConnection Streams
This last step, Start RTCPeerConnectionStreams, is where they differ. Essentially, the caller will create and send an offer and the called party will receive the offer and return an answer. At this point, media will flow.
Got it? Great! Let’s get started with some examples of how you can implement those steps.
Start Signaling
This can be done any number of different ways, but most WebRTC developers have settled on WebSocket to create a communications channel from a client to a signaling server.
signalingChannel = new WebSocket(signalingURL);
signalingChannel.onopen = onChannelOpened;
signalingChannel.onmessage = onChannelMessage;
signalingChannel.onclose = onChannelClosed;
The parameter signalingURL indicates the URL of the signaling server.
After the WebSocket has been created, you need to set three callbacks. In this example:
The function onChannelOpened will be invoked when the connection to the signaling server has been established. This is where you will negotiate (calling party) or enter (called party) a meeting room with the signaling server and begin capturing local media.
The function onChannelMessage will be invoked when a new message is received from the signaling server. This is where you will be informed of WebRTC offers, answers, and the RTCIceCandidate.
The function onChannelClosed will be invoked when the connection to the signaling server has been released.
Once the channel has been opened (onChannelOpened is invoked), the WebRTC application is able to send messages to the signaling server via signalingChannel.send(msgString).
Exchange Contact Information
This is where a WebRTC application deals with issues that arise from private IP addresses. I wrote extensively about this in my article Understanding WebRTC Media Connections: ICE, STUN, and TURN, so rather than repeating myself, I ask that you find the pertinent information there.
Negotiate Media Sessions
Once clients know how to communicate with each other, they need to agree upon the type and format of the media. This is accomplished with something called JavaScript Session Establishment Protocol (JSEP). JSEP uses Session Description Protocol (SDP) to identify the codec, resolution, bitrate, frame size, etc. of the media supported by a client.
This magic is invoked using the RTCPeerConnection object methods createrOffer() and createrAnswer(). According to the WebRTC specification, these functions are defined as the following:
The createOffer method generates a blob of SDP that contains an RFC 3264 offer with the supported configurations for the session, including descriptions of the local MediaStreams attached to this RTCPeerConnection, the codec/RTP/RTCP options supported by this implementation, and any candidates that have been gathered by the ICE Agent. The options parameter may be supplied to provide additional control over the offer generated.
The createAnswer method generates an SDP answer with the supported configuration for the session that is compatible with the parameters in the remote configuration. Like createOffer, the returned blob contains descriptions of the local MediaStreams attached to this RTCPeerConnection, the codec/RTP/RTCP options negotiated for this session, and any candidates that have been gathered by the ICE Agent. The options parameter may be supplied to provide additional control over the generated answer.
As I stated above, createOffer() and createAnswer() will be kicked off via messages from the signaling server.
Start RTCPeerConnection Streams
After the peers have initialized their local media streams, found their ICE candidates, and exchanged SDP, data transfer can begin. This is accomplished by calling the attachMedia() function defined in Part Two of this missive.
That’s All Folks
Well, that’s it. This is not easy stuff, folks. However, it’s also not impossible to master and if I can get a WebRTC application to work, so can you.
I realize that there is much more to understand about this power subject and I recommend that you do what I did. Find yourself a good book or two. Read the WebRTC specification. Search out well written articles on the Internet. Find the sample code that people have freely shared. Most importantly, play around with WebRTC and have some fun. I guarantee that it will be time well spent.
Tao, Zen, and Tomorrow 