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

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

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 .

Debug helper

Common issues around media playback

  • DOMException: The play() request was interrupted by a new load request
  • webrtcdevelopment_min.js:1 [Violation] Only request notification permission in response to a user gesture.

Read more about best WebRTC frameworks and code in this book

WebRTC SDKs Analysis

In the last few months, I have been keenly tracking how the course for WebRTC is turning out. In my opinion, it is an incredible game-changer and a market disrupter for the telco industry plagued by licensed codecs and heavy call session control software.

Contrary to my expectations the fundamental holes in WebRTC specification are still the same with less being done to fulfil them – Desktop sharing on Chrome Extension, media compatibility with desktop popular H264 being prominent obstacles to adoption. Of course, now there exists an abundance of interactive use-cases for WebRTC APIs from gaming to telemedicine. However, none of the applications is complete and standalone since each uses a new gateway to connect to their existing platform or service.

As new webrtc SDKs and open-sourcing platforms surface, many seem to be wrapping around the same old WebRTC functions ( getusermedia data-channel and peer-connection ) with few or no addons. Few of I am listing down some popular working ones in this blog but there still exists no concrete stable reliable guide to set up the backbone network ( yes I am referring to Media interconversion, relay, TURN, STUN servers ). It is left to a telecom software engineer/developer to find and figure out the best integrations to configure session handling and PSTN or desktop application compatibility.

Some commercial off the shelf service providers have begin to extend interconnecting gateways ( SBC’s) for their backend for Web-Javascript based WebRTC implementations but there are concerns on the end to end encryption and media management as it passes via transcoding media server and many points of relay. This in my opinion completely defeats the objective of WebRTC’s peer-to-peer communication which by design is supposed to be independent of centralised server setup. 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/WebSockets ) which can be quickly used by web developers to create peer to peer media session on web endpoints via a WebRTC supported browser web page.

1.appRTC

apprtc
apprtc2

Neat process of setting up offer-answer and SDP . Notice the Relay candidate gathering 

apprtc3

Session Description ( SDP) for the WebRTC peer with audio / video codecs and other session specificatiosn such as bitrate , framerate , codec profile , RTP specs etc.

apprtc4
apprtc5

No over the top media control which is good as media flows end to end here without any centralized media server .

2. talky.io

Also related to SimpleWebRTC which is a lightweight MIT licensed library providing wrappers around core WebRTC API to support application building while easing the lower level peerconnection and session management from developer.

talky1

talky2

talky3

Simmilar offer-answer handshake and SDP excahnge.

talky4 talky5 talky6

There seems to be better noise control management which could be my browser acting on my fluctuating network bandwidth as well . 

3. tokbox

tokbox2
tokbox1

More control from UI on Media settings which is provided as part of getusermedia in WebRTC specification. Read more about the webrtc APIs in my other writeup 

tokbox7
tokbox6
tokbox5

Simmilar to previous WebRTC session ( totally dependant on my own network and CPU ) , independant of any thord party control . 

As my peers network degrated , my webrtc session automatically adjust based on RTCP feedback to send lower resolutions and framerate.

tokbox4
tokbox3

4. webrtcdevelopment

Open source MIT licensed libray to spin up Webrtc calls quickly and easily from a chrome supported browser . It is a fork of best features from multiple libraries such as apprtc , webrtcexperiments , simplewebrtc and is maintained by n open community of users including me.


WebRTC Media Stack is explained in following articles