Monthly Archives: December 2014

Steps for building and deploying WebRTC solution

Step 1  : USE Local machine to test the client server WebRTC funcationality

Pick any WebRTC API and run its demos . It works kool . download and run in local-machine with nodejs server . Awesome . Everything is Awesome !!

You can learn more about some WS based WebRTC API here:  https://altanaitelecom.wordpress.com/2014/12/02/current-state-of-webrtc/.

If you are a diehard telecom engineer and only want SIP based WebRTC solutions go here : https://altanaitelecom.wordpress.com/2014/07/16/interoperability-between-webrtc-sip-phones-and-others/

Steps for building and deploying WebRTC solution Step 1 : Pick a WebRTC API and run locally ( ie open 2 browsers and run on local machine )

Steps for building and deploying WebRTC solution
Step 1 : Pick a WebRTC API and run locally ( ie open 2 browsers and run on local machine )

Step 2 : Use cloud Server and different client Browsers  

Now what good is it doing to anyone if its running locally on my machine with addresses like localhost and 127.0.0.1  . Let us put it on the cloud and at-least let my colleague / friends enjoy it .  Cloud Web Server and Nodejs signalling server . That is okay use amazon’s Ec2. works for most of the people most of the time .

Steps for building and deploying WebRTC solution Step 2 : Put Server on cloud and WebRTC clients on different machine

Steps for building and deploying WebRTC solution
Step 2 : Put Server on cloud and WebRTC clients on different machine

Here is when we discover the issues of ICE ( Interactive Connectivity Establishment ) I have mentioned this in detail on the post NAT Traversal using STUN and TURN .  Briefly ICE helps us in coping up with NAT ( Network Address Traversal and Firewalls ) .

Note that this step only works if everyone you want to connect to is either on same intranet or on public internet without and UDP blocks / firewalls / restriction .

As we try to connect 2 WebRTC clients from different machine and different networks we find that network address from client’s OS and network card fails to connect to Signalling Server due to either Firewalls issues or other Network policies . We therefore use a STUN server to map the private IP to a publicly accessible IP that will help in completing the signalling

The Signalling is establishes using a STUN server for address mapping and NAT . One can use google’s default STUN server stun.l.google.com:19302. Easy and free .

Steps for building and deploying WebRTC solution Step 2.1 : Put Server on cloud and WebRTC clients on different machine + STUN for address discovery ( NAT traversal )

Steps for building and deploying WebRTC solution
Step 2.1 : Put Server on cloud and WebRTC clients on different machine + STUN for address discovery ( NAT traversal )

There you go everything is looking good from here now , both peers join the session successfully  , but the video may appear black . This is so because the media under most inter network conditions fails to flow between private and public network .

This is where step 3 comes into picture ie using a TURN ( media relay ) server .

Step 3: TURN server to Call people in a inter-network fashion 

Sure the architecture I have setup is bound to work everywhere where the network is open and public . However error in connectivity , errors in console , blank video are the problems that might appear when one tries to connect from private to public connections.

To bypass network firewalls , corporate net policies , UDP blocks and filters we require a TURN server which help in media traversal across different networks in a relay mechanism.

Now we have 3 options to choose from

1.  Use a wildly popular http://numb.viagenie.ca/

2. Build your own TURN server with RFC 5766 ( COTURN )  , or rather easier would be to use any open source TURN server code available in Github.

3. Pay and use a commercial TURN service provider or you can even use their trail version to see if things work out for you ( example Xirsys)  .

Remember you can use any TURN service it does not affect your WebRTC API functionality . All we need to do is add it to Peerconnection configuration like

</address><address>peerConnectionConfig: {
iceServers:[</address><address>{"url": < stunserver address >},</address><address>{"username":"xx","url":< turn server address transport=udp>,"credential":"yy"},</address><address>{"username":"xx","url":< turn server address transport=tcp> , "credential":"yy"}]</address><address>},</address><address>

There we go , now anyone from anywhere should be able to use our WebRTC setup for making audio , video calls or just exchanging data via DataChannel ( like screen-sharing , file transfer , messages , playing games , collaborative office work etc )  .

Steps for building and deploying WebRTC solution TURN based media Relay for WebRTC traffic

Steps for building and deploying WebRTC solution
TURN based media Relay for WebRTC traffic

The setups covers scenarios wherein user is on office corporate network , home network , mobile network , no problem as long as he / she has a webrtc enables browser ( read Chrome , Mozilla , Opera ) .

It is noteworthy that ideally voice should be traversing on TCP while video and data can go around in UDP however unless restrained the WebRTC API’s self determine the best protocol to route the packets / stream .


Read more about best WebRTC frameworks and code in this book

APPRTC , Talky.io , TokBox

In the last few months I have been observing how the course for WebRTC is turning out so far . Unfortunately contrary to my expectations the fundamental holes in WebRTC specification are still the same with less being done to fulfill them . Ofcourse now there are abundance of interactive
WebRTC API each using a new masking method to call the same old WebRTC API function of getusermedia and peer-connection . Few of these I will list down in this blog but no concrete stable reliable  guide to setup the backbone network ( yes i am referring to Media inter conversion , relay , TURN , STUN servers ) which is left to telecom software engineer / developer to find out and configure . Instead I see many commercial service providers who claim of providing their backend for our WebRTC implementation but that in my opinion completely defeats the objective of WebRTC based communication .  WebRTC was meant to *everything you can’t do with proprietary communication tools and networks* .

Well moving on , here are some nice API implementations of WebRTC ( only for Websockets no SIP )

1.appRTC

apprtc apprtc2 apprtc3 apprtc4 apprtc5

2. talky.io

talky3 talky2 talky1 talky4 talky5 talky63. tokbox

tokbox2tokbox1tokbox7 tokbox6 tokbox5 tokbox4 tokbox3