If you have an account with Packt at www.PacktPub.com, you can use this to access PacktLib today and view nine entirely free books. Simply use your login credentials for immediate access.

The differentiation between signal and media flows is an important aspect of the WebRTC call setup.

The signaling mechanism can be any among HTTP/REST, JavaScript Object Notation (JSON) via XMLHttpRequest (XHR), Session Initiation Protocol (SIP) over websockets, XMPP, or any custom or proprietary protocol. The media (audio/video) is defined through the Session Description Protocol (SDP) and flows from peer to peer.

A few instances of end-to-end signaling and media flow variants are shown in the following screenshot:

The preceding figure depicts signaling over the WebRTC API in the JSON format via XHR.

Now, the following figure depicts signaling over the WebRTC API in eXtensible Messaging and Presence Protocol (XMPP):

While it's very popular to use the WebRTC API with SIP support through JavaScript libraries such as JSSIP, SIPML5, PJSIP, and so on, these libraries cater to the SIP/IMS (IP Multimedia Subsystem) world and are not mandatory for setting up enterprise-level WebRTC Infrastructure. In fact, it is a misconception that WebRTC is coupled with SIP in itself; it isn't.

The JavaScript getUserMedia function (also known as MediaStream) is used to allow the web page to access users' media devices such as camera and microphone using the browser's native API, without the need of any other third-party plugins such as Adobe Flash and Microsoft Silverlight.

The following is the code to access the IP camera in the Google Chrome browser and display the local video in a <video/> element:

/*The HTML to define a button to begin the capture and HTML5 video element on web page body */
<video id="vid" autoplay="true"></video>
<button id="btn" onclick="start()">Start</button>

/*The JavaScript block contains the following function call to start the media capture using Chrome browser's getUserMedia function*/
video = document.getElementById("vid");
function start() {
  navigator.webkitGetUserMedia({video:true}, gotStream, function() {});
  btn.disabled = true;
}

/*The function to add the media stream to a video element on a page*/
  function gotStream(stream) {
  video.src = webkitURL.createObjectURL(stream);
}

The following screenshot depicts the user notification for granting permission to access the camera in Google Chrome:

The following screenshot depicts the user notification for granting permission to access the camera in Mozilla Firefox:

The following screenshot depicts the user notification for granting permission to access the camera in Opera:

In WebRTC, media traverses in a peer-to-peer fashion and is necessary to exchange information prior to setting up a communication path such as public IP and open ports. It is also necessary to know about the peer's codecs, their settings, bandwidth, and media types.

To make the peer connection, we will need a function to populate the values of the RTCPeerConnection, getUserMedia, attachMediaStream, and reattachMediaStream parameters. Due to the fact that the WebRTC standard is currently under development, the JavaScript API can change from one implementation to another. So, a web developer has to configure the RTCPeerConnection, getUserMedia, attachMediaStream, and reattachMediaStream variables in accordance to the browser on which we are running the HTML content.

The browser APIs of different browsers have different names. The criterion is to determine the browser on which the web page is opened and then call the appropriate function for the WebRTC operation. The identity of the browser can be determined by extracting a friendly name or checking for a match with a specific library name of the different browser. For example, when navigator.webkitGetUserMedia is true, then WebRTCDetectedBrowser = "chrome", and when navigator.mozGetUserMedia is true, then WebRTCDetectedBrowser = "firefox". The following table shows the W3C standard elements in Google Chrome and Mozilla Firefox:

Such methods also exist for Opera, which is a new addition to the WebRTC suite. Hopefully, Internet Explorer, in the future, would have native support for WebRTC standards. For other browsers such as Safari that don't support WebRTC as yet, there are temporary plugins that help capture and display the media elements, which can be used until these browsers release their own enhanced WebRTC supported versions. Creating WebRTC-compatible clients in Internet Explorer and Safari is discussed in Chapter 9, Native SIP Application and Interaction with WebRTC Clients.

The following code snippet is used to make an RTC peer connection and render videos from one HTML video frame to another on the same web page. The library file, adapter.js, is used, which renders the polyfill functionality to different browsers such as Mozilla Firefox and Google Chrome.

The HTML body content that includes two video elements for the local and remote videos, the text status area, and three buttons to start capturing, sending, and stop receiving the stream are given as follows:

<video id="vid1" autoplay="true" muted="true"></video>
<video id="vid2" autoplay></video>
<button id="btn1" onclick="start()">Start</button>
<button id="btn2" onclick="call()">Call</button>
<button id="btn3" onclick="hangup()">Hang Up</button>
<xtextarea id="ta1"></textarea>
<xtextarea id="ta2"></textarea>

The JavaScript program to transmit media from the video element to another at the click of the Start button, using the WebRTC API is given as follows:

/* setting the value of start, call and hangup to false initially*/
btn1.disabled = false;
btn2.disabled = true;
btn3.disabled = true;

/* declaration of global variables for peerconecection 1 and 2, local streams, sdp constrains */
var pc1,pc2;
var localstream;
var sdpConstraints = {'mandatory': {
                        'OfferToReceiveAudio':true,
                        'OfferToReceiveVideo':true }};

The following code snippet is the definition of the function that will get the user media for the camera and microphone input from the user:

function start() {
  btn1.disabled = true;
  getUserMedia({audio:true, video:true},
  /* get audio and video capture */
  gotStream, function() {});
}

The following code snippet is the definition of the function that will attach an input stream to the local video section and enable the call button:

function gotStream(stream){
  attachMediaStream(vid1, stream);
  localstream = stream;/* ready to call the peer*/
btn2.disabled = false;
}

The following code snippet is the function call to stream the video and audio content to the peer using RTCPeerConnection:

function call() {
  btn2.disabled = true;
  btn3.disabled = false;
  videoTracks = localstream.getVideoTracks();
  audioTracks = localstream.getAudioTracks();
  var servers = null;

  pc1 = new RTCPeerConnection(servers);/* peer1 connection to server */
  pc1.onicecandidate = iceCallback1;
  pc2 = new RTCPeerConnection(servers);/* peer2 connection to server */

  pc2.onicecandidate = iceCallback2;
  pc2.onaddstream = gotRemoteStream;
  pc1.addStream(localstream);
  pc1.createOffer(gotDescription1);
}

function gotDescription1(desc){/* getting SDP from offer by peer2 */
pc1.setLocalDescription(desc);
pc2.setRemoteDescription(desc);
pc2.createAnswer(gotDescription2, null, sdpConstraints);
}

function gotDescription2(desc){/* getting SDP from answer by peer1 */
pc2.setLocalDescription(desc);
pc1.setRemoteDescription(desc);
}

On clicking the Hang Up button, the following function closes both of the peer connections:

function hangup() {
  pc1.close();
  pc2.close();
  pc1 = null; /* peer1 connection to server closed */
  pc2 = null; /* peer2 connection to server closed */
  btn3.disabled = true; /* disables the Hang Up button */
  btn2.disabled = false; /*enables the Call button */

}

function gotRemoteStream(e){
  vid2.src = webkitURL.createObjectURL(e.stream);
}

function iceCallback1(event){
  if (event.candidate) {
    pc2.addIceCandidate(new RTCIceCandidate(event.candidate));
  }
}

function iceCallback2(event){
  if (event.candidate) {
    pc1.addIceCandidate(new RTCIceCandidate(event.candidate));
  }
}

In the preceding example, JSON/XHR (XMLHttpRequest) is the signaling mechanism. Both the peers, that is, the sender and receiver, are present on the same web page; this is represented by the two video elements shown in the following screenshot. They are currently in the noncommunicating state.

As soon as the Start button is hit, the user's microphone and camera begin to capture. The first peer is presented with the browser request to use their camera and microphone. After allowing the browser request, the first peer's media is successfully captured from their system and displayed on the screen. This is demonstrated in the following screenshot:

As soon as the user hits the Call button, the captured media stream is shared in the session with the second peer, who can view it on their own video element. The following screenshot depicts the two peers sharing a video stream:

The session can be discontinued by clicking on the Hang Up button.

The DataChannel function is used to exchange text messages by creating a bidirectional data channel between two peers. The following is the code to demonstrate the working of RTCDataChannel.

The following code snippet is the HTML body of the code for the DataChannel function. It consists of a text area for the two peers to view the messages and three buttons to start the session, send the message, and stop receiving messages.

<div id="left">
<br>
<h2>Send data</h2>
<textarea id="dataChannelSend" rows="5" cols="15" disabled="true">
</textarea>
<br>
<button id="startButton" onclick="createConnection()">
  Start</button>
<button id="sendButton" onclick="sendData()">Send Data</button>
<button id="closeButton" onclick="closeDataChannels()">Stop Send Data
</button>
<br>
</div>
<div id="right">
<br>
<h2>Received Data</h2>
<textarea id="dataChannelReceive" rows="5" cols="15" disabled="true">
</textarea><br>
</div>

The style script for the text area is given as follows; to differentiate between the two peers, we place one text area aligned to the right and another to the left:

#left { position: absolute; left: 0; top: 0; width: 50%; }
#right { position: absolute; right: 0; top: 0; width: 50%; }

The JavaScript block that contains the functions to make the session and transmit the data is given as follows:

/*Declaring global parameters for both sides' peerconnection, sender, and receiver channel*/
var pc1, pc2, sendChannel, receiveChannel;

/*Only enable the Start button, keep the send data and stop send data button off*/
startButton.disabled = false;
sendButton.disabled = true;
closeButton.disabled = true;

The following code snippet is the script to create PeerConnection in Google Chrome, that is, webkitRTCPeerConnection that was seen in the previous table. It is noted that a user needs to have Google Chrome Version 25 or higher to test this code. Some old Chrome versions are also required to set the --enable-data-channels flag to the enabled state before using the DataChannel functions.

function createConnection() {
  var servers = null;
  pc1 = new webkitRTCPeerConnection(servers,{
    optional: [{RtpDataChannels: true}]});
    try {
      sendChannel = pc1.createDataChannel("sendDataChannel", {
        reliable: false});
    } catch (e) {
      alert('Failed to create data channel.' + 'You need Chrome M25 or later with --enable-data-channels flag'););
    }

  pc1.onicecandidate = iceCallback1;
  sendChannel.onopen = onSendChannelStateChange;
  sendChannel.onclose = onSendChannelStateChange;
  pc2 = new webkitRTCPeerConnection(servers,{
    optional: [{RtpDataChannels: true}]});
  
  pc2.onicecandidate = iceCallback2;
  pc2.ondatachannel = receiveChannelCallback;

  pc1.createOffer(gotDescription1);
  startButton.disabled = true; /*since session is up, disable start button */
  closeButton.disabled = false;  /*enable close button */
}

