image courtesy – flickr
WebRTC the backbone of modern communications
We had earlier worked with media devices and played the content back on a browser. This is a good test. In fact, in many of the remote collaboration softwares, if you remember, we will have a loop back test. What we accomplished earlier is equivalent to that loop back test. In this dispatch we are going to send that across the network over to a friend to fulfill the promise we started with – Staying connected!
Heads up
Now that we are approaching closer to connect with your friend, it is absolutely required that you host the web-app or the single index.html in web. There are many easy ways. URL and domain are not that much important. So to begin with you can work your way with cryptic URLs. You can start with a simple VM running in any of your favorite cloud provider could be Azure, AWS or Google. For the rest of this dispatch we will be building a simple socket-based server running in node. You can begin with Azure VM by following these steps. So, you can check out on steps to host your node js application in Azure VM in cloud here [Need to be updated].
This is required so that you could ask your friend also to come up to the same location. Treat this like more of a virtual location, a place where you and your friends hangout.
This is a simple implementation however in enterprise application scale this might be protected with server credentials at various levels e.g. in HTML, in TURN (much about it later) etc.
Signaling
This might come across a term known yet unknown to us. If you had a background of armed forces you might recollect there is a separate division / core with this exact word. In WebRTC the word stands up to the meaning of it. It is a probe which determines the route to use over internet to connect with a remote friend. I hope the last statement got you nostalgic with college level content on networks, routing etc. Well as it might sound rudimentary or simply basic, it is very important aspect of communication. Typically, we are all so educated about server and client where server is well known and client is not well known. So, client can easily connect to server and get the data it wants. For peer to peer (P2P) that is not the case, both peers are clients here thus signaling is required.
Signaling is achieved using an intermediary server which (similar to the virtual room) invites your friends, then hosts the communication. However, it does not broker or intermediate the call like a typical web server will do if we had to build a chat using a web server instead of a signaling server.
Signaling server is not a standard part of WebRTC because many offerings already exists which are standards by their own means. E.g. SIP, XMPP and the popular one which we will be using is Sockets. We will be using the socket.io library for node to be part of signaling server. Remember we said we will have to host the signaling server in web so that it is visible to your friends. We will be writing the code for that server using node js here. It is simple few lines of code written in a file called server.js
|
var httpService = require(‘http’); var socketService = require(‘socket.io’); var staticFileService = require(‘node-static’); var htmlServer = new(staticFileService.Server)();
var httpApp = http.createServer((request, response) => { htmlServer.serve(request, response) ; }).listen(3001);
var sio = socketService.listen(httpApp); let glbSocket; sio.sockets.on(‘connection’, socket => { this.glbSocket = socket; socket.on(‘message’,onMessage); socket.on(‘join’, onJoin); socket.on(‘exit’, onExit); socket.on(‘bye’, onBye); });
const onMessage = message => { console.log(‘message received => ’ + message); this.glbSocket.broadcast.emit(‘bye’); }
const onJoin = room => { console.log(‘new room creation in progress…’); var existingClients = io.sockets.adapter.rooms[room]; let clients = 0; if(existingClients) { clients = Object.keys(existingClients.sockets).length ; } switch(clients) { case 0 : this.glbSocket.emit(‘created’, room, this.glbSocket.id); console.log(‘new room created’); break ; case 1 : this.glbSocket.join(room); this.glbSocket.emit(‘joined’, room, this.glbSocket.id); io.sockets.in(room).emit(‘ready’, room); this.glbSocket.emit(‘ready’, room); break ; case 2 : this.glbSocket.emit(‘full’, room); break ; } }
const onExit = room => { this.glbSocket.broadcast.emit(‘bye’); }
const onBye = room => { console.log(`Peer exited at room ${room}.`); }
|
You can run the server by running this command in the Azure VM like you would generally do in your local machine.
|
node server.js
|
Do remember you should have configured SSL on the VM with node js server. If you miss that you will not be able to access the user media. SSL does not cost you much but implicitly carries the need to have a domain. We can cover the topic of getting a free SSL and tying it up to node js server in a VM in different dispatch.
Now that you have the server running let us pick the topic of STUN and TURN.
STUN and TURN
They are addressed hand-in-hand almost always. They solve similar sounding problem but with subtle difference. They are another piece of server software which mostly are available together. You could check coturn server on github. Needless to say if time permits you could write your own server like you endeavoured to write the signalling server.
STUN is achieved with an intermediary server which uses a light weight protocol to discover the path between two peers. This path is then used by the peers to exchange content via the signaling server. The address is used to establish the socket connection. Once that is established both STUN server and signaling server are out of the way and the two peers connect directly.
If you are not comfortable with coturn; though it should be straight forward as you already have a VM and is publicly exposed you could use a different port for the coturn. Anyways, you could use a publicly available STUN server hosted by google. There is more such server which you could discover in the internet. URL of the public STUN server of google is stun:stun.l.google.com:19302.
We did not touch upon the critical difference between STUN and TURN. In fact, for our purpose TURN might help. STUN is a simplistic protocol and sometimes it fails when a peer is behind a NAT gateway. This might be the case if your friend is connecting from a different network segment. It is advised to use a TURN server in that case. In such scenarios it is highly advised to use an owned TURN server which is coturn. You could secure a TURN server via many means. E.g. password or a certificate.
In this dispatch we have covered the ground on the signaling server. We would have a concluding write up on this where we talk about the code we have written, stitch this up together with the client code and also talk about the experience. Till then do set the expectation with your friend soon you will be connecting via a solution you had built!
