The peers have to login to the signaling server through a certain way. This would help the server in identifying the proper recipient of a call. This is indicated using (1,2,3 and 4)

Once logged in, our guy creates his offer, stores a copy of it (Local description) and sends it to the server which acts as a courier and delivers it to the rightful lady. (5,6,7 and 8)

The girl now opens up the offer, stores it to her collection (Remote description), generates the response to the offer (answer), stores it locally and sends it through the same courier to our boy (9–13)

Our guy now stores the response received from her (14)

Some negotiation (Ice Candidates negotiation) happens between them(15–20)

Once connected, they both could talk their hearts out, as long as they want! This could happen either through a direct P2P connection between them or through a TURN server if someone is behind a firewall (More like a giant of a dad!)

Ready to Serve

To start off, we need a server setup up and running along with TURN and STUN. If you are new, STUN is usually used to find out the public IP of a device and TURN is used as a relay server incase P2P is not possible between the peers. If you want to know more, you could refer the part 2 of this series which deals with all the theoretical stuff!

For this demo, we are going to use the amazing platform given by Xirsys for our STUN and TURN needs. I have a free subscription to their website and using their free tier. You might have to opt for a paid subscription or have your own setup if you want to scale it to production.

We are going to use the Google’s code labs article to set our signalling server. This article is more focused on the Android developer scope and doesn’t do much on the server side. So, we are going to use almost the same server as in the code labs demo.

Follow the link here to find out how to configure socket.io for local development. You might not want to go production with this server code as it has a lot of security holes in it. (The code there is from socket.io version 1.2 — We are going to use the same version for the sake of demo)

For the complete node server, check out the GitHub repository.

The Android Way

Coming to the Android part, if you have been following the series so far, you might find this a lot easier. In the previous part, we created the local and remote peers in the same activity class and tried to transfer the audio and video from one peer to another. We got the offer from local peer and set it to the remote peer instance.

When we are dealing with remote calls, we care just about our own local peer. Instead of managing the remote peer, we send the data needed for connection (SDP and ICE candidates) through the signaling channel.

Let us take a look at the code for call handling and signaling.

That’s a lot of code. But if you break it into pieces, and reference it with the code of Part — 2, it would make a lot of sense. The comments should help you out in finding your way through the code. (If you are still into JAVA, check out the Github repository — MainActivity.java and SignallingClient.java files)

In short, what we do is, we try to establish a connection to the socket.io web socket, and when the connection is created, we send a room name to the server. The server would then create a new room if it is not created already or add you to the room if it is already present and has vacant space. (Room capacity is set to 2 for demo purposes)

If you are the creator, you need to send the offer to the other participant once they get connected to the session. The second participant would then receive it through the socket and create their answer and send it over through the socket to the initiator.

Closing up

Now that the SDP and ICE candidates are transferred through the socket from one participant to another, WebRTC will do its magic and transfer the Audio and Video streams between the participants.

Our guy now with his small weekend project, is now able to get in touch with his girl and speak out his mind 😬 (Everything worked out perfectly fine for him and that might even be the reason for this post to get delayed 😉)

The code for this step is here on Github. In case you are wondering, this uses the latest gradle dependency for WebRTC and it might have some breaking changes to your code if you are using an older version of WebRTC. Make sure that you enable Java 8 compatibility in your app and have another look where we create PeerConnectionFactory and PeerConnection instances. There have been some changes going on there and it might break your old code.

Get in touch if you face any issues!