The following function is used to invoke the sendChannel.send function along with user text to send data across the data channel:

function sendData() {
  var data = document.getElementById("dataChannelSend").value;
  sendChannel.send(data);
}

The following function calls the sendChannel.close() and receiveChannel.close() functions to terminate the data channel connection:

function closeDataChannels() {
sendChannel.close();
receiveChannel.close();
pc1.close();      /* peer1 connection to server closed */
pc2.close();      /* peer2 connection to server closed */

  pc1 = null;
  pc2 = null;
startButton.disabled = false;
sendButton.disabled = true;
closeButton.disabled = true;
document.getElementById("dataChannelSend").value = "";
document.getElementById("dataChannelReceive").value = "";
document.getElementById("dataChannelSend").disabled = true;
}

Peer connection 1 sets the local description, and peer connection 2 sets the remote description from the SDP exchanged, and the answer is created:

function gotDescription1(desc) {
  pc1.setLocalDescription(desc);
  pc2.setRemoteDescription(desc);
  pc2.createAnswer(gotDescription2);
}

function gotDescription2(desc) {
  pc2.setLocalDescription(desc);
  trace('Answer from pc2 \n' + desc.sdp);
  pc1.setRemoteDescription(desc);
}

The following is the function to get the local ICE call back:

function iceCallback1(event) {
  if (event.candidate) {
    pc2.addIceCandidate(event.candidate);
  }
}

The following is the function for the remote ICE call back:

function iceCallback2(event) {
  if (event.candidate) {
    pc1.addIceCandidate(event.candidate);
  }
}

The function that receives the control when a message is passed back to the user is as follows:

function receiveChannelCallback(event) {
  receiveChannel = event.channel;
  receiveChannel.onmessage = onReceiveMessageCallback;
  receiveChannel.onopen = onReceiveChannelStateChange;
  receiveChannel.onclose = onReceiveChannelStateChange;
}

function onReceiveMessageCallback(event) {
  document.getElementById("dataChannelReceive").value = event.data;
}

function onReceiveChannelStateChange() {
  var readyState = receiveChannel.readyState;
}

function onSendChannelStateChange() {
  var readyState = sendChannel.readyState;
  if (readyState == "open") {
    document.getElementById("dataChannelSend").disabled = false;
    sendButton.disabled = false;
    closeButton.disabled = false;
  } else {
    document.getElementById("dataChannelSend").disabled = true;
    sendButton.disabled = true;
    closeButton.disabled = true;
  }
}

The following screenshot shows that Peer 1 is prepared to send text to Peer 2 using the DataChannel API of WebRTC:

Empty text areas before beginning the exchange of text

On clicking on the Start button, as shown in the following screenshot, a session is established between the peers and the server:

Putting in text from one's peers after hitting the Start button

As Peer 1 keys in the message and hits the Send button, the message is passed on to Peer 2. The preceding snapshot is taken before sending the message, and the following picture is taken after sending the message:

Text is exchanged on DataChannel on the click of the Send button

However, right now, you are only sending data from one localhost to another. This is because the system doesn't know any other peer IP or port. This is where socket-based servers such as Node.js come into the picture.

Real-time Transport Protocol (RTP) is the way for media to flow between end points. Media could be audio and/or video based.

RTP in WebRTC is by default peer-to-peer as enforced by the Interactive Connectivity Establishment (ICE) protocol candidates, which could be either STUN or TURN. ICE is required to establish that firewalls are not blocking any of the UDP or TCP ports. The peer-to-peer link is established with the help of the ICE protocol. Using the STUN and TURN protocols, ICE finds out the network architecture and provides some transport addresses (ICE candidates) on which the peer can be contacted.

An RTCPeerConnection object has an associated ICE, comprising the RTCPeerConnection signaling state, the ICE gathering state, and the ICE connection state. These are initialized when an object is first created. The flow of signals through these nodes is depicted in the following call flow diagram:

ICE, STUN, and TURN are defined as follows:

1. On a Windows machine, install nodejs.exe from the official download site, http://www.nodejs.org.
2. To check whether Node.js is properly installed and working, check the version using the following command lines

   node -v
   

   The output in my case is v0.10.26.

3. Open the command prompt, and type node <name of the JS file> in the window. Consider the following command line as an example:

   node signaler.js
   

1. First, we need a JavaScript library to support WebRTC signaling operations. We can use signaller.js for this. Download signaller.js from https://github.com/muaz-khan/WebRTC-Experiment/blob/master/websocket-over-nodejs/signaler.js.
2. Next, we should run the JavaScript library using the Node.js server. We can do so by executing the following command in the terminal window:

   node signaler.js
   

3. Specify the address of the Node.js server machine in the WebRTC client.

   Now, we can make inter-browser WebRTC audio/video calls, where the signaling is handled by the Node.js WebSocket signaling server. The following diagram depicts how Node.js is used as a signaling server:

   

• SIPJS: This is an SIP stack in JavaScript to implement SIP-based audio and video user agents in the browser. You can find a running demo at http://theintencity.com/sip-js/phone.html?network_type=WebRTC. The demo application has the option to switch between WebRTC capabilities and Flash for browsers that support and do not support WebRTC.
• JSSIP: This is an SIP over WebSocket transport API for audio/video calls and instant messaging. It works with all SIPWS-compatible SIP servers such as OverSIP, Kamailio, and Asterisk servers. You can find a running demo at http://tryit.jssip.net/.
• sipML5: This is an open source JavaScript library with a provision for RTCWeb Breaker (audio and video transcoding when the endpoints do not support the same codecs or the remote server is not RTCWeb compliant). For example, features such as audio/video call, instant messaging, presence, call hold/resume, explicit call transfer, and Dual-tone multi-frequency (DTMF) signaling using SIP INFO are present. You can find a running example at http://sipml5.org/call.htm.
• QuoffeSIP: This is another WebRTC SIP library to establish real-time communication between browsers. This is developed in CoffeeScript (simple syntax). It features video/audio call capabilities using SIP over the Websockets protocol and also uses the SIP Outbound and GRUU protocols. You can find a running example athttp://talksetup.quobis.com/.

• SIP stack, in the form of a JavaScript library, to perform signaling
• Cascading Style Sheets (CSS) to style a page
• WebRTC media API to render a peer-to-peer connection between the audio-video components of a page
• An HTML5-based graphical interface to provide inputs such as registration parameters, self-URI (short for Uniform Resource Identifier), URI of the party to be called, and so on

• The WebRTC gateway to connect to the native SIP world
• The SIP server to embed the SIP application/proxy logic

The sipML5 client is a library of SIP and Session Description Protocol (SDP) stacks written in JavaScript, using WebSocket as the network transport mechanism. It supports TCP, UDP, and TLS transports. It is provided under the BSD license. There are three ways of using SipML5 WebRTC client:

Let's begin the exercise using only the primitive and necessary sipML5 functions to make a call successfully from a web page without the need of backbone components such as web.xml and the Java source. To simplify things, we will not look into the enhanced features such as Presence (Subscribe, Notify), DTMF, and speed dialing at this point. These topics will be covered in Chapter 6, Basic Features of WebRTC over SIP.

SIPML5 API version = 1.3.214 
User-Agent=Mozilla/5.0 (Windows NT 6.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 Safari/537.36 
WebSocket supported = yes 
SIP stack start: proxy='ns313841.ovh.net:12060', realm='<SIP:sip2sip.info>', impi='altanai', impu='<SIP:altanai@sip2sip.info>' 
Connecting to 'WS://ns313841.ovh.net:12060' 

__tsip_transport_WS_onopen 
State machine: c0000_Started_2_Outgoing_X_oINVITE PeerConnectionClass = function RTCPeerConnection() { [native code] } SessionDescriptionClass = function RTCSessionDescription() { [native code] } IceCandidateClass = function RTCIceCandidate() { [native code] } 

Video Constraints:{ /* video constrains added to WebRTC client appear here */}
ICE servers:[/* list of stun servers added to WebRTC client appear here */] 
onGetUserMediaSuccess 
createOffer

GET http://144.55.64.89:8080/WebRTCphone/images/.gif 404 (Not Found)

ICE GATHERING COMPLETED!
onIceGatheringCompleted 
SEND: INVITE SIP:testagent@sip2sip.info SIP/2.0
Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bKSM7tGLdSUy3DpGehaPa78HHpvmir89Uh;rport
From: <SIP:altanai@sip2sip.info>;tag=2CEhe0X78NxVm7aRCaBa
To: <SIP:testagent@sip2sip.info>
Contact: "undefined"<SIP:altanai@df7jal23ls0d.invalid;rtcweb-breaker=no;click2call=no;transport=WS>
Call-ID: 16a15a79-e4a6-78a1-2310-1243ebafe826
CSeq: 59935 INVITE
Content-Type: application/sdp
Content-Length: 3984
Max-Forwards: 70

v=0
o=- 6574822970880695000 2 IN IP4 127.0.0.1
s=Doubango Telecom - chrome
t=0 0
a=group:BUNDLE audio video
m=audio 15856 RTP/SAVPF 111 103 104 0 8 106 105 13 126
c=IN IP4 103.253.172.143
a=ice-options:google-ice
a=mid:audio
a=sendrecv
a=ice-options:google-ice
a=mid:video
a=sendrecv
a=rtcp-mux

The jsSIP client is a JavaScript library of the SIP stack and SDP, much similar to sipML5.It can also be used in the following three ways:

• Publicly hosted SIP server with WebRTC support as SIP2SIP
• SIP servers' executables hosted in our servers, such as the OfficeSIP server
• SIP servers built from source and hosted in our servers, such as Kamailio

To test the functionality of our customized WebRTC client, let's register it with the SIP2SIP server.

The steps to register the client with the SIP2SIP server are as follows:

OfficeSIP is the Window's version of an SIP server. It is free for academic and personal use. To use the OfficeSIP server to register the clients we made, we will first have to install and configure it by performing the following steps:

The task of connecting a WebRTC client to a native SIP client such as X-Lite, Twinkle, and SIP phone is dealt with in two ways:

Through a WebRTC to SIP gateway, use a gateway that does the SIPWS to SIP conversion so that the traditional SIP server in the SIP legacy network can understand the SIP request originating from WebRTC clients. To understand this better, we can consider any native SIP server such as the Brekeke SIP proxy registrar server or Bea WebLogic Sip Application server. These do not understand the WebSocket protocol in their default behavior.

The hosted server supports SIP over WebSocket. In this case, the WebRTC client does not need a gateway to pass its SIP messages, as the SIP server itself understands WebSocket with SIP protocol. There are some popular servers that understand WebSocket, such as Kamailio, Asterisk, and FreeSWITCH. It is, however, required that you customize the default behavior of these servers, and add the WebSocket module to the configuration file before usage. We shall cover both of these approaches in the sections that follow.

WebRTC2Sip is a gateway that uses RTCWeb Breaker and SIP. It allows calls from the SIP legacy network to operate with calls from the SIP-based WebRTC client. It primarily has the following three modules:

The following diagram shows the overall functioning of the WebRTC to SIP gateway:

The call flow of the SIPWS request from the WebRTC client, conversion to a simple SIP request, and the passage from the SIP legacy network to reach the SIP legacy endpoint via the WebRTC2sip gateway is shown in the following figure:

The steps for the installation of the WebRTC2sip gateway are described as follows:

Brekeke is also a popular SIP server that does not support WebSocket as yet. The following steps describe the process of configuring WebRTC to run through this SIP server with the help of the WebSocket gateway:

Kamailio is an open source SIP server that also supports SIP over WebSocket, among other features. It can be hosted only on Linux-based machines. Due to machine dependency of the gateway and scalability issues, I recommend that you use the Kamailio SIP server as an open source option to set up WebRTC to any SIPUA infrastructure. Let's try to get a basic configuration of Kamailio started.

Some prerequisites for the installation of the Kamailio SIP server should be installed on the machine before starting to build Kamailio from source. The following are the packages you need to install before installing Kamailio 4.1.1:

Now, perform the following steps to install the Kamailio SIP server:

Setting up the admin console for Kamailio is an optional task. However, it's recommended as it provides a graphical provisioning system to configure and alert the settings of the SIP server. The following screenshot shows the admin GUI SIREMIS, which gives a visual interface to server management rather than the command prompt to monitor user accounts and usage statistics:

We can also monitor the real-time traffic using the Wireshark protocol analyzer. The following screenshot depicts the flow graph generated from Wireshark, which captures on all interfaces using the SIP and the WebSocket filters. In the following screenshot, the flow graph traces the Kamailio SIP server:

The flow depicts a call session that begins with an invite request traversing across various network nodes. It's not important to trace the path of the signal for now; however, the sequence of signal flows is a crucial task in determining that the WebRTC client server model is performing well.

• Media should not be free flowing between peer to peer but passing through a media relay mechanism. A media relay mechanism involves a media server to be in the path of the media flow. This way, the media server receives the audio/video from one end and relays it to the other end. This leads to a better control on the communication by centralized network nodes.
  
• Ipv4 and Ipv6 must be supported.
• The Telecom Application server is needed to embed the logic of SIP services such as call waiting, call forwarding, and call screening.
  
• Database implementation must happen to keep track of calls, user authentication, user profile, and so on.
• The monitoring tools allow for real-time statistics that, in turn, help the service provider to make predictive judgments and review the status at real time. This also aids in charging and billing if the service provider opts to bill the customer.

1. Direct the control towards the CSCF nodes of IMS, namely, Proxy-CSCF, Interrogating-CSCF, and Serving-CSCF.
2. The subscriber details and the location are updated in the HSS.
3. Serving-CSCF (SCSCF) routes the call through the SIP Application Server to invoke any services before the call is processed. The Application Server, which is part of the IMS service layer, is the point of adding logic to call processing in the form of VAS.
4. Additionally, we will uncover the process of integrating media server for an inter-codec conversion between legacy SIP phones and WebRTC clients.

The three parts of CSCF are described as follows:

IMS core Home Subscriber System (HSS) is the database component responsible for maintaining user profiles, subscriptions, and location information. The data is used in functions such as authentication and authorization of users while using IM services.

The components of the WebRTC infrastructure primarily comprises of WebRTC Web Application Servers, WebRTC web-based clients, and the SIP gateway.

There are other servers that act as IMS nodes as well, such as the STUN/TURN Server, Media Server, and Application Server. They are described as follows:

• Make sure that you have the following packages installed on your Linux machine, as their absence can hinder the IMS installation process:
  • Git and Subversion
  • GCC3/4, Make, JDK1.5, Ant
  • MySQL as the database
  • Bison and Flex, the Linux utilities
  • libxml2 (Version 2.6 and above) and libmysql with development versions

  Install these packages from the Synaptic package manager or using the command prompt.

• For the LoST interface of E-CSCF, use the following command lines:

  sudo apt-get install mysql-server libmysqlclient15-dev libxml2 libxml2-dev bind9 ant flex bison curl libcurl4-gnutls-dev
  sudo apt-get install curl libcurl4-gnutls-dev
  

• The Domain Name Server (DNS), bind9, should be installed and run. To do this, we can run the following command line:

  sudo apt-get install bind9
  

• We need a web browser to review the status of the connection on the web console. To download a web browser, go to its download page. For example, Chrome can be downloaded from https://www.google.com/intl/en_in/chrome/browser/.
• We must verify that the Java version installed is above 1.5 so as to not break the compilation process in between, and set the path of JAVA_HOME as follows:

  export JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64/jre
  

  The output of the command line that checks the Java version is as follows:

1. Go to the /opt folder and create a directory to store the OpenIMS core, using the following command lines:

   mkdir /opt/OpenIMSCore
   cd /opt/OpenIMSCore
   

2. Create a directory to store FHOSS, check out the HSS, and compile the source using the following command lines:

   mkdir FHoSS
   svn checkout http://svn.berlios.de/svnroot/repos/openimscore/FHoSS/trunk FHoSS
   cd FHoSS
   ant compile deploy
   

   Note

   Note that the code requires Java Version 7 or lower to work.

3. Also, create a directory to store ser_ims, check out the CFCs, and then install ser_ims using the following command lines:

   mkdir ser_ims
   svn checkout http://svn.berlios.de/svnroot/repos/openimscore/ser_ims/trunk ser_ims
   cd ser_ims
   make install-libs all
   

   After downloading and installing the OpenIMS installation directory, its contents are as follows:

   

1. Run the following command line:

   ./opt/ser_ims/cfg/configurator.sh
   

2. Replace 127.0.0.1 (the default IP for the localhost) with the new IP address that is required to configure the IMS Core server.
3. Replace the home domain (open-ims.test) with the required domain name.
4. Change the database passwords.

   The following figure depicts the domain change process through configurator.sh:

   
5. To resolve the domain name, we need to add a new IMS domain to bind the configuration directory. Change to the system's bind folder (cd /etc/bind) and copy the open-ims.dnszone file there after replacing the domain name.

   sudo cp /opt/OpenIMSCore/ser_ims/cfg/open-ims.dnszone /etc/bind/
   

6. Open the name.conf file and include open-ims.dnszone in the list that already exists:

   include "/etc/bind/named.conf.options";
   include "/etc/bind/named.conf.local";
   include "/etc/bind/named.conf.default-zones";
   include "/etc/bind/open-ims.dnszone";
   

   Note

   One can also add a reverse zone file, which, contrary to the DNS zone file, converts an address to a name.

7. Restart the naming server using the following command:

   sudo bind9 restart
   

8. On occasion of any failure or error note, the system logs/reports can be generated using the following command line:

   tail -f /var/log/syslog
   

9. Open the MySQL client (sudo mysql) and add the SQL scripts for the creation of database and tables for HSS operations:

   mysql -u root -p -h localhost<ser_ims/cfg/icscf.sql
   mysql -u root -p -h localhost<FHoSS/scripts/hss_db.sql
   mysql -u root -p -h localhost<FHoSS/scripts/userdata.sql
   

   The following screenshot shows the tables for the HSS database:

   

   Note

   Users should be registered with a domain (that is, one needs to make changes in the userdata.sql file by replacing the default domain name with the required domain name). Note that while it is not mandatory to change the domain, it is a good practice to add a new domain that describes the enterprise or service provider's name.

   The following screenshot shows user domains changed from the default to the personal domain:

   
10. Copy the pcscf.cfg, pcscf.sh, icscf.cfg, icscf.xml, icscf.sh, scscf.cfg, scscf.xml, and scscf.sh files to the /opt/OpenIMSCore location.
11. Start the Policy Call Session Control Function (PCSCF) by executing the pcscf.sh script. The default element port assigned for P-CSCF is 4060.

    A screenshot of the running of PCSCF is as follows:

    
12. Start the Interrogating Call Session Control Function (I-CSCF) by executing the icscf.sh script.

    The default element port assigned to I-CSCF is 5060. If the scripts display a warning about connection, it is just because the FHoSS client still needs to be started. A screenshot of the running I-CSCF is as follows:

    
13. Start SCSCF by executing the scscf.sh script. The default element port assignment for S-CSCF is 6060.

    A screenshot of the running SCSCF is as follows:

    
14. Start the FOKUS Home Subscriber Server (FHoSS) by executing FHoss/deploy/startup.sh.

    The HSS interacts using the diameter protocol. The ports used for this protocol are 3868, 3869, and 3870.

    A screenshot of the running HSS is shown as follows:

    
15. Go to http://<yourip>:8080 and log in to the web console with hssAdmin as the username and hss as the password as shown in the following screenshot.
    
16. To register the WebRTC client with OpenIMS, we must use an IMS gateway that performs the function of converting the SIP over WebSocket format to SIP. In order to achieve this, use the IP port or domain of the PCSCF node while registering the client.

    The flow will be from the WebRTC client to the IMS gateway to the PCSCF of the IMS Core. The flow can also be from the SIPML5 WebRTC client to the webrtc2sip gateway to the PCSCF of the OpenIMS Core.

1. Download the SIP Application Server logic package from https://code.google.com/p/sipservlets/wiki/Downloads.
2. Unzip the contents. Make sure that the Java environment variables are in place.
3. Start the JBoss container from mobicents\jboss-5.1.0.GA\bin

   In case of MS Windows, click on run.bat, and for Linux, click on run.sh. The following figure displays the traces on the console when the server is started on JBoss:

   
4. The Mobicents application can also be developed by installing the Tomcat/Mobicents plugin in Eclipse IDE. The server can also be added for Mobicents instance, enabling quick deployment of applications.
5. Open the web console to review the settings. The following screenshot displays the process:
   

   Mobicents SLEE Management console home screen in a web browser

6. In order to deploy Resource Adaptors, enter:

   ant -f resources/<name of resource adapter>/build.xml deploy
   

7. To undeploy the resource adapters, execute ant undeploy with the name of the resource adapter:

   ant -f resources/<name of resource adapter>/build.xml undeploy
   

   Make sure that you have Apache Ant 1.7. The deployed instances should be visible in a web console as follows:

   

   Services deployed on Mobicents Telecom Application Server

8. To deploy and run SIP Servlet applications, use the following command line:

   ant -f examples/<name of application directory>/build.xml deploy-all
   

   

   Resources hosted on Mobicents Telecom Application Server

9. Configure CSCF to include the Application Server in the path of every incoming SIP request and response.

• Speed Dial: This application lets the user make a call using pre-programmed numbers that map to actual SIPURIs of users.
• Click to Dial: This application makes a call using a web-based GUI. However, it is very different from WebRTC, as it makes/receives the call through an external SIP phone.
• Find me Follow Me: This application is beneficial if the user is registered on multiple devices simultaneously, for example, SIP phone, X-Lite, and WebRTC. In such a case, when there is an incoming call, each of the user's devices rings for few seconds in order of their recent use so that the user can pick the call from the device that is nearest to him.

1. Download and store the source code for compilation in the /usr/src folder, and run the following command lines:

   cd usr/src
   git clone -b v1.4 https://stash.freeswitch.org/scm/fs/freeswitch.git
   

2. A directory named freeswitch is made using the following command line and binaries will be stored in this folder. Assign all permissions to it.

   sudo chown -R <username> /usr/local/freeswitch
   

   Replace <username> with the name of the user who has the ownership of the folder.

3. Go to the directory where the source will be stored, that is, the following directory:

   cd /usr/src/freeswitch
   

4. Then, run bootstrap using the following command line:

   ./bootstrap.sh
   

5. One can add additional modules by editing the configuration file using the vi editor. We can open our file using the following command line:

   vi modules.conf
   

   The names of the module are already listed. Remove the # symbol before the name to include the module at runtime, and add # to skip the module. Then, run the configure command:

   ./configure --enable-core-pgsql-support
   

6. Use the make command and install the components:

   make && make install
   

7. Go to the Sofia profile and uncomment the parameters defined for WebSocket binding. By doing so, the WebRTC clients can register with FreeSWITCH on port 443.

   Sofia is an SIP stack used by FreeSWITCH. By default, it supports only pure SIP requests. To get WebRTC clients, register with FreeSWITCH's SIP Server.

   <!-- uncomment for SIP over WebSocket support -->
   <!-- <param name="ws-binding" value=":443"/>
   

8. Install the sound files using the following command line:

   make all cd-sounds-install cd-moh-install
   

9. Go to the installation directory, and in the vars.xml file under freeswitch/conf/ make sure that the codec preferences are set as follows:

   <X-PRE-PROCESS cmd="set" data="global_codec_prefs=G722,PCMA,PCMU,GSM"/>
   <X-PRE-PROCESS cmd="set" data="outbound_codec_prefs=G722,PCMA,PCMU,GSM"/>
   

10. Make sure that the SIP profile is directly using the codec values as follows:

    <param name="inbound-codec-prefs" value="$${global_codec_prefs}"/>
    <param name="outbound-codec-prefs" value="$${global_codec_prefs}"/>
    

    We can later add more codecs such as vp8 for video calling/conferencing.

11. To start FreeSWITCH, go to the /freeswitch/bin installation directory and run FreeSWITCH.
12. Run the command-line console that will be used to control and monitor the passing SIP packets by going to the /freeswitch/bin installation directory and executing fs_cli.

    The following is the screenshot of the FreeSWITCH client console:

    
13. Go to the /freeswitch/conf/SIP_profile installation-directory and look for the existing configuration files.
14. Load and start the SIP profile using the following command line:

    sofia profile <name of profile> start load
    

15. Restart and reload the profile in case of changes using the following command line:

    sofia profile <name of profile>restart reload
    

16. Check its working by executing the following command line:

    Sofia status
    

17. We can check the status of the individual SIP profile by executing the following command line:

    sofia status profile <name of profile> reg
    

    

The following steps outline the process of using the FreeSWITCH media services:

We can use other services of FreeSWITCH as well, such as voicemail, IVR, and conferencing. We will cover them in later chapters of the book.

We can also configure this setup in such a way that media passes through the FreeSWITCH Media Server, and the SIP signaling is via the Telecom Kamailio SIP server.

Use the RTP proxy in the SIP proxy server, in our case, Kamailio, to pass the RTP media through the Media Server. The RTP proxy module of Kamailio should be built in a format and configured in the kamailio.cfg file. The RTP proxy forces the RTP to pass through a node as specified in the settings parameters. It makes the communication between SIP user agents behind NAT and will also be used to set up a relaying host for RTP streams. Configure the RTP Engine as the media proxy agent for RTP. It will be used to force the WebRTC media through it and not in the old peer-to-peer fashion in which WebRTC is designed to operate. Perform the following steps to configure the RTP Engine:

The following diagram shows the MediaProxy relay between WebRTC clients:

The potential of media server lies in its media transcoding of various codecs. Different phones / call clients / softwares that support SIP as the signaling protocol do not necessarily support the same media codecs. In the situation where Media Server is absent and the codecs do not match between a caller and receiver, the attempt to make a call is abruptly terminated when the media exchange needs to take place, that is, after invite, success, response, and acknowledgement are sent.

In the following figure, the setup to traverse media through the FreeSWITCH Media Server and signaling through the Kamailio SIP server is depicted:

The role of the rtpproxyng engine is to enable media to pass via Media Server; this is shown in the following diagram:

• Gateway GPRS Support Node (GGSN) manages the interworking between packets from the Radio Access Network (RAN) to the external IP world such as the Internet
• Serving GPRS Support Node (SGSN) is responsible for mobility, routing, authentication, and so on for the GPRS core

The WebRTC platform resides in the IP world of SIP and IMS. A mobile phone can connect to the IP world via data packets, that is, GPRS. The following figure gives an architectural representation of interconnecting a WebRTC IMS platform with a mobile phone through GGSN:

HSS in the IMS core network holds the profile of subscribers. CSCFs are the IMS entities responsible for call control. Overall, the preceding diagram gives a clear picture of GSN integrated with IMS to render GPRS packets to GSM mobile phones. It also mentions 3G, which uses Node B as the access node, and 4G, which uses Evolved Node B (eNodeB) as the access node.

The packet-switched domain provides the IP bearer with access to the IMS through the Packet Data Protocol (PDP) context. The phases of mobile access to the packet-switched network of IMS are as follows:

The following diagram shows the flow of the phases of mobile access to the packet-switched network of IMS:

The preceding figure depicts the sequence flow between a User Equipment (UE), which is a mobile phone in this case, and a WebRTC client via Serving GPRS Support Node (SGSN) and Gateway GPRS Support Node (GGSN). As outlined, the first step is GPRS Attach and PDP context activation. At this stage, the authentication at the bearer level is achieved. In the next stage, the mobile phone will connect itself to CSCF, which is the core of the IMS network. Once this is achieved, the mobile phone can make calls, which will traverse through the IMS network. The IMS entities such as Application Server and Media Server will also apply to such signals. The following screenshot shows the sipML5 WebRTC client web page opened in a mobile browser:

• SIP Servlets: These are Java extension APIs for SIP servers (SIP Servlet Request / Sip Servlet Response) and are similar to the HTTP Servlets (HTTP Servlet Request / HTTP Servlet Response)
• JAIN SIP: This is also a Java-based API for SIP signaling, however, it's more generic and low level
• SIP CGI: The Common Gateway Interface (CGI) for SIP is very similar to the HTTP CGI
• CPL: This is the Common Programming Language, which is an XML-based script for call control logic and needs to be validated and parsed by a CPL interpreter

• Oracle's Service Broker
• Open cloud's Service Broker

1. Download the source code from http://www.kannel.org/download.shtml
2. Configure the downloaded content using the following command line:

   ./configure

   The following screenshot shows the Kannel Configure running:

   
3. Build the Kannel executables using the following command lines:

   make
   make bindir=/directory path for installation

   
4. Define an SMS box group into the configuration file.

   group = sms-service
   keyword = complex
   get-url = "http://host/service?sender=%p&text=%r"
   accept-x-kannel-headers = true
   max-messages = 3
   concatenation = true
   Start kannel

5. It requires a physical GSM handset to achieve this. We must connect the phone to the machine that runs the Kannel gateway and modify the config file for the phone specification. The phone must bear a valid SIM. Also, the amount per message is deducted from the balance of the SIM holders' account.
6. Send the content from the WebRTC application in the HTTP format and pass it on to the Kannel gateway. The content will be delivered to the phone in the form of an SMS. For example, consider the following content:

   http://smsbox.host.name:13013/cgi-bin/sendsms?
   username=foo&password=bar&to=0123456&text=Hello+world
   

   

• The OpenSIPS SMS module also supports sending and receiving SMS directly from a GSM network.
• The Kamailio SMS module performs SIP message to GSMS and SMS delivery too. It requires a GSMS telephone to act as the modem. The format of the SIP address header should be as follows:

   sip:<number>@domain, for example sip:988768238@tcs.com.
  

• One can also opt for an enhanced SMSC gateway such as Mobicents SMSC built over Mobicents SS7 and Mobicents JSLEE. They support Short Message Peer-to–Peer Protocol (SMPP), SIP IM, and legacy SS7 MAP interfaces as well.

• Signaling Gateway (SGW)
• Media Gateway (MGW)
• Media Gateway Controller (MGC)

• IMS signaling to PSTN signaling: For signaling, CS networks use ISDN User Part (ISUP) (or BICC) over Message Transfer Part (MTP), while IMS uses SIP over IP.

  A Signaling Gateway (SGW) interfaces with the signaling plane of the CS. It transforms lower layer protocols such as Stream Control Transmission Protocol which is a transport layer protocol over IP, into Message Transfer Part which is a Signaling System 7 protocol. This is done in order to pass ISDN User Part (ISUP) from the MGCF to the CS network.

• IMS Media to PSTN Media: For media, CS networks use Pulse-code modulation (PCM), while IMS uses Real-time Transport Protocol (RTP). The codecs required for this are G.711 and G.729, which can be configured with Media Server.

  A Media Gateway (MGW) interfaces with the media plane of the CS network, by converting between RTP and PCM. It can also transcode when the codecs don't match (e.g., IMS might use AMR, PSTN might use G.711).

The SIP signals that originate from the WebRTC clients are proxied through the IMS nodes. After the service logic is executed by the Application Server, the signal arrives at the PSTN gateway, which is the entry point to the PSTN world. The interconversion form IP standard protocols and codecs to PSTN accepted values take place here. The modified version is sent across the PSTN network to the addressed telephone device. The flow among nodes is demonstrated in the following sequence:

WebRTC browser | WebRTC to SIP gateway | MGC / PSTN Gateway | ISUP Switch | Fixed Landline phone

The following diagram shows the call flow between the WebRTC and PSTN endpoints:

We have seen the role of the WebRTC-to-SIP gateway in Chapter 2, Making a Standalone WebRTC Communication Client. In brief, it converts the SIP-over-WebSocket signals to legacy plain SIP signals that IMS nodes can understand.

The MGC node handles all call signaling (SIP and ISUP), while MG handles media under the control of MGC. For ease of understanding, they are depicted together. They can be considered as the components of the PSTN gateway. The ISUP switch further converts the ISUP signals from MGC into the analog format expected by the PSTN endpoint. The ISUP switch is responsible for converting the incoming as well as the outgoing call format from the analog to the digital ISUP format as understood by the back network.

A step-by-step description of the call flow is given as follows:

This way, a call that originates from the PSTN endpoint can reach a WebRTC client, and both the parties can communicate.

This section describes the mapping of the SIP headers in an INVITE message to the ISUP parameters in an IAM. An IAM ISUP message bears these five essential parameters:

A major task involved in the translation of the fields of an INVITE message to the parameters of an IAM is the inspection of the Request-URI and the construction of the telephony URL. When an SIP INVITE arrives at a PSTN gateway, the gateway should attempt to make use of the encapsulated ISUP, if any, within INVITE to assist in the formulation of outbound PSTN signaling.

If suitable ISUP headers encapsulated within the SIP request body are not found or the gateway ID is not able to decipher them anyway, then MGC formulates one on its own.

The MGC gateway sets the Interworking Indicator bit of the FCI to "No Interworking" and the ISDN User Part Indicator to "ISUP used all the way"; the gateway might also set the Originating Access Indicator to "Originating access non-ISDN".

In case of no response, abrupt termination, or purposeful call termination, the SIP network is sent an appropriate response, and all the resources in MG are released.

For example, when no answer is received by the PSTN terminal or the ISUP timeout SIP Response is 504 gateway timeout, the Release and Release complete messages are used by the ISDN to make the network ready for fresh reuse.

The REL message contains a cause value. The SIP response is sent based on this cause value. If a cause value other than what is listed in the following table is received, the default response of "500 Server internal error" will be used.

In the instances of Normal event, the following cause values might be generated; the column alongside depicts the SIP response message they would be translated into:

The resource unavailable kind of cause value indicates a nonpermanent situation. A Retry-After header has to be added to the response.

The instances where the service or option not available status is generated, indicating a permanent solution, are discussed here. It is not appended by a Retry-After header, as in the previous case.

The service or option not available option indicates a permanent solution:

The instances where service or option not implemented status is generated are discussed here. For enhanced SIP services such as SUBSCRIBE, NOTIFY, PUBLISH, and MESSAGE, there is no equivalent service on the PSTN front. Such requests are generally replied to with a "Not Implemented" cause value. The same is translated into the SIP response message and shared with the WebRTC client.

For the cases where ISU receives an invalid message, the response and cause values are given as follows. These are also translated into the SIP response, 503 Service unavailable.

In the event of protocol error and timer expiry, the ISUP response and equivalent SIP response generated are shown as follows.

For instances where the interworking rules are not specified clearly, the cause of the generated ISUP error is "Interworking, unspecified". It is translated to "Server internal error" in the SIP message format.

This section describes the response generated for the occasions where the call is successfully routed across the network nodes from IMS to PSTN. Once the call signal reaches the PSTN phone, it might send a busy tone if it is engaged in another call or start ringing if it is free. In some cases, the telephones are configured just to record the voicemail; in such cases, the status sent back to the SIP world is "Call is being forwarded". Thus, in case of Call in Progress (CPG) message format, the following are the responses sent back to the SIP network:

When a Conference (CON) call is encountered, 200 OK success responses are sent back to the SIP network. After the receipt of acknowledgement, the media session is established between both the end points.

• Registration
• Audio/video call
• Instant message
• Presence

A SIP client, such as a SIP phone, SIP soft client, and SIP WebRTC web page, ought to register itself with the Registrar. The Registrar informs the VoIP systems about how you can be reached for an incoming event such as a call, instant message, and Presence update.

A Registrar notes down the physical address of each of the clients through the SIP REGISTER request and confirms their registration with a 200 OK response. The values obtained are copied to the HSS/Location Server as well.

The ideal scenario for the SIP Registration call flow without any authentication challenge is shown in the following diagram:

However, with the introduction of secure registration with authentication, the server throws an authentication challenge in the form of a 407 Proxy Authentication Required response. It is for the request initiator to provide the assurance of its identity. For this purpose, a nonce (such as HTTP Digest) is computed and carried out in order to validate its identity. The following diagram shows the SIP Registration call flow with the authentication challenge:

During the processing of a call, the Location Server is queried to find out which Serving Call Session Control Function (SCSCF) should be used in order to forward the request. We discussed the role of CSCF nodes in Chapter 3, WebRTC with SIP and IMS.

The SIP Traces for the Registration request by WebRTC is as follows:

SEND: REGISTER sip:domain.com SIP/2.0
Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bKkKS7wNb4eUtrGC4eqAcsLkFtwdmmcUhr;report
From: "userA"<sip:userA@domain.com>;tag=QprEnFLGbLoZ1JzOAZro
To: "userA"<sip:userA@domain.com>
Contact: "userA"<sip:userA@df7jal23ls0d.invalid;rtcweb-breaker=yes;transport=ws>;expires=200;click2call=no;+g.oma.sip-im;+audio;language="en,fr"
Call-ID: 45771a0b-a074-a703-137e-95732a99422c
CSeq: 40303 REGISTER
Content-Length: 0
Max-Forwards: 70
Authorization: Digest username="userA",realm="domain.com",nonce="U3mcb1N5m0PhCzqVWIgBxQPNuPAzfYMy",uri="sip:domain.com",response="cabd8882851165fbd23f2de7410ee4c1",algorithm=MD5
User-Agent: IM-client/OMA1.0 sipML5-v1.2013.08.10B
Organization: 
Supported: path

The first line tells us that this is a REGISTER message. It also specifies the Request-URI, which, in this case, is the domain for which the registration is meant .This line also identifies the version of the protocol, which is SIP/2.0. The To and From headers denote the address of the record; in case of REGISTER, these two are same unless it is a third-party registration. The Call-ID header field is mainly for dialog identification. For registration, a SIP or WebRTC client will use the same Call-ID value to register with a particular registrar. The Contact header holds the address bindings. The expires header indicates how long the registration should be valid, with the value given in seconds. Other headers are not mandatory.

The authentication challenge with the 407 Proxy Authentication Required response is thrown by the server. This is depicted in the following SIP RESPONSE trace:

recv=SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/WS df7jal23ls0d.invalid;report=52131;received=122.160.87.159;branch=z9hG4bKgpH8F0UP8eOnWOKKQ9TZIKEgKnSy7FnN
From: "userA"<sip:userA@domain.com>;tag=nBAgXU4kKmnC7Xx2JEpr
To: <sip:userB@domain.com>;tag=38aee63c0935fb6b672c4ad12db0cc71.0f98
Call-ID: ac8d4e18-3c8b-5a3f-45c9-f236112e8d69
CSeq: 60293 INVITE
Content-Length: 0
Proxy-Authenticate: Digest realm="domain.com",nonce="U3ml01N5pKcIQXLqXHRThzGzj+erPWIK",stale=FALSE
Server: kamailio (4.1.1 (x86_64/linux))

SEND: ACK sip:userB@domain.com SIP/2.0
Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bKgpH8F0UP8eOnWOKKQ9TZIKEgKnSy7FnN;rport
From: "userA"<sip:userA@domain.com>;tag=nBAgXU4kKmnC7Xx2JEpr
To: <sip:userB@domain.com>;tag=38aee63c0935fb6b672c4ad12db0cc71.0f98
Call-ID: ac8d4e18-3c8b-5a3f-45c9-f236112e8d69
CSeq: 60293 ACK
Content-Length: 0
Max-Forwards: 70

This is primarily the most crucial and important part of any communication client. We have already made sure of this feature in Chapter 2, Making a Standalone WebRTC Communication Client. To refresh the concept of a call on SIP clients, we can recall the SIP requests that are sent out when a party wants to invite the other side for a communication session.

The overall working principle for a SIP call based on requests revolves around the following four requests:

A 200 OK SIP response to the Invite SIP request is followed by the transmission of the Ack SIP request. The Ack SIP request is used to transport the Session Description Protocol (SDP) for media negotiation. This leads to successful call establishment between the caller and receiver parties. A call request that does not receive a success response of 200 OK is gracefully ended with a Cancel SIP request. An ongoing call is ended with a Bye SIP request.

SIP employs the Request-Response Model in a fashion similar to HTTP. The transactions are used to keep an account of the internal state and keep timers for every request/response. A dialog is a complete set of signaling protocols exchanged between both parties, and every subset of requests and final responses inside this is considered as a single transaction. This implies that a dialog can consists of many transactions.

To brush up our understanding of the SIP communication sessions, let's go through the difference between SIP Transaction and SIP Dialog.

The following diagram gives a description of the SIP Dialog and SIP Transaction:

The call setup process, shown as follows, depicts a call between two WebRTC clients through a WebSocket-capable SIP Server. These kinds of calls can operate solely on SIP over WebSockets (SIP-WS) protocol and do not require a SIP-WS to SIP gateway. The following diagram shows a call between WebRTC clients using the SIP-over-WebSockets server:

For interoperability of WebRTC clients with SIP agents such as hard phones, other desktop SIP phones, and mobile SIP phones, we require the WebRTC to SIP gateway (SIP-WS to SIP convertor). A call flow depicting such cases is shown as follows; here, the call is between the SIP agent and the WebRTC client using the SIP Server with a SIP-over-WebSockets support/gateway:

As visible from the preceding two diagrams, to call a WebRTC-only client, a SIP-over-WebSocket server is sufficient. However, to be able to call any true SIP agent such as hard SIP phone or a desktop-based soft SIP phone (Kapanga, X-Lite, Twinkle, and so on), we need to have the SIP flow passed through a SIP Server, which is capable of performing the inter-transformation from the WebSocket request to a true SIP.

Assuming that we have such a server deployed, as discussed in Chapter 2, Making a Standalone WebRTC Communication Client, we will focus on other services such as Presence, message, and information for WebRTC clients.

Before establishing a call, the browser's WebRTC stack requests permission to access the webcam and microphone to enable an audio/video call. The following screenshot shows a browser requesting permission to allow the usage of the camera and microphone for WebRTC calls:

The browser's WebRTC stack might also set the ICE parameters with the STUN and TURN servers for network discovery, as shown in the following trace:

State machine: c0000_Started_2_Outgoing_X_oINVITE SIPml-api.js:1
PeerConnectionClass = function RTCPeerConnection() { [native code] } SessionDescriptionClass = function RDOMAINessionDescription() { [native code] } IceCandidateClass = function RTCIceCandidate() { [native code] } SIPml-api.js:1
Video Constraints:{"mandatory":{},"optional":[]} SIPml-api.js:1
ICE servers:[{"url":"stun:stun.l.google.com:19302"},{"url":"stun:stun.counterpath.net:3478"},{"url":"stun:numb.viagenie.ca:3478"}] SIPml-api.js:1
==stack event = m_permission_requested
ICE GATHERING COMPLETED! SIPml-api.js:1
onIceGatheringCompleted SIPml-api.js:1

Let's look at the SIP traces for a single side in a call between WebRTC clients in a sequential order:

Similarly, a call between a WebRTC client and SIP phone is established via the WebRTC-to-SIP gateway. Interoperability with various native mobile and desktop-based SIP phones is described in Chapter 9, Native SIP Application and Interaction with WebRTC Clients.

The MESSAGE SIP request is the way through which messages are delivered to the SIP Server. The frontend of the WebRTC client issues a MESSAGE SIP request from the sender to the receiver who carries the message body, which is sent through the SIP signaling server infrastructure. The text of the instant message is transported in the body of the SIP request. A call-flow diagram depicting the traversal of SIP MESSAGE requests and subsequent responses is shown as follows:

The SIP traces for instant messages in the form of text chats are shown through the SIP request and response messages. The sent and received messages between two parties using WebRTC clients are shown in a sequential order as follows:

The MESSAGE requests do not establish a dialog and will always traverse the same set of proxies. There are not one but many ways to implement text. We discussed the SIP message in this section. It can also be implemented via the Message Session Relay Protocol (MSRP). We will discuss this in greater detail in Chapter 8, WebRTC and Rich Communication Services.

The availability of users is determined by a SIP process called Presence. Depending on their registration validation and reachability, a SIP or WebRTC client might send online or offline status notifications. This is used to notify others that the particular user is unavailable to take messages or calls right now.

The PUBLISH SIP request publishes the status of a user to the SIP Server, which might either be online or offline. Let's assume that user X has published their status to the Server. The SIP Server also receives the SUBSCRIBE SIP request, which indicates that the other users would like to know about the status update of this particular user (user X). The Server then sends out the NOTIFY SIP request to update the subscribed users about the current status of user X. This process is replicated and repeated for all users. A person might like to subscribe for status updates of all their contacts in the phonebook so that they can view their online or offline status with a green or red indicator alongside their address entries in their phonebook.

The call flow depicted in the following diagram is derived from SIP Extension for Event State Publication of RFC 3903. The following diagram shows the call flow for the Presence service, using the PUBLISH, SUBSCRIBE, and NOTIFY requests:

The working principle for the Presence service is described in this section. The participating entities in this scenario are described as in the following figure:

The Presence Agent publishes its current state to the Presence Server via the Watcher, which continuously monitors the state change for users. The other user agent listens for notifications from the Presence Server .The three major SIP requests for the Presence service are given as follows:

The SUBSCRIBE message establishes a dialog and is immediately replied by the server using the 200 OK response. At this point, the dialog is established. The server sends a NOTIFY request to the user every time the event to which the user is subscribed to changes. The NOTIFY messages are sent within the dialog established by the SUBSCRIBE message.

Presence is a user's reachability and willingness to communicate its current status information. Once subscribed, the user receives notifications for every state change of the agent. This is a way to have sustained stateful communication.

The trace for WebRTC SIP Presence requests and responses are given as follows in a sequential order:

The SIP service discussed so far has covered audio/video call, registration, Presence, and instant message services. We have seen the sequence of SIP request and response messages in the preceding call-flow diagram and also analyzed the traces. These SIP services are very basic in nature and provide simple communication scenarios between two SIP or WebRTC endpoints. We are now ready to focus on more detailed services within the developer-defined call-control logic described in the next section.

Let's assume that there are two users, user A and user B. A typical call screening application will block the SIP URI of user A, while they are trying to contact user B, based on preset values. In real time, when user A calls user B, the SIP request reaches the core network logic and then matches the SIP URI of user A with the blocked SIP URI list. If a match is found, the call is cancelled; otherwise, the call is continued as normal to user B. The following diagram shows the SIP call flow for a call-screening application:

The preceding diagram denotes the case when a caller 's SIP URI is found matching the entries in the screened user's list of receivers. In such a case, the caller is responded to with an error message.

The requirement for a more accurate call-control logic in screening applications is a primary concern for telecom service providers due to the following reasons:

• Unconditional
• On unavailable (busy/no answer)

In this scenario, all the incoming calls are transferred to a third party on an unconditional basis. The following diagram shows the SIP call flow for unconditional call forwarding:

The enhanced logic can also be specified in the application that will be deployed on the application server. A user might switch on the call-forwarding service for a period of time or for specific people. These values are fed into the system using a provisioning system, which can be IVR based or web based.

For instances where the call is to be forwarded on specific error responses such as 486 Busy Here and 487 Request Timeout (that is, the call is not answered), the SIP Server connects the call to a second party. The logic for this application, along with identities of the primary and secondary party who want to use the call-forwarding service, must be deployed on the application server.

The following diagram shows the SIP call flow for call forwarding in case of user unavailability:

In this scenario, the user, who we assume is the transfer originator, puts the called party on hold and establishes a call with the transfer target to alert them to the impending transfer. The user then places the target on hold and then proceeds with the transfer using an escaped Replace header field instead of the Refer-To header.

The following figure depicts the attended call transfer from user B to user A:

In this scenario, the first handshake between A and B creates a new RTP session and then puts it in a hold state. The second handshake between B and C creates a new RTP session and puts it in a hold state too. Then, user B passes the credentials of C to A using the REFER message, and A establishes a new RTP session with C. Thereafter, C closes the session with B, and A notifies B about the new session with C. Then, B closes the session with A.

Now, user A and user C are in a session successfully. Despite the BYE message sent by user C, the dialog still exists until the subscription created by the REFER message has terminated.

In case of an unattended call-transfer scenario, the user provides the contact URI of the target (the SIPURI or PSTN number) to the receiver. The receiver attempts to establish a session using that contact and reports the results of this attempt.

The following diagram depicts a call flow for call transfer in an unattended manner:

This scenario bears a substantial difference from the attended call transfer where parties were preinformed about the call transfer. However, this is not the case here. In this case, the call transfer takes place without putting any party on hold. Just like in the previous case, here too, user A calls user B initially. Thereafter, B refers C to A, and users B and A disconnect. Now, A is connected to C, which also replaces the session. In this example, the Replaces header field is inserted into the Refer-To URI to achieve unattended call transfer from B to C.

• Basic proxying mode: In this mode, it does not alter the media stream transmission
• Functional mode: In this mode, the media parameters are altered to get the best configuration

The working principle of multiparty audio/video call conferencing is based on the playback ability of the Media Server. The following diagram depicts conferencing between multiple parties:

For a dedicated conferencing app, services such as group chat, file sharing, private chat, and desktop sharing are of prime importance. WebRTC and Media Server alone cannot provide all the capabilities required to build a team conference application. The various ways of implementing a WebRTC-based conference will be discussed in Chapter 10, Other WebRTC Use Cases

• IP Geolocation: Using this, each IP block corresponds roughly to a geographical area, which often results in false positives.
• GPS: Using GPS satellites, maximum accuracy of user location is obtained.
• Wi-Fi Positioning: Using Wi-Fi networks and routers, especially in urban areas (using Skyhook Wireless), user location is obtained.
• Cell Tower Triangulation: This is based on the cellular signals that the user gets from towers. This is mostly useful for mobile devices that have built-in cellular radios.

• Latitude: 28.459497
• Longitude: 77.02663799999999
• Accuracy: 25000
• Altitude: Null
• Altitude accuracy: Null
• Heading: Null
• Speed: Null

• Google
• Facebook
• Twitter
• LinkedIn

• The web application itself recognizes that there is a 100 trying or 180 ringing SIP response and displays the advertisement using the video src element of HTML5. Consider the following code:

  <video width="500" height="450" controls>
    <source src="advertismentawalmart.mp4" type="video/mp4">
  </video>

• The SIP Server recognizes a 100 trying or 180 ringing SIP response and connects the call to the Media Server, which plays the advertisement over RTP.

• Presentation Tier: This tier deals with the GUI through which the client interacts with the application. It is usually a set of HTML elements with other frontend technologies such as JavaScript for scripting logic and CSS for design format. It will be loaded into the browser as a web page, for example, login.html, home.html, and so on.
• Logic Tier: The middle tier, also known as the Application Tier, is responsible for processing logic, obtaining values from the Data Tier, and delivering the results to the web engine.
• Data Tier: The database and repositories that hold data values and files are referred to as the Data Tier.

• UserDetails: This class contains the main field for user identification and registration, such as SIP URI, private identity, domain, display name, and password. These values are required to register a user with the SIP Registrar so that he can make use of SIP services such as call, message subscribe, and notify.
• CallLogs: This class is meant to record the information of every incoming, outgoing, missed, or failed call for every user in his history of transactions. The information includes caller and called SIP URI, date/time stamp, and call ID.
• MessageLogs: This class holds the records for all messages sent and received by the user. Similar to call logs, this class also contains member variables such as the sender and receiver SIP URI, date/time stamp, and message ID.
• OtherAccount: Since the WebRTC client also interacts with third-party social networking platforms and services, this table takes care of mapping between SIP URI and other account IDs. For now, it includes fields for Google, Facebook, Yahoo, and Twitter.
• Geolocation: The Geolocation coordinates of a user obtained through their browser's Geolocation API, Mobile phone's GPS, or by any other means is stored in this table. The values are mapped to a user's unique SIP URI for later referencing. The fields include SIP URI, latitude, longitude, date/time stamp, and so on. In this project, any user's new Geolocation values are overwritten over the existing ones.
• Conferencing: Since WebRTC supports a multiparty conferencing feature, this table is made to keep record of all conferences. The values include conference name, conference ID, host URI, members URI, and sequence. The host URI denotes the SIP URI of the user who is the host of the conference, and the members URI contain a list of SIP URIs of users who are guests for a conference.
• Notification: Any kind of notifications such as missed calls or conference call invitations are stored in this table along with date/time stamp.
• Voicemail: Voicemails are audio message files that are sent when a user is unavailable to receive messages or calls. This table contains links to voicemails and their associated sender's SIP URI with date/time stamp.
• OfflineMessages: Some messages are not delivered through the SIP Instant Message service on account of the user getting disconnected or being unavailable. Such messages can be directly sent to the user's mailbox using the SMTP gateway. The record of such messages or mails is kept in this table.
• Phonebook: The quick contacts or friends of users are stored in this table for easy reference. The SIP URI is used to link some values of the user details table to appear here.
• Presence: Online or offline status update of the user is stored in this table. The value is used to inform others about the availability or unavailability of this user.

• JSP- / Servlet-based WebRTC web project: These are small-scale applications usually employed for Proof of Concept (POC) building.
• Struts- / Hibernate-based WebRTC web project: This framework is used for more scalable and organized applications. Hibernate employs data abstraction.
• Spring 3 MVC-based WebRTC web project: This framework is the most preferred one for the development of rich and enterprise-grade WebRTC client application projects.

• Quick development: This does not require thorough design and is ideal for small applications with light processing
• Easy to deploy and debug: The modules are divided into only three source folders: DAO, Model, and Controllers

The JSP- / Servlet-based application architecture has quick buildup time and doesn't require detailed design structure. However, it must be noted that it leads to complexity and becomes hard to alter once the size and number of modules begin to increase beyond a point. The components of a JSP Servlet web project are as follows:

The overall architecture of WebRTC web project POC, based on JSP- / Servlet-based design, is depicted in the following diagram:

There are only a handful project components for JSP- / Servlet-based web project development. All of them are defined with their individual roles with no or minimal dependency on the other modules. We shall cover three prominent modules in this section:

The Call module is an HTML/JSP page-driven mechanism that does not depend on Java programming. It has been provided in Chapter 2, Making a Standalone WebRTC Communication Client. The flow between the View and Controller classes from the process of logging in to the process of displaying the home page with user-specific data is depicted in the following diagram:

Initially, the user lands on the Login.jsp page where he is required to either register for a new account or login with his credentials. A new user must create an account so that the database is populated with his SIP entities, such as domain, display name, and private identity, and any consecutive login with the SIP URI can fetch his existing details. Once the account is created and the user has entered his credentials to login, the Login Controller Servlet consults the database to ascertain whether the entered username and password were correct or not. If they were incorrect, the user reaches the login page again. If the user has entered the correct username and password, then he is redirected to the Call.jsp page where he can make or receive calls.

The steps to build a JSP- / Servlet-based WebRTC application are as follows:

The User Account module

The User Account module holds the SIP entities, such as SIP private identity, public identity domain, password, and display name, that the user is registered with initially. Later, the user uses these values to login and make calls to other WebRTC users.

The logic for the login and registration processes must be programmed to enable new user registration after he has filled the registration form. The users who already have an account should be able to login with their username and password. The following code snippet is the Servlet implementation class named loginServlet:

public class loginServlet extends HttpServlet {
  public loginServlet() {
    super();
  }

  protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
  PrintWriter out = response.getWriter();
  switch (request.getParameter("processtag")){

    case("login"):
      String privateIdentity=null,sipuri=null;
      String userName = request.getParameter("userName");
      String password = request.getParameter("password");
      webrtclogin wl = new webrtclogin();
      ArrayList<registration>result=
            wl.login(userName,password,realm);

      if(result.size()!=0){
        response.sendRedirect("loginsession?name="+result.get(0).getDisplayName()+"&pvt="+result.get(0).getPrivateIdentity()+"&pub="+result.get(0).getSipuri()+"&pass="+result.get(0).getPassword()+"&realm="+result.get(0).getRealm()+"&serverip="+serverip);
      }
      else{
        response.sendRedirect("login.jsp");
      }
      break;

    case("registration"):
      registration reg= new registration();
      reg.setDisplayName(request.getParameter("displayName"));
      reg.setsipuri(request.getParameter("sipuri"));
      reg.setPrivateIdentity(request.getParameter("privateIdentity"));
      reg.setPassword(request.getParameter("password"));
      reg.setWSUri(request.getParameter("wsuri"));
      reg.setRealm(request.getParameter("realm"));
      LoginDao dao=new LoginDao();
      if(dao.register(reg)==true) {
        response.sendRedirect("http://"+serverip+":8080/WebRTC_presentation/addmoredetails.jsp?privateIdentity="+privateIdentity+"&displayName="+displayName);
      }
      else{
        response.sendRedirect("http://"+serverip+":8080/WebRTC_presentation/addmoredetails.jsp");
      }
    break;

    default:
      response.sendRedirect("login.jsp");
    break;
    }
  }
}

The following screenshot is the GUI representation of the Registration/Login page:

In the preceding screenshot, the top section has a registration form with input boxes for Display Name, Authorization SIPURI, Private Identity, Password, and Domain. The lower section has a login form that is only for registered users to login to WebRTC client using their Authorization SIPURI and Password.

The Communication module

In a WebRTC client application program, the majority of the media-related tasks are handled by the browser's WebRTC media stack and signaling through SIP stack (in our case sipML5 JavaScript library). Our responsibility is to record the logs and render the AJAX calls to SIP invite methods. It's also concerned with the display of an appropriate status message if a call is not connected. When a call is successfully established between two parties, the video window with the local and remote party's captured video as well as the captured audio must be presented on the frontend JSP page.

The following screenshot is the GUI representation of the Call and Message page:

In the preceding screenshot, the upper section is for messaging functions. It is made up of three elements: a textbox for the SIP URI of the other party in message conversion, a textbox for current messages being sent from our side, and a text area to display the most recent messages sent and received between the two parties.

The lower section is for making and receiving calls. When a user is trying to make a call or receive a call, a drop-down window appears in this section that has the local and remote party's media elements such as audio and video. Furthermore, the call can be either of two types for which two buttons are present: Audio Call (for audio) and Video Call (for video).

The Phonebook module

The Phonebook module can be used to add the SIP URI of other users for quick reference. Also, the present status of the users is indicated with a green (user online) or red (user unavailable) symbol adjacent to their SIP URI.

The following code snippet is the Servlet implementation of the FriendListController class for the Phonebook module:

public class FriendListController extends HttpServlet {
  private static final long serialVersionUID = 1L;
  public FriendListController() {
    super();
  }
  protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    String action=request.getParameter("action");
    HttpSession session=request.getSession();
    String username=(String) session.getAttribute("name");
    
    if(action.equalsIgnoreCase("removefriend")){
      String friendUri=request.getParameter("friendName");
      FriendListDAO.removeFriendFromList(friendUri,user);
      response.sendRedirect("phonebook.jsp");
    }
    
    else if (action.equalsIgnoreCase("addFriendURI")){
      String sipURI=request.getParameter("friendName");
      FriendListDAO.addFriendToList(user,sipURI,str);
      response.sendRedirect("phonebook.jsp");
    }
  }

The following screenshot is the GUI representation of the Phonebook page:

The preceding screenshot depicts a Phonebook page that holds the contacts that the user has added to keep for future reference. There are three important elements in a phonebook interface, as follows:

• The SIP URI of the users that are added to the phonebook
• A textbox to add a new SIP URI to the phonebook
• The offline/online status of each user depicted by a red/green symbol alongside their SIP URI

The primary JAR files used are servlet-api.jar for Servlet and mysql-connector-java-5.0.8-bin.jar for MySQL connectivity. The scalability of this POC on WebRTC client depends on factors such as server CPU, server memory, bandwidth, and so on.

The following screenshot shows the Project Explorer window after the project completion of the WebRTC client POC:

The project can be run with any web server such as Tomcat, JBoss, and others. Some substantial limitations of using only JSP/Servlet pattern for a WebRTC project are:

• The properties file and the file IO systems are slow and outdated. However, in order to avoid slow disk access, properties can be defined using the environment variables.
• JavaScript-based validation can be easily overruled. They are easily subject to SQL Injection.
• Multithreading issues are not handled in the existing JSP/Servlet project. It might lead to memory leaks before the lifetime of the connection objects ends. Also, the buffer might overflow with garbage values.

Struts uses the Model 2 architecture. The Struts Action Servlet controls the navigation flow. Struts classes, such as Action, are used to access the business logic classes named Service. When the Action Servlet receives a request from the container, it uses the request URI or path to determine what action will be used to handle the request. The Action Servlet can verify the input, retrieve information from a database, or perform data processing in the business layer. For more information, refer to https://struts.apache.org.

The overall architecture of the WebRTC application with the Struts framework is shown in the following diagram:

The server machine depicted in the preceding diagram is Red Hat Enterprise Linux 6 (RHEL 6); however, any upgraded machine can be used in place of this. The components of Business Logic Layer, Presentation Layer, and Data Access Layer are differentiated. Add-on features such as SMTP for e-mail, log4j for logging, and sipML5 for SIP signaling are also depicted. The database (MySQL server), SIP signaling server (Kamailio), and WebSocket conferencing servers (Node.js) are shown in the lower part of the diagram.

Since modules for Login, Account, and Call Control have already been discussed in the previous section, JSP- / Servlet-based WebRTC web project, we shall cover the OtherAccount module in this part. The OtherAccount module, as the name suggests, links other/third-party accounts such as the Google account, the Facebook account, and the Yahoo account of users with his WebRTC SIP account. This will be used for extended functionality of the WebRTC application such as login using the third party, OAuth, sending e-mail from WebRTC account to offline users, importing contacts from other accounts, and so on.

The steps to build a Struts2-based WebRTC application, are listed as follows:

These steps summarize the building process of a generic Struts framework-based web application with Hibernate support. The detailed process of making and deploying a module on this framework with database mapping using Hibernate is provided in the upcoming section.

The Spring 3 framework has considerable advancements from the previous version, Spring 2. Spring 3 is ideal for an enterprise-level application, capable of delivering efficient performance and secure control to data and application logic. Logical entities in the Spring framework are provided here with a short description:

It is important to highlight the importance of the Spring dispatcher Servlet around which the whole project is structured. The Spring web Model-View-Controller (MVC) framework is designed around DispatcherServlet. A DispatcherServlet Servlet dispatches requests to handlers. It may do so with configurable handler mappings, view resolution, local time zone, or even support for uploading files.

The important interfaces defined by Spring MVC, and their responsibilities, are listed as follows:

The following diagram outlines the components of the Spring MVC:

For more information on Spring features, refer to the link: http://spring.io/.

Out of the various features provided by the Spring 3 framework, a combination of the following was finalized for the architecture of a WebRTC client project:

The following diagram shows the organization of code blocks, which are divided into five major segments:

A detailed look at every segment is represented with the help of the following diagram:

The modules discussed in the final Spring-based project are listed as follows:

The steps to build a Spring 3-based WebRTC application are follows:

Since the previous sections have outlines for the blueprint of developing services such as login, account management, and phone book, we shall discuss the implementation of the Geolocation module with Spring MVC framework.

The Geolocation module

The Geolocation module comprises the following code snippets:

1. The Controller defines the logic for processing the URL for the Geolocation request:

   @RequestMapping(value = "/geolocationtogether", method = RequestMethod.GET)
   public ModelAndView geolocationtogether() {
     return new ModelAndView("geolocationtogether");
   }
   
   @RequestMapping(value = "/savegeolocation", method = RequestMethod.POST)
   public ModelAndView saveGeolocation(@ModelAttribute("command") GeolocationBean geolocationBean, BindingResult result) {
   
     Geolocation geolocation = prepareModelGeolocation(geolocationBean);
     geolocationService.addGeolocation(geolocation);
     return new ModelAndView("redirect:/ addgeolocation.html?sipuri="+geolocation.getGeosipuri());
   }
   
   @RequestMapping(value="/geolocation", method = RequestMethod.GET)
   public ModelAndView listGeolocation() {
     Map<String, Object> model = new HashMap
       <String, Object>();
     model.put("geolocation", prepareListofBeanGeolocation(geolocationService.listGeolocations(allinoneBean.getSipuri())));
     return new ModelAndView("geolocationList", model);
   }

2. Define the AJAX request handler for Geolocation-based requests:

   @RequestMapping(value="/addgeolocationajax",method=RequestMethod.POST)
   
   public @ResponseBody String addGeolocationAjax(@RequestParam("sipuri") String sipuri,@RequestParam("latitude") String latitude,@RequestParam("longitude") String longitude,@RequestParam("date") String date,@RequestParam("time") String time){
     GeolocationBean bean=new GeolocationBean();
     bean.setSipuri(sipuri);
     bean.setLatitude(latitude);
     bean.setLongitude(longitude);
     bean.setDate(date);
     bean.setTime(time);
     Geolocation geolocation = prepareModelGeolocation(bean);
     geolocationService.addGeolocation(geolocation);
   
     return "Saved successfully";
   }

3. Preparing a list of Beans for passing Geolocation objects in an array list is done using the following lines of code:

   private Geolocation prepareModelGeolocation(GeolocationBean geolocationBean){
     Geolocation geolocation = new Geolocation();
     geolocation.setGeoLatitude(geolocationBean.getLatitude());
     geolocation.setGeoLongitude(geolocationBean.getLongitude());
     geolocation.setGeodate(geolocationBean.getDate());
     geolocation.setGeotime(geolocationBean.getTime());
     geolocation.setGeosipuri(geolocationBean.getSipuri());
     return geolocation;
   }
   
   private List<GeolocationBean> prepareListofBeanGeolocation(List<Geolocation> geolocations){
   
     List<GeolocationBean> beans = null;
     if(geolocations != null && !geolocations.isEmpty()){
       beans = new ArrayList<GeolocationBean>();
       GeolocationBean bean = null;
       for(Geolocation geolocation : geolocations){
         bean = new GeolocationBean();
         bean.setSipuri(geolocation.getGeosipuri());
         bean.setLatitude(geolocation.getGeoLatitude());
         bean.setLongitude(geolocation.getGeoLongitude());
         bean.setDate(geolocation.getGeodate());
         bean.setTime(geolocation.getGeotime());
         beans.add(bean);
       }
     }
     return beans;
   }
   
   private GeolocationBean prepareBeanGeolocation(Geolocation geolocation){
   
     GeolocationBean bean = new GeolocationBean();
     bean.setLatitude(geolocation.getGeoLatitude());
     bean.setLongitude(geolocation.getGeoLongitude());
     bean.setDate(geolocation.getGeodate());
     bean.setTime(geolocation.getGeotime());
     bean.setSipuri(geolocation.getGeosipuri());
     return bean;
   }

4. Create a Bean class:

   public class GeolocationBean {
     private String sipuri;
     private String latitude;
     private String longitude;
     private String date;
     private String time;
   
   /* getter and setters of the datamembers declared above */
   }

5. Create an interface named GeolocationService:

   public interface GeolocationService {
     public void addGeolocation(Geolocation geolocation);
     public List<Geolocation> listGeolocations(String sipuri);
     public Geolocation getGeolocation(String sipUri);
     public void deleteGeolocation(Geolocation geolocation);
   }

6. The GeolocationModel class is provided in the following code snippet. It declares variables for containing the SIP URI, latitude, and longitude components of the coordinate, and date and time values to specify when the reading was recorded.

   public class GeolocationBean {
     private String sipuri;
     private String latitude;
     private String longitude;
     private String date;
     private String time;
   /* getters and setters of above datamembers */
   }

7. The DAO interface for the Geolocation module is given in the following code snippet:

   public interface GeolocationDao {
     public void addGeolocation(Geolocation geolocation);
     public List<Geolocation> listGeolocations(String sipuri);
     public Geolocation getGeolocation(String sipUri);
     public void deleteGeolocation(Geolocation geolocation);  
   }

8. Develop the View component for the Geolocation service that comprises JavaScript, CSS, and HTML elements. The following screenshot shows the main page for embedding the call, phonebook, message, profile, and the Geolocation views:
   

The following screenshot shows the Project Explorer window after the project completion of the WebRTC client web application using the Spring Framework. It shows the structure of the WebUnifiedCommunicator project based on Spring:

After POC and the main project development, let's proceed to the testing of the application built so far.

Active since 2012, RCS initially swept over Europe. It has been enhanced and made into an enterprise software package to reach the critical masses. Downloadable clients are also in market for closed environments. Communication Service Providers (CSPs) can use RCS to support IMS as a service-delivery platform and also consider offering software suites as cloud or hosted services to enterprise consumers.

Factors that drive an RCS adoption are the device's availability and the strong requirement of a standardized, open, and extensible ecosystem. Devices were initially the main factor that blocked the RCS adoption. However, all major manufacturers have announced RCS support in their handsets. Today, RCS is supported on mobile platforms such as Android, iOS, RIM, Symbian and so on; however, some CSPs might provide their own open source stack to device manufacturers. GSMA is ensuring interoperability by an extensive and continuous testing process. The growth of RCS is expected to ramp up quickly with the support of majority of OEMs in Asia, Europe and America.

The last couple of years have seen users drifting away from some traditional telecom services such as SMS and embracing the services offered by online service providers or Over the Top (OTT) players. Similar trends have been observed in voice segments as well with the upcoming online audio/video call services. With this fast decline in the usage of traditional telecom services, there is a threat of loss of revenue and user loyalty to a telecom service provider. Therefore, it is now the right time to enhance the set of services that already exist and add new, exciting ones.

RCS is the way to attain a better user experience with innovative new services, but what does it have in store for CSPs and enterprises? The answer is RCS provides methods to monetize these new services while keeping the cost and timescales short. CSPs need a clear business case in relation to capitalization, besides protecting and increasing the subscriber base.

CSPs that launch RCS need to ensure quality and services better than OTT players such as Skype; they also need to ensure a high-level experience in mobile video. With proper Quality of Service (QoS) in place, CSPs can test out price points and find potential new revenue streams.

QoS is defined as the overall performance of a telephony or computer network, particularly the performance seen by the users of the network.

GSMA has stated that RCS is the gateway to innovation. An operator can use their network infrastructure that is already set up, to support the RCS cause. The elements of Ubiquity, global interoperability, QoS assurance, and security and privacy management are essentially the game changers with respect to OTTs. The following points state the positive aspects of using RCS:

RCS-e is defined by RCS 1.2.2 specifications. Refer to http://www.gsma.com/network2020/wp-content/uploads/2012/03/rcs-e_advanced_comms_specification_v1_2_2_approved.pdf for more information. RCS-e looks into the following areas of WebRTC:

GSMA has said that Joyn is a consumer-facing brand that identifies and promotes RCS services. If RCS is the service design and implementation done by the operator, then Joyn is the visual interface implementation of the capabilities done by the device manufacturer. It is the native adoption of RCS capabilities in a device. Joyn specifications were written in order to ensure the interoperability of services across various platforms. This, in turn, prevents vendor lock-in through proprietary or over customized implementation of RCS. Like RCS, JOYN too is backed by GSMA. The GSMA RCS IOT Joyn Blackbird Implementation Guidelines Version 1.3 is the latest one now.

The first time a user makes use of an RCS device, it is configured by the network provider. If the process is successful, the device receives the correct configuration XML, including the validity period of the associated RCS configuration parameters. If the device has no issues, that is, the device receives no errors during the registration process, then the device refrains from contacting the server again until the validity period has expired.

This process could require several retries until the provisioning in IMS is successfully performed. For those devices that have not successfully completed the configuration process, any RCS-specific UX available on the device remains disabled (known as the vanilla behavior) until a valid RCS configuration is successfully received and processed.

The use of another device's PS connection (for example, a Wi-Fi-to-cellular PS router) might lead to an incorrect identification of the requesting device. Therefore, this request can only be sent reliably by clients that are aware that any PS connection in the path towards the RCS configuration server is provided by themselves. When this initial request is performed over a non-PS access network, the RCS configuration server is unable to successfully identify/verify the identity of the requester (that is, RADIUS or header enrichment is no longer an option). In this case, the RCS configuration server will reply with an HTTP 511 Network Authentication Required error response. This response will trigger the RCS client to start the SMS-based configuration mechanism.

We will start by learning some mandatory RCS features that will help us achieve the goal of building a WebRTC client with RCS compliance. The following standardized services are a part of the 5.1 specifications of RCS: