Web RTC Integrator's Guide WebRTC%20Integrator's%20Guide
User Manual:
Open the PDF directly: View PDF .Page Count: 382
WebRTC Integrator's Guide
Successfully build your very own scalable WebRTC
infrastructure quickly and efficiently
Altanai
BIRMINGHAM - MUMBAI
WebRTC Integrator's Guide
Copyright © 2014 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval
system, or transmitted in any form or by any means, without the prior written
permission of the publisher, except in the case of brief quotations embedded in
critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy
of the information presented. However, the information contained in this book is
sold without warranty, either express or implied. Neither the author, nor Packt
Publishing, and its dealers and distributors will be held liable for any damages
caused or alleged to be caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the
companies and products mentioned in this book by the appropriate use of capitals.
However, Packt Publishing cannot guarantee the accuracy of this information.
First published: October 2014
Production reference: 1251014
Published by Packt Publishing Ltd.
Livery Place
35 Livery Street
Birmingham B3 2PB, UK.
ISBN 978-1-78398-126-7
www.packtpub.com
Cover image by Gagandeep Sharma (er.gagansharma@gmail.com)
Credits
Author
Altanai
Reviewers
Alessandro Arrichiello
Pasquale Boemio
Antón Román Portabales
Andrii Sergiienko
Commissioning Editor
Usha Iyer
Acquisition Editor
Llewellyn Rozario
Content Development Editor
Akashdeep Kundu
Technical Editor
Menza Mathew
Copy Editors
Karuna Narayanan
Laxmi Subramanian
Project Coordinator
Neha Thakur
Proofreaders
Jenny Blake
Stephen Copestake
Maria Gould
Joel T. Johnson
Indexers
Hemangini Bari
Mariammal Chettiyar
Rekha Nair
Graphics
Ronak Dhruv
Valentina D'silva
Disha Haria
Abhinash Sahu
Production Coordinators
Adonia Jones
Nitesh Thakur
Cover Work
Nitesh Thakur
About the Author
Altanai, born into an Indian army family, is a bubbly, vivacious, intelligent
computer geek. She is an avid blogger and writes on Research and Development
of evolving technologies in Telecom (http://altanaitelecom.wordpress.com).
She holds a Bachelor's degree in Information Technology from Anna University,
Chennai. She has worked on many Telecom projects worldwide, specifically in the
development and deployment of IMS services. She firmly believes in contributing to
the Open Source community and is currently working on building a WebRTC-based
JS library with books for more applications.
Her hobbies include photography, martial arts, oil canvas painting, river rafting,
horse riding, and trekking, to name a few.
This is her first book, and it contains useful insight into WebRTC for beginners and
integrator in this field. The book has definitions and explanations that will cover
many interesting concepts in a clear manner.
Altanai can be contacted at tara181989@gmail.com.
About the Reviewers
Alessandro Arrichiello is a computer enthusiast. He graduated in Computer
Engineering from the University of Naples Federico II, Italy.
He has a passion for and knowledge of GNU/Linux systems that began at age
of 14 and continues today. He is an independent Android developer, who develops
apps for Google Play Store, and has strong knowledge of C++, Java, and other
derivatives. He also has experience with many other interpreted languages such
as Perl, PHP, and Python.
Alessandro is a proud open source supporter and has given his contribution to
many collaborative projects developed for academic purposes.
Recently, he enriched his knowledge on Network Monitoring, focusing on
Penetration Testing and Network Security in general.
At the moment, Alessandro is working as a software engineer in the
Communications and Media Solution group of Hewlett Packard in Milan, Italy.
He's involved in many business projects as a developer and technology consultant.
Alessandro has worked as a reviewer and author for Packt Publishing. He has
technically reviewed the book, WebRTC Blueprints, and now, he's working on a
video course on developing an application using the WebRTC technology.
Pasquale Boemio fell in love with Linux and the open source philosophy
at the age of 12. He has a Master's degree in Computer Engineering, and he
works as a researcher at the Computer Engineering department of the University
of Naples Federico II, Italy. At the same time, he collaborates with Meetecho
(www.meetecho.com), experimenting with a large number of innovative technologies
such as WebRTC, Docker, and Node.js.
Even though Pasquale is involved in such activities, he still releases free software on
GitHub (www.github.com/helloIAmPau).
Antón Román Portabales is the CTO of Quobis. After graduating as a
telecommunications engineer, he began working in Motorola as an IMS developer.
In 2008, he left Motorola to join Quobis, a Spanish company focused on SIP
interconnection. It works for major operators and companies in Europe and South
America. In 2010, he finished a Pre-PhD program in Telematics Engineering as the
main author of a paper about the use of IMS networks to transmit real-time data
from the electrical grid; he presented this paper in an IEEE conference in 2011.
He has been actively working on WebRTC since 2012, when Quobis decided to focus
on this technology. He has recently got involved in the activities of IETF, along with
other colleagues from Quobis. He also frequently participates in VoIP-related open
source events.
Andrii Sergiienko is an entrepreneur who's passionate about IT and also
about travelling. He has lived in different places, such as Ukraine, Russia, Belarus,
Mongolia, Buryatia, and Siberia, spending a considerable number of years in every
place. He also likes to travel by an auto rickshaw.
From his early childhood, Andrii was interested in computer programming and
hardware. He took the first steps in this field more than 20 years ago. Andrii has
experience in a wide set of languages and technologies, including C, C++, Java,
Assembler, Erlang, JavaScript, PHP, Riak, shell scripting, computer networks,
security, and so on.
During his career, Andrii has worked for both small, local companies, such as
domestic ISP; and large world corporations, such as Hewlett Packard. He also
started his own companies; some of them were relatively successful, while others
were a total failure.
Today, Andrii is working on growing Oslikas, his company, headquartered
in Estonia. The company is focused on modern IT technologies and solutions.
They also develop a full-stack framework to create rich media WebRTC
applications and services. You can find them at http://www.oslikas.com.
www.PacktPub.com
Support files, eBooks, discount offers, and more
You might want to visit www.PacktPub.com for support files and downloads related
to your book.
Did you know that Packt offers eBook versions of every book published, with PDF and
ePub files available? You can upgrade to the eBook version at www.PacktPub.com and
as a print book customer, you are entitled to a discount on the eBook copy. Get in touch
with us at service@packtpub.com for more details.
At www.PacktPub.com, you can also read a collection of free technical articles, sign up
for a range of free newsletters and receive exclusive discounts and offers on Packt books
and eBooks.
TM
http://PacktLib.PacktPub.com
Do you need instant solutions to your IT questions? PacktLib is Packt's online digital
book library. Here, you can access, read and search across Packt's entire library of books.
Why subscribe?
•
•
•
Fully searchable across every book published by Packt
Copy and paste, print and bookmark content
On demand and accessible via web browser
Free access for Packt account holders
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.
Table of Contents
Preface
Chapter 1: Running WebRTC with and without SIP
1
7
JavaScript Session Establishment Protocol (JSEP)
Signal and media flows
Running WebRTC without SIP
Sending media over WebSockets
7
8
10
10
WebRTC through WebSocket signaling servers
Node.js
Making a peer-to-peer audio call using Node.js for signaling
Running WebRTC with SIP
Session Initiation Protocol (SIP)
JavaScript-based SIP libraries
Summary
24
24
26
32
32
36
37
getUserMedia
RTCPeerConnection
RTCDataChannel
Media traversal in WebRTC clients
Chapter 2: Making a Standalone WebRTC Communication Client
Description of the WebRTC client-server model
The sipML5 WebRTC client
Developing a minified webphone application using Tomcat
Developing our customized version of the sipML5 client
The jsSIP WebRTC client
Developing our version of the jsSIP client
SIP servers
SIP-WS to SIP-WS
SIP2SIP
OfficeSIP
SIP WS to SIP and vice-versa
The gateway to convert SIP over WebSocket to native SIP
The WebRTC2SIP gateway
10
12
18
23
39
40
41
42
46
49
50
53
55
56
57
58
59
59
Table of Contents
The WebRTC client with Brekeke SIP server
The WebRTC client with the Kamailio SIP server
Limitations of the existing setup
Firewall and NAT issues
Media transcoding
Summary
Chapter 3: WebRTC with SIP and IMS
The Interaction with core IMS nodes
The Call Session Control Function
Home Subscriber System
The IP Multimedia Subsystem core
The OpenIMS Core
The Telecom server
The Mobicents Telecom Application Server
The Media Server
The FreeSWITCH Media Server
Media Services
WebRTC over firewalls and proxies
The final architecture for the WebRTC-to-IMS integration
Summary
Chapter 4: WebRTC Integration with Intelligent Network
From mobiles to WebRTC client through GPRS
IMS connectivity to Gateway GPRS Support Node
From mobiles to WebRTC client through GSM
Call processed with the IN service logic
The WebRTC client's communication with the GSM phone
through IMS
The WebRTC client's communication with a GSM phone
with IN services
The services broker for endpoints and WebRTC in IMS to GSM
phone in Intelligence Networks
The WebRTC client's SIP messages to SMS in a GSM phone (SMSC)
The Kannel gateway
Summary
Chapter 5: WebRTC Integration with PSTN
What is PSTN?
WebRTC connectivity to the PSTN
The PSTN gateway
The PSTN connectivity to IMS via PSTN gateways
The call flow from a WebRTC SIP browser client to a fixed landline phone
[ ii ]
64
66
74
75
75
79
81
82
83
83
85
86
96
96
99
99
103
109
112
113
115
116
118
121
124
125
127
129
130
130
135
137
138
139
141
142
142
Table of Contents
The challenges in connecting the WebRTC world to
the PSTN landscape
Address mapping
Translation from SIP to ISUP
145
145
145
The service logic
SIP service logic through application server
IN services via IMSSF
The Service Broker for the orchestration of services
Summary
150
150
151
152
154
The call setup
The call termination
The call in progress
Chapter 6: Basic Features of WebRTC over SIP
SIP services
Registering a SIP client
Making audio and video calls using SIP
Text Chat using SIP
Obtaining the online/offline status of users using SIP
Services in the Application Server
Back-to-back user agent
Call screening
Basic call screening
Enhanced call screening
146
147
149
155
156
156
159
165
167
172
174
175
175
176
Call hold/resume
Call forwarding
176
177
Call transfer
179
Unconditional call forwarding
Call forwarding when the user is unavailable
Attended call transfer
Unattended call transfer
178
178
179
181
Generation of call log for tracking
Media Server-based features
Announcement
Media relay
Voicemail
Music on Hold
Interactive Voice Response
Conferencing
182
182
183
183
184
186
186
187
Features of a web application
Geolocation
Authenticating users with OAuth
188
188
190
Multipart communication
187
[ iii ]
Table of Contents
Import contacts from other accounts
Advertisements in the WebRTC call
Delivering an instant message as a mail
The admin console
Summary
Chapter 7: WebRTC with Industry Standard Frameworks
The Multitier architecture
The design of a WebRTC client
The Class diagram
The Entity Relationship model
The environment setup
Java Runtime Environment (JRE)
Integrated Development Environment with Java Enterprise Edition (EE)
Databases
The web application server
The web application infrastructure
JSP- / Servlet-based WebRTC web project
Programming the JSP- / Servlet-based web project structure
The development of modules
191
192
193
194
194
195
196
197
197
200
201
201
202
202
203
204
204
205
206
Struts- / Hibernate-based WebRTC web project
213
Spring 3 MVC-based WebRTC web project
223
Programming the Struts- / Hibernate-based web project structure
The development of modules
Programming the Spring 3 MVC web project structure
The development of modules
Testing
Testing the signal flow
Test cases for WebRTC client validation
Summary
Chapter 8: WebRTC and Rich Communication Services
Rich Communication Services
Position and adoption of RCS
Business impact of RCS
Technology impact
Rich Communication Services enhanced (RCS-e)
Joyn
The RCS configuration process
RCS specifications
Service discovery by an RCS-enabled device
User capability exchange
Chats with multimedia sharing
[ iv ]
213
215
223
226
236
237
237
241
243
244
244
245
245
246
246
246
247
248
248
249
Table of Contents
Group chat in a conference session
User availability through XCAP
REST-based notifications
Interoperability and interworking
251
252
253
253
The RCS ecosystem and WebRTC
RCS services in WebRTC
254
255
WebRTC architecture with RCS modules
Telecom operator's benefit derived from RCS
Voice over LTE
Combination of WebRTC, VOLTE, and RCS
Summary
266
266
268
268
269
User profile
Integration with social networks
The enhanced phonebook
User capabilities and Presence
Unified messaging box
Message history
Rich calls
Call logs
Message history
Multiparty conferencing
Chapter 9: Native SIP Application and Interaction
with WebRTC Clients
Support for WebRTC in various operating systems
Windows OS
Native browser support for WebRTC clients
SIP softphones capable of interacting with WebRTC clients
WebRTC unsupported browsers interacting with WebRTC clients
255
257
258
259
260
261
261
263
264
265
271
273
274
274
280
282
Linux OS
283
Mac OS
289
Android OS for mobiles
295
Windows OS for mobiles
Apple iPhone
301
302
Native browser support for WebRTC clients
SIP softphones capable of interacting with WebRTC clients
Native browser support for WebRTC clients
SIP softphones capable of interacting with WebRTC clients
WebRTC unsupported browsers interacting with WebRTC client
Native browser support for WebRTC clients
Android phone's/tablet's SIP applications capable of interacting with WebRTC clients
Developing a lightweight Android SIP application
iPhone/iPad IP applications interacting with WebRTC clients
Developing an iPhone SIP application
Summary
[v]
284
286
290
291
294
295
298
300
302
304
304
Table of Contents
Chapter 10: Other WebRTC Use Cases
Unified Communicator
Team Communicator
Customized Communicator for specific enterprise segments
Branches and back office communications
The Customer Relationship Management system
Network Operation Center
The human resource management tool
Communicating with candidates for an open post directly
from the job portal
Social networking – targeting consumers
Social networking platforms
Dating sites with anonymous call and chat
Retail services
WebRTC online marketing centers
WebRTC contact centers
Users contacting customer care
Health care
Online medical consultation with the doctor
Financial services
Communication with financial services
Insurance claims
Calling from the ATM
Remote management
Surveillance
Managing the connected device
WebRTC games
Two-player games
Multiplayer games
TV experience with WebRTC
Live broadcasting
IPTV integration and streaming
Streaming movies among peers
Interfacing services
WebRTC for e-learning
WebRTC for e-governance
Summary
Index
[ vi ]
305
306
306
310
310
313
318
319
319
321
321
323
325
325
327
328
329
330
334
334
336
338
338
339
340
340
341
342
343
344
345
346
348
348
350
350
351
Preface
WebRTC Integrator's Guide is a deep dive into the world of real-time telecommunication
and its integration with the telecom network. This book covers a wide range of
WebRTC solutions, such as GSM, PSTN, and IMS, designed for specific network
requirement. It also addresses the implementation woes by describing every minute
detail of the WebRTC platform setup from the APIs to the architecture, code-to-server
installations, RCS-to-Codec interoperability, and much more. It also describes various
enterprise-based use cases that can be built around WebRTC.
What this book covers
Chapter 1, Running WebRTC with and without SIP, is a quick brush-up of WebRTC
basics such as Media APIs. It also describes the use of plain WebSocket signaling
to deliver WebRTC-based browser-to-browser communication.
Chapter 2, Making a Standalone WebRTC Communication Client, talks about the use
of the Session Initiation Protocol (SIP) as the signaling mechanism for WebRTC.
It describes the setup of the SIP server for this purpose.
Chapter 3, WebRTC with SIP and IMS, outlines the interaction of a SIP-based WebRTC
client with the IP Multimedia Subsystem (IMS).
Chapter 4, WebRTC Integration with Intelligent Network, describes the ways in which
WebRTC can be made interoperable with mobile phones, as the majority of mobile
communications today are still on GSM under the IN model.
Chapter 5, WebRTC Integration with PSTN, describes the backward compatibility of
the WebRTC technology to the old, fixed-line telephones.
Chapter 6, Basic Features of WebRTC over SIP, describes the basic WebRTC SIP services
such as audio/video call, messaging, call transfer, call hold/resume, and others.
Preface
Chapter 7, WebRTC with Industry Standard Frameworks, discusses the
development of the WebRTC client over the industry-adopted framework
(that is, Model-View-Controller).
Chapter 8, WebRTC and Rich Communication Services, discusses how RCS enriches
the communication technology with features such as file transfer, Presence,
phonebook, and others.
Chapter 9, Native SIP Application and Interaction with WebRTC Clients, addresses a very
important concern, that is, the WebRTC interoperability with other SIP endpoints
such as desktop clients, SIP hardphones, and mobile-based SIP applications.
Chapter 10, Other WebRTC Use Cases, presents an interesting array of WebRTC use
cases that are both innovative and practical with the current WebRTC standards.
What you need for this book
A brief understanding of SIP is required to set up the operation environment.
It is recommended that you use Linux, as it supports the installation of many open
source components described in the book. Web development skills are required
to make the WebRTC web-based application using HTML and browser APIs. It is
recommended that you use the Eclipse IDE for client-side development, as depicted
in many screenshots provided in the book. To host the applications, any web server,
such as Apache, will do.
Who this book is for
Web developers, SIP application developers, and IMS experts can use this book to
develop and deploy a customized, readily deployable WebRTC platform. The use
cases described in the book cater to WebRTC integration in any industry segment.
Therefore, anyone with basic knowledge of HTML and JavaScript can develop a
WebRTC client after referring to this book.
Conventions
In this book, you will find a number of styles of text that distinguish between
different kinds of information. Here are some examples of these styles, and an
explanation of their meaning.
[2]
Preface
Code words in text, database table names, folder names, filenames, file extensions,
pathnames, dummy URLs, user input, and Twitter handles are shown as follows:
"We saw how to program the three basic APIs of WebRTC media stack namely,
getUserMedia, RTCPeerConnection, and DataChannel."
A block of code is set as follows:
public class loginServlet extends HttpServlet {
public loginServlet() {
super();
}
...
Any command-line input or output is written as follows:
ws://ns313841.ovh.net:10060/
Request Method:
GET
Status Code:
101 Switching Protocols
New terms and important words are shown in bold. Words that you see on the
screen, in menus or dialog boxes for example, appear in the text like this: "As peer 1
keys in the message and hits the Send button, the message is passed on to peer 2."
Warnings or important notes appear in a box like this.
Tips and tricks appear like this.
Reader feedback
Feedback from our readers is always welcome. Let us know what you think about
this book—what you liked or may have disliked. Reader feedback is important for
us to develop titles that you really get the most out of.
To send us general feedback, simply send an e-mail to feedback@packtpub.com,
and mention the book title via the subject of your message.
If there is a topic that you have expertise in and you are interested in either writing
or contributing to a book, see our author guide on www.packtpub.com/authors.
[3]
Preface
Customer support
Now that you are the proud owner of a Packt book, we have a number of things to
help you to get the most from your purchase.
Downloading the example code
You can download the example code files for all Packt books you have purchased
from your account at http://www.packtpub.com. If you purchased this book
elsewhere, you can visit http://www.packtpub.com/support and register to have
the files e-mailed directly to you.
Downloading the color images of this book
We also provide you a PDF file that has color images of the screenshots/diagrams
used in this book. The color images will help you better understand the changes in
the output. You can download this file from: https://www.packtpub.com/sites/
default/files/downloads/1267OS_ColoredImages.pdf.
Errata
Although we have taken every care to ensure the accuracy of our content, mistakes
do happen. If you find a mistake in one of our books—maybe a mistake in the text or
the code—we would be grateful if you would report this to us. By doing so, you can
save other readers from frustration and help us improve subsequent versions of this
book. If you find any errata, please report them by visiting http://www.packtpub.
com/submit-errata, selecting your book, clicking on the errata submission form link,
and entering the details of your errata. Once your errata are verified, your submission
will be accepted and the errata will be uploaded on our website, or added to any list of
existing errata, under the Errata section of that title. Any existing errata can be viewed
by selecting your title from http://www.packtpub.com/support.
[4]
Preface
Piracy
Piracy of copyright material on the Internet is an ongoing problem across all media.
At Packt, we take the protection of our copyright and licenses very seriously. If you
come across any illegal copies of our works, in any form, on the Internet, please
provide us with the location address or website name immediately so that we can
pursue a remedy.
Please contact us at copyright@packtpub.com with a link to the suspected
pirated material.
We appreciate your help in protecting our authors, and our ability to bring
you valuable content.
Questions
You can contact us at questions@packtpub.com if you are having a problem
with any aspect of the book, and we will do our best to address it.
[5]
Running WebRTC with
and without SIP
WebRTC lets us make calls right from a web page without any plugin. This was
made possible using media APIs of the browser to fetch user media, WebSocket for
transportation, and HTML5 to render the media on the web page. Thus, WebRTC
is an evolved form of WebSocket communication. WebSocket is a Transport Layer
protocol that carries data. The WebSocket API is an Application Programming
Interface (API) that enables web pages to use the WebSocket protocol for (duplex)
communication with a remote host.
In this chapter, we will study how WebRTC really works. We will also
demonstrate the use of WebRTC media APIs to capture and render input from a
user's microphone and camera onto a web page. In the later part of chapter, we will
find out how to build a simple standalone WebRTC client using the plain WebSocket
protocol as the signaling mechanism.
JavaScript Session Establishment
Protocol (JSEP)
The communication model between a client and remote host is based on the
JSEP architecture, which differentiates the signaling and media transaction
into different layers.
Running WebRTC with and without SIP
The differentiation is shown in the following figure:
WebRTC: JSEP Approach
Signaling vs Media
Network
Signaling
Signaling
App
App
App
SessionDescription
SessionDescription
WebRTC
Browser
Browser
Media
Caller
Callee
JSEP signaling and media
As an example, let's consider two peers, A and B, where A initiates communication
with B. Initially, in the first case, A being the offerer will have to call the
createOffer function to begin a session. A also mentions details such as codecs
through a setLocalDescription function, which sets up its local config. The remote
party, B, reads the offer and stores it using the setRemoteDescription function. The
remote party, B, calls the createAnswer function to generate an appropriate answer,
applies it using the setLocalDescription function, and sends the answer back
to the initiator over the signaling channel. When A gets the answer, it also stores it
using the setRemoteDescription function, and the initial setup is complete. This
is repeated for multiple offers and answers. The latest on JSEP specifications can be
read from the Internet Engineering Task Force (IETF) site at http://datatracker.
ietf.org/doc/draft-ietf-rtcweb-jsep/.
Signal and media flows
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.
[8]
Chapter 1
A few instances of end-to-end signaling and media flow variants are shown in the
following screenshot:
JSON via XMLHttpRequest
Signaling
JSON via XMLHttpRequest
Network
Signaling
App
App
App
SessionDescription
SessionDescription
WebRTC
RTP
Browser
Caller
Browser
Media
websocket subprotocol JSON XMR
Callee
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):
XMPP
Signaling
Network
App
App
XMPP
Signaling
App
SessionDescription
SessionDescription
WebRTC
Browser
Media
Caller
Browser
Callee
eXtensible Messaging and Presence Protocol (XMPP)
[9]
Running WebRTC with and without SIP
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.
IP Multimedia System (IMS) is part of the Next Generation
Network (NGN) model for IP-based communication.
Running WebRTC without SIP
HTML5 websockets can be defined by ws:// followed by the URL in the server field
while readying a WebRTC client for registration. This enables bidirectional, duplex
communications with server-side processes, that is, server-side push events to the
client. It also enables the handshake after sharing media metadata such as ports,
codecs, and so on.
It should be noted that WebRTC works in an offer/answer mode and has ways
of traversing the Network Address Translation (NAT) and firewalls by means
of Interactive Connectivity Establishment (ICE). ICE makes use of the Session
Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using
Relay NAT (TURN). This is covered later in the chapter.
Sending media over WebSockets
WebRTC mainly comprises three operations: fetching user media from a
camera/microphone, transmitting media over a channel, and sending messages
over the channel. Now, let's take a look at the summarized description of every
operation type.
getUserMedia
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.
[ 10 ]
Chapter 1
For simple demos of these methods, download the WebRTC read-only
by executing the following command:
svn checkout http://webrtc.googlecode.com/svn/trunk/
webrtc-read-only
The following is the code to access the IP camera in the Google Chrome browser
and display the local video in a Start
/*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);
}
When the browser tries to access media devices such as a camera and
mic from users, there is always a browser notification that asks for the
user's permission.
Downloading the example code
You can download the example code files for all Packt books you have
purchased from your account at http://www.packtpub.com. If you
purchased this book elsewhere, you can visit http://www.packtpub.
com/support and register to have the files e-mailed directly to you
[ 11 ]
Running WebRTC with and without SIP
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:
RTCPeerConnection
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.
[ 12 ]
Chapter 1
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.
It is noted that WebRTC standards are in rapid evolution.
The API that was used for the first version of WebRTC was the
PeerConnection API, which had distinct methods for media
transmission. As of now, the old PeerConnection API has
been deprecated and a new enhanced version is under process.
The new Media API has replaced the media streams handling in
the old PeerConnection API.
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:
W3C Standard
Chrome
Firefox
getUserMedia
webkitGetUserMedia
mozGetUserMedia
RTCPeerConnection
webkitRTCPeerConnection
mozRTCPeerConnection
RTCSessionDescription
RTCSessionDescription
mozRTCSessionDescription
RTCIceCandidate
RTCIceCandidate
mozRTCIceCandidate
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.
[ 13 ]
Running WebRTC with and without SIP
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:
Start
Call
Hang Up
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() {});
}
[ 14 ]
Chapter 1
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
btn3.disabled
videoTracks =
audioTracks =
var servers =
{
= true;
= false;
localstream.getVideoTracks();
localstream.getAudioTracks();
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);
}
[ 15 ]
Running WebRTC with and without SIP
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.
[ 16 ]
Chapter 1
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.
[ 17 ]
Running WebRTC with and without SIP
RTCDataChannel
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.
Send data
Start
Send Data
Stop Send Data
Received Data
in the window. Consider the following command line as an example:
node signaler.js
To write and run a simple server-side program, open Notepad, make a sample JS file
with a name, say, console, and add some content to the console.log('node.js
running fine') file. Run this file using the following Node.js command from the
command prompt:
node console.js
The following screenshot shows the output of the preceding command line:
[ 25 ]
Running WebRTC with and without SIP
Let's now look at the overview of steps using Node.js to set up the signaling
environment for a WebRTC client.
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:
Node.js
Signaling
Signaling
Encrypted Media
RTP
Alice's Browser
Bob's Browser
The preceding diagram denotes signaling across WebRTC clients over the
Node.js WebSocket-based server. The media flows from peer to peer.
Making a peer-to-peer audio call using
Node.js for signaling
We have seen how a JavaScript program is hosted on a Node.js signaling server.
Now, let's study the process of making an audio/video call using this setup. The
following code references Muaz Khan WebRTC experiments, which is under the
MIT license. The library used is PeerConnection.js. The following are the CSS
descriptions for the audio and video content on a page:
audio, video {
vertical-align: top;
[ 26 ]
Chapter 1
}
.setup {
border-bottom-left-radius: 0;
border-top-left-radius: 0;
margin-left: -9px;
margin-top: 8px;
position: absolute;
}
.highlight { color: rgb(0, 8, 189); }
Next, we will look at the JavaScript functions that define the behavior of the WebRTC
client. This is a modified version of code from one-to-one-peerconnection.html
under the WebRTC experiments master from Muaz Khan. For better clarity and easy
understanding, I have removed the functions of unique ID, rotate video, and scale
video, and have minimal CSS styling.
The following code defines the websocket.onopen and websocket.send operations:
var channel = location.href.replace( /\/|:|#|%|\.|\[|\]/g, '');
var websocket = new WebSocket('ws://' + document.domain +
':12034');
websocket.onopen = function() {
websocket.push(JSON.stringify({
open: true, channel: channel
}));
};
websocket.push = websocket.send;
websocket.send = function(data) {
websocket.push(JSON.stringify({
data: data, channel: channel
}));
};
The following code is for the creation of a new peer connection and for every user
who joins a session:
var peer = new PeerConnection(websocket);
peer.onUserFound = function(userid) {
if (document.getElementById(userid)) return;
/* adding the name of room to room list */
var tr = document.createElement('tr');
var td1 = document.createElement('td');
var td2 = document.createElement('td');
[ 27 ]
Running WebRTC with and without SIP
td1.innerHTML = userid + ' video call';
/* creating element button to room list */
var button = document.createElement('button');
button.innerHTML = 'Join';
button.id = userid;
button.style.float = 'right';
/* add the user to session on button click */
button.onclick = function() {
button = this;
getUserMedia(function(stream) {
// get user media
peer.addStream(stream);
// add the stream
peer.sendParticipationRequest(button.id);
});
button.disabled = true;
};
td2.appendChild(button);
tr.appendChild(td1);
tr.appendChild(td2);
roomsList.appendChild(tr);
};
The following code adds streaming to the video element of HTML and sets
its characteristics:
peer.onStreamAdded = function(e) {
if (e.type == 'local')
document.querySelector('#start-broadcasting').disabled =
false;
var video = e.mediaElement;
video.setAttribute('width', 400);
video.setAttribute('height', 400);
video.setAttribute('controls', true);
videosContainer.insertBefore(video,
videosContainer.firstChild);
video.play();
};
[ 28 ]
Chapter 1
The following code is to close the streaming session:
peer.onStreamEnded = function(e) {
var video = e.mediaElement;
if (video) {
video.style.opacity = 0;
setTimeout(function() {
video.parentNode.removeChild(video);
scaleVideos();
}, 1000);
}
};
document.querySelector('#start-broadcasting').onclick =
function() {
this.disabled = true;
getUserMedia(function(stream) {
peer.addStream(stream);
peer.startBroadcasting();
});
};
document.querySelector('#your-name').onchange = function() {
peer.userid = this.value;
};
var videosContainer = document.getElementById(
'videos-container') || document.body;
var btnSetupNewRoom = document.getElementById('setup-new-room');
var roomsList = document.getElementById('rooms-list');
if (btnSetupNewRoom) btnSetupNewRoom.onclick =
setupNewRoomButtonClickHandler;
The following code is to capture the user media:
function getUserMedia(callback) {
var hints = {
audio: true,
video: {
optional: [],
mandatory: {
minWidth: 200, minHeight:200, maxWidth: 400,
maxHeight: 400, minAspectRatio: 1.77
}
}
};
[ 29 ]
Running WebRTC with and without SIP
navigator.getUserMedia(hints, function(stream) {
var video = document.createElement('video');
video.src = URL.createObjectURL(stream);
video.controls = true;
video.muted = true;
peer.onStreamAdded({
mediaElement: video,
userid: 'self',
stream: stream
});
callback(stream);
});
}
The following is the web page's HTML content to add a button to start transmitting
the media, a video element to display the media, a text field to add a user's name,
and a table to list the existing available sessions:
Start Transmitting Yourself!
The following screenshot depicts a user, Alice, creating a new session named alice.
Here, the user Alice creates a session for broadcasting video, which will be added to
the room list.
[ 30 ]
Chapter 1
Alice's media is streamed on the session space, as shown in the next screenshot:
A new user, Bob, views the list of ongoing sessions from his remote computer,
and clicks on the Join button, as shown in the following screenshot, to join
Alice's session:
[ 31 ]
Running WebRTC with and without SIP
The following screenshot displays a two-way audio and video session in progress
between Bob and Alice:
Bob and Alice are in an audio/video sharing session. Using other WebRTC APIs,
we can also add file sharing, text chat, screen sharing capabilities, and so on to this
simple demonstration to turn it into a multifeatured communication tool.
Running WebRTC with SIP
This section introduces the approach to use the SIP signaling mechanism with
WebRTC. Like any other VoIP protocol, SIP also provides the signaling framework
before setting up an actual media path. However, the foundation of open standard
and industry-adopted signaling protocol such as SIP is recommended, as it provides
the first and most crucial step to a strong, scalable architecture.
Session Initiation Protocol (SIP)
As we already know, SIP is a signaling protocol that is used to establish an RTP
between two endpoints.
As per the official document, RFC 3261, SIP is an application-layer
control protocol that can establish, modify, and terminate multimedia
sessions (conferences) such as Internet telephony calls.
[ 32 ]
Chapter 1
The SIP stack defines the Request and Response methods. These methods are
used to gather the information about endpoints that wish to participate in a
communication so that the device-specific information such as IP, port, availability,
media understanding, and audio-video device compatibility can be sorted out
before establishing a flowing media connection.
However, it should be noted that traditional SIP is a bit different from SIP over
WebSocket (SIPWS), which is used in case of WebRTC with SIP signaling.
It is not by default that every SIP server would understand SIPWS. Only those
SIP servers that have WebSocket support, or state that they are WebRTC compliant,
will be able to proxy or understand the SIP messages sent from a WebRTC client.
Why do we use SIPWS? This protocol allows the development of Convergent
applications, that is, applications that support SIP for communication, HTTP for
web components, and WebRTC for media. SIPWS can be transformed into plain SIP
signal through a gateway, which can then interact with the IMS network. Also, SIP
can be used to integrate application logic such as call screening and call rerouting,
with the help of SIP Servlets or other kinds of SIP programming. More of this is
given in Chapter 3, WebRTC with SIP and IMS.
SIPWS is explained in detail in the IETF draft, The WebSocket Protocol as a Transport for
the Session Initiation Protocol (SIP) draft-ietf-sipcore-sip-websocket-10 and can be found at
http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-10.
The following figure depicts the use of SIPWS signaling plane with WebRTC
media plane:
[ 33 ]
Running WebRTC with and without SIP
The following figure provides the call flow of the SIPWS signaling mechanism.
Any SIP request is preceded by a one-time WebSocket handshake.
Alice loads a web page using her web browser and retrieves the JavaScript code that
implements the SIP WebSocket subprotocol. The JavaScript code (SIP WebSocket
Client) establishes a secure WebSocket connection with a SIP proxy/registrar
(SIP WebSocket Server) at proxy.example.com.
The following is an example of a WebSocket handshake in which the Client requests
the WebSocket SIP subprotocol support from the Server:
ws://ns313841.ovh.net:10060/
Request Method:
GET
Status Code:
101 Switching Protocols
Request Headers:
Provisional headers are shown.
Cache-Control:no-cache
Connection:Upgrade
Host:ns313841.ovh.net:10060
Origin:http://sipml5.org
Pragma:no-cache
Sec-WebSocket-Extensions:permessage-deflate; client_max_window_bits,
x-webkit-deflate-frame
Sec-WebSocket-Key:4aUpDOwtSWPaLmXKzQefJQ==
Sec-WebSocket-Protocol:sip
Sec-WebSocket-Version:13
Upgrade:websocket
[ 34 ]
Chapter 1
User-Agent:Mozilla/5.0 (X11; Linux i686 (x86_64)) AppleWebKit/537.36
(KHTML, like Gecko) Chrome/32.0.1700.102 Safari/537.36
Response Headersview source
Connection:Upgrade
Content-Length:0
Sec-WebSocket-Accept:5l6iqk2+moekkwZsqlXo4cewzcw=
Sec-WebSocket-Protocol:sip
Sec-WebSocket-Version:13
Upgrade:websocket
The following diagram shows the call between Alice and Bob through the SIP proxy
server over WebSocket signaling:
Every SIP endpoint is registered with the SIP Server by a unique callable ID. This is
referred to as the SIP URI and is denoted by the sip:@
format. When a user, Alice, calls another user, Bob, through Bob's SIP URI, then the
SIP WebSocket Server at proxy.example.com acts as a SIP proxy node and routes
the INVITE call to Bob's contact. Bob answers the call to start a conversation and then
terminates it with a BYE request when the communication is over.
[ 35 ]
Running WebRTC with and without SIP
JavaScript-based SIP libraries
There are many popular JavaScript libraries that offer easy-to-integrate support
for WebRTC communication using SIP signaling:
•
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 at http://talksetup.quobis.com/.
The implementation of the sipML5 and JSSIP libraries to constitute a simple
WebRTC browser client that is able to communicate to a similar peer in any
WebRTC-supported browser is covered in the next chapter.
[ 36 ]
Chapter 1
Summary
In this chapter, we learned that a WebRTC communication process is divided into
two parts: signaling, where the session setup and teardown is agreed to, and media
transactions, which deals with the actual RTP streams that contain voice/video/
data that the user has sent. We saw how to program the three basic APIs of WebRTC
media stack, namely, getUserMedia, RTCPeerConnection, and DataChannel.
The Running WebRTC without SIP section described signaling done over JSON via
XMLHttpRequest using Node.js as the intermediately signaling server to connect the
peers and prepare for the media flow. The next section, Running WebRTC with SIP,
listed the libraries or WebRTC clients that use SIP over WebSocket to take care of the
signaling between WebRTC peers. In the following chapters, we will see how to use
WebRTC media APIs over the SIP WebSocket protocol in detail.
[ 37 ]
Making a Standalone
WebRTC Communication
Client
The objective of this chapter is to make a simple WebRTC client and server module
that bypasses a centralized server and, instead, makes a direct peer-to-peer
connection between browsers through a Session Initiation Protocol (SIP) proxy
server. The aim is to connect a WebRTC client to another WebRTC client using
SIP over WebSocket as the signaling protocol. In this chapter, we will study the
following three prime ways of making SIP WebRTC calls:
•
WebRTC to WebRTC call through a public cloud-hosted, WebRTC-capable
SIP server, such as SIP2SIP
•
WebRTC to WebRTC call through a locally hosted, WebRTC-capable SIP
server, such as OfficeSIP
•
WebRTC call to SIP phone through a WebSocket gateway and SIP server,
such as Kamailio
We will begin the chapter by describing a simple WebRTC client-server model.
Making a Standalone WebRTC Communication Client
Description of the WebRTC
client-server model
The components of a typical WebRTC SIP-based client include the following:
•
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 following diagram depicts the important components to set up a WebRTC
infrastructure:
Browser-based Client Environment
HTML 5
Based GUI
CSS
JavaScript/
jQuery
SIP stack
HTTP/ REST
WebRTC media API
Voice
Audio
Codecs
Noise
Reduction
SIP Server
Environment
Web
Server
SIP/WS
Session Management
Video
Web Server
Environment
Transport
VP8 Codec
SRTP
Video Jitter
Buffer
Multiplexing
Image
Enhancement
STUN+
TURN+ICE
.
[ 40 ]
WebRTC
GW
SIP
SIP Server
Chapter 2
The client side must be linked to a server that runs on the network side to complete
the signal flow. The components that must be deployed on the network side are
as follows:
•
The WebRTC gateway to connect to the native SIP world
•
The SIP server to embed the SIP application/proxy logic
The web browser is the key component in WebRTC transactions. It is the client-side
environment that pulls out the HTML content from a web server, interprets the
HTML tags, and displays the web page to the user. A WebRTC-capable browser has
the additional ability to access the user's input media devices, such as microphones
and camera, and stream them across the network. In the preceding diagram, there
are some key functions of WebRTC media API that are embedded in the browser.
These include codecs for audio and video, noise reduction, image enhancements,
jitter buffer, multiplexing, SRTP, ICE in STUN /TURN, and so on. The gateway is the
internetworking node between WebRTC's SIP over WebSocket side and traditional
SIP/IMS side. The traditional SIP-based network is depicted by the SIP server in the
preceding diagram.
The parts for media handling between WebRTC and non-WebRTC clients, such as
relay and transcoding, will be explained in depth in later chapters. Here, we shall
look at an infrastructure compromising of only SIP and WebRTC. For now, consider
a simple WebRTC client trying to communicate with another WebRTC client through
the browser interface. There are many SIP and WebRTC implementations available
today; we will consider sipML5 and jsSIP among these to make a simple WebRTC
client, which will communicate via an SIP server.
The sipML5 WebRTC client
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:
•
The first option is to use the online demo version available at
http://sipml5.org/call.htm
•
The second option is to make use of the minified version of the JavaScript
API and code that can be imported and loaded directly using the web server
•
The third option (recommended for integrators) is to get the developers'
version of the sipML5 master that can be checked out from GitHub and
used for development and debugging for enhanced operations
[ 41 ]
Making a Standalone WebRTC Communication 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.
Developing a minified webphone application
using Tomcat
The steps to set up a Tomcat web server are described in this section.
1. First is the installation of a web application server to host the web archive (war)
that contains the WebRTC call page. We are using Apache Tomcat Version
7.0.50 here. It can be downloaded from https://tomcat.apache.org/.
2. We must ensure that JAVA_HOME is set as an environmental variable for
Tomcat in Windows (refer to the following screenshot).
3. Start the Tomcat batch script after the preceding two steps. You will see
the following output in the console:
The code for the web page that acts like a web-based phone using WebRTC calls
(along with the explanation of various code snippets) is given as follows:
1. Start the process by making a local copy of the SIP-signaling JavaScript
file. Open an empty text file and import the sipml5-api JS library file from
http://sipml5.googlecode.com/svn/trunk/release/SIPml-api.js.
2. Write the following JavaScript functions to initialize the engine:
var readyCallback = function(e){
createSipStack();
// see next section
};
[ 42 ]
Chapter 2
var errorCallback = function(e){
// stack failed to initialize
console.error('Failed to initialize the engine:' + e.message);
}
SIPml.init(readyCallback, errorCallback);
3. The following function shows how to define event reactions when the client
has started and when a call arrives:
var eventsListener = function(e){
if(e.type == 'started'){
login();
}
else if(e.type == 'i_new_call'){
// incoming audio/video call acceptCall(e);
}
}
4. The following is the JavaScript code to start an SIP stack with parameters in
SIPml:
var sipStack;
function createSipStack(){
sipStack = new SIPml.Stack({
realm: 'sip2sip.info',
// mandatory : domain name
impi: 'altanai',
// mandatory : IMS Private Identity
impu: 'SIP:altanai@sip2sip.info',
// mandatory : IMS Public Identity
password: '/*enter sip2sip.info account password*/',
display_name: 'altanai',
websocket_proxy_url: 'wss://sipml5.org:10062',
outbound_proxy_url: 'udp://example.org:5060',
enable_rtcweb_breaker: false,
events_listener: { events: '*', listener: eventsListener },
//optional: '*' means all events
});
}
sipStack.start();
5. The declaration of the elements to make and receive a call is given as follows:
var callSession;
var makeCall = function(){
callSession = sipStack.newSession('call-audiovideo', {
video_local: document.getElementById('video-local'),
[ 43 ]
Making a Standalone WebRTC Communication Client
video_remote: document.getElementById('video-remote'),
audio_remote: document.getElementById('audio-remote'),
events_listener: { events: '*', listener: eventsListener }
});
callSession.call('johndoe');
}
6. The function definition to accept an incoming call using the sipML5 library is
given as follows:
var acceptCall = function(e){
e.newSession.accept();
// e.newSession.reject() to reject the call
}
7. Add HTML containers for local and remote videos as shown in the following
lines of code:
8. Make a folder under the webapps folder within the Tomcat folder. Name it
miniSipml5phone, place the SIPml5-API.js file, and rename the file we
created as index.html.
9. Open http://:/ in a browser to load the
web page. To test whether this code is working on the machine or not,
add http://localhost:8080/miniSipml5phone in the address bar to
load the call page.
After developing the WebRTC client and deploying it over the Application Server,
it's time to test its functions. The best way to do this is by inspecting the traces.
Use the console screen of Chrome or Firefox to see the traces of SIP requests.
The trace for an SIP stack initialization should be of the following structure.
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='', impi='altanai', impu=''
[ 44 ]
Chapter 2
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
If an exception occurs for a missing resource such as an audio, a JavaScript, or an
image file, the browser console depicts a notification for it. The following statement
is a "GIF file not found" notification:
GET http://144.55.64.89:8080/WebRTCphone/images/.gif 404 (Not Found)
We must make amendments to the HTML content that points to the correct resource
path so as to run the WebRTC client code unobstructed. In case the JavaScript file
for SIP functions is not loaded properly, the web handshake and the subsequent
communication operation will not take place.
The SIP requests and SDP can be viewed here; this can help in solving errors.
The trace for the SIP INVITE request from the WebRTC client is of the following
structure. The ICE candidates come in to play first. After this, the SIP INVITE
request for a call is generated and sent to the other user along with SDP.
ICE GATHERING COMPLETED!
onIceGatheringCompleted
SEND: INVITE SIP:testagent@sip2sip.info SIP/2.0
Via: SIP/2.0/WS df7jal23ls0d.invalid;branch=z9hG4bKSM7tGLdSUy3DpGehaPa78H
Hpvmir89Uh;rport
From: ;tag=2CEhe0X78NxVm7aRCaBa
To:
Contact: "undefined"
Call-ID: 16a15a79-e4a6-78a1-2310-1243ebafe826
[ 45 ]
Making a Standalone WebRTC Communication Client
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 SDP and SIP traces shown here are modified to depict only
the important headers. Many other headers have been removed
from traces for clarity.
Now that we have gained a bit of insight into WebRTC code components,
let's use this to develop the complete JavaScript of the sipML5 library and
constitute a dynamic web project, which will be later used to embed the logic
of other features such as phonebook, call logs, voicemail, and user profile.
Developing our customized version of the
sipML5 client
This section describes the process of building our own customized WebRTC client.
It is built over the SIP library, WebRTC API, and the web-based Graphical User
Interface (GUI) to enable the user to make and receive calls. The following steps
outline the process of creating a customized WebRTC client using Dynamic Project
wizard of Eclipse. This differs from the earlier approach, in which we were using the
web-deployed sipML5 WebRTC web page.
[ 46 ]
Chapter 2
Once we set up our own sipML5 web project, it is easy to make changes in the
configurations and user interface.
1. Download sipML5-master from GitHub (refer to https://github.com/
sipml5). Unzip and extract the folder.
2. Make an empty, dynamic, web project in Eclipse. Let's assume that the name
of the project is WebRTCSimpl5.
3. Copy the files under the release folder into the WebContent folder of Eclipse.
Now, the project explorer should look like the following screenshot:
4. Run call.htm on any web server such as Tomcat. Tomcatv7.0 is used on
the localhost.
[ 47 ]
Making a Standalone WebRTC Communication Client
5. Open the web page in a web browser that supports WebRTC. We must add
our SIP credentials on this page for the server to register the WebRTC SIP
client. An SIP client registration requires the authentication name, SIP URI,
password, and domain name fields to be specified at the time of registration.
The following screenshot shows the call.htm page that runs from the local
Tomcat web server:
6. Open the expert.htm page by clicking on the Expert mode? button. When
using a public server such as iptel or SIP2SIP, the domain name entered
in the registration section is enough to locate the server and connect the
client with it. However, for self-configured servers, the server address
of the WebSocket server must be entered in the WebSocket server URL
field. For example, if the WebSocket SIP server is installed on the machine
with IP 97.54.67.12 and the ws port is 443, then the ws URL will be
ws://97.54.67.12:443. The following screenshot shows the Expert.htm
page, where the server parameters are entered when the page is run from the
local Tomcat web server:
[ 48 ]
Chapter 2
Expert.htm page, where server parameters are entered while the page is run from local Tomcat web server
7. Register the client with the SIP server by clicking on the Register button.
The browser console can be monitored at this stage; the console depicts the
registration SIP request being generated and sent to the SIP server.
Check browser console traces to find out any server errors of components
and missing exceptions on the web page.
Similarly, a jsSIP WebRTC client can also be configured to use a WebRTC-supported
SIP server.
The jsSIP WebRTC client
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:
•
The first option is to use the online demo of the jsSIP WebRTC client that can
be found at http://tryit.jssip.net/.
•
The second option is to use the minified version of the jsSIP JavaScript API,
and the code.
•
The third option is to get the developer's version of the jsSIP master from
GitHub and use it for development and debugging.
[ 49 ]
Making a Standalone WebRTC Communication Client
Developing our version of the jsSIP client
To integrate the SIP WebRTC functionality into an existing web application, it is
required that you develop the WebRTC client from basic components so that it can be
customized later. We can perform the following steps to make a Dynamic Web Project
of the jsSIP WebRTC client using Eclipse Wizard, similar to the sipML5 project:
1. Download jsSIP-demo-master from GitHub (http://jssip.net/
download/) and unzip it.
2. Make an empty dynamic web project in Eclipse. Let's assume that we name it
WebRTCJssip.
3. Copy the files into WebContent of the project in Eclipse. The project explorer
should look like the following screenshot:
4. Open the index.html file to add the reference to the latest jssip-0.3.0.js
library file using the following line of code:
[ 50 ]
Chapter 2
5. Instantiate the following config parameters now or add them later:
$(document).ready(function(){
// Default settings.
var default_SIP_uri = "jmillan@jssip.net";
var default_SIP_password = '';
var outbound_proxy_set = {
host: "tryit.jssip.net:10080",
WS_path:'WS',
WS_query: 'wwdf'
};
JSsipPhone = new JsSIP.UA(configuration);
6. Use the existing event definition or add your own under the existing
function's body. The event definition is as follows:
//WebSocket connection events
JSsipphone.on('connected', function(e){ });
JSsipphone.on('disconnected', function(e){ });
//New incoming or outgoing call event
JSsipphone.on('newRTCSession', function(e){ });
//New incoming or outgoing IM message event
JSsipphone.on('newMessage', function(e){ });
//SIP registration events
JSsipphone.on('registered', function(e){ });
JSsipphone.on('unregistered', function(e){ });
JSsipphone.on('registrationFailed', function(e){ });
7. The following functions describe how to make an outgoing or receive an
incoming audio/video call. Use the existing function calls to add your
Graphical User Interface (GUI) response with the help of CSS and jQuery,
such as show remote and local video captured in the video div and print
console info traces for tracing.
8. The following are the HTML5 elements in which local and remote
videos will be shown:
var selfView = document.getElementById('my-video');
var remoteView = document.getElementById('peer-video');
[ 51 ]
Making a Standalone WebRTC Communication Client
9. Register callbacks to the desired call events using the following lines of code:
var eventHandlers = {
'progress':
function(e){ },
'failed':
function(e){ },
'started':
function(e){
var rtcSession = e.sender;
10. Attach local stream to selfView using the following lines of code:
if (rtcSession.getLocalStreams().length > 0) {
selfView.src = window.URL.createObjectURL(
rtcSession.getLocalStreams()[0]);
}
11. Attach remote stream to remoteView using the following lines of code:
if (rtcSession.getRemoteStreams().length > 0) {
remoteView.src = window.URL.createObjectURL(
rtcSession.getRemoteStreams()[0]);
}},
'ended': function(e){ /* Your code here */ }
};
var options = {
'eventHandlers': eventHandlers,
'extraHeaders': [ 'X-Foo: foo', 'X-Bar: bar' ],
'mediaConstraints': {'audio': true, 'video': true}
};
JSsipPhone.call('SIP:bob@somedomain.com', options);
12. The event handlers for messages are similar to the event handlers for a call.
To send or receive messages, use the existing function calls to add your
GUI responses, such as open a new window or show an alert on successful
sending of messages using the following lines of code:
var text = 'Hello';
// Register callbacks to desired message events
var eventHandlers = {
'succeeded': function(e){ },
'failed': function(e){ };
};
var options = {
'eventHandlers': eventHandlers
};
JSsipPhone.sendMessage('SIP:bob@somedomain.com', text, options);
[ 52 ]
Chapter 2
13. Run index.html that contains the phone elements and uses the jsSIP call
functions on any web server, such as JBoss or Apache.
14. Open the web page in the Google Chrome or Firefox web browser.
15. Register the client with SIP server-supporting WebSockets, such as Kamailio,
or use a WebSocket gateway as OverSIP.
16. Monitor the WebRTC client traces on Wireshark.
In a similar fashion, other SIP stacks can also be integrated with WebRTC media
APIs to make a ready script to make and receive WebRTC calls over SIP.
The SIP stack can also be a proprietary C code or adopted from
freely available version of the Internet. JavaScript will aim to invoke
the functions from an HTML-based web page. WebRTC browser
media APIs will provide a way to capture and route the media.
SIP servers
The WebRTC client with an SIP stack can be registered and can send an invitation
or give answers through an SIP server. The SIP server might or might not have the
support for WebSocket. This categorization can be understood in two parts:
•
This part consists of a WebRTC-compliant SIP server, and the caller
and receiver are both on SIP over WebSocket (SIP WS to SIP WS).
The WebRTC-compliant SIP server can belong to one of the following
two categories:
°°
Using open public domains (such as SIP2SIP, JSSIP Tryit Server,
or sipML5.org). This is demonstrated in the following diagram:
Internet
Web-based SIP
server(SIP2SIP.info)
WebRTC Client
dynamic web
Project
WS SIP
WS SIP
Webrtc Client
dynamic web
Project
WebRTC client on local machine and web-based SIP server such as SIP2SIP.info
[ 53 ]
Making a Standalone WebRTC Communication Client
°°
Using locally hosted WebRTC-compatible SIP server (OfficeSIP).
This is demonstrated in the following diagram:
Local hosted SIP
server (officeSIP)
WS SIP
WS SIP
WebRTC client
WebRTC client
Web-based WebRTC client and local installed / configured SIP server
•
This part consists of a simple SIP server that does not respond to SIP over
WebSocket, but only to SIP (Sip WS to Sip). This server can belong to one
of the following two categories:
°°
Using the WebRTC2sip gateway as an inter-conversion node between
SIPWS and SIP. This enables the WebRTC client to connect with a
legacy SIP server (such as Bea WebLogic, Rhino Telecom Application
Server, and Brekeke), which does not have support for WebSocket
yet. The OverSIP gateway also achieves the same goal. This
architecture is diagrammatically represented as follows:
Webrtc2sip gateway
(webrtc2sip)
WebRTC Client
dynamic web
project
sip
WS SIP
SIP server
(bea weblogic)
SIP
WebRTC client on one and SIP phone on another
SIP server that does not understand SIP over WebSocket
communicates to one another using webrtc2sip gateway
[ 54 ]
Native SIP
client
Chapter 2
°°
If we implement a Telecom Server with both WebSocket and SIP
support, then the traditional SIP clients and WebRTC clients can
connect to each other without the use of any external gateway.
This is due the fact that the server itself does the conversion
between the SIPWS and SIP protocols as and when a request arrives.
Kamailio, FreeSwitch, and Mobicents are some of the open source
SIP servers of this nature. This architecture is diagrammatically
represented as follows:
SIP server
(Kamailio)
WS SIP
WebRTC client
SIP
media
SIP client
WebRTC client communicating with SIP client through SIP server
that also acts as SIP-WebSockets to SIP convertor
SIP-WS to SIP-WS
This section describes a SIP-WS to SIP-WS call, which involves making a call from
the WebRTC client to another WebRTC client using SIP over WebSocket as the
signaling protocol. To begin this task, we can use either the online-hosted demo
WebRTC-enabled projects of sipML5/jsSIP, or the self-compiled source code on the
local machine, as seen in the first part of this chapter. In addition to this, we must
set up a WebRTC server to provide signaling. The signaling can be in any of the
following 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
[ 55 ]
Making a Standalone WebRTC Communication Client
SIP2SIP
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:
1. To register the client with the SIP2SIP SIP server, make an account at
https://mdns.sipthor.net/register_sip_account.phtml
2. Log in with the credentials. On the home page, click on the Identity
tab to view your public address and outbound proxy, as shown in
the following screenshot:
The SIP2SIP Internet-based account page
3. Go to our WebRTC client, leave the expert.htm page empty, and enter
values into the call.htm page directly. The following screenshot shows
the registration fields of the call.htm page to be registered with SIP2SIP:
4. Click on the Login button to register with the server. Successful registration
will be indicated by the connected status on the web page.
[ 56 ]
Chapter 2
OfficeSIP
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:
1. Download the OfficeSIP server msi file from http://www.officesip.com.
It is free for academic use. Click on the Next button on successive windows
to proceed with the installation of the OfficeSIP software.
2. Start the admin console .exe file from the installation directory or the
shortcut icon that gets created during the installation or can be seen on the
Windows start menu. Alternatively, go to http://localhost:5060/admin/.
3. Add Domain Name from the Domain tab. Add users to the domain from the
.csv File tab under USERS, as shown in the following screenshot:
[ 57 ]
Making a Standalone WebRTC Communication Client
4. Register the WebRTC clients with the OfficeSIP server and make calls.
5. In the earlier example, we made use of a simple browser console debug
logfile to see the SIP transaction. The following screenshot shows Wireshark
traces for the OfficeSIP server. This is used to view the incoming and
outgoing data packets:
SIP WS to SIP and vice-versa
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:
[ 58 ]
Chapter 2
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.
The gateway to convert SIP over WebSocket
to native SIP
There can be custom-built or open source SIPWS to SIP gateways. To be able to
communicate with these SIP servers, we need to first use a WebRTC to SIP gateway,
such as WebRTC2sip or OverSIP.
The WebRTC2SIP gateway
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:
•
SIP proxy is used to convert the SIP transport from WebSocket protocol to
UDP, TCP, or TLS; these are supported by all legacy networks
•
RTCWeb Breaker is used to negotiate and convert the media stream to allow
SIP legacy endpoints and WebRTC clients to interoperate
•
Media coder is for interoperability between different codecs supported by
different endpoints
[ 59 ]
Making a Standalone WebRTC Communication Client
The following diagram shows the overall functioning of the WebRTC to SIP gateway:
Video
SIP over
WebSocket
SIP WS
Audio Codec
HTML5-based GUI
SIP
PROXY
Noise
Reduction
CSS
SIP
ICE
Video
DTLS/SRTP
VP8 Codec
SRTCP-FB
JavaScript
RTP
RTC Web
Breaker
Video Jitter
Buffer
WebRTC media
Image
Enhancement
Hosted on
Apache Tomcat
Web server
media
Codecs
SIP UDP ,
TCP, TLS
SIP
server
opus, G.711, G.722 media
...
opus, G.711
VP8, H.264
RTCP
Media
Coder
GSM, AMR, G.729,
Speex , UBC
VP8, H.264, H.263
Theora, MP4V-ES
WebRTC to SIP gateway
WebRTC client
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:
web Browser
webrtc2sip
SIP-legacy Network
SIP-legacy endpoint
REGISTER F1
REGISTER F2
200 OK F3
200 OK F4
INVITE F5
INVITE F6
100 Trying F7
INVITE F8
200 OK F9
200 OK F10
200 OK F11
RTCWeb Media
Legacy Media
[ 60 ]
Chapter 2
The steps for the installation of the WebRTC2sip gateway are described as follows:
1. The source code for webrtc2sip can be downloaded from
http://WebRTC2sip.org/ or by executing the following svn checkout
statement from the terminal window:
svn checkout http://WebRTC2sip.googlecode.com/svn/trunk/
WebRTC2sip-read-only
After this, follow the technical guide in the document folder.
2. The WebRTC2sip gateway depends on Doubango IMS Framework v2.0.
Therefore, to configure the WebRTC2sipgateway, we first need to install
the Doubango IMS framework by running the following command line
in the command prompt:
svn checkout http://doubango.googlecode.com/svn/branches/2.0/
doubango doubango
3. Also, we need to install some mandatory and optional libraries such as the
following ones:
°°
libsrtp for SRTP
°°
openSSL for WSS
°°
libspeex and libspeexdsp (these are audio codecs)
°°
YASM to enable VPX (VP8 video codec) or x264 (H.264 codec)
°°
libvpx ,libyuv provide support for video calls
°°
libopus for Opus audio codec
°°
libgsm for GSM based audio codecs
°°
g729, iLBC for G.729, and iLBC audio codecs
°°
x264, FFmpeg for H.263, H.264, and MP4V-ES video codecs
4. Build and install Dubango using the following command lines:
cd doubango && ./autogen.sh && ./configure --with-ssl --with-srtp
--with-vpx --with-yuv
--with-amr --with-speex --with-speexdsp --with-gsm --with-ilbc
--with-g729 --with-ffm
--with- ffm-peg
make && make install
[ 61 ]
Making a Standalone WebRTC Communication Client
The following screenshot shows how Dubango IMS is installed to support
libraries for the WebRTC2sip gateway:
[ 62 ]
Chapter 2
5. Build and install the WebRTC2sip gateway using the following
command lines:
export PREFIX=/opt/WebRTC2sip
cd WebRTC2sip && ./autogen.sh && ./configure --prefix=$PREFIX
make clean && make && make install
[ 63 ]
Making a Standalone WebRTC Communication Client
6. The gateway is configured using the following XML file named config.xml,
and it is stored in the same folder where the gateway is running:
ERROR
udp;*;10060
WS;*;10060
wss;*;10062
vga
65535
sdes;dtls
opus;pcma;pcmu;gsm;vp8;h264-bp;h264-mp;h263;h263+
The file specifies the ports for transport protocols. It also specifies the
preference for video size and codecs supported, among others.
7. Register the WebRTC client with the WS:// address that contains the
WebRTC2sip gateway. To make the interaction of our WebRTC client with
the SIP server without WebSocket support (in our case, Brekeke), we will use
a WebRTC to SIP gateway.
The WebRTC client with Brekeke SIP server
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:
1. Download and run Brekeke on a Windows machine
(refer to http://www.brekeke.com/downloads/sip-server.php).
[ 64 ]
Chapter 2
2. Configure the Brekeke SIP server through the admin console in the local
network/machine. Register the X-Lite phone through the Brekeke SIP
registrar, as shown in the following screenshot:
3. Register the WebRTC client through the WebRTC2sip server to the Brekeke
SIP server as well.
Enter the address of the WebRTC2sip gateway machine in the WS server
input box of the Expert settings page, for example, WS://115:90:56:4:443.
Enter the address of the SIP server machine that runs Brekeke in the
outbound proxy input box of the Expert settings page, for example,
udp://117:67:45:2:5060.
4. Run and test the X-Lite call to the WebRTC client using the WebRTC2sip
gateway and SIP server.
[ 65 ]
Making a Standalone WebRTC Communication Client
The WebRTC client with the Kamailio SIP server
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:
•
Git client
•
Gcc compile
•
Flex
•
Bison
•
Make
•
Libxlm2
Now, perform the following steps to install the Kamailio SIP server:
1. The first step to configure the Kamailio SIP server is to get the source, its
compilation, and its installation. We should create a directory on the file
system, where the sources will be stored, using the following command line:
mkdir -p /usr/local/src/kamailio-4.0
2. We can download the sources from GIT using the following command lines:
git clone git://git.SIP-router.org/SIP-router kamailio
cd kamailio
git checkout -b 4.0 origin/4.0
3. Generate the config files for the build system using the following command:
make cfg
4. The next step is to enable the MySQL module. For this, edit the modules.lst
file and add db_mysql to the variable include_modules as follows:
include_modules= db_mysql
[ 66 ]
Chapter 2
5. Once you add the mysql module to the list of enabled modules, you can now
compile and install it using the following commands:
make all
make install
You might get error messages in between the installation if some
prerequisites were not installed. If so, just install these using yum install.
The following screenshot shows the execution of the Kamailio make all and
make install commands after the GIT checkout:
6. The next step is to set the path to the installation directories. So, before we
proceed further, let's have a look at the root directories and other installed
paths. The binaries to execute Kamailio and add or delete users are installed
inside the sbin folder of the Kamailio installation directory. These binaries
are as follows:
°°
kamailio: This is the Kamailio SIP server
°°
kamdbctl: This is the script to create and manage the databases
[ 67 ]
Making a Standalone WebRTC Communication Client
°°
kamctl: This is the shell script to manage and control the Kamailio
°°
sercmd: This is the command line tool to interface with the
SIP server
Kamailio SIP server
The configuration files can be found inside the etc folder of the installation
directory. Kamailio modules are installed inside the module, modules_k, and
modules_s folders. One must ascertain that the installation path for modules
match those inside the config files so that Kamailio doesn't yield an error
when it starts or, at the worst, at runtime. The following screenshot shows
the content of the sbin folder:
[ 68 ]
Chapter 2
7. To configure the Kamailio SIP server as per out environment needs,
we must edit the config files. We have to add the IP address of the server
in the kamailio.cfg file. Add the following lines to kamailio.cfg,
if not already present:
#!define WITH_DEBUG
#!define WITH_MYSQL
#!define WITH_AUTH
#!define WITH_ALIASDB
#!define WITH_USRLOCDB
#!define WITH_PRESENCE
#!define WITH_XCAPSRV
#!define WITH_RLS
#!define WITH_XMLRPC
#!define WITH_TLS
#!define WITH_MULTIDOMAIN
#!define WITH_WEBSOCKETS
#!define WITH_REGINFO
Make sure that the following line regarding the SIP domain is uncommented
in the kamctlrc file:
SIP_DOMAIN=
The database type can be MYSQL, PGSQL, ORACLE, DB_BERKELEY,
DBTEXT, or SQLITE, by default, none is loaded. Also, one has to specify
the database host, database name, user, and password.
DBENGINE=MYSQLs
DBHOST=localhost
DBNAME=kamailio
DBRWUSER="kamailio"
DBRWPW="kamailiorw"
DBROUSER="kamailioro"
DBROPW="kamailioro"
ALIASES_TYPE="DB"
8. In the next step, we will cover the process of adding more modules to the
existing setup. We must use the make and configure commands for this
purpose. Once the .so file is created, copy it to the folder where modules
are installed.
[ 69 ]
Making a Standalone WebRTC Communication Client
9. In the next and most crucial step, we must create the MySQL Kamailio
database. To create the MySQL database, we have to use the database
setup script. First, edit the kamctlrc file to set the database server type.
Locate the DBENGINE variable and set it to MYSQL as follows:
DBENGINE=MYSQL
10. Once we are done updating the kamctlrc file, run the following script to
create the database used by Kamailio. We can find kamdbctl inside the
sbin folder of the installation directory.
# ./kamdbctl create
The preceding script will add two users in MySQL:
°°
kamailio (with the default password as kamailiorw): This user has
full access rights to the kamailio database
°°
kamailioro (with the default password as kamailioro): This user
has read-only access rights to the kamailio database
We can check the database created inside MySQL using the show database
and show tables commands of MySQL.
11. To start Kamailio, go to sbin inside the Kamailio installation directory and
run the following command:
./kamailio start
[ 70 ]
Chapter 2
12. To add users to the database, use the kamctl command as follows:
./kamctl add
13. Register the WebRTC clients with Kamailio by adding user details and
domain information in the call.htm registration section. Add the address of
the machine as ws://ip:port, for example, ws://10.34.65.98.443, under
the WS server input box on the register.htm page. The status displayed on
the call.htm page should read Connected.
14. Register another user, and one can make multiple calls between them.
[ 71 ]
Making a Standalone WebRTC Communication Client
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:
[ 72 ]
Chapter 2
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:
[ 73 ]
Making a Standalone WebRTC Communication Client
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.
Limitations of the existing setup
We saw how to develop a WebRTC client, install an SIP server, and configure a
WebRTC to SIP environment. A sky view of our final, existing client-server solution
setup for SIPWS signaling and WebRTC media so far is shown as follows:
SIP server as proxy
SIP WS
SIP WS
Media
WebRTC client
(depicted here sipML5))
webrtc client
(depicted here sipml5))
Signalling SIP over WebSockets, media P2P
or
WebRTC
compliant SIP
softphone
(iDoubs)
As per our current setup status, only the WebRTC-enabled client and servers can
participate in the communication flow in an offer/answer (O/A) model.
There are, however, numerous limitations of the existing solution, some of which
are mentioned in the following sections. In the upcoming chapters, we shall do away
with most of the limitations.
[ 74 ]
Chapter 2
Firewall and NAT issues
The existing architecture does not provide the Network Address Translation (NAT)
technique to overcome the blockage due to firewalls and enterprise policies. As a
solution, we must see the alternative for public IP discovery in the WebRTC client
server setup. NAT is possible in the Kamailio server through RTP proxy modules
and STUN.
Media transcoding
If the codecs on two endpoints do not match for audio and video communication,
then it could lead to a session failure with an abrupt termination of calls when a user
picks up a ringing call. There is where the media transcoder is required to support
communication with non-WebRTC devices such as SIP phone and softphones.
As a solution, we can either use the RTCWeb Breaker, which converts SDP and
media streams for WebRTC and other UAs, or configure the media server such as
FreeSWITCH, which provides the functionality. The following diagram shows the
complete architecture with the STUN server and RTCWeb Breaker:
SIP
WebRTC
Client
SIP
Kamailio
RTP/SAVPF
STUN
Control
Protocol
RTCweb
Breaker
STUN
Server
[ 75 ]
Non-WebRTC
Client
RTP/SAVP
or
RTP/AVP
Making a Standalone WebRTC Communication Client
A call flow that depicts the flow of media from the WebRTC client to the nonWebRTC client (SIP phone) through the RTCWeb Breaker is shown as follows:
Call flow with Media Transcoder to connect WebRTC and non-WebRTC endpoints
Real time-Transport Protocol (RTP), which is the media flow mechanism in most
SIP clients, including SIP-based WebRTC, comprises two parts: the RTP data transfer
protocol and the RTP Control Protocol (RTCP). In addition to this, WebRTC also
mandates the use of Secure RTP Profile (RTP/SAVP) for RTCP-based feedback.
An RTP profile defines media parameters such as compression and encoding.
The RTP/SAVPF profile, as depicted in the following diagram, is the
combination of the basic RTP/AVP profile, the RTP profile for RTCP-based
feedback (RTP/AVPF), and the RTP/SAVP. The RTCP-based feedback extensions
are needed for the improved RTCP timer that enables features such as more flexible
transmission and report of congestion.
[ 76 ]
Chapter 2
After fulfilling the limitations, there are some recommended enhancements in the
existing architecture; they contribute to making a robust, secure communication
platform. The limitations are described as follows:
•
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.
HTTP
Tomcat web server
SIP WS
HTTP
Kamailio SIP server
as proxy
SIP WS
media (SRTP)
Media Relay and
transcoding
WebRTC client
(depicted here sipML5))
WebRTC client
(depicted here sipML5)
Signaling SIP over WebSockets till proxy SIP server Kamilio,
SIP services(call screening, call waiting, call forwarding) at telecom application server
RTP media P2P
•
Ipv4 and Ipv6 must be supported.
[ 77 ]
or
WebRTCcompliant SIP
softphone
(iDouts)
Making a Standalone WebRTC Communication Client
•
The Telecom Application server is needed to embed the logic of SIP services
such as call waiting, call forwarding, and call screening.
HTTP
HTTP
Tomcat web server
Telecom Application
server(CS,CF,CW)
SIP WS
SIP WS
Kamailio SIP server
as proxy
SIP WS
media
WebRTC client
(depicted here sipML5))
WebRTC client
(depicted here SipML5))
or
Signaling SIP over WebSockets till proxy SIP server Kamilio,
SIP services(call screening, call waiting, call forwarding) at telecom application server
media P2P
WebRTCcompliant SIP
softphone
(iDouts)
•
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.
We will overcome these and a few more limitations when integrating with the IP
Multimedia Subsystem (IMS) environment. They will be discussed in detail in the
next chapter.
[ 78 ]
Chapter 2
Summary
In this chapter, we learned how to make a dynamic web application for the WebRTC
client using primitive building blocks such as CSS, JavaScript, SIP library, and
HTML form elements. We also saw the setup of various kinds of SIP servers and
their applicability in establishing an end-to-end call. In this process, we studied the
implementation of WebSocket-supported SIP servers. We also studied the integration
of the SIP WebRTC client with non-WebSocket supported SIP servers, through
WebSocket gateways.
In essence, we learned about how client development and essential servers help
to support the WebRTC SIP infrastructure. This includes the Tomcat web server,
which caters to the loading of a web page and the HTTP handshake; the Kamailio
SIP server, which acts as a registrar; and the SIP proxy node. The WebRTC client
programs used open source libraries such as jsSIP and sipML5. The interaction and
challenges inherent in communication between non-WebRTC sip endpoints, such as
SIP phones and softphone, were also discussed.
[ 79 ]
WebRTC with SIP and IMS
IP Multimedia Subsystem (IMS) is an architectural framework for IP Multimedia
communications and IP telephony based on Convergent applications. It specifies
three layers in a telecom network:
•
Transport or Access layer: This is the bottom-most segment responsible for
interacting with end systems such as phones.
•
IMS layer: This is the middleware responsible for authenticating and routing
the traffic and facilitating call control through the Service layer.
•
Service or Application layer: This is the top-most layer where all of the call
control applications and Value Added Services (VAS) are hosted.
IMS standards are defined by Third Generation Partnership Project (3GPP)
which adopt and promote Internet Engineering Task Force (IETF) Request for
Comments (RFCs). Refer to http://www.3gpp.org/technologies/keywordsacronyms/109-ims to learn more about 3GPP IMS specification releases.
This chapter will walk us through the interaction of WebRTC client with important
IMS nodes and modules. The WebRTC gateway is the first point of contact for the
SIP requests from the WebRTC client to enter into the IMS network. The WebRTC
gateway converts SIP over WebSocket implementation to legacy/plain SIP, that is,
a WebRTC to SIP gateway that connects to the IMS world and is able to communicate
with a legacy SIP environment. It also can translate other REST- or JSON-based
signaling protocols into SIP. The gateway also handles the media operation that
involves DTLS, SRTP, RTP, transcoding, demuxing, and so on.
In the previous chapter, we saw how to create the WebRTC environment using
the SIP server that has WebSocket capabilities. In this chapter, we will study a case
where there exists a simple IMS core environment, and the WebRTC clients are
meant to interact after the signals are traversed through core IMS nodes such as
Call Session Control Function (CSCF), Home Subscriber Server (HSS), and
Telecom Application Server (TAS).
WebRTC with SIP and IMS
The Interaction with core IMS nodes
This section describes the sequence of steps that must be followed for the integration
of the WebRTC client with IMS. Before you go ahead, set up a Session Border
Controller (SBC) / WebRTC gateway / SIP proxy node for the WebRTC client
to interact with the IMS control layer.
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 setup will allow us to support all SIP nodes and endpoints as part of the IMS
landscape. We will follow the interaction of the WebRTC SIP client with IMS nodes,
assuming that the SIPWS to SIP gateway is configured, as described in Chapter 2,
Making a Standalone WebRTC Communication Client.
The following figure shows the placement of the SIPWS to SIP gateway in the
IMS network:
WebRTC
Client
WebRTC Server
HSS
P/I/S-CSCF
SIP WS to
SIP
gateway
SBC
[ 82 ]
IMS Network
Chapter 3
The WebRTC client is a web-based dynamic application that is run over a Web
Application Server. For simplification, we can club the components of the WebRTC
client and the Web Application Server together and address them jointly as the
WebRTC client, as shown in the following diagram:
WebRTC
Client
HTTP
WebRTC Web APP
server
=
WebRTC client
There are four major components of the OpenIMS core involved in this setup
as described in the following sections. Along with these, two components of the
WebRTC infrastructure (the client and the gateway) are also necessary to connect the
WebRTC endpoints. Three optional entities are also described as part of this setup.
The components of Open IMS are CSCF nodes and HSS. More information on each
component is given in the following sections.
The Call Session Control Function
The three parts of CSCF are described as follows:
•
Proxy-CSCF (P-CSCF) is the first point of contact for a user agent (UA) to
which all user equipments (UEs) are attached. It is responsible for routing
an incoming SIP request to other IMS nodes, such as registrar and Policy
and Charging Rules Function (PCRF), among others.
•
Interrogating-CSCF (I-CSCF) is the inbound SIP proxy server for querying
the HSS as to which S-CSCF should be serving the incoming request.
•
Serving-CSCF (S-CFCS) is the heart of the IMS core as it enables centralized
IMS service control by defining routing paths that act like the registrar,
interact with the Media Server, and much more.
Home Subscriber System
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.
[ 83 ]
WebRTC with SIP and IMS
The components of the WebRTC infrastructure primarily comprises of WebRTC Web
Application Servers, WebRTC web-based clients, and the SIP gateway.
•
WebRTC Web Application Server and client: The WebRTC client is
intrinsically a web application that is composed of user interfaces, data access
objects, and controllers to handle HTTP requests. A Web Application Server
is where an application is hosted. As WebRTC is a browser-based technique,
it is meant to be an HTML-based web application. The call functionalities
are rendered through the SIP JavaScript files. The browser's native WebRTC
capabilities are utilized to capture and transmit the data. A WebRTC service
provider must embed the SIP call functions on a web page that has a call
interface. It must provide values for the To and From SIP addresses, div to
play audio/video content, and access to users' resources such as camera,
mic, and speakers.
•
WebRTC to IMS gateway: This is the point where the conversion of the
signal from SIP over WebSockets to legacy/plain SIP takes place. It renders
the signaling into a state that the IMS network nodes can understand. For
media, it performs the transcoding from WebRTC standard codecs to others.
It also performs decryption and demux of audio/video/RTCP/RTP.
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:
•
STUN/TURN Server: These are employed for NAT traversals and
overcoming firewall restrictions through ICE candidates. They might not be
needed when the WebRTC client is on the Internet and the WebRTC gateway
is also listening on a publicly accessible IP.
•
Media Server: Media server plays a role when media relay is required
between the UEs instead of a direct peer-to-peer communication. It also
comes into picture for services such as voicemail, Interactive Voice
Response (IVR), playback, and recording.
•
Application Server (AS): Application Server is the point where developers
can make customized logic for call control such as VAS in the form of call
redirecting in cases when the receiver is absent and selective call screening.
[ 84 ]
Chapter 3
The IP Multimedia Subsystem core
IMS is an architecture for real-time multimedia (voice, data, video, and messaging)
services using a common IP network. It defines a layered architecture. According
to the 3GPP specification, IMS entities are classified into six categories:
•
Session management and route (CSCF, GGSN, and SGSN)
•
Database (HSS and SLF)
•
Interworking elements (BGCF, MGCF, IM-MGW, and SGW)
•
Service (Application Server, MRFC, and MRFP)
•
Strategy support entities (PDF)
•
Billing
Interoperability with the SIP infrastructure requires a session border controller
to decrypt the WebRTC control and media flows. A media node is also set up for
transcoding between WebRTC codecs and other legacy phones. When a gateway
is involved, the WebRTC voice and video peer connections are between the browser
and the border controller. In our case, we have been using Kamailio in this role
(refer to Chapter 2, Making a Standalone WebRTC Communication Client). Kamailio
is an open source SIP server capable of processing both SIP and SIPWS signaling.
As WebRTC is made to function over SIP-based signaling, it is applicable to enjoy all
of the services and solutions made for the IMS environment. The telecom operators
can directly mount the services in the Service layer, and subscribers can avail the
services right from their web browsers through the WebRTC client. This adds a new
dimension to user accessibility and experience. A WebRTC client's true potential will
come into effect only when it is integrated with the IMS framework.
We have some readymade, open IMS setups that have been tested for
WebRTC-to-IMS integration. The setups are as follows:
•
3GPP IMS: This is the IMS specification by 3GPP, which is an association
of telecommunications group
•
OpenIMS: This is the open source implementation of the IMS CSCFs
and a lightweight HSS for the IMS core
•
DubangoIMS: This is the cross-platform and open source 3GPP IMS/LTE
framework
•
KamailioIMS: Kamailio Version 4.0 and above incorporates IMS support
by means of OpenIMS
[ 85 ]
WebRTC with SIP and IMS
We can also use any other IMS structure for the integration. In this chapter, we
will demonstrate the use of OpenIMS. For this, it is required that a WebRTC client
and a non-WebRTC client must be interoperable by means of signaling and media
transcoding. Also, the essential components of IMS world, such as HSS, Media
Server, and Application Server, should be integrated with the WebRTC setup.
The OpenIMS Core
The Open IMS Core is an open source implementation for core elements of the IMS
network that includes IMS CSCFs nodes and HSS. The following diagram shows
how a connection is made from WebRTC to CSCF:
IMS network Core
HSS
Cx
Cx
Mw
I-CSCF
Mw
S-CSCF
Mw
P-CSCF
SIP
SIP
WebRTC IM $gateway
SIP WS
WebRTC
Client
HTTP
[ 86 ]
VoIP client
WebRTC Web APP
server
Chapter 3
The following are the prerequisites to install the Open IMS core:
•
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:
[ 87 ]
WebRTC with SIP and IMS
The following are the steps to install OpenIMS. As the source code is preconfigured
to work from a standard file path of /opt, we will use the predefined directory
for installation.
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 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:
[ 88 ]
Chapter 3
By default, the nodes are configured to work only on the local loopback, and the
default domain configured is open-ims.test. The MySQL access rights are also
set only for local access. However, this can be modified using the following steps:
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";
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
[ 89 ]
WebRTC with SIP and IMS
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:8080 and log in to the web console with
hssAdmin as the username and hss as the password as shown in the
following screenshot.
[ 94 ]
Chapter 3
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.
The subscribers are visible in the IMS subscription section of the portal of OpenIMS.
The following screenshot shows the user identities and their statuses on a web-based
admin console:
As far as other components are concerned, they can be subsequently added to
the core network over their respective interfaces. We can study the integration
of Policy Control Resource Function, Application Server, Media Server, and other
vital components in Chapter 7, WebRTC with Industry Standard Frameworks.
[ 95 ]
WebRTC with SIP and IMS
The Telecom server
The TAS is where the logic for processing a call resides. It can be used to add
applications such as call blocking, call forwarding, and call redirection according to
the predefined values. The inputs can be assigned at runtime or stored in a database
using a suitable provisioning system. The following diagram shows the connection
between WebRTC and the IMS Core Server:
IMS network Core
Sh
Telelom
Application Server
HSS
Cx
Cx
ISc
Mw
I-CSCF
Mw
S-CSCF
Mw
P-CSCF
SIP
SIP
WebRTC IM $gateway
SIP WS
VoIP client
WebRTC Client
For demonstration purposes, we can use an Application Server that can host SIP
servlets and integrate them with IMS core.
The Mobicents Telecom Application Server
Mobicents SIP Servlet and Java APIs for Integrated Networks-Service Logic
Execution Environment (JAIN-SLEE) are open platforms to deploy new call
controller logic and other converged applications. The steps to install Mobicents
TAS are as follows:
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
[ 96 ]
Chapter 3
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
[ 97 ]
WebRTC with SIP and IMS
6. In order to deploy Resource Adaptors, enter:
ant -f resources//build.xml deploy
7. To undeploy the resource adapters, execute ant undeploy with the name of
the resource adapter:
ant -f resources//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//build.xml deployall
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.
[ 98 ]
Chapter 3
With the introduction of TAS, it is now possible to provide customized call control
logic to all subscribers or particular subscribers. The SIP solution and services can
range from simple activities, such as call screening and call rerouting, to a complex
call-handling application, such as selective call screening based on the user's
calendar. Some more examples of SIP applications are given as follows:
•
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.
These services are often referred to as VAS, which can be innovative and can take the
user experience to new heights.
The Media Server
To enable various features such as Interactive Voice Response (IVR), record
voice mails, and play announcements, the Media Server plays a critical role. The
Media Server can be used as a standalone entity in the WebRTC infrastructure or
it can be referenced from the SIP server in the IMS environment.
The FreeSWITCH Media Server
FreeSWITCH has powerful Media Server capabilities, including those for functions
such as IVR, conferencing, and voice mails. We will first see how to use FreeSWITCH
as a standalone entity that provides SIP and RTP proxy features.
Let's try to configure and install a basic setup of FreeSWITCH Media Server using
the following steps:
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
[ 99 ]
WebRTC with SIP and IMS
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 /usr/local/freeswitch
Replace 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.
listOtheraccount
/otheraccount.jsp
/otheraccount.jsp
[ 221 ]
WebRTC with Industry Standard Frameworks
listOtheraccount
Like web.xml, struts.xml too should reside on the class path of the web app
(such as /WEB-INF/classes).
The following is a screenshot of the Project Explorer window after the project
completion of the WebRTC client web application using Struts Framework:
The testing phase of SDLC is explained in a later section of this chapter. For some
enterprise-based applications, there exists a requirement to integrate WebRTC
communication functionality in their existing Spring framework. To meet such cases,
we shall also cover the development of WebRTC client on the Spring framework.
[ 222 ]
Chapter 7
Spring 3 MVC-based WebRTC web project
Due to the robust nature of Spring and the associated plugins for database
abstraction, security, handlers, and other external services, it was finally and
rightly adopted as the framework to host the WebRTC Communicator web project.
Programming the Spring 3 MVC web project
structure
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:
•
Aspect Oriented Programming (AOP): This is used to deal with crosscutting
concerns. By embedding AOP, the Spring framework modularizes the
programming approach to prevent code confusion and interdependencies.
•
Object Relational Mapping (ORM): This deals with the mapping of objects
to database tables.
•
The Spring Web module: This is a part of the Spring web application
development stack that includes Spring MVC and web services.
•
Data Access Objects (DAO): This is primarily for standardizing the data
access work. It performs resource management by automatically acquiring
and releasing database resources and exception handling by translating
data-access-related exceptions to a Spring data access hierarchy.
•
Spring Context: This builds on the beans package to add support for
message sources. It also adds the ability for application objects to obtain
resources using a consistent API.
•
Spring Web MVC: This is a request-based framework such as Struts. This is
the module that provides MVC implementations for the web applications.
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.
[ 223 ]
WebRTC with Industry Standard Frameworks
The important interfaces defined by Spring MVC, and their responsibilities, are listed
as follows:
•
•
•
•
•
•
•
•
HandlerMapping: This interface is used for selecting objects that handle
incoming requests (handlers) based on any internal or external attribute
or condition.
HandlerAdapter: This interface is used for the execution of objects that
handle the incoming requests.
Controller: This interface comes between Model and View to manage the
incoming requests and redirect to a proper response. It acts as a gate that
directs the incoming information. It switches its direction by either going
into Model or View.
View: This interface is responsible for returning a response to the client.
Some requests may go straight to View without going to the Model part;
others may go through all the preceding three interfaces.
ViewResolver: This interface comes into the picture when selecting a View
based on a logical name for the View (optional interface).
HandlerInterceptor: This interface is an interception of incoming requests
comparable but not equal to Servlet filters, (its use is optional and not
controlled by DispatcherServlet).
LocaleResolver: This interface is useful for resolving and optionally saving
the locale of an individual user.
MultipartResolver: This interface facilitates working with file uploads by
wrapping incoming requests.
The following diagram outlines the components of the Spring MVC:
Incoming
request
1
request
response
2
Controller name
DispatcherServlet
response
5
3
View name
model
View
HandlerMapping
FrontController
6
view
4
ViewResolver
[ 224 ]
model
request
Controller
Chapter 7
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:
•
Spring 3 MVC for the middle layer
•
Hibernate for database management
•
Asynchronous call to Controllers using AJAX and JSON
•
Spring security for Session Management
•
Spring Validator for validation through dispatcher instead of JavaScript
•
Annotations to map model and bean entities with the Controller
The following diagram shows the organization of code blocks, which are divided
into five major segments:
[ 225 ]
WebRTC with Industry Standard Frameworks
A detailed look at every segment is represented with the help of the
following diagram:
The development of modules
The modules discussed in the final Spring-based project are listed as follows:
•
Admin console
•
Audio / video Call, IM
•
Presence
•
Advertisement
•
Contacts/Friends
•
Conferencing
•
Geolocation
•
Notification
[ 226 ]
Chapter 7
•
User Profile
•
Offline Messages
•
Voicemail
•
Call logs
The steps to build a Spring 3-based WebRTC application are follows:
1. Create a dynamic web project in Eclipse. Let's assume that we name it
WebUnifiedCommunicator:
2. Define the resources in web.xml that is placed inside the project's
WebContent/WEB-INF folder. The following code snippet depicts
the Servlet name and mapping:
webrtc
[ 227 ]
WebRTC with Industry Standard Frameworks
org.springframework.web.servlet.DispatcherServlet
1
webrtc
/
We can also add the error pages, shown as follows, that we want to display
when abrupt terminations occur or errors are introduced by the web project.
404
/WEB-INF/views/weberror.jsp?errorMsg=
"resources not found"
401
/WEB-INF/views/weberror.jsp?errorMsg=
"resources not found"
403
/WEB-INF/views/weberror.jsp?errorMsg=
"resources not found"
500
/WEB-INF/views/weberror.jsp?errorMsg=
"resources not found"
503
/WEB-INF/views/weberror.jsp?errorMsg=
"resources not found"
The following is the code snippet for adding a context listener:
[ 228 ]
Chapter 7
org.springframework.web.context.ContextLoaderListener
3. Set up a Hibernate properties file. It provides values of crucial property
parameters such as database.driver, database.url, database.user,
database.password, and database.dialect. These are required to
successfully establish a connection between the web project and the backend
database. The hibernate.show tag specifies whether the SQL statements on
every database activity should be displayed on the console screen or not.
The hibernate.hbm2ddl.auto automatically validates or exports the
schema DDL to the database when SessionFactory is created. The list
of possible options for this property is as follows:
°°
validate: This option is used to validate the schema only. It makes
no changes to the database.
°°
update: This option is used to update the schema.
°°
create: This option is used to create the schema and destroys all
°°
create-drop: This option is used to create a fresh database on
previous data.
startup and drop the schema at the end of the session.
We shall be using the update option in our case.
database.driver=com.mysql.jdbc.Driver
database.url=jdbc\:mysql\://localhost\:3306/DAVDB
database.user=root
database.password=
hibernate.dialect=org.hibernate.dialect.MySQLDialect
hibernate.show_sql=true
hibernate.hbm2ddl.auto=update
4. Now, the dispatcher xml spring should be defined with the Hibernate
usage inside it as follows:
com.webrtc.model.Userdetail
com.webrtc.model.Geolocation
com.webrtc.model.Contact
com.webrtc.model.Presence
com.webrtc.model.Users
com.webrtc.model.User_roles
[ 230 ]
Chapter 7
${hibernate.dialect}
false
${hibernate.hbm2ddl.auto}
5. Define the Controller logic for mapping a URL to model the View.
@Controller
@Scope("session")
public class MainController implements Serializable {
private GeolocationService geolocationService;
static Logger log = Logger.getLogger(
MainController.class.getName());
AllinoneBean allinoneBean= new AllinoneBean();
6. Add the login functionality into the Controller. This is primarily a
three-stage program: loading the login-related pages, adding logic
to process login requests, and adding functionality for fetching the user
profile details after successful login authentication in the controller.
7. Programming for any module involves the following steps:
°°
Adding the Bean classes
°°
Defining the Service logic
°°
Adding the Modal classes
°°
Defining the DAO logic
°°
Adding the HTML frontend pages
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.
[ 231 ]
WebRTC with Industry Standard Frameworks
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 model = new HashMap
();
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){
[ 232 ]
Chapter 7
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 prepareListofBeanGeolocation(
List geolocations){
List beans = null;
if(geolocations != null && !geolocations.isEmpty()){
beans = new ArrayList();
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;
[ 233 ]
WebRTC with Industry Standard Frameworks
}
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 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 */
}
[ 234 ]
Chapter 7
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 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:
[ 235 ]
WebRTC with Industry Standard Frameworks
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.
Testing
Just as testing marks the beginning of SDLC, testing is the milestone for project
competition. By now, we should have an efficient WebRTC web project capable
of video/audio calls, messaging, Geolocation, and so on. It is time to test the
functionality and search for bugs that might have crept in to the code.
[ 236 ]
Chapter 7
Testing the signal flow
Wireshark is a good tool to monitor all of the traffic flow between connected
machines. We can test the packets sent and received, and generate flow diagrams
to visualize the call flow between parties, end points, as well as the server.
The following screenshot shows the Wireshark tool analyzing signal traces:
To filter the packets captured by Wireshark as per our need, filter it using
sip||websocket as shown in the preceding screenshot.
Test cases for WebRTC client validation
Test cases are used for validation and verification of the end product. The test cases in
the following table are to gauge the correct working of the WebRTC client in known
situations. Of course the development/testing team will add more test cases to these
already-existing ones to debug all errors that are or might occur in this project.
Test No.
Feature tested
Test
description
WebRTC_1
User
Authorization
Initial check for
a valid user
WebRTC_2
User
Authorization
Precondition
Initial check for
a valid user
[ 237 ]
Test steps
Expected results
•
The
Username
field is left
empty
Alert: Username
field should not be
left empty
•
Click on
the Submit
button
•
Enter
Username
•
The
Password
field is left
empty
•
Click on
the Submit
button
Alert: Please enter a
password
WebRTC with Industry Standard Frameworks
Test No.
Feature tested
Test
description
WebRTC_3
User
Authorization
Initial check for
a valid user
WebRTC_4
WebRTC_5
WebRTC_6
WebRTC_7
WebRTC_8
WebRTC_9
User
Authorization
VIDEO
Calling
VIDEO
Calling
VIDEO
Calling
VIDEO
Calling
VIDEO Calling
Precondition
Initial check for
a valid user
Test steps
Expected results
•
Enter an
invalid
username or
password
Alert: The username
or password you
entered is incorrect
•
Click on the
submit button
•
Enter valid
Username
and
Password
•
Click on
the Submit
button
•
Enter SIPURI
of B
•
Click on the
Call button
•
Leave the
SIPURI field
empty
•
Click on the
Call button
Successful login
Check the
status of A (the
calling party )
A is not
logged in
Check for
validation in
the SIP address
field
A is logged in
Check the
status of B (the
calling party)
•
A is logged in
•
B is not logged
in
Enters
SIPURI of B
•
•
The call
progresses
•
Click on the
Call button
•
The call
declines due
to the absence
of B
Check for
unanswered
calls
•
A is logged in
•
•
B is logged in
A enters the
SIPURI of B
•
A clicks on
the Call
button
An appropriate
notification is
received by A for
status of the call as
unanswered
•
B does not
answer the
call
•
A enters the
SIPURI of B
•
A clicks on
the Call
button
•
B cancels the
call
Check for call
cancellation
by the remote
party
•
A is logged in
•
B is logged in
[ 238 ]
The call button is
disabled
The call button is
disabled
An appropriate
notification is
received by A for the
status of the call as
cancelled.
Chapter 7
Test No.
Feature tested
Test
description
Precondition
Test steps
Expected results
WebRTC_10
VIDEO Calling
Check for call
establishment
•
A is logged in
•
B is logged in
Enter the
SIPURI of B
•
•
The call
progresses
•
Press the Call
button
•
Remote
ringing
•
The call is
established
between A
and B with a
message: In
a call
WebRTC_11
WebRTC_11
WebRTC_12
WebRTC_13
VIDEO Calling
VIDEO Calling
VIDEO Calling
Instant
Messaging
Check for
simultaneous
calls
Check for call
on hold
Check for call
termination
Check the
status of the
sending party
A
•
A is logged in
•
B is logged in
•
C is an
authorized
party
•
A and B are
engaged in
a call
•
A is logged in
•
B is logged in
•
A and B are
engaged in
a call
•
A is logged in
•
B is logged in
•
The call
has been
established
A is not logged in
[ 239 ]
C calls either A or
B while they are in
a call
The call attempt
by C is declined,
leaving a message
that the "user is
busy"
•
A puts B on
hold while
they are in
a call
The call goes on
hold and resumes as
soon as A retrieves it
•
A retrieves
the call
Press the Hang up
button
The call is
terminated
•
A clicks on
the instant
messaging
link on the
Services page
The message box is
disabled
•
A enters the
account name
of the remote
party and
tries to enter
a message in
the message
box
WebRTC with Industry Standard Frameworks
Test No.
Feature tested
Test
description
Precondition
Test steps
Expected results
WebRTC_14
Instant
Messaging
Check the
status of the
sending party
A
A is logged in
•
A clicks on
the instant
messaging
link on the
Services page
A is able to type the
message
•
A enters the
account name
of the remote
party and
tries to enter
a message in
the message
box
•
A clicks on
the instant
messaging
link on the
services page
•
A enters
the account
name of the
remote party
and enters a
message in
the message
box
•
A clicks on
the Facebook
link to
send the
message to
the account's
Facebook
page
•
A clicks on
the instant
messaging
link on the
Services page
•
A enters the
Facebook
account
name of B
and enters a
message in
the message
box
•
A clicks the
Facebook link
to send the
message
WebRTC_15
WebRTC_16
Instant
Messaging
Instant
Messaging
Check whether
the message
receiver, B, is
an authorized
user or not
Success check:
Message being
sent by A to
the Facebook
account of B
•
A is logged in
•
B is an
unauthorized
user
•
A is logged in
•
B is an
authorized
user
[ 240 ]
Alert: Enter an
authorized account
name
The message
is successfully
transferred to the
Facebook account
of B
Chapter 7
Test No.
Feature tested
Test
description
Precondition
Test steps
Expected results
WebRTC_17
Instant
Messaging
Success check:
Message being
sent by A to the
Gmail account
of B
•
A is logged in
•
•
B is an
authorized
user
A clicks on
the instant
messaging
link on the
Services page
The message
is successfully
transferred to the
Gmail account of B
•
A enters
the Gmail
account
name of B
and enters a
message in
the message
box
•
A clicks on
the Gmail
link to send
the message
Summary
This chapter was all about enveloping the WebRTC client application in frameworks
that are standard and enterprise-accepted. The path from POC building to a
fail-proof WebRTC client application was portrayed in this chapter. The chapter
includes code snippets and step-by-step processes to develop WebRTC JSP- /Servletbased projects, Struts- and Hibernate-based projects, and Spring framework-based
projects. The various stages of SDLC were elaborated in the context of the WebRTC
Client application. These included design with UML, development on Java EE, and
testing use cases.
In the next chapter, we shall encounter more features that are part of a rich
communication suite of services.
[ 241 ]
WebRTC and Rich
Communication Services
Two decades ago, when mobile phones had just begun to become vital for everyone,
the telecom service providers were using only basic call services to generate revenue.
In a few years from then, the masses became used to the old voice calls, and the need
for more service over mobile was stirred up. Then began the era of Short Message
Service (SMS) followed by Multimedia Message Service (MMS), which involved
interaction with text and multimedia files. The wheel of innovation again spun in a
few years. This time it led to the merging of the existing telecom services with the
IP world as well as convergence between desktop computers and mobile devices as
communication end points. This resulted in enhanced services such as video calls; live
streaming; and syncing of messages, logs, and contacts between different call agents
registered with a user. However, this also led to some issues such as handling multiple
clients, services, identities, and numbers. The need of the hour now is innovation in the
old format of services and the availability of a more enriching experience, for example,
the possibility of being able to transfer files and share pictures, location information,
voicemail, texts, and emoticons, all under one roof on one screen. The aim is towards a
single identity-based, guided communication technique that is unified for all services,
has centralized data management, and indicates the capabilities of other contacts
in your phonebook too. This is where Rich Communication Services (RCS) comes
into picture. The RCS initiative meets these hurdles and ambitions with international
standards to smoothen out the scattered services.
In the previous chapters, we saw the process of setting up a basic WebRTC
communication front. This chapter marks the transition from a normal
communication client built on any protocol support with any arbitrary set
of services to a standardized all-IP-based communication client that possesses
rich communication features.
WebRTC and Rich Communication Services
Rich Communication Services
The RCS is a concept of IP telephony that involves standardized architecture and a
uniform set of services supported by all vendors. By profiling the existing services
and setting up the defined, expected behavior from the creation of any future service,
RCS aims to do away with the vendor dependency and proprietary implementations
found today. The specifications are described in detail by the Global System
for Mobile Communications Association (GSMA) at http://www.gsma.com/
network2020/rcs/specs-and-product-docs/.
A joint effort by leading telecom industry players, RCS is proving to be the
cornerstone in lending network and vendor-agnostic shape to services, and also
rendering them simple to upgrade and enhance since there is no vendor lock-in
on proprietary protocols.
Developers today strive to build a communication platform that supports
GSMA RCS 1.0/2.0/RCS-e and also refines the message-service network based
on converging the traditional and new message services from the Internet, such as
e-mails and updates on social networking sites and blogs.
Position and adoption of RCS
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.
[ 244 ]
Chapter 8
Business impact of RCS
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.
Technology impact
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 will change the end-user behavior. It will help standardize the
capabilities of devices for rich communication. It will also help ensure
interoperability between fixed and mobile networks and between client
devices from many different vendors. RCS will give an edge to CSPs only
if they perform better than their competitors (that is, OTT).
•
Carrier investments in IMS are better protected with RCS. RCS uses IMS to
handle the underlying network features such as authenticating and charging
for services. IMS defines the key interoperability requirements between RCS
features, including Presence, location-based services, and connection through
HSS between the network and user device.
[ 245 ]
WebRTC and Rich Communication Services
Rich Communication Services enhanced
(RCS-e)
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:
•
Discovery and activation
•
Group chat
•
Integrated messaging
•
File transfer
•
Geolocation push
•
One-to-one chat
•
IP voice call
•
IP video call
•
Multidevice support
Joyn
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 RCS configuration process
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.
[ 246 ]
Chapter 8
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.
RCS specifications
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:
•
Capability discovery with the help of SIP OPTIONS message, or Presence, that
involves precall capability discovery, in-call/in-session capability discovery,
and multi-device handling
•
Social Presence – the phonebook and location features are part of it
•
Standalone messaging, that is, both one-to-one chat and group chat
(the messaging-processing session management and multidevice scenarios
are mentioned in the test case specification v3.0.)
•
File transfer using HTTP/Message Session Relay Protocol (MSRP)
•
IP voice call and video call
•
Network Address Book and blacklist
•
User availability through XML Configuration Access Protocol (XCAP)
•
Notification service through REST
We will cover majority of these features one by one in this section, keeping WebRTC
client as the end user tool.
[ 247 ]
WebRTC and Rich Communication Services
Service discovery by an RCS-enabled device
A mobile network that offers RCS services to its subscriber base should be able to
detect when a user connects to the network for the first time with an RCS-capable
device. Upon detecting a user connection, two processes are triggered to be executed:
•
Service provisioning: This is the process where the relevant configuration
is performed on the network elements to make the RCS services available to
the user (for example, provisioning an account on the IMS core and relevant
application servers). In addition to this autoprovisioning on first usage, the
service might be provisioned in advance by the service provider.
•
Client configuration: This is the process where the network provides the
client with its configuration. A user can only initiate the use of RCS services
once their client is configured and the corresponding subscriber (uniquely
identified by the relevant IMS URI, that is, a tel URI and/or a SIP URI) is
provisioned by the RCS service provider to access the RCS services.
Both processes should be performed automatically (for example, when a subscriber
first turns on their RCS-capable devices and connects with their Service Provider).
The autoprovisioning and configuration processes for a WebRTC client is initiated
by a REGISTER SIP request. The following diagram shows the WebRTC RCS client
registering with the RCS server in the IMS Core environment:
IMS Core
UE User /Client A
WebRTC
RCS AS
Registration
Location
Server
SIP REGISTER
200 OK Expiry Value
The preceding setup gives the end user the impression that the RCS services are
working out of the box and minimizes any operational impacts to Service Providers.
An alternative way is to use an HTTP-based configuration, but this is not discussed
here for simplification purposes.
User capability exchange
The user must be able to avail the RCS/RCS-e services with other users, and in order
to do so, they must know if the other party is RCS capable or not. It is for this reason
that the device must send out periodic signals to check and confirm whether the
contacts in the phonebook are RCS capable.
[ 248 ]
Chapter 8
On confirmation, the user can make a rich call to that contact. The SIP request used
to achieve this is called OPTION. The following diagram shows the user capability
exchange for WebRTC clients via the RCS server in the IMS Core environment:
IMS Core
RCS AS
UE User /Client A
Presence
Server
WebRTC
UE User /Client B
XDMS
WebRTC
SIP OPTIONS (User B)
SIP 200 OK (CapabilitiesUser B)
SIP OPTIONS (User C)
Error 480 TEMPORARYUNAVAILABLE/
408 REQUEST TIMEOUT
SIP OPTIONS (User D)
ERROR 404 NOT FOUND
The preceding call-flow diagram used the OPTIONS message mechanism.
We are assuming that user B is REGISTERED, user C is NOT REGISTERED,
and user D is not an RCS user.
Chats with multimedia sharing
A rich messaging agent is expected to enable a large variety of messaging options,
including chat, emoticons, location sharing, and file sharing. There must be
support for the open standard protocol frameworks and a provision of one-to-one
conversations and group interactions such as private chat, group chat, private file
sharing, group file sharing, and others.
MSRP, which is a protocol for messaging sessions, does message encoding very
similar to SIP and HTTP. Then, there is MSRP SIP and SDP to negotiate the
parameters of the communication.
Messaging sessions require explicit setup and teardown. They do the following:
•
Use SDP to describe sessions (where m means message) and SDP
Offer/Answer to convey parameters
•
Exchange dynamic transport addresses for communications (MSRP URLs)
[ 249 ]
WebRTC and Rich Communication Services
•
Negotiate supported message formats
•
Use the SEND method to convey messages
•
Might request confirmation from the remote side (on success and/or failure)
•
Support for chunking of large messages (2 KB chunks)
•
Use the REPORT method to provide confirmations
MSRP has two modes of operation:
•
Direct communication between peers (simple case)
•
Communication via relays (NATs, firewalls, policies, and so on)
As we have WebRTC platform network nodes in between peers, we will discuss the
second mode of operation, that is, communication via relays.
The one-to-one text chat over MSRP
A one-to-one text chat is an MSRP data exchange inside an SIP session. The user
enters in one-to-one IM and sends a message. The IM server can decide whether
to stay in the MSRP media path (to store message history, for example) or let the
MSRP session be established end to end. Once an IM session is established, it will
remain active until one of the peers leave the IM or the inactivity timer triggers. The
following diagram depicts a one-to-one chat session between two WebRTC clients:
IMS Core
UE User /Client A
RCS AS
UE User /Client B
WebRTC
IM
WebRTC
SIP INVITE
SIP INVITE
200 OK
180 RINING
ACK
ACK
MSRP
MSRP
MSRP SEND
MSRP 200 OK
The user might leave the IM/chat window in the background, which means that the
session is still active and can return afterwards.
[ 250 ]
Chapter 8
File transfer over MSRP
File transfer goes to the background and it can be tracked in the notification area.
However, note that if it is started from a chat window, the transfer information is
presented on screen. The following diagram shows an MSRP file transferred from
WebRTC clients via the RCS Server in the IMS Core environment:
IMS Core
UE User /Client A
WebRTC
RCS AS
UE User /Client B
WebRTC
SIP INVITE (SDP MSRP Session)
SIP 200 OK (SDP MSRP Session)
ACK
MSRP SEND (File data)
MSRP 200 OK
MSRP SEND (File Data)
MSRP 200 OK
File Transfer Completed
(Size Check)
File Transfer Completed
(Size Check)
SIP BYE
SIP 200 OK
Group chat in a conference session
The group chat involves multiparty session management and delivers the text
messages to users in the same way as in a two-party message. To initiate a group
chat, the user enters the IM application and chooses to start a new chat. The list of
RCS users is displayed and the user gets to choose one or more contacts. When a
contact is selected, the OPTIONS exchange takes place to verify whether they are
available for chat. This sets the request URI to the conference factory URI for the IM
service in the home network of the IM user, and adds all of the invited users to the
Multi-Purpose Internet Mail Extensions (MIME) resource list body.
[ 251 ]
WebRTC and Rich Communication Services
The following diagram shows a group chat among WebRTC clients via the RCS
Server in the IMS Core environment:
IMS Core
UE User /Client B
UE User /Client A
RCS AS
WebRTC
SIP INVITE (Including list of invites)
WebRTC
WebRTC
SIP INVITE (Including list of invites)
SIP INVITE (Including list of invites)
SIP 200 OK
SIP 200 OK
ACK
ACK
SIP 200 OK
ACK
Conference Session established between AB and C
User availability through XCAP
XCAP allows a client to read, write, and edit the application's configuration data
stored on a server in the XML format. It's an Application Layer protocol and maps the
XML elements to HTTP URIs so that they can be accessed via HTTP requests. It can
be implemented to indicate user availability on chat rooms in a WebRTC platform.
We can also use XCAP for authentication, to share a file by checking the file extension
through the XML file. The following diagram depicts user availability through XCAP:
IMS Core
RCS AS
UE User /Client A
Presence
Server
WebRTC
XCAP
server
UE User /Client B ( watcher )
UE User /Client C ( watcher )
WebRTC
WebRTC
PUBLISH
PUT
SUBSCRIBE
NOTIFY
SUBSCRIBE
NOTIFY
[ 252 ]
Chapter 8
The preceding call flow diagram describes how the WebRTC client can implement
the PUBLISH, SUBSCRIBE, and NOTIFY methods along with XCAP to create the
feature of User Availability Indication in the phonebook.
REST-based notifications
Representational State Transfer (REST) is mostly applied to web services.
HTTP-based RESTful APIs have POST, PUT, GET, HEAD, OPTIONS, and DELETE
methods. Even though REST is not directly applicable in the case of WebRTC
platform building, it can be used for third-party service integration such as
weather notification, reminders, alarms, and so on. The following diagram
shows the REST-based notifications:
IMS Core
UE User /Client A
RCS AS
WebRTC
HTTP REST Server
Create Notification (HTTP
REST Request on JSON)
Notification reminder
(HTTP REST Response
on JSON)
The preceding figure depicts a REST-based notification service for a WebRTC client.
Before creating any REST service, we first have to identify the different resources
in the application and map the actions performed over them to the HTTP methods
and addresses, for example, create notifications and get reminders. Then, a media
type is decided to carry data such as JSON, XML, or others. After this, the referenced
resources can be fetched along with the HTTP methods.
Interoperability and interworking
The scope of interoperability not only pertains to a network but to a device
as well. This is ensured by a strict adherence to Interoperability Testing (IoT).
A communication device/software prepares a test matrix after successful IoT
and assigns self-accreditation to RCS.
[ 253 ]
WebRTC and Rich Communication Services
In conclusion, we can configure the WebRTC platform architecture and make it RCS
compliant by collaborating with GSMA RCS-accredited vendors to extend the RCS
functionality in order to cover the following features/components:
•
RCS Application Server, a single platform that supports both OTT and
RCS apps
•
RCS Joyn GSMA-accredited stack complying with all the expected standards
•
Seamless integration with the underlying media engine, supporting all major
codecs such as H323, H324, G-711, VP8, Opus, and others
•
Adding enriched services such as enhanced phonebook, messaging, and so
on, as described in the preceding sections
The RCS ecosystem and WebRTC
RCS is all about an agreed set of standards and protocols based on IMS. This section
of the chapter defines the integration of RCS features into a WebRTC client. RCS
defines two types of clients:
•
RCS embedded client: This is the client that is provided as part of
the handset implementation, and it is fully integrated with the native
applications (address book, gallery/file browser application, calling
application, and so on). Consequently, the RCS client will represent its
identity, and the International Mobile Station Equipment Identity (IMEI)
will be used in an SIP instance during registration.
•
RCS downloadable client: This is a client that might be preinstalled or
that has to be downloaded by the user. However, it is not part of the device's
base software (that is, it has no access to internal Application Programming
Interfaces (APIs) and advanced Operating System (OS) functionalities). The
level of integration with the native applications is limited to the possibilities
permitted by the corresponding mobile OS or the OS platform API.
In the context of WebRTC web-based communication client, we will see scenarios
where SIP is RCS-capable, and the WebRTC application accesses the RCS functions
through a web interface.
[ 254 ]
Chapter 8
The following diagram shows the RCS WebRTC client that is interoperable with all
call agents:
SIP o WS
HTTP REST
WebRTC
Signaling
Gateway
SIP
RCS
WebRTC
Client
DTLS
SRTP
WebRTC Media
Gateway
Mobile Phone
(VoLTE/VoIP)
RCS enabled
SIP WebRTC
Server
RTP
IMS
network
2G/3G
Cellular
Mobile phone (CS)
PSTN GW
Legacy / Fixed line
phone
Any RCS or non-RCS enabled client, such as an SIP phone, desktop phone, PSTN
agent, or a mobile phone, should be able to call an RCS WebRTC client. However, the
RCS capability of end users is queried, and the services will be invoked according to
each client's specifications. For example, the file transfer icon on the WebRTC RCS
client will be dimmed or inactive for a PSTN phone, as the capabilities do not match.
RCS services in WebRTC
The array of services readily deployable in the WebRTC platform and complying
with the RCS feature set are mentioned in this section.
User profile
RCS outlines the user's status and capabilities and service of sharing the current
user's status. It includes the depiction of whether the user is online to take calls
or is offline and unavailable. It has a customized status message by the user, such
as Away from desktop or Holidaying at home. It also bears information about
the devices that the user is currently using, for example, Android phones, Linux
desktops, Nexus tablets, and so on. Information on whether the user has the ability
to take video calls and play multimedia files is also displayed.
[ 255 ]
WebRTC and Rich Communication Services
The following screenshot shows the prototype of a WebRTC profile-management
service:
A user might also set or update their network's black and white lists. Blacklisted
users are always screened from calling, while users in the white list are always
given priority in calls, to the extent that their calls are connected even if the user has
activated Do Not Disturb (DND). The following screenshot shows the prototype of
the WebRTC call-setting provisioning interface:
The preceding diagram shows other options in the Profile and Settings page too.
These are covered in the subsequent sections.
[ 256 ]
Chapter 8
Integration with social networks
Social Presence signifies the ability to link a WebRTC SIP account with an account
user on other social networking sites such as Google, Facebook, Yahoo, and others.
The capabilities derived from this feature are many, such as:
•
Signing in without a password but using tokens. OAuth allows an
application to access restricted contents (such as Facebook or Google user
information). To sign in without a password, the OpenID protocol is used.
•
Posting updates to other networking sites
•
Import contacts from other platforms:
•
Importing the profile status and/or picture from other sites
•
Continuing a conversion even when the user signs out of WebRTC by
sending messages/ mails over other platforms
[ 257 ]
WebRTC and Rich Communication Services
The enhanced phonebook
An enhanced phonebook, also referred to as the Network Address Book, is synced
with the user's account everywhere. It involves sharing user capabilities such as
the ability to make a video call, codecs support, and others. It also helps in service
discovery by mentioning the SIP URI accounts that are listed to be updated for their
statuses. Rich phonebook also describes the sharing of the Presence status of a user's
contacts, such as available or not available. The design of the phonebook should be
such that it updates itself regularly with the status of the contacts.
Refer to the following screenshot to see a prototype of the phonebook for the
WebRTC client, which shows the following information:
•
A contact's latest profile picture or default picture in case no picture
is available
•
Links to their social networking accounts
•
Timestamp of the last-accessed hour
•
Presence (offline/online) and/or customized status text
•
RCS capabilities support such as file sharing, video/audio call, video/audio/
text message, and others
In terms of functionality, the phonebook should have a built-in way of handling
click-to-call audio/video and click-to-message SMS/IM commands. The backup
and synchronization of contacts across all of the user's devices should happen
transparently to the user.
[ 258 ]
Chapter 8
User capabilities and Presence
The WebRTC client must update the Presence and capabilities of contacts in the
phonebook so that the user knows what services to invoke for which contacts.
The following screenshot shows a contact with the RCS-e capabilities:
Capabilities and Presence in profile of a RCS user
The following screen shot prototype shows the contact as online to take calls but
doesn't support the RCS-e capabilities. This might be the case when a subscriber has
registered via an SIP phone. For example, the contact is not capable of receiving file
transfers. Therefore, the file transfer icon is dimmed and nonclickable in this case.
Capabilities and Presence in profile of a non-RCS user
[ 259 ]
WebRTC and Rich Communication Services
Unified messaging box
The message box should have the option of various message delivery options
such as SMS, MMS, e-mail, IM, voice message, video message, and fax message.
The idea is to combine the legacy and futuristic messaging services under one
umbrella. It must aggregate the message from various servers and put them into
a single view. Hence, it should have control buttons for:
•
File browser
•
Media gallery
•
Camera application
•
Desktop sharing
Some features of a messaging client, which are obviously expected, are also
mentioned here. These options are a must-have:
•
Forwarding a message
•
Copying a message
•
Sharing a chat
•
Replying to a message
The prototype of the one-to-one messaging WebRTC page is shown as follows:
[ 260 ]
Chapter 8
With these standards, a messaging solution must also allow users to share emoticons
(symbols that depict emotions) to make the chat less mundane and more interactive.
The prototype of the Group Messaging WebRTC page is shown as follows.
Message history
The message logs must also be backed up and synchronized like phonebook entries.
The media shared between parties during the message session must also be stored
and linked to the context to understand when and why it was shared.
Rich calls
The rich call service enables calls enriched with multimedia content sharing.
RCS supports multiple call options and the ability to invoke rich services such
as desktop sharing, file sharing, HD Call support, and others.
[ 261 ]
WebRTC and Rich Communication Services
The following screenshot is a prototype of how an RCS-enabled WebRTC audio
call page should look:
It is worth noting that the audio call screen depicts the essential operations a user can
perform from their WebRTC client. This includes desktop sharing (the first icon on
the tray from the left-hand side). The following screenshot is a prototype of how an
RCS-enabled WebRTC video call page should look:
[ 262 ]
Chapter 8
The following screenshot is a prototype of the feature of desktop sharing
during a call:
Sharing remote desktop view during a Call
Call logs
The WebRTC client/server setup must synchronize with the network node of the call
operator to provide a uniform view of all calls made or received until now. It must
also bear the timestamp for the start and end of every call, in addition to the caller's
and receiver's details.
[ 263 ]
WebRTC and Rich Communication Services
The following screenshot shows a prototype of the Call Logs web page with quick
links displayed on any selected entry:
The Call Logs page must bear quick links such as click-to-call, voicemail, messaging,
or view profile links to any entry mentioned there, the same way a phonebook has.
Message history
Just as the Call Logs page displays the call history of the user with a timestamp, the
Message History page is regarding the message interaction of user. The following
screenshot displays the text messages received by the user in a tabular layout:
[ 264 ]
Chapter 8
Clicking on any one of the entries opens the full message window with all the
messages displayed. Just like the Call Logs page, the Message Logs page also bears
a quick link pop-up box to let the user reply with text/audio/video or just call the
other party back.
Multiparty conferencing
A multiparty conferencing session is similar in nature to a normal video call.
However, the difference lies in the fact that video call between two parties does
not require media mixing activities on part of the Media Server. Multiparty
conferencing does require this and also the spacing for multiple windows needs
to be made available on the current window frame as and when the users join.
The following screenshot shows the prototype of conferencing among four users
on a WebRTC client:
The visual representations provided in this section give a neat idea of planning a
WebRTC communication interface coupled with RCS features.
[ 265 ]
WebRTC and Rich Communication Services
WebRTC architecture with RCS modules
As the SIP server is replaced with an RCS-capable SIP server, the modules for
MSRP Relay, Presence Server, Location Server, and Messaging Server become
of acute importance. The following diagram depicts an overall deployment
diagram for RCS-capable WebRTC communication platforms:
Server Side
SRTP
Client Side
Voice
CSS
Audio Codec
Java Script
Noise Reduction
New Service Invocation
Video
WebRTC Stack
Hosted on webserver
WebRTC RCS Client
VP8 Codec
Video Jitter
Buffer
Image
Enhancements
Codecs
STUN . TURN . ICE
Multiplexing
Hosted on Telecom Server
Multiple Browsers
HTML5 Based GUI
Session Management
Application
configuration files
Integration
Interfaces
IM
Server
Presence
Server
XCAP
Server
Media
Relay
MSRP Relay Server
SIP Registrar
Multiple Devices
WebRTC RCS Server
Note that this is a highly capable RCS deployment scenario, and it is okay if not all
nodes depicted in the diagram are present in an RCS client server environment.
Telecom operator's benefit derived
from RCS
The billing and charging models with the RCS service are multidimensional in
nature. The following diagram depicts some aspects of the revenue generation
model derived from an RCS-capable WebRTC communication platform aimed
towards Business to Business (B2B):
[ 266 ]
Chapter 8
End User
B2C
B2B
$
$
Use cases
Target
Enterprisers
Healthcare
Automotive
RCS
Solution
Incontext
Usage
Security
SME’s
E-learning
RCS, VoIP,
Messaging
Users
RCS
Features
operatot
Infrastructure
RCS APIs
Call
centre
IT
process
Interoperable Interconnected
The following charging models are primarily for the Service Provider's benefit,
as they discuss the monetization aspects of an RCS-enabled communication:
•
Subscription-based model: This model allows full RCS usage after a
monthly payment. This is a flat-pricing model. It adds RCS features on top
of a user's existing service plan. After the expiry of the subscription period,
the user is reverted to the old service plan.
•
Service bundled model: In service bundling, the user's existing service plan
is completely replaced with the RCS service plan. The performance is better
than the subscription-based model, and no separate billing is required to
handle subscriptions.
•
Loyalty model: This model can be offered to specific sections of users
or premium users. Here, the RCS service set is customized to meet the
requirements of a set of users such as Enterprise users, the healthcare
industry, and the manufacturing industry. Such filtered targeting is done
after a thorough analysis of communication trends in that industry segment.
•
RCS-enabled Applications: In this scenario, the service provider exposes
RCS APIs to the developer community. This encourages the developers
to make their own applications using the APIs that hook into the telecom
service provider's network infrastructure and data. The interests of the service
provider lies in the fact that such applications indirectly result in revenue
generation either through services or through the generation of chargeable
events such as calls, messages, data fetching, and others (for example, the RCS
API for rich messaging for online doctor consultation application).
[ 267 ]
WebRTC and Rich Communication Services
•
Revenue through advertisements: Revenue generation through
advertisements is the current industry trend. In this scenario, the RCS services
are offered free of cost, but an advertisement is displayed or played along with
the rendered service (for example, a bar at the bottom of the screen space to
message or play advertisements during the ringing tone in a call).
Voice over LTE
While we are at it, we might as well study a thing or two about Voice over LTE
(VOLTE). After all, RCS and VOLTE are said to be the major game changers in
the coming generation of telecommunication. VOLTE is an all-IP mobile-access
technology with the promise of high bandwidth and low latency. VOLTE is a subset
of the IMS technology that is discussed time and again in the book. LTE is not just
a concept anymore with commercial LTE network setups at many places and huge
investments. There already is mass interest in VOLTE from telecom operators,
equipment manufacturers, and even GSMA.
Combination of WebRTC, VOLTE, and RCS
This combo has the potential to completely revolutionize the way we see
communication today. It provides the environment for innovative service creation
while adhering to open standards. An architectural depiction of these technologies
working together is shown in the following diagram:
Service Layer
Enhanced
phonebook
Geolocation
Presence
Social
Networks
Unified
Messaging
Multimedia
Network Layer
IMS network
RCS server
Access Layer
VOLTE
LTE Infrastructure
joyn
WebRTC RCS client
[ 268 ]
Chapter 8
Why is it important for CSPs? The combo of WebRTC, VOLTE, and RCS will
enrich the user experience in ways that OTT players can never match, for example,
preinstalled software in the phone, greater quality standards and reliability.
More so, not only is it aligned to the BYOD trend that is catching up pretty fast,
but also results in the Capital Expenditure (CAPEX) reduction.
Summary
This chapter talked all about the evolving technology standards in the telecom
domain and their usage in the context of WebRTC. We provided insight into RCS
and its feature implementation in the WebRTC web client, such as enriched call
experience, converged phonebook, unified messaging, and service discovery,
among others. We also discussed the RCS-enabled SIP Server for the WebRTC client.
In addition to this, we briefed on JOYN, which is a standard to embed RCS features
in an end user device. We also shed some light on VOLTE, which is an access-layer
technology for faster speed in the IMS environment.
In the upcoming chapter, the compatibility of various browsers, SIP softphone,
and mobile applications to WebRTC standards will be gauged. We will also discuss
the methods to bridge the gaps in enabling communication between WebRTC
browsers and SIP devices.
[ 269 ]
Native SIP Application
and Interaction with
WebRTC Clients
With the passage of time, better standards for mobile phone networks emerged
that which were much faster than their predecessors. This led to the widespread
adoption of VoIP protocols to communicate between different kinds of devices over
wireless networks. As WebRTC is meant to be used not only over a LAN but also
over mobile data packet networks, it is crucial for all the functionality, performance,
and interoperability scenarios to be ascertained. WebRTC is intended to be a
homogeneous technology for every browser; however, there are marginal differences
between the browser types/versions for devices and operating systems (OSs).
Intercommunicating between a native SIP client and WebRTC is also a challenge,
considering the format of Media codecs and signaling used. While native SIP phones
use SRTP or RTP for media, G.7xx, AMR-xx, Speex, GSM audio codecs, and H.263
and H.264 video codecs, WebRTC offers SRTP as a video codec for media flow, G.711
and Opus as audio codecs, and VP8 and H.264 AVC as video codecs.
Native SIP Application and Interaction with WebRTC Clients
In Chapter 4, WebRTC Integration with Intelligent Network, we discussed how to extend
WebRTC client calls to handheld mobile phones such as smart phones that have
2G (UMTS), 3G, and 4G (LTE devices). In Chapter 5, WebRTC Integration with PSTN,
we came across the WebRTC network configuration to support public-switched
landline phones. While Chapter 8, WebRTC and Rich Communication Services, was all
about upgrading the standard communication services to RCS, this chapter takes us
through the support and interoperability of the WebRTC platform with other kinds
of devices and SIP software. We will take into consideration popular desktop-based
softphones, mobile applications, and widely used browsers to depict WebRTC's scope
of usage. Some browsers that are popular and occupy a good market share but are not
interoperable with standard WebRTC calls as yet are also taken into consideration.
Furthermore, the use of the Flash plugin is also discussed.
The W3C WebRTC and IETF RTCWeb working groups are busy defining standards
for web-based real-time communication to use the power of the Web without plugins
for audio/video calls. However, many browsers that occupy a major chunk of the
market have not adopted WebRTC as yet or are not interoperable with the standard
WebRTC functions. The challenges in the interoperability of WebRTC with phone
applications pertain not just to signaling but also to media standards. Let's categorize
the SIP phones into four groups.
Category 1
This consists of SIP phones that work on SIP signaling and have
traditional codecs support, that is, video codecs, such as H.263, H.263,
and so on, and audio codecs, such as G.711
Category 2
This consists of SIP phones that work with SIP but have codec supports
via Opus and VP8, just as WebRTC does
Category 3
This consists of SIP phones with SIP over WebSockets but that do not
support codecs supported by WebRTC
Category 4
This consists of SIP phones that support SIP over WebSockets for
signaling and also support WebRTC-supported codecs such as
Opus and VP8
In category 4, the SIP phones that support SIP over WebSockets for signaling and
also support WebRTC supported codecs do not require any additional setup, as they
are already WebRTC-compliant.
[ 272 ]
Chapter 9
For the phones in categories 1 and 2, we need to set up a WebSocket gateway that
converts signaling from SIP over WebSockets to traditional SIP signaling. However,
we observe that, even though the SIP signal flows between two endpoints and calls
can be made, as soon as these calls are picked, there is an abrupt termination. This
is caused due to media incompatibility between the end points. It is for this reason
that, for the phones in categories 1 and 3, we must configure a Media Server to
support all the audio/video codecs that our endpoints might use. It should be able to
interconvert between standard WebRTC and traditional codecs.
While running a WebRTC application on a browser, challenges arise due to the fact
that all browsers do not yet support WebRTC functionality. What can a developer do
when the particular browser is not WebRTC supported? A developer can:
•
Refrain from showing communication options (WebRTC components)
if the website is opened from a non-WebRTC-supported browser
•
Restrict access of non-WebRTC-supported browsers to the website
•
Build a backward plugin, for example, using Flash
We will take a deep dive into the extent to which WebRTC can be used by itself,
the temporary solutions using Flash-based SIP, and interoperability from other
platform-specific native SIP applications in the upcoming sections. Let's first divide
the test cases for WebRTC client functioning across various operating systems.
It will be followed by browsers and software supported by the particular OS.
Support for WebRTC in various operating
systems
We will cover all the major SIP-based endpoints to establish their compliance/
noncompliance with a WebRTC client. We will look at native browser support for a
WebRTC client and SIP softphones capable of interacting with a WebRTC client for
the following desktop operating systems:
•
Windows OS for computer
•
Linux OS for computer
•
Mac OS for computer
[ 273 ]
Native SIP Application and Interaction with WebRTC Clients
We will also analyze the support for WebRTC communication from mobile phone
operating systems. For this purpose, we will chiefly analyze the following three OSs
for mobile platforms:
•
Android OS for mobiles/tablets
•
Windows OS for mobiles
•
iOS for mobiles/tablets
Let's first divide the test cases for WebRTC client functioning across various OSs.
It will be followed by browsers and software supported by the particular OS.
Windows OS
Windows OS is the most widely used operating system in the world, occupying
more than half the market. The following pie chart shows the percentage of usage
of this OS in the common public space; refer to http://www.netmarketshare.com/
operating-system-market-share.aspx:
Other: 2.96 %
Linux: 1.74 %
Windows Vista: 2.95 %
Mac OS X 10.0: 3.95 %
Windows 8: 5.93 %
Windows 7: 50.55 %
Windows 8.1: 6.61 %
Windows XP: 25.31 %
Source: NETMARKETSHARE
It is, hence, of acute importance to establish the reach of WebRTC support and
interoperability to various SIP endpoints over the Windows OS. The WebRTC
communication solution has been tried and tested in four major Windows
versions, namely, Windows XP, Windows Vista, Windows 7, and Windows 8.
The performances of these are primarily the same, which is an absolute compliance,
using standard WebRTC-compliant browsers of latest versions.
Native browser support for WebRTC clients
This section takes a deep dive into WebRTC compliance with major web browsers
on the Windows OS.
[ 274 ]
Chapter 9
Chrome browser support for WebRTC clients
Chrome hosts many different versions, in addition to stable builds such as the Dev
and Beta channels. It is worth pointing out that while Google Chrome is essentially
closed-sourced, the Chromium project, which is the base of Chrome, is open source
(refer to http://www.chromium.org/). Google Chrome is the stable build for public
use. Above Version 25, the Google Chrome browser supports WebRTC without
changing the flag settings. The latest version of Google Chrome, currently Version
36, now supports these functions by default. The following diagram is the screenshot
of WebRTC running from a Windows 7 Chrome browser:
[ 275 ]
Native SIP Application and Interaction with WebRTC Clients
Chrome Dev and Beta channels are majorly for the purpose of testing and reporting
for bugs before launching a public release. Google provides official Canary builds
for Windows and Mac too; unlike the other channels (Beta and Dev), Canary's
side-by-side feature allows builds to be installed without overwriting a regular
Chrome build. It is a developer's playground to install plugins, switch between
flags, and test and try out extensions for a web product without affecting the stable
Chrome. Chrome Canary is shown to support smooth WebRTC audio calls, but
it does not support video calls without proper settings. For old Chrome browser
versions as well, we need to ascertain that they support PeerConnection functions
by taking a look at the flags.
The preceding screenshot shows WebRTC running from a Windows 7 Canary browser.
It is favorable if the users have updated versions of Google Chrome to use WebRTC.
[ 276 ]
Chapter 9
Mozilla browser support for WebRTC clients
Mozilla Firefox also shows compliance to WebRTC ranging from audio/video
calls, messaging, Geolocation, and so on. The following screenshot shows WebRTC
running from a Windows 7 Firefox browser:
Mozilla also releases its builds in many versions, mainly, Beta, Aurora and Nightly.
[ 277 ]
Native SIP Application and Interaction with WebRTC Clients
The Nightly version is the one under heavy development. It was least stable and
secure and was the first to come with WebRTC support in late 2012. The Nightly
release is aimed at performing first tests of new features and should only be used
by experienced users/testers. The latest Nightly builds also support the WebRTC
function by default. The following screenshot shows WebRTC running on a
Windows 7 Nightly browser:
Firefox Beta (as of 16 May, 2013) and Chrome 25 and later are interoperable but
currently require a small degree of adaptation on the part of the calling site.
For more information, visit http://www.webrtc.org/interop.
[ 278 ]
Chapter 9
Opera browser support for WebRTC clients
It is interesting to note that Opera too has joined the league of WebRTC since
early 2014. The following screenshot shows WebRTC running from a Windows 7
Opera browser:
The preceding screenshot shows that it renders seamless intercommunication
with other WebRTC web clients for both audio and video calls. After the study on
WebRTC capable-browsers, let's proceed to the SIP softphones that are majorly used
for VoIP calls from the Windows operating system.
[ 279 ]
Native SIP Application and Interaction with WebRTC Clients
SIP softphones capable of interacting with
WebRTC clients
There are many SIP-based call applications in the market for Windows OS, both in
the free and paid spheres. We will discuss some popular ones here to show
WebRTC's interoperability.
X-Lite
X-Lite is a very popular call agent for desktop-based phones. Currently, there are
two X-Lite versions in popular use: new and old. First, let us consider the old version
with a typical gray interface, displayed in the following figure:
It shows intercommunication only via audio calls with a WebRTC client. X-Lite with
a newer Lite version and with more codec support also shows the same compatibility
with WebRTC.
[ 280 ]
Chapter 9
Codec support by the X-Lite Lite version (new) is displayed in the preceding figure.
Zoiper
Zoiper is a third-party SIP phone that is supported by all major OS platforms.
The preceding screenshot displays its interworking with a WebRTC client registered
via a common SIP server.
[ 281 ]
Native SIP Application and Interaction with WebRTC Clients
Boghe
Boghe is an RCS-enriched SIP softphone; it shows compatibility not only with
WebRTC-based audio and video communication but also with Instant Messaging,
Presence, MSRP file transfer, and so on. The UI for Boghe IMS / RCS SIP softphone
on Windows OS is displayed in the following figure:
The SIP softphone, Boghe IMS/RCS client
The RCS capabilities of a Boghe SIP softphone can be used after specific modules such
as XCAP, Presence, and MSRP are deployed on the WebRTC SIP server. To read more
about the RCS features, refer to Chapter 8, WebRTC and Rich Communication Services.
WebRTC unsupported browsers interacting with
WebRTC clients
Internet Explorer (IE) is the default browser for any Windows user. However,
as standard WebRTC functions are not supported by IE, there is a prominent
requirement to use a plugin that can perform the job of media capture and streaming
using the SIP protocol. The webrtc4all plugin aimed to achieve the end goal but
was unable to realize it. The webrtc4all plugin is an extension meant to support
WebRTC's PeerConnection JavaScript API in all browsers on the Windows OS,
including IE9+. It was part of sipML5 solution. The source code of the webrtc4all
plugin can be found at https://code.google.com/p/webrtc4all/.
[ 282 ]
Chapter 9
The Temasys plugin also brings support for WebRTC to desktop versions of Safari
and IE. These plugins can be downloaded from https://temasys.atlassian.net/
wiki/display/TWPP/WebRTC+Plugins.
The intercommunication between a non-WebRTC-capable and a WebRTC- or SIPbased end point can be realized by the Flash plugin, which accesses the webcam
and microphone of the user and uses SIP for signaling. A good example of this is the
sip.js project, which uses the Flash network to make intercommunication between
non-WebRTC browsers such as IE and WebRTC browsers such as Google Chrome
a reality. A live demo can be found at http://theintencity.com/sip-js/phone.
html?network_type=Flash.
A screenshot of the Phone app is shown as follows. It is registered with the SIP
server, receiving incoming calls from a WebRTC client and requesting permission
to access user media through Adobe Flash.
A SIP-JS Web client using Flash
Note that media flow difficulties might arise, resulting in abrupt call hang
or termination after ringing, but this is solvable using the Media Server.
Linux OS
Linux OS has a rich variety of flavors and each flavor has a different purpose.
The WebRTC communication client must be supported by a majority of flavors
of Linux to aid the Linux users' community. Some noteworthy OS candidates are
SUSE, Red Hat, Ubuntu, Fedora, and CentOS.
[ 283 ]
Native SIP Application and Interaction with WebRTC Clients
Native browser support for WebRTC clients
This section explains WebRTC compliance with major web browsers on
Linux-based OSs.
Chrome browser support for WebRTC clients
Chrome on the Linux operating system supports WebRTC functionality without any
hassles just as in the Windows operating system. The popups to allow a web page
to capture media from the microphone and camera, Geolocation, and so on are also
similarly displayed.
WebRTC functionality and traces displayed in a Chrome browser in the Linux OS
For older versions of Chrome, to enable screen sharing through a WebRTC client,
we should verify that the required flags of Chrome are set. This can be achieved by
typing chrome://flags in the address bar of the Chrome browser and verifying that
the required flags are all set.
Flags set for WebRTC functionality screen share
[ 284 ]
Chapter 9
The flag, described as follows, must be enabled for screen sharing to work on WebRTC:
Enable screen capture support in getUserMedia(). Mac, Windows, Linux,
Chrome OS
Allow web pages to request access to the screen contents via the getUserMedia()
API. #enable-usermedia-screen-capture"
Mozilla browser support for WebRTC clients
Mozilla Firefox on a Linux operating system supports WebRTC functionality. The
Firefox Nightly Linux operating system also supports WebRTC functionality. Note
that, since 2014, Mozilla Firefox (current version 29 for Ubuntu Canonical) shows full
support to WebRTC.
The preceding screenshot shows a WebRTC client functioning from a Mozilla
browser in real time.
[ 285 ]
Native SIP Application and Interaction with WebRTC Clients
Opera browser support for WebRTC clients
Opera for Linux does not support WebRTC functionality as yet. However, in the
light of the fact that Opera for Windows has WebRTC compliance, we might soon
see Opera Linux with the same capabilities as well.
SIP softphones capable of interacting with WebRTC
clients
There are many Linux-based SIP clients in use. We will consider a few of these to
establish WebRTC interoperability with a desktop-based SIP softphone on Linux.
However, due to interface limitations, advanced features such as Presence, Notify,
and file sharing are not supported.
Kapanga
Kapanga (through the Wine Windows compatibility software) is compatible with
WebRTC clients for communication. The following screenshot shows Kapanga:
[ 286 ]
Chapter 9
Note that Windows-to-Linux compatibility software such as Wine can run
other SIP software meant for Windows OS in Linux OS too.
Linphone
Linphone's open source SIP Phone is available on mobile and desktop environments.
It renders good results while communicating with WebRTC clients. There are marginal
differences between Linphone features for various operating systems' mobile phones
and desktops; however, the base libraries remain the same. The audio codecs generally
supported are G711, Speex, G722, AMR-WB (G722.2), GSM 6.10, AMR-NB, iLBC, SILK,
G729, and Opus. The video codecs are H.263, H.264, MPEG-4, and VP8.
The preceding screenshot shows Linphone communicating with a WebRTC
client. Linphone also offers the web plugin, the demo of which can be found
at http://web.linphone.org/.
[ 287 ]
Native SIP Application and Interaction with WebRTC Clients
Yate
Yate is another SIP softphone capable of interoperability with WebRTC and easily
downloadable from the Linux Software Center. A screenshot of the Yate phone
connecting with the WebRTC SIP server is displayed here:
SFL
An SFL phone is yet another SIP softphone capable of interoperability with
WebRTC. A screenshot of the SFL phone with supported codecs is displayed in
the following screenshot:
[ 288 ]
Chapter 9
Many other SIP phone applications are present to verify the interoperable status
of WebRTC.
Mac OS
The Macintosh desktop OS gives a perfect response when using a WebRTC-supported
browser such as the Chrome browser for audio/video call, presence, Geolocation, and
instant messaging. However, some well-known and useful browsers such as Safari
do not have WebRTC compliance as yet and pose a serious limitation to the usage of
WebRTC interoperability. To tackle this, there is a temporary solution of using the
Flash plugin, which allows for media capture and streaming with the SIP server,
that can then be connected to WebRTC-based endpoints. A good and working
example of a Flash-based SIP client is available at http://theintencity.com/sipjs/phone.html.
[ 289 ]
Native SIP Application and Interaction with WebRTC Clients
Native browser support for WebRTC clients
The Chrome browser on Mac OS supports WebRTC calls, both audio and video.
This is displayed in the screenshot here:
[ 290 ]
Chapter 9
The Mozilla browser on Mac OS supports WebRTC calls, both audio and video.
This is displayed in the screenshot here:
After discussing the browser-based WebRTC accessibility options, let's now
consider the existing SIP solution that should be able to interoperate with the
WebRTC endpoints.
SIP softphones capable of interacting with
WebRTC clients
Mac OS can interoperate with WebRTC using many of its native-build SIP
softphones such as Linphone 3CX, Jitsi, and Zoiper. They deliver WebRTC
interoperability when traversed via the media server for transcoding.
[ 291 ]
Native SIP Application and Interaction with WebRTC Clients
iDoubs
The iDoubs SIP client is also an open source SIP phone that bears RCS capabilities.
A screenshot of the iDoubs SIP client running on Mac Version 10.6 Mountain Lion,
authenticating itself with the WebRTC SIP server is displayed here:
Note that iDoubs is an RCS-rich communication client from Dubango, and its
source code is free for native application building for the Mac and iOS operating
systems. Also, the WebRTC-favorable codecs such as PCMA, PCMU, and VP8 are
supported. For more information, refer to https://code.google.com/p/idoubs/
wiki/UserGuide.
[ 292 ]
Chapter 9
Jitsi
Jitsi is a multiplatform open source SIP softphone. It runs on Mac OS as well. Jitsi
supports RTP, Secure RTP, and ZRTP for encrypted media transmission. The audio
codecs supported are Opus, SILK, G.722, Speex, iLBC, G.711 (PCMU and PCMA),
and G.729. For video it can support H.264, H.263, and VP8. The royalty codecs need
purchased licenses, of course.
The Jitsi SIP client calling a SIP user from Mac OS
The preceding screenshot depicts a Jitsi softphone in the process of making a call.
It is worth noting that besides SIP, the Jitsi softphone also supports the XMPP
protocol and can send instant messages to MSN, Yahoo, and ICQ/AIM. Jitsi can be
downloaded from https://github.com/jitsi/jitsi.
[ 293 ]
Native SIP Application and Interaction with WebRTC Clients
WebRTC unsupported browsers interacting with
WebRTC client
The Safari browser on Mac OS has not yet come up with support for WebRTC
media APIs, but the Flash plugin support enables us to make a web client capable
of interoperability with WebRTC clients, also discussed in the WebRTC unsupported
browsers interacting with WebRTC clients section. The following screenshot uses a
customized version of SIP-JS open source code, used to communicate with WebRTC
users. It shows the WebRTC functionalities and traces displayed on a Safari browser
running through the Flash network:
WebRTC functionality and traces displayed on a Safari browser running through the Flash network
It is to be noted that, while Safari on Mac supports the Flash plugin, the iOS tablet
and iOS phone do not support Flash. The WebRTC accessibility options in the
iOS tablet and iOS phone will be discussed under the iPhone/iPad IP applications
interacting with WebRTC clients section later in the chapter.
[ 294 ]
Chapter 9
Android OS for mobiles
Android for mobiles such as Samsung, Micromax, and Karbon and for Android
tablets, such as Nexus, has been thoroughly tested for WebRTC adherence,
as interoperability between mobile browsers and desktop browsers is critical
for the growth and acceptance of WebRTC.
Native browser support for WebRTC clients
Android phones' and tablets' mobile Chrome browsers support WebRTC.
The screenshot depicting the Chrome mobile browser seeking user's permission
to access the camera and microphone is seen here:
WebRTC functionality from an Android phone's Chrome browser
[ 295 ]
Native SIP Application and Interaction with WebRTC Clients
A Screenshot depicting the Nexus Android tablet engaged in WebRTC
communication through the Chrome browser is displayed here:
WebRTC functionality from an Android tablet's Chrome browser
[ 296 ]
Chapter 9
Mozilla on Android tablet and phone also shows seamless support with WebRTC.
The following screenshot shows the WebRTC web client in action from the Mozilla
mobile browser, making a call to another WebRTC client.
While the mobile browsers for Chrome and Mozilla show full support for WebRTC,
the Opera browser on Android does not support WebRTC yet.
[ 297 ]
Native SIP Application and Interaction with WebRTC Clients
Android phone's/tablet's SIP applications capable
of interacting with WebRTC clients
In the process of determining the interoperability status of a WebRTC application,
some popular SIP-based Android applications that run on both Android tablet and
Android phone were tested. The following are some popular SIP apps that can be
considered in this respect:
•
SIPdroid: This is an open source Android-based SIP application. It shows
audio compatibility with a WebRTC client as long as the Media Server
plays the role of transcoding. SIPdroid in action is displayed in the
following screenshot:
[ 298 ]
Chapter 9
•
Linphone: As mentioned earlier for other OSs, this is a popular SIP call agent
application for Android OS as well. An audio call between a WebRTC web
client and Linphone application that traverses through the Media Server is
a successful scenario, while a video call faces some difficulties in delivering
the remote video even though the WebRTC client user is able to view both
remote and local videos.
The preceding screenshot of an Android mobile phone depicts an ongoing audio call
with a WebRTC client.
[ 299 ]
Native SIP Application and Interaction with WebRTC Clients
Developing a lightweight Android SIP application
To demonstrate WebRTC interoperability (Presence, audio/video call, message)
with a native Android client, it is a good option to develop a lightweight Android
SIP application and customize it for your company's requirements, such as logo,
theme, and so on. This also enables added services to the WebRTC client, such as
Geolocation, visual voicemail, phonebook, and call-control options, to be set from an
Android application as well.
An overview of the steps to build a customized SIP application in Android is
as follows:
1. Get the development environment, which is an ADT bundle for the OS, in
use from http://developer.android.com/sdk/index.html.
2. Import the sample application provided under samples to get a hang of the
development process.
3. One can import an open source SIP phone or develop one's own from
scratch. In case you choose option two, take care of the SIP stack and codecs
to handle the signaling and media traversal from the device.
4. Deploy and run the SIP phone on a simulator/physical Android phone to
register with the SIP server and make calls.
5. One can also add additional views for features such as importing contacts
into a WebRTC-synced phonebook from an Android phonebook.
As the GPS on a phone achieves Geolocation with greater precision than the
HTML-based Geolocation, it is a good idea to implement Geolocation using GPS
on a phone.
For more information on Android native support for SIP, refer to
http://developer.android.com/guide/topics/connectivity/SIP.html.
[ 300 ]
Chapter 9
Windows OS for mobiles
Unlike the Windows desktop OS, Windows mobile shows no support for WebRTC
communication features from its native browsers. This can be directly tested by
opening the SIPML5 demo page directly from the Windows mobile phone.
We can see that the Login button is disabled. This is because the webpage did not
find WebRTC support in this browser. We can use a native windows phone SIP
application such as Zoiper to interact with the WebRTC web client. We also have
the option of developing our own SIP-based Windows 8.1 phone application, which
provides a better compliance with WebRTC than the third-party software.
[ 301 ]
Native SIP Application and Interaction with WebRTC Clients
Apple iPhone
Unlike the iOS Mac OS, the iPhone shows no support for WebRTC communication
features from its mobile Chrome browser. As iPhone is a widely used device, it is
expected that soon some means for intercommunication between the iOS phone and
WebRTC users will be established. Developers have the option to advertise the use
of the existing native SIP applications in store, to set up media transcoding support
in the WebRTC infrastructure, or develop a new one that already embeds the
WebRTC-supported codecs. Let's study this in detail in the next section.
iPhone/iPad IP applications interacting with
WebRTC clients
For intercommunication between WebRTC and iPhone, we can use some native
iPhone-specific SIP applications. Linphone is a viable option. Tested for functionality
through the FreeSWITCH Media Server, a Linphone application is able to take
audio calls without any trouble from an iPhone. A Screenshot of Linphone
successfully registered with the SIP server and ready to make calls is displayed
in the following figure:
[ 302 ]
Chapter 9
The iOS tablet also shows interoperability with the WebRTC client through
Linphone's native application. The media server takes care of codec exchange
on the network side.
The preceding screenshot is that of a Linphone SIP client on an iPad. This can
be downloaded from the iTunes store at https://itunes.apple.com/in/app/
linphone/id360065638?mt=8.
[ 303 ]
Native SIP Application and Interaction with WebRTC Clients
Developing an iPhone SIP application
Similar to the native SIP application development for Android, to demonstrate
WebRTC interoperability with an iOS device, the iOS developer team also has the
option to build a native iOS application using Xcode. The advantages of doing so
are personalized appearance; enhanced functioning; RCS support; and the addition
of many WebRTC client-specific services, such as profile management, phonebook,
and others.
An overview of the steps to build a customized SIP application in an iOS is
as follows:
1. Get the Xcode development environment on Mac.
2. Build an application with the SIP stack and codecs to handle the background
functionality of calling and media flow.
3. Provide a user interface for user interaction such as call, phonebook,
and authentication.
4. Run and test the application on an iPhone/iPad simulator.
Run the application on a real iPhone after obtaining the developer's
license. For more information on iOS app development, refer
https://developer.apple.com/devcenter/ios/index.action.
Summary
In this chapter, we saw the various means and resources to enable the adoption of
WebRTC communication technology by the masses. This was achieved through
the analysis and study of WebRTC-capable browsers such as Chrome, Mozilla, and
Opera. This chapter also uncovered the technique to enable other noncompatible
browsers, such as IE on Windows and Safari on Mac, to communicate with WebRTC
clients using the Flash plugin till the time they do come with native support for
WebRTC APIs. In addition to this, we also saw many desktop-based native SIP
clients and mobile platform-based SIP applications that are able to receive and make
calls to the WebRTC web client. Chapter 10, Other WebRTC Use Cases, is an interesting
look at the use of the WebRTC technology in various trades such as online marketing
and consultation. The chapter also shows how WebRTC can play a pivotal role in
delivering communication features in gaming and educational sites.
[ 304 ]
Other WebRTC Use Cases
Creative minds can use WebRTC for other purposes besides just communication.
Games, real-time marketing, and targeted advertising services can be built over
WebRTC too. In this chapter, we shall discuss more of such applications, keeping
in mind the role played by WebRTC.
We begin with a simple Team Communicator application with WebRTC and
progress to make it a customized Communicator for specific enterprise segments,
such as branches and back-office communications; for Customer Relationship
Management (CRM) systems; and for network and operations tools. We will
cover the use of WebRTC in the HR management tool as a separate section, since it
involves keeping employees' records and recruiting new candidates. New ways of
social networking are the burning need of the hour as users find themselves devoting
a large share of their time to get in touch with their family and friends over social
networking platforms. Thus, the book also explores the applicability of the WebRTC
communication engine for social networking platforms.
How retail services that involve e-commerce and customer care can benefit from
WebRTC in a big way will be explained in this chapter. The next section describes
WebRTC's implementation in fun- and entertainment-based use cases such as online
multiparty games, streaming music, Video on Demand (VoD), sharing an ongoing
movie via multipoint conferencing, interacting through group chat or conferencing
while watching a live broadcast of a match, and so on. This section describes how
there is plenty of room for more creativity and innovation with WebRTC. The
chapter ends with how WebRTC is applied to education by connecting classrooms
across the geographies.
Other WebRTC Use Cases
The purpose of this chapter is to inspire the reader to think of varied ways to apply
WebRTC applications, not necessarily plain communication, that can be beneficial.
The true potential of WebRTC is realized when it's integrated with the foundation of
the signaling protocol. Since the existing WebRTC standards do not provide a fixed
signaling protocol, it is up to the integrator to use any means of signaling they find
best suited to the work environment.
Unified Communicator
The easiest and the most likely application of WebRTC is building a unified
Communicator and target enterprises. WebRTC can easily fit into the role of a
Team Communicator by virtue of its simplicity. A WebRTC communication endpoint
is purely a web-based application that does not require the user to install any
additional plugin or set it up before making calls. To get connected to their teams,
users only need to be logged in to their WebRTC SIP accounts through a browser.
This way, the team can share files, text-chat, conference, share screens, make
audio/video calls, or simply know each other's device capability and presence status.
Team Communicator
The WebRTC communication client is essentially a browser-based phone having
features such as audio/video calling, Instant Messaging, and file sharing. The
WebRTC-based software is a web-based SIP phone using HTML5 and JavaScript.
It can interact with another web phone or softphone with the help of a middleware
proxy server that acts as a convertor between SIP over WebSocket and SIP over
TCP/UDP. Features expected from a standard Communicator are audio/video calls,
instant messages, conference calls, file sharing, contact book, and user presence.
Some sample screenshots of a unified Communicator for team communications are
shown on the following pages:
[ 306 ]
Chapter 10
The following screenshot depicts a typical home screen with an ongoing call in a
web-based unified team Communicator client. It has frames for phonebook, profile,
calls, the call history page, and so on.
The following screenshot depicts a multiconference session between team
members. Such a scenario is possible while brainstorming ideas with people
from different locations.
[ 307 ]
Other WebRTC Use Cases
Since WebRTC does not require a special plugin or any installation process
for participating in a call, such calls can be taken from any computer that supports
the latest version of Chrome, Mozilla Firefox, or the Opera browser in any computer
or mobile device.
[ 308 ]
Chapter 10
The following screenshot depicts the use of the screen-sharing feature of WebRTC to
share the Eclipse Integrated Development Environment (IDE) screen with the team
manager to show the actual coding in progress.
Code review through screen sharing in a WebRTC-based inter team communication tool
[ 309 ]
Other WebRTC Use Cases
Since this use case is only aimed at intercommunication between team members
in an office and does not necessarily need a telecom operator's network, it is feasible
to use a simple signaling mechanism such as plain WebSocket signaling through
a signaling server; for example, Node.js. You can find the detailed description in
Chapter 1, Running WebRTC with and without SIP.
This way, WebRTC's communication technologies can help build a unified
Communicator for team communication. Further, we shall see how other
collaborative applications such as Geolocation, voicemail, and Internet Protocol
television (IPTV) can also be integrated with the WebRTC communication platform.
Customized Communicator for specific
enterprise segments
A SIP WebRTC solution is intrinsically only a web technology with browser support.
It is possible to integrate WebRTC-based communication services into almost any
kind of online web project. WebRTC can serve as a communication medium between
branches and back to the Network Operation Center (NOC) that involves large
groups of people spread across different geographies, or for Business to Business
(B2B) communication needs.
For an enterprise, WebRTC can serve as a communication technology over LAN to
help users to communicate within an office without having to set up any specialized
software and hardware except for the web server and the signaling server. This
will greatly reduce expenditure to third-party call agents or service providers as all
the communication is taking place over an IP network. Enterprise communications
would be transformed from a fixed point-to-point architecture to an integrated,
multidevice, mobile architecture. WebRTC calls at the employees' desks can be
preceded with a screen display of call-related information with the ability to
selectively answer or not answer the call.
Branches and back office communications
In this section, by back office system processes, the task of generating an order,
provisioning, shipping, invoicing, and applying the payment are implied. These
processes are essential to help run an organization itself. Generally, these processes
are heavyweight and involve a lot of tracking and record keeping.
[ 310 ]
Chapter 10
These activities can be broadly classified into three groups:
•
Enterprise Resource Planning (ERP): This is used to streamline internal
business processes and operations. It involves the backend processes such
as product planning, development, manufacturing processes, finance,
accounting, and so on.
•
Supply Chain Management (SCM): This is used for maintaining logistics
with external partners. It involves activities such as order tracking, inventory
control, product distribution, transportation, and so on. The Communicators
within the SCM domain include suppliers, manufacturers, distributors,
and partners.
•
Field Force Management (FFM): This is used to keep employees organized
and coordinated for better output. The Communicators involve technicians,
ground engineers, transporters, and so on.
Besides automation, for the preceding software, communication plays a key role
in determining the success for each activity. In the existing system, the modes of
communication are restricted to e-mails and phone calls with PSTN calls, SMSes,
and faxes also in some cases. It's a difficult task to assimilate information from
various sources, maintain histories of calls and e-mails, check the progress of these
calls and e-mails, and so on. The following diagram shows the existing interaction
between various players in an organization's operation:
[ 311 ]
Other WebRTC Use Cases
WebRTC can bridge the gaps of communication barriers between various parties,
and also provide the one-stop solution to handle all interactions. Needless to say,
this saves a lot of investment in time, software, and hardware to keep the parties
well communicated. The following diagram shows the WebRTC-based interaction
between various players in an organization's operations:
By implementing the PSTN and GSM gateways, a WebRTC client can even
reach out to laborers and on-the-move workers for coordination. Also, with
the provided Geolocation and Presence capabilities, the location and availability
status of employees can also be tracked real-time. The following screenshot shows
WebRTC and Geolocation services as part of the Work Force Management (WFM)
and depicts how contacts are located on the map using Geolocation API's of
browsers and the GPS of phones.
[ 312 ]
Chapter 10
Using this WebRTC client, the manager may call or send an instant message to a
technician based on his proximity to the specific area as depicted from the map:
WebRTC and Geolocation services as part of Work Force Management
The Customer Relationship Management
system
The CRM system involves customer-facing interactions such as order capture,
configuration, pricing, and order query. While ERP is used for internal
communication, CRMs facilitates collaboration between customers. CRMs are used
more like a sales-and-marketing tool to stay in contact with current clients, track
opportunities, and create new business opportunities with leads, such as Salesforce,
BPMOnline, and so on. As evident from the description, a CRM solution mostly
requires an engaging interface. With WebRTC, the user engagement levels can
reach new heights as members can directly connect with each other in a call without
navigating away from the CRM page or using their physical mobile devices to make
calls. This is in contrast to the existing system of writing mails to each other and
awaiting replies.
[ 313 ]
Other WebRTC Use Cases
The life cycle of transforming a lead to closing deals spans several systems, including
CRM, ERP, and SCM, and involves a number of roles, including call center agents,
shipping clerks, order process analysts, and managers. Communication via e-mail or
phone may take several minutes or days to complete. Also, such processes require
an approval and oversight from higher management from time to time. This is
where WebRTC comes in. The Sales and Marketing life cycle, combined with rich
communication features, can accelerate the growth for a business organization as call
history, purchases, documents exchanged, and everything else can be done at one
place without relying on external service providers.
A sample screenshot of the CRM system designed using WebRTC as the
communication medium between various parties is shown as follows. It
demonstrates a typical home page for a CRM client and shows the tabs for
Work History, planned Work items, Contacts, and various other data available.
Also, it shows the profile pictures of people who are marked as important:
The home page of a web-based CRM solution
[ 314 ]
Chapter 10
The following screenshot shows a presentation shared between multiple users over
the WebRTC CRM solution. In addition to viewing a current ongoing presentation,
users may also send files or engage in a group or private chat. The files shared with
each party are stacked in the drawer area. The drawer area refers to the Shared
Items window that is present at the bottom panel of the following screen:
Video conference and presentation on WebRTC CRM solution
Note that a CRM system is independent of the OS or browser version
but WebRTC is not. A list of WebRTC-supported devices and
interoperable endpoints is given in Chapter 9, Native SIP Application
and Interaction with WebRTC Clients. Besides this, it is also possible to
connect to GSM- or UMTS-based mobile users via WebRTC. So, with
some additional setup, a CRM system designed with WebRTC can
have absolute phone integration.
[ 315 ]
Other WebRTC Use Cases
The following screenshot shows how a mobile user is also able to participate in a
conference session using their mobile browser on WebRTC.
Video conference and presentation on WebRTC CRM solution from a mobile browser
The following figure gives an overall architecture for the deployment and integration
of WebRTC-enabled communication with a CRM setup. The services such as
reporting tools, handling workflow, and scheduling, are part of services under the
Business Layer. The interaction with third-party servers is handled via web services.
The outbound and inbound call handling is handled via WebRTC from the online
CRM's browser-based customer interface.
[ 316 ]
Chapter 10
Additionally, the Presence feature of SIP provides an indication of when a user is
reachable to respond to calls. In a situation when the user is not reachable, the logic
to redirect the call to his voice box is defined in the SIP server. The integration of
advanced SIP services such as Virtual Private Network (VPN) and call routing are
provided by the SIP Application Server; media services such as IVR, Dual Tone
Multi Frequency (DTMF), and transcoding are provided by the Media Server.
User End (online CRM client, browser WebRTC support, attached media device)
Call
IP network
Web Application Server
Call
SIP Application Server
Presentation Layer(Ui, scripts styling, WebRTC)
SIP
Services
Controller
Model
View
Business Layer for we webclient
Media Server
(IVR . VoiceMail)
Services
Web
services
audio
files
Underlying Business Engine
business
logic
data access
components
DB
There are various roles and responsibilities of a CRM besides the ones mentioned in
this section. Since the subject at hand is to make the CRM screen capable of making
instant calls, the WebRTC-related points are highlighted. The implementation and
design of other features, such as offline access, tickets, escalations, incentives, quotes,
expense management, and automation, are left to the developers and integrators of
the CRM application.
[ 317 ]
Other WebRTC Use Cases
This way, WebRTC's communication technologies can help build a unified
Communicator that is aligned to the goals of both the operator and the enterprises.
In fact, the Communicator use cases described earlier demonstrate the potential to
build a value chain that can bring financial and commercial benefits, operational
savings, and process streamlining to the vertical industry segments involved. WebRTC
can also play a pivotal role in creating new market business opportunities for the
operator, service provider, web application management firm/enterprise, and so on.
Network Operation Center
NOC is the main entity that is responsible for emitting control over the enterprise
network, which can be a computer system or a telephone system. WebRTC technology
provides the opportunity to merge the real-time communication ability with in-context
usage and benefit to the NOC functionality. The NOC admin can view the Presence
status of users to determine their availability and call them as they are logged into
their WebRTC accounts from their systems. As a user reports a fault or raises a ticket to
resolve a problem on his system, the NOC representative can get in touch with directly
and them instantaneously. The following screenshot depicts an NOC admin's control
screen with tabs for Hardware, Software, and Network. The admin is also authorized
to monitor traffic and exercise control over the system behavior remotely. Of course
the screen-sharing feature of WebRTC is very valuable for this use case.
[ 318 ]
Chapter 10
Every NOC personnel have their own ID for signing into the WebRTC portal with
privileged access. The users on the other hand sign in to their office portals with their
IDs that are also callable. The NOC admin will get a list of issues or matters in their
inbox and they can contact the concerned user from the web portal itself.
The human resource management tool
An HR personnel must be able to manage various user groups and should be
immediately reachable in case of concerns. In addition to this, an HR personnel also
must primarily manage two things, that is, communicate with candidates for an
opening post directly from the job portal, and for interviewing and recruiting the
candidates. Hence, such a system requires database management for user skills
and provisions for immediate audio/video communication if the user is online.
Communicating with candidates for an open
post directly from the job portal
A recruitment-based WebRTC client allows an HR personnel to make direct
audio/video calls in context with the available requirements. A WebRTC client
allows sharing the skill set and profiles to the concerned person seamlessly during
a call. Thus, it's applicable to be used as an HR management tool. A simple call can
be directed to any particular HR or the manager as per the associate profile. HR
personnel, managers, and associates have their own login credentials, using which
they can track a particular department. The record of requirements for any particular
project and skills can be maintained for HR personnel and managers. The user's
profile preview from the contact book too should contain a brief summary of their
skill set and work history. By enabling high definition video calls, the interaction
between the recruiter and the candidate will become lifelike. The following
screenshot gives a good representation of this use case.
[ 319 ]
Other WebRTC Use Cases
The skill set of the user is displayed alongside the user's call window for easy
reference while talking to a client on their expertise and work experience.
A sample project for a WebRTC-based HR communication system is provided along
with the book. In this proposed WebRTC-based interviewing and recruitment
system, the applicants for a job are sent a notification for a scheduled series of
interviews through the WebRTC message service. The file sharing service of
WebRTC enables a candidate to send in their resumé without employing the
traditional e-mail service. The WebRTC audio/video call facility enables both
parties, the recruiter and the applicant, to engage in an interview session. In case
the application requires technical testing or problem solving, the screen-sharing
capability of the WebRTC agent enables the recruiter to see the applicant typing in
the code and executing it for output in their own machine.
[ 320 ]
Chapter 10
Social networking – targeting consumers
WebRTC develops user interaction by providing a simpler, quicker, and hassle-free
medium of interconnecting two call parties. With the power of web-based social
networking, WebRTC will bring about a massive wave of change in the way people
socialize over the Web.
Social networking platforms
With WebRTC, we may build a standalone social networking platform or a common
platform to let users link their social networking profile and interact over WebRTC
communication technologies. The array of features begins right from the process
of signing up/logging in through the token-based OAuth mechanism. Further,
integrating the friend list by importing friends from other accounts, finding new
people through friend suggestions, and search options are part of the solution. The
following screenshot shows the flow of how to access social networking solutions
and make WebRTC calls:
[ 321 ]
Other WebRTC Use Cases
A WebRTC-based social networking platform is realized by giving an interactive
outlook and an array of interactive services, such as sharing pictures/videos/
posts, click to call, sharing updates about life events, and others. With the advanced
features of SIP, the communication choices can range from chat, group chat, audio
call, video call, multiparty call, file transfer, real-time location updates, Presence and
status updates, and so on. Also, the device capability through which a user accesses
the WebRTC social networking client at that point of time can be exchanged; these
device capability factors include the OS name, whether the camera and microphone
are attached, whether the user is on an RCS-enabled client, and so on. Other features
such as sharing posts and media publically can also be done over RCS-specific
protocol such as MSRP as an alternate option. A timeline-based history of shared
posts is a desired requirement for social engagement.
A sample view of the WebRTC-enabled communication through a social network
portal is shown in the following screenshot. The mock web view shows the user's
self-profile section on the extreme left, the history of shared updates from others in the
middle section, and the friend list on the extreme right. It also depicts an ongoing text
chat and video call with two different users over WebRTC. Likewise, many additional
features can also be integrated with a WebRTC-based social networking platform:
[ 322 ]
Chapter 10
WebRTC's interaction with other social networking accounts such as Facebook,
Google+ through OAuth, messages via SMTP, and inviting existing friend contacts
give an upper hand to WebRTC's role in enabling the user to interact with people
around the world in a text/audio/video conversation.
Dating sites with anonymous call and chat
Of late, the trend of dating sites and web matrimony platforms is on the rise.
The prime requirement of users here is to interact with the other party without
revealing too much of their actual identity details, such as personal mobile number,
e-mail, or even their name, at the first instance. For such instances there could be an
anonymous WebRTC call session between the users. Here, the user is assigned an
alias URI for every session and the user's actual identity such as their telephone SIP
URI is kept secret.
The screenshot of one such site is given as follows. This page is the homepage
where a user can navigate through a list of persons or filter them as per their
interests or location:
[ 323 ]
Other WebRTC Use Cases
The following screenshot depicts an audio/video call, voicemail, or a chat option
alongside the person's profile that the user has set the focus on. The embedded
functionality to make calls lets the user to get connected with the other user instantly.
This use case has been discussed to exhibit the low-lying fruits of the WebRTC
technology. It is possible to track the user by packet sniffing such as lawful
interception through analyzer tools such as Wireshark and it is also possible to mask
the user identity by assigning a temporary user ID and setting up 1-minute timers
for every session.
[ 324 ]
Chapter 10
Moreover, the public IP of the other party that might be visible in the SDP can
also be masked by using a gateway in the middle. The service provider can come
up with many ways to charge for the call, such as recharge the account through
payment gateways before making calls and then charge for calls per minute or make
the first minute of the call session free but require payment for the conversation
session to continue.
Retail services
Retail services cover a wide spectrum of many big and small services. The act of
proactive marketing from advertisements/offers to answering calls regarding
the product's enquiry or complaints is all covered under retail services. This also
includes various other services such as connecting users to online marketing agents
after clicking on an advertisement, invoice tracking through Geolocation, and
updates from the SCM system regarding the consignment delivery. WebRTC can be
effectively used to fasten the process and inject transparency for the end user to get
connected to all parties with the click of a button on a web page. In contrast to this,
the traditional scenarios of looking up the call center toll-free number from the Web,
notifying and keying it down on mobile phones, waiting for the circuit-switched call
to be converted to IP-based at network, and then being able to talk to a customer care
person seems long and tedious.
We shall start the discussion with the WebRTC-based Online Marketing System and
end it with WebRTC integration with the existing contact centers.
WebRTC online marketing centers
Marketing through advertisements is the most common way of luring customers
to buy a product. However, the goal is not reached until an order is finally placed.
Enabling the journey between the user clicking on an advertisement and convincing
him enough to finally click on the buy button is a tough job. Some sites employ a live
chat facility to let the users express their interest or concerns regarding a particular
product and others employ an old e-mail-based system to achieve the same result.
WebRTC can help the process here.
[ 325 ]
Other WebRTC Use Cases
A sample screenshot of an online marketing application integrated with WebRTC
communication mode is shown as follows:
Many a times, people find it better to talk to a person, such as a shopkeeper, about
a certain product before actually shelling out money for it. Also, a number of facts
about a particular product are not depicted well in a picture or textual description.
WebRTC blends in perfectly in such cases, which lets sellers to directly communicate
with the prospective customers by further talking about a product before they buy
it. This way the given proposal will not only enable marketing agents to personally
introduce their product to the users, but also fetch quicker results for the users as
well.
[ 326 ]
Chapter 10
WebRTC contact centers
Call centers have come a long way from Private Branch Exchange (PBX) to today's
virtual call centers. The modern call center infrastructure provisions maximum
business process automation. The routing solution on the network side is built on
an Automatic Call Distributor (ACD)-based and IP-based platform, supporting the
receipt and intelligent routing of incoming calls. The call center agents use unified
Communicator softphones.
Typically, a call center solution today should contain an ACD/multichannel
routing, reporting, and analytics tool, IVR, and self-service automation through
user DTMF input, outbound dialing, and multichannel recording. Over-the-top
enhancements include knowledge management, Quality of Service, admin monitoring,
and WFM. Often, calls to call centers are also followed by customer satisfaction
surveys. The following screenshot displays a call center architecture with WebRTC
end points:
Customer A
WebRTC call
Customer B
live chat on Web RTC
Customer C
WebRTC call
Reporting Tools
SIP WebRTC
SBC
Customer D
send Email
Customer E
makes PSTN
call
analytics
ACD / routing
admin cont.
Automation
CRM
EMail gateway
PSTN gateway
centralised
signalling
Server
WFM
m
media
Server
IVR/ Input System
Customer F
send SMS
data centre
account info
of caller
call recording
SMS gateway
speech analytics
Contact centre
Branch 1
Contact centre
Branch 2
This section described the ease of processing a call from the user end to the contact
center. The next sections deal with some contact center use cases that include the
customer calling up customer care to fetch answers to queries.
[ 327 ]
Other WebRTC Use Cases
Users contacting customer care
In the present day scenario, for an aggregated customer to address his concerns
with a customer care agent, they have to first look for a toll-free number on the site,
dial the number, navigate through a chain of IVR and response input, and then
be connected to an agent. With the introduction of a WebRTC-based click-to-call
service on the web page, a customer can save himself a lot of effort. For example, a
consumer using their smartphone interacts with an airline to change a return ticket.
The consumer uses WebRTC-integrated services to select an interactive chat response
and engage in a live conversation with a customer support agent to obtain a new
boarding pass. The experience is simple, fast, seamless, and strengthens the overall
customer satisfaction. Systematic, real-time marketing, and offer management would
become much more precise for customer service operations.
WebRTC enables browsers to be another end point for customer-to-call center
interaction besides mobile phones, landline phones, e-mails, and live chats. In fact,
WebRTC-based live interaction between a customer and a call center executive is
quicker and a more sophisticated way of resolving issues, then and there with just
the click of a button on the web page. WebRTC will not only provide direct IP-to-IP
calls but also fosters the development of more specific call routing right from the
start, a task that is currently handled by a complex IVR system and response.
For example, answers to customer queries regarding the whereabouts of a store and
availability of a product. Alternatively, suppose that a user wants information on the
stores selling a particular product around a user right now, and then they can just
contact the call center from the web page or their phone. The customer care officials
at pronto call center use the retail measurement API to find out about all stores
selling the particular product near the user. After collecting the information, the call
center official shares the information with the user on the same call.
WebRTC is a revolutionizing technology that enables one to call other people
through a browser. With the help of gateways, it is also possible to make calls from
WebRTC to a traditional mobile or telephone system and vice versa. In cases where
the user is calling through a WebRTC client, his real-time location can be fetched
using the HML5 Geolocation API and shared with the customer care executive
so that the user doesn't explicitly have to share his location. The user end devices
could be any mobile phone (3G/GSM/PSTN) for GSM calls or WebRTC-supported
browsers (for example, Google Chrome, Opera, and Mozilla Firefox) for WebRTC
calls. The customer care center executive is able to take calls via the WebRTC
API on his web browser. The network consists of the SIP signaling server, Media
Transcoder, Application Server for call queue logic, and third-party retail APIs for
finding answers to user queries.
[ 328 ]
Chapter 10
A sample component diagram using the Kamailio SIP server for SIP over WebSocket
to SIP signaling, FreeSWITCH for media management, Application Server to host
the web application, and third-party retail APIs for information retrieval is shown
as follows. As you can see in the following diagram, there are many endpoints to
reach the customer care center (more information on WebRTC to GSM network
connectivity and WebRTC to legacy PSTN network connectivity has been described
in Chapter 4, WebRTC Integration with Intelligent Network and Chapter 5, WebRTC
Integration with PSTN, respectively). Of course a customer care center has the
option to not set up the architecture itself, but rather to use the existing network
of conversion services by telecom operators.
Kamilio sip
server
Freeswitch
server
application
server
Nelson retatil
measurement
API
Call centre
Pstn phone
Modile phone
Smart phone
Nelson retatil
measurement
API
Sip soft phone
Pstn phone
Pstn phone
Now, we shall progress towards the application of WebRTC in nonconventional
areas, such as healthcare, which is described in the next section.
Health care
As mobile technologies become more widespread, medical institutions are aiming to
take patients from hospitals to their homes. Using the power of the Web, WebRTC
provides the platform for such a health care portal for patients to communicate with
a medical practitioner just with the click of a button on a web page, with the help
of which one can also view the doctor's location, status, and availability. WebRTC
allows options to share files and engage in a multiparty conference for discussion
between many doctors; it can be integrated as the web component of the existing
hospital management system, and much more.
[ 329 ]
Other WebRTC Use Cases
Online medical consultation with the doctor
The WebRTC call functionality can be embedded into the software belonging to big
hospitals dealing with multiple tasks as described earlier. However, here we shall
only consider WebRTC's integration with the online HealthCare portal. Every doctor,
nurse, and other officers in the hospital can have a unique call ID (SIP URI) using
which they can be contacted in times of emergency. The patient can have a direct login
to the WebRTC client after getting their registration ID. Since WebRTC doesn't require
an installation or special equipment, patients will be able to directly call the doctor
without bothering about the setup. Consulting patients and providing diagnostics in
remote areas is also possible with WebRTC. Additionally, the code for recordkeeping,
maintaining call histories with every patient and doctor, sending message reminders
for the next call/meeting, and other hospital communications can be built and
integrated with the healthcare WebRTC project. The following scenarios show how
WebRTC solves communication barriers and aids in delivering services to the user:
•
Users could describe symptoms to doctors and show HD videos that
enable doctors to get a cursory look at surface symptoms, for example,
skin ailments such as rashes, scars, and others. This enables them to
get an initial assessment of the disease.
•
The routine checkups or follow-ups that do not require an actual visit to
the hospital can also be carried out with WebRTC that saves the patient the
hurdle of commuting to the hospital personally to meet the doctor.
•
If a patient has a general question, for example, on the dosage or prescription
such as "Will the XYZ medicine cause a problem with my other dose of ABC
pills?" These brief communications can be easily done anywhere and any
time with WebRTC.
•
Due to the collaborative nature of WebRTC, multiple teams of doctors
from different locations can also study a case together and share views
on the best treatment.
[ 330 ]
Chapter 10
A sample architecture depicting the role of WebRTC in a doctor-patient
communication, where the WebRTC communication platform integrates with
an online healthcare and hospital portal, is shown in the following screenshot:
Hospital Management System
DB
clinical information
system
data access
components
Hospital Application
Web Server
Public
Internet
via
Doctors consultation
co
Online port
portal over WebRTC
Patient
User End (Hospital Portal,
browser WebRTC support,
attached media device)
call
call
Hosital
network
WS SIP Server
call routing
services
Media Server
WebRTC
infrastructure
audio
files
[ 331 ]
Staff to book an appointment
Online portal over WebRTC
Other WebRTC Use Cases
The sample screenshot of a proposed healthcare portal is shown as follows.
This is the initial screen that depicts a portal for patients to find doctors online
that they think can best solve their ailments. The details of doctors are categorized
as per their departments and specialities, so that patients can themselves easily
navigate through to find the doctor they want to be treated by.
[ 332 ]
Chapter 10
The following screenshot shows a video call in action between a patient and a doctor:
Since health is a vital subject, it is axiomatic that patients are serious about every
call and would not react calmly to a long waiting music, complex IVR menu, or a
machine response to their queries. It is hence necessary to build a special program
logic to provide immediate human support to any of the patient concerns. However,
due to workforce limitations from the hospital's end, it is not a practical solution.
Meeting this challenge will be tough since the doctors do not have a direct reachable
number and they cannot be present near the hospital computer/phone system all
day long. By delivering the call through browsers, it can land directly on their phone,
PC, or tablet. This aids in reachability.
[ 333 ]
Other WebRTC Use Cases
Financial services
Financial services, which are mostly of the Business to Consumer (B2C) type in
nature, consist of online trading, banking, insurance claims, and so on. There are
many instances when a secure form of communication is required between a bank
and a user. In present times, these are made using a normal GSM/UMTS phone call
through mobile phones. WebRTC can simplify communication by enabling users
to connect directly through their desktop, mobile, or kiosk browsers. A few relative
use cases are highlighted in the following sections; these include communication
between a bank agent and a customer regarding loans and offers, communication
between an insurance agent and a customer regarding a refund, or communication
from a distressed user at the ATM to the bank to report wrong withdrawal of money.
Communication with financial services
The concept of net banking has become very popular in the last decade as it simplifies
fund transfer, checking account transactions, and going through the latest offers from
the bank. Consider the situation when the user logs in to his net banking account; a
financial agent connects with him over the call to assist in reviewing new loan policies
and offers. This agent-to-customer communication has many advantages. An agent
can discuss new benefits and policies face-to-face with the customer. This way, a user
can direct his queries to the bank representative directly without the need of visiting
the bank. For extra safety there are many state-of-the-art face recognition systems that
can recognize a customer's identity through face and voice recognition. This goal is
realized with WebRTC that enables agent-user communication to be embedded right
inside the web page with many extra features. Of course end users will need to have
access to a well-organized personal document repository that can be used to support
faster and more precise communications with the financial enterprise,
A sample workflow that uses WebRTC to connect to a financial adviser is described
in this section. In the web navigation sessions, the customer accesses the website and
communicates with the customer service or specialized financial advisers on their
device of choice. The web page will display a customer-specific directory that will offer
all of the unique points of contact for various services such as opening a new account,
applying for loans, requesting a credit card, and other such tasks. This directory
would include the branch, customer service, special advisers, loan officers, insurance
specialists, and so on. A click-to-call button alongside every unit/department is
displayed that lets users directly call a bank representative on any matter.
[ 334 ]
Chapter 10
A simplified customer-and-bank agent call scenario regarding opening a new bank
account is shown in the following screenshot. The customer has queries between
different types of account that she is able to resolve directly from the agent on the
bank's website itself without having to make a call from a mobile, write chains of
e-mails, or meet the agent personally.
[ 335 ]
Other WebRTC Use Cases
The banking software is mostly a part of Software as a Service (SAAS) with
additional banking logic as required; also, a CRM system is built within it.
A simple architecture representing a banking portal, core banking system,
and WebRTC components in one is shown as follows:
Bank
Remote user B
Home User A
Banking website
Kiosk / ATM user C
Bank Agent
SIP call signal
SIP Application Server
call Widgets
media signal
Portal Engine
Authentication
Analytics
ebanking
Transaction log
SIP
Services
Media Server
(record call for auditing)
Modules
Debit
Notification
account info
Credit
Loans
Funds
Market feeds
Bill payment
audio
files
Head office
Bank Administration
Core Banking
banking logic
banking
services
DB
The preceding screenshot is of a very high-level view and must be further
refined by adding logic to various entities such as analytics, the authorization
engine, and others.
Insurance claims
The advancing digital economy allows users to invest in various short-term and
long-term benefits. This may be in the form of loans, or new investment schemes
such as fixed deposit, recurring deposits, or even insurance.
In present times, when a user logs in to his online insurance website, the details of
the available insurance plan and other policies, schemes, and offers are displayed.
Users have the option of filling up forms to apply for any scheme online or view
their own insurance status.
[ 336 ]
Chapter 10
However, the users might have instant questions and would need clarification
about certain points mentioned in the terms and conditions, or might want to alter
a certain clause. In the later stages, when the request for insurance funds reaches
an insurance agent, the agent too would want to clarify certain things from the user
before sanctioning the funds. The existing click-to-call features on banking sites are
not actually click-to-call in essence. They merely ask for numbers from users to make
a call on. The users' attention diverges from the content on the website to the mobile
phone awaiting a call. The proposed WebRTC-enriched online insurance system
aims to eliminate these communication hiccups in the existing system.
Consider an example where the information needed by an insurance company after
a minor accident is rapid and there is automatic access to emergency assistance.
An automotive insurance claim after an accident will be processed by the end user
through the use of WebRTC, instead of using third-party services such as e-mail
clients, telephonic conversations, fax, letters, and others. In the case of a car accident,
there are two categories of insurance that can be obtained; health insurance and
automotive insurance. The following screenshot depicts the communication links
between various endpoints involved in insurance through a WebRTC-enriched
online insurance system for auto motives:
Insurance company
Web Server
call to insurance agency
Online
insurance
service
SIP Application
Server
call to hospital
Hospital
SIP
Services
Media Server
(record call for auditing)
call to police station
audio
files
[ 337 ]
Police station
Other WebRTC Use Cases
The application touch points are insurance agency for reporting the insurance claim;
hospital to get the medical reports and for the verification of injuries and the amount
spent on the treatment; and police station to report the accident and property
damage of. Through WebRTC-based communication systems, the parties can engage
in conference calls and finish the verification in minutes; this would otherwise take
a number of days to complete. The documents could be easily exchanged between
parties and the majority of the manual form-filling process could be automated
through a single unified system. As mentioned earlier, the service could be
standalone on a simple WebSocket signaling protocol or could be integrated with SIP
for connecting with other communication endpoints such as PSTN, GSM, and others,
thus meeting the open standard specifications.
Calling from the ATM
The process of reporting the loss of a credit/debit card, enquiries regarding
automatic deductions from the account, or the generation of a new PIN to unlock a
blocked account are often sudden and encountered while at the ATM. The process
of contacting the bank and solving the problem is not only long but also complex, as
the users have to first navigate through the intense IVR system and then authenticate
themselves through a set of numerous questions. Also, the current system is
dependent on mobile device for any communication with the bank. This is far from
the ideal in terms of customer satisfaction. With WebRTC-based communication,
customers can communicate with anyone within the financial services enterprise
from a web browser in an ATM itself, all with the click of a button. The quality of
services for handling customer concerns will improve drastically.
Remote management
Besides the obvious applications, WebRTC can play a significant role in other
spheres such as security, remote device management, and gaming. Here, remote
management refers to the act of monitoring or controlling the activities of connected
computer systems. The WebRTC solution is for anyone who needs hassle-free remote
access, including parents, technicians, engineers, IT consultants, managers, and
system administrators. Users can control remote computers from WebRTC browsers
on Windows, Mac, or Linux and even through mobile browsers on android. They
can use calls or connect via Instant Messaging to chat, send, and receive files; get
remote system information and session statistics; and work behind firewalls, proxies,
and NAT.
[ 338 ]
Chapter 10
Surveillance
The use case involving surveillance recording to be sent as a stream through
WebRTC media API is a low-cost and effective solution to monitor a remote location
without installing any hardware or software other than a desktop with attached
camera. This section describes how WebRTC's feature-rich communication suite can
be extended to security-based use cases. WebRTC allows media capture from remote
devices to local devices. If automated for various intervals with media permission
granted to the website beforehand, a WebRTC-enabled browser can send a call to the
inspecting user's browser at that specified time. This enables the local user to get a
view from the remote IP camera and microphone. The WebRTC site must be under
the HTTPS protocol to achieve this. A sample view form of the Administrator web
page is shown as follows. The local media captures taken from four locations are
being transmitted to the surveillance web page in real time. There is a provision to
sound an alarm as and when one detects an unusual activity on the screen. Also, the
media captures from the surveillance locations are being recorded to be monitored at
a later stage.
[ 339 ]
Other WebRTC Use Cases
Also, there is a motion-sensor software implemented in JavaScript that triggers
an event as soon as the camera detects an activity. Events such as these can be
programmed to send WebRTC calls to users for their inspection. Their alarm system,
thermostat, and security cameras are enabled to work together and send a WebRTC
call to the owner who can access the information (audio, video, data, or images). In
the future, we may see smarter WebRTC applications where every automobile and
home may have a computer component containing call features. Owners or security
officials should be able to track the activity around in the area just by switching on
the WebRTC media stream and remotely control the operations by what they see.
Managing the connected device
An enterprise computer system (that is, desktops on various cubicles) is often managed
by an admin department responsible for tracking the health of these systems, ensure
that it is virus-free and has optimum network speed to connect to the Internet, and so
on. Not only enterprises, but a house owner too would like to control his connected
devices from one place. The desktop-sharing feature of WebRTC enables this and also
lets the remote user to communicate with the admin user without using any hardware
or software other than a simple browser. Consumers can achieve unified home control
and monitoring. The WebRTC API that enables remote desktop sharing is provided at
https://developer.chrome.com/extensions/desktopCapture.
Innovation in the automation section will eventually lead to devices operated by
network-based intelligence. The inputs from a user's location, Presence, and activity
patterns will help create an environment wherein services such as unlocking the
car, turning the lights on/off, and others, will be managed automatically. The most
important component in designing such services is data capture and data sharing.
The WebRTC integrated with a standards signaling mechanism, such as SIP and
implying the security specifications, can make both ends meet.
WebRTC games
WebRTC can play a pivotal role in fun- and entertainment-centric business.
A few targeted factors from gaming and movies-based services areas that can
directly benefit from WebRTC calls, Presence, and chat are described in the
upcoming sections.
[ 340 ]
Chapter 10
Two-player games
Using the power of web-based real-time communication, the gaming server allows
the game players to engage in a video conference along with an ongoing game;
not only can they see, but they can also hear each other's voice, which boosts
interactivity. The players of a team can use WebRTC-based audio call to instruct each
other for a specific command or action within a game unlike the way a live chat was
employed earlier. This saves the user from diverting their attention from the game
screen to chat screen as WebRTC can function in the background with the game
being played on the foreground of the screen.
A sample two-party game could be any board game such as checkers, chess,
and others. The following screenshot shows a two-party chess game with the
WebRTC technology:
A WebRTC two-point call is a relatively simple process due to its peer-to-peer
nature. However, a multiparty call involves media relay and multiple remote
screen views. This is described in the upcoming section.
[ 341 ]
Other WebRTC Use Cases
Multiplayer games
A sample multiparty game could either be a war game, racing game, or a strategy
game such as poker. The online game played by multiple players could be coupled
with WebRTC-based chat, call, and Presence services. The following screenshot
represents a WebRTC SIP-based game. The users participating in the game are able
to chat alongside the play area. Note that the SIP session is active for group chat till
the period when the game is active.
[ 342 ]
Chapter 10
The following screenshot represents another WebRTC-based game. The users
participating in the game share their video streams with other members so that
each member can view other members in real time.
After exploring WebRTC application for games, we will proceed toward applying a
WebRTC communication channel and endpoint to TV-based services.
TV experience with WebRTC
WebRTC has been applied in the basic communication sector with overwhelming
results. However, there the capability to stream media is not just limited to
communication; it can be applied to stream multimedia content from the server as
well. This section describes the application of WebRTC in IPTV, VOD, and online
FM (audio from Radio stations online). All this is possible without the need to
download plugins or any additional installations of third-party products. Also, with
the inclusion of the element in HTML5, there is no requirement for external
handles to display and play the multimedia content on the web page.
[ 343 ]
Other WebRTC Use Cases
Live broadcasting
The multimedia content could be directly streamed to the server right after recording
from the field. An instance of the first use case could be live broadcasting of FIFA
on a web page directly from the stadium. In the case of a two-way communication
channel, the viewers can also stream their local camera captures with other viewers of
the game in real time, and have a group chat via the WebRTC DataChannel API too.
For realizing the proposed solution, there is a requirement for a real-time encoder
that records the media from the playground and sends it to the media server, which
further relays it to various WebRTC viewers after transcoding to VP8 and encrypting
it via DTLS/SRTP routed through NAT traversal techniques.
A sample screenshot of a live match played on WebRTC media APIs along with an
interactive group chat between viewers is depicted as follows:
[ 344 ]
Chapter 10
To draw more clarity on the process of transmitting live video feed on WebRTC,
we will study the main solution components briefly. The signaling server negotiates
the audio and video codecs through SDP. The media engine responsible for
transcoding the streams to the requested codecs and encrypting them are brought
into action. The user only needs to call the operator's SIP address through their SIP
phone or WebRTC browser and get the content streamed to your client. Additionally,
using WebRTC DataChannel APIs, there may be multiple user conferencing in
any permutation and combination of text, audio, or video.
IPTV integration and streaming
Using the WebRTC browser page as a TV to watch the channels is as lucrative to
viewers as TV channel operators. The multimedia content is streamed from a server
that is connected to an IPTV content provider's network or video content repository.
IPTV refers to streaming of TV channels over IP protocol that can be viewed from
smart TV's or from web-based interfaces. The content is delivered through an IPTV
Server and the session exists between the user's WebRTC endpoint and SIP Server
just as a normal SIP call-based session.
VoD is also a service aligned to IPTV. While the content broadcasted on the IPTV
service is independent of the user's control, VoD lets the user to directly decide
on what to watch now as they can request for any particular video or movie to
be streamed to their account.
An architectural representation of the proposed application is shown as follows:
TV on WebRTC
play TV
chat
Call
Web Application
Server
WebRTC website
timers
channels list
parental control
view log
SIP Application
server
SIP applications
live feed
video repository
Content
provider
channel from
content provider
Media Server
Signaling
server
recording
playback
IVR /DTMF
Transcoding
desktop
Media application
media
encoder
streaming
server
media
engine
laptop
tablet
digital rights
management
billing and
charging
Network modules
[ 345 ]
advertising
engine
phone
Other WebRTC Use Cases
Let's go over the different components and their interaction with each other for a
WebRTC SIP-based IPTV and VoD infrastructure as follows:
•
Media Source: Media Source can either be a live feed or a video from the
media repository; it can even be a live channel from the content provider.
•
WebRTC user client: This is where the SIP stack is provided in JavaScript
code and the media are exchanged via WebRTC browser APIs. The client is
designed for WebRTC-compatible browsers that fit different devices such as
desktops, laptops, tablets, smartphones, and others.
•
Signaling server: A signaling server is responsible for acting as a proxy agent
between the SIP infrastructure and WebRTC endpoints. It also converts the
SIP over WebSocket to plain SIP, understandable by back network.
•
Media engine: A media engine is the intermediary between the WebRTC
SIP server that supports transcoding DTLS-SRTP streams to normal RTP
and vice versa, and browser APIs.
•
Media transcoder: A media transcoder role is for intercodec conversion so
that a streamed video can be played over RTP to a recipient. A user should
be able to watch the session not only on his WebRTC browser, but also on
legacy SIP phones' software.
•
SIP Application Server: The logic to connect media streams for applications,
such as IPTV or VoD, is embedded in the SIP application that often acts as
the end point for a call. The user calls up the SIP address depending on the
content they want to watch. The call is made between the user and the SIP
Server. Once a subscriber calls up at the IPTC service module in the SIP
Application Server, the Server inspects the SDP body of the INVITE message
to figure out the device's capability that includes a list of supported audio
and video codecs, platforms, routes, ports, and so on. It uses this information
to stream the video content directly from the media repository or source to
the client by setting up a media path. When the call is ended, the application
server needs to tear down the streaming session, release resources, and make
the server ready for a new session.
Streaming movies among peers
The multimedia content could be streamed from a server that is connected to a
video source. An instance of the second use case could be a group of users playing
multimedia content in a synchronized way, such as five friends watching a movie
streaming from a single user's desktop.
[ 346 ]
Chapter 10
The following screenshot shows multiple users watching a movie streamed over
WebRTC TV:
This is multipoint, one-to-many video conferencing in action. The first step in this
process is when the client-side broadcaster sends out a single media stream to the
server. The network-signaling server makes sure that the media stream is headed in
the right direction, and then the network media server enables all the participants
to have an open, active session. The web client can itself modify the media features
such as resolution, frame rate, and bit rate. A requirement for real-time streaming
services is that the media should be in multiresolution and bandwidth-adaptive
streaming formats.
Note that the issues of piracy and digital rights management are
meant to be addressed separately and are not included within
the context of this book.
[ 347 ]
Other WebRTC Use Cases
Interfacing services
WebRTC-based communication technologies are very customizable in nature and
can fit into any communication scenario. With a JavaScript-based signaling stack and
a peer-to-peer media connection, WebRTC enables users to get connected like never
before. Besides the many kinds of use cases mentioned in the book, there are thousands
of more ideas that need the creative adoption of WebRTC to boost their efficiency
such as call-to-connect Governance and e-learning with WebRTC-based classes. In this
section, we shall cover WebRTC's application in e-learning (distant education through
online classrooms) and e-governance (expressing concerns over a subject directly to
government officials in a real-time multiconference session).
WebRTC for e-learning
This application of WebRTC is for the Learning Management System (LMS) that
includes e-portfolios, online open course, smart education, and others. More students
and educators are interacting online every day, but currently this is primarily using
standard web page- and document-based user interfaces. The only video and audio
conferencing options commonly available to educators and students today are those
using proprietary systems. Each of these solutions require additional software and
often a completely standalone application to be installed. The setup time to establish
each of these calls is usually quite high, and some of these solutions also require a
licensing fee or setup cost. Therefore, it is high time that an open standard-based, easy
e-learning solution that does not require any setup software, plugin, or installation
comes about. The following diagram depicts WebRTC in e-learning:
archive server
network
students
Signaling server
WebRTC enabled
browser
educators
TURN server
Figure : WebRTC e-learning Ecosystem
[ 348 ]
Chapter 10
WebRTC helps to consolidate services hosted across different domains such as
Presence, Instant Messaging, audio, video, and web conferencing, and to deliver
an IT and educational application to the end user. This application can create a
new learning platform that will allow classroom collaboration at any time with
participants anywhere. The interactivity and ease of use of the interfacing service
determine its adoption in use. It will help students to take up online courses, interact
with professors of different universities, and communicate with foreign classrooms
in an interactive and easy way.
The general architecture for this type of application or platform consists of seven key
elements that work together to deliver an overall experience:
•
Educators: This is the account for educators and takes care of the payment
of fees
•
Students: This is the account for registering for a subject course and fee
submissions
•
WebRTC capable browsers: Google Chrome and Mozilla Firefox browsers
now support the draft, WebRTC 1.0
•
WebRTC e-learning application: These platforms provide the perfect
launch pad for connecting users via WebRTC
•
Signaling server: This can be either be the SIP-based Kamailio or the
non-SIP-based Node.js
•
TURN server: This is used for media relay
•
Archive server: This is used to store copies of the course or the
education material
While introducing WebRTC into an e-learning environment, there are issues that
are commonly faced, such as restrictive network policies and outdated browsers.
While upgrading the browsers is in the hands of the user, the network control
policies are not. An organizational network system may block ports, protocol, or sites
from reaching the end user. These factors can cause problems in smooth WebRTC
communication. The solution to these problems is to use a public network while
making WebRTC calls or set up a NAT traversal through effective TURN/STUN
server configuration.
The benefits of the ease of use and removal of barriers for setting up an audio or
video call or screen-sharing session cannot be underestimated. This will drive
more interpersonal interaction between educators and students, among students
themselves, and even among educators themselves.
The distributed peer-to-peer nature of WebRTC can also lead to some significant
network and infrastructure cost reductions.
[ 349 ]
Other WebRTC Use Cases
WebRTC for e-governance
The digital revolution has raised the standards almost everywhere for information,
communication, and electronics. The Government is also rapidly employing IT to
upgrade its mode of communication in various countries. In the age of e-governance,
it should be no surprise if the WebRTC browser's CONNECT functionality is used to
reach out to any particular government official regarding the state of affairs in their
designated department or area. This not only leads to more transparency in public
sector information sharing, but also lets us establish our Right to Information (RTI) in
a better way by directly communicating with the concerned authorities. The WebRTC
platform with the gateway to the PSTN and UMTS world can play an important role
in such a system as it can send information and media over IP networks to the telecom
operator's network and vice-versa. So, if a party is not online over WebRTC web
application, they can still take calls and join the communication.
Summary
After the digital revolution, general inhibitions about Internet technologies and
insecurity around it were relieved. Now, every industry fragment, from hospitals
to banks, is investing in web technologies to meet their goals while enhancing their
user experience. The plugin-free communication technology is open to innovators
and entrepreneurs to integrate and develop new use cases.
In this chapter, we saw how WebRTC can be used by doctors, teachers, government
officers, gamers, insurance agents, and many more. We also saw how new
applications, such as movie streaming, games, and others, can be built using
WebRTC as the base communication technology. Due to its ease of use and
extremely customizable format, it is as useful for small- and medium-sized business
organizations as it is for enterprises.
The age of web communication is already here and many service providers and
other OTT player companies are trying to cash in in the IP-based communication
technologies by developing their own extensions, plugins, or protocols, to support it.
Some are so closed that the protocols are supported only through their closed source
hardware/software while others have developed their own layers over existing open
source communication protocols as SIP.
In this confusion, WebRTC is a breath of fresh air for developers who are trying
to build a unified communication platform that meets open standards and is
backward-compatible as well as extensible for future needs.
[ 350 ]
Index
Symbols
407 Proxy Authentication Required 157
486 Busy Here 178
487 Request Timeout 178
A
Ack SIP request 159
admin console 194
advertisements, web application 192
Android OS
lightweight Android SIP application,
developing 300
WebRTC clients support 295
answer message (ANM) 144
Apache Ant 1.7 98
Apache Tomcat Version 7.0.50
URL 42
Apple iPhone
iPhone/iPad IP applications, interacting
with WebRTC clients 302, 303
iPhone SIP application, developing 304
Application Programming Interface (API) 7
Application Server
about 172, 173
diagrammatic representation 173
services 172, 173
Application Server (AS) 84
application touch points, insurance claims
hospital 338
insurance agency 338
police station 338
Aspect Oriented Programming (AOP) 223
audio and video calls
making, SIP used 159-165
B
back office communications 310-312
Back-to-Back User Agent (B2BUA),
Application Server 174
Bearer Independent Call Control
(BICC) 123
binaries, Kamailio
kamailio 67
kamctl 68
kamdbctl 67
sercmd 68
Boghe 282
Border Gateway Control Function
(BGCF) 123
branches 310-312
Brekeke SIP server
URL 64
using, with WebRTC client 64, 65
Business Layer 316
Business to Business (B2B) 266
Business to Consumer (B2C) 334
Bye SIP request 159
C
Called Party's Number (CPN) 146
call forwarding service, Application Server
about 177
call forwarding, in case of user
unavailability 179
unconditional call forwarding 178
call hold/resume service,
Application Server 176, 177
Calling Party's Category (CPC) 146
Call in Progress (CPG) message format 149
call logs, Application Server
generating 182
CallLogs class 197
call, processing with IN service logic
about 124
services broker, for endpoints 129, 130
WebRTC client communication with GSM
phone, through IMS 125-127
WebRTC client communication with GSM
phone, through IN services 127, 128
call screening, Application Server
about 175
basic call screening 175, 176
enhanced call screening 176
Call Session Control Function. See CSCF
call transfer service, Application Server
about 179
attended call transfer 179, 180
unattended call transfer 181
Cancel SIP request 159
Capital Expenditure (CAPEX) reduction 269
Cascading Style Sheets (CSS) 40
Chrome browser
about 275, 276
download link 87
WebRTC clients support,
on Linux OS 284, 285
WebRTC clients support,
on Windows OS 275, 276
Chromium project
URL 275
Circuit-Switched (CS) network
versus Packet-Switched (PS)
network 121, 122
Circuit-Switched system 138
Class diagram, WebRTC client project
about 197
CallLogs 197
Conferencing 198
Geolocation 198
MessageLogs 197
Notification 198
OfflineMessages 198
OtherAccount 197
Phonebook 198
Presence 198
UserDetails 197
Voicemail 198
Communication module 209, 210
Communication Service
Providers (CSPs) 244
Conference (CON) 150
Conferencing class 198
conferencing, Media Server
about 187
multipart communication 187
configuration process, RCS 246
connected device
managing 340
contact centers, WebRTC 327
contacts, web application
importing 191
Controller interface 224
Convergent applications 33
core GPRS Support Nodes (GSNs)
structure 117
Create Read Update Delete (CRUD)
operations 205
CRM system 305
CSCF
about 81, 83
I-CSCF 83
P-CSCF 83
S-CFCS 83
Customer Relationship Management
system. See CRM system
customized Communicator
back office communications 310
branches 310
for specific enterprise segments 310
customized version, sipML5 WebRTC client
developing 46-49
[ 352 ]
D
eXtensible Messaging and Presence Protocol
(XMPP) 9
Data Access Objects (DAO) 223
databases
about 202
Oracle 202
PostgreSQL 202
DataChannel function 18
Data Tier, Multitier architecture 196
dating sites
anonymous call 323, 324
chat 323, 324
design, WebRTC client 197
development environment, Android OS
URL 300
Domain Name Server (DNS) 87
Do Not Disturb (DND) 256
Dual Tone Multi Frequency (DTMF) 317
F
E
Eclipse WTP
URL 202
Enterprise Resource Planning (ERP) 311
Entity Relationship (ER) model 200
environment setup, WebRTC web project
about 201
databases 202, 203
IDE, with Java Enterprise Edition (EE) 202
Java Runtime Environment (JRE) 201
JSP- / Servlet-based WebRTC web
project 204
Struts- / Hibernate-based WebRTC web
project 213
web application infrastructure 204
web application server 203
ER diagram, WebRTC web application 200
Evolved Node B (eNodeB) 118
existing WebRTC setup, limitations
about 74
firewall issues 75
media transcoding 75
Network Address Translation (NAT)
issues 75
Field Force Management (FFM) 311
financial services
about 334
calling, from ATM 338
communicating with 334, 336
insurance claims 336-338
firewall 75
FOKUS Home Subscriber Server
(FHoSS) 94
Forward Call Indicators (FCI) 146
FreeSWITCH Media Server
about 99
configuring 101, 102
installing 99-101
FreeSWITCH media services
using 103-108
G
Gateway GPRS Support Node (GGSN) 116
General Packet Radio Services (GPRS) 116
Geolocation class 198
Geolocation module 232-236
Geolocation, web application
about 188-190
Cell Tower Triangulation 188
GPS 188
IP Geolocation 188
Wi-Fi positioning 188
getUserMedia 10-12
Global System for Mobile Communications
Association (GSMA)
URL 244
Graphical User Interface (GUI) 46
H
HandlerAdapter interface 224
HandlerInterceptor interface 224
HandlerMapping interface 224
[ 353 ]
health care
about 329
online medical consultation 330-333
Hibernate mapping Class diagrams,
WebRTC client project 199
Hibernate Query Tool (HQL) 213
home page, CRM client
Contacts 314
planned Work items 314
Work History 314
Home Subscriber System (HSS) 83
HSS/Location Server 156
HTTP 511 Network Authentication
Required error response 247
human resource management tool
about 319
used, for direct communication with
candidates 319, 320
I
IDE, with Java Enterprise Edition (EE) 202
iDoubs
about 292
URL 292
IMS
about 10, 81
IMS layer 81
PSTN connectivity, via PSTN gateways 142
Service or Application layer 81
Transport or Access layer 81
IMS connectivity
to Gateway GPRS Support Node 118
IMS core
about 85, 86
OpenIMS Core 86
open IMS setups 85
IMS core nodes
Call Session Control Function (CSCF) 81
Home Subscriber Server (HSS) 81
interacting with 82, 83
Telecom Application Server (TAS) 81
IMS Media to PSTN Media 142
IMSSF (IP Multimedia Service Switching
Function) node 151
IMS signaling to PSTN signaling 142
Initial Address Message (IAM) 144
IN Service Control Point (SCP) 150
instant message, web application
delivering as mail 193
insurance claims 336, 337
Integrated Development Environment
(IDE) 309
Integrated Service Digital Network
(ISDN) 138
Intelligent Network (IN) 115
Interactive Connectivity Establishment
(ICE) 10, 23, 24, 109
Interactive Voice Response (IVR) 84, 99
Internet Engineering Task Force (IETF)
URL 8
Internet Engineering Task Force (IETF)
Request for Comments (RFCs) 81
Internet Explorer (IE) 282, 283
Internet Protocol television (IPTV) 310
Interoperability Testing (IoT) 253
interoperability, with circuit-switched
networks
achieving 123
Interrogating-CSCF (I-CSCF) 83
Invite SIP request 159
iOS app development
reference link 304
IP connectivity
via GSN 116, 117
iPhone/iPad IP applications
interacting, with WebRTC clients 302, 303
IP Multimedia Service Switching Function
(IMSSF) 127
IP Multimedia Subsystem. See IMS
IVR (Interactive Voice Response),
Media Server 186
J
JAIN-SLEE 96
Java Database Connectivity (JDBC) 205
Java Development Kit (JDK)
download link 201
Java Runtime Environment (JRE) 201
[ 354 ]
JavaScript-based SIP libraries
about 36
JSSIP 36
QuoffeSIP 36
SIPJS 36
sipML5 36
JavaScript getUserMedia function 10
JavaScript Object Notation (JSON) 8
JavaScript Session Establishment
Protocol. See JSEP
Java Virtual Machine (JVM) 201
Jitsi
about 293
URL, for downloading 293
Joyn 246
JSEP
about 7, 8
architecture 7
signal and media flows 8, 9
JSP- / Servlet-based WebRTC web project
about 204
advantages 204
building 206, 207
Communication module 206-210
controller 205
DAO 205
deployment descriptor 205
diagrammatic representation 205
model 205
modules, development 206
Phonebook module 206-212
programming 205
User Account module 206-209
view 205
JSSIP
about 36
URL 36
jsSIP-demo-master
URL 50
jsSIP WebRTC client
URL 49
using, ways 49
version, developing 50-53
K
Kamailio 214
Kamailio SIP server
installing, steps 66-71
prerequisites 66
using, with WebRTC client 66-74
Kannel gateway
about 130
configuring 130-135
download link 130
installing 130
Kapanga 286
key elements, WebRTC for e-learning
archive server 349
educators 349
signaling server 349
students 349
TURN server 349
WebRTC capable browsers 349
WebRTC e-learning application 349
L
Learning Management System (LMS) 348
Linphone
about 287
URL 287
WebRTC clients support,
on Android OS 299
Linphone SIP client, on iPad
URL, for downloading 303
Linux OS
WebRTC clients support 283
live broadcasting 344, 345
Local Area Network (LAN) 109
LocaleResolver interface 224
Logic Tier, Multitier architecture 196
Login Controller Servlet 206
Long Term Evolution (LTE) 119
loyalty model 267
M
Mac OS
WebRTC clients support 289
[ 355 ]
media announcement, Media Server
playing 183
media engine 346
Media Gateway Control Function
(MGCF) 123, 142
Media Gateway (MGW) 123, 141, 142
media relay mechanism 77
media relay, Media Server 183, 184
Media Resource Function (MRF) 183
Media Server
about 84, 99, 182
FreeSWITCH 99
Media Server-based features
about 183
announcement 183
conferencing 187
IVR 186
media relay 183, 184
Music on Hold 186
voicemail 184, 185
Media Source 346
media transcoder 346
media transcoding 75-78
media traversal, in WebRTC clients 23
MessageLogs class 197
Message Session Relay Protocol
(MSRP) 247
MESSAGE SIP request 165
minified webphone application
developing, with Tomcat 42-46
Mobicents Telecom Application Server
about 96
installing 96-98
Mozilla browser
about 277, 278
WebRTC clients support, on Linux OS 285
WebRTC clients support, on
Windows OS 277, 278
Multimedia Message Service (MMS) 243
MultipartResolver interface 224
multiplayer games 342, 343
Multi-Purpose Internet Mail Extensions
(MIME) 251
Multitier architecture
about 196
Data Tier 196
Logic Tier 196
Presentation Tier 196
Music on Hold, Media Server 186
MySQL components
reference link 203
MySQL Database Management System
(DBMS) 202
MySQL server) 214
N
Nature of Connection Indicators (NCI) 146
Network Address Book 258
Network Address Translation (NAT) 10, 75
Network Operation Center. See NOC
Next Generation Network (NGN) model 10
NOC 310, 318, 319
Node B 118
Node.js
about 24, 214
using 25, 26
Normal event 147
Notification class 198
NOTIFY messages 168
NOTIFY SIP request 167
O
Object Relational Mapping (ORM) 223
offer/answer (O/A) model 74
OfficeSIP server msi file
URL 57
OfflineMessages class 198
one-to-one messaging WebRTC page 260
online marketing centers, WebRTC 325, 326
online medical consultation
about 330-333
scenarios 330
online/offline status, users
obtaining, SIP used 167-172
Open IMS
CSCF 83
HSS 83
[ 356 ]
OpenIMS Core
about 86
configuring 89-95
installing 88
prerequisites 87
Open IMS setups
3GPP IMS 85
DubangoIMS 85
KamailioIMS 85
OpenIMS 85
Opera browser
about 279
WebRTC clients support, on Linux OS 286
WebRTC clients support, on
Windows OS 279
OtherAccount class 197
OtherAccount module
about 217
code snippets 217-222
Over the Top (OTT) 245
P
Packet Data Protocol (PDP) context 119
PBX 139, 327
Phonebook class 198
Phonebook module 210-212
Plain Old Telephone Systems (POTS) 138
Policy and Charging Rules Function
(PCRF) 83
Policy Call Session Control Function
(PCSCF) 91
Presence 167
Presence Agent 168
Presence class 198
Presence Server 168
Presentation Tier, Multitier architecture 196
Private Brach Exchange. See PBX
Proxy-CSCF (P-CSCF) 83
PSTN
about 138
diagrammatic representation 139
connectivity to IMS, via PSTN
gateways 142
WebRTC connectivity 139, 140
PSTN gateways
about 141
Media Gateway Controller (MGC) 141
Media Gateway (MGW) 141
Signaling Gateway (SGW) 141
Public Land Mobile Network (PLMN) 138
Public Switched Telephone
Network. See PSTN
Public Switched Telephone Network
(PSTN) / Integrated Switched Digital
Network (ISDN) 116
PUBLISH SIP request 167
Q
Quality of Service (QoS) 245
QuoffeSIP
about 36
URL 36
R
Radio Access Bearer (RAB) 119
Radio Access Network (RAN) 116
Radio Network Controller (RNC) 119
RCS
about 243, 244
adoption 244
business impact 245
configuration process 246, 247
integrating, with VOLTE and WebRTC 268
Joyn 246
position 244
RCS downloadable client 254
RCS embedded client 254
technology impact 245
telecom operator's benefit 266
RCS downloadable client 254
RCS-e 246
RCS ecosystem
in WebRTC 254, 255
RCS embedded client 254
RCS-enabled Applications 267
RCS-enabled communication
loyalty model 267
RCS enabled applications 267
[ 357 ]
revenue through advertisements 268
service bundled model 267
subscription-based model 267
RCS integration
in WebRTC 254
RCS services
client configuration 248
service provisioning 248
RCS services, in WebRTC
about 255
call logs 263, 264
enhanced phonebook 258
integration, with social networks 257
message history 261, 264, 265
multiparty conferencing 265
Presence and user capabilities 259
rich calls 261-263
unified messaging box 260, 261
user profile 255, 256
RCS specifications
about 247
chats, with multimedia sharing 249, 250
file transfer, over MSRP 251
group chat, in conference session 251
interoperability 253
interworking 254
one-to-one text chat, over MSRP 250
REST-based notifications 253
service discovery, by RCS-enabled
device 248
user availability, through XCAP 252, 253
user capability exchange 248, 249
Real-time Transport Protocol (RTP) 23, 76
Registrar 156
release (REL) message 144
remote management
about 338
connected device, managing 340
surveillance 339, 340
Representational State Transfer (REST) 253
Resource Adapter (RA) 133
RESPONSE SIP message 166
retail services
about 325
customer care facility 328, 329
WebRTC contact centers 327
WebRTC online marketing centers 325, 326
revenue through advertisements model 268
Rich Communication Services. See RCS
Right to Information (RTI) 350
RTCDataChannel 18-23
RTCP-based feedback (RTP/AVPF) 76
RTCPeerConnection 12-17
RTP Control Protocol (RTCP) 76
RTP Engine
URL 106
RTP Proxy
basic proxying mode 184
functional mode 184
rtpproxyng engine 108
S
Safari 294
SDP 41
Secure RTP Profile (RTP/SAVP) 76
Service Broker 128
service bundled model 267
Service Delivery Platform (SDP) 153
service logic
about 150
IN services, via IMSSF 151
Service Broker, for orchestration of
services 152, 153
SIP service logic, through application
server 150, 151
services
interfacing 348
services, Application Server
Back-to-Back User Agent (B2BUA) 174, 175
call forwarding service 177
call hold/resume service 176
call logs, generating 182
call screening 175
call transfer service 179
services, interfacing
WebRTC for e-governance 350
WebRTC for e-learning 348, 349
Serving-CSCF (S-CFCS) 83
[ 358 ]
Serving GPRS Support Node
(SGSN) 116, 120
Session Border Controller (SBC) 82, 153
Session Description Protocol (SDP) 8, 159
Session Initiation Protocol (SIP) 8, 32-35
Session Traversal Utilities for NAT (STUN)
protocol 10
setLocalDescription function 8
SFL 288, 289
Shared Items window 315
Short Message Peer-to-Peer Protocol
(SMPP) 134
Short Message Service Center (SMSC) 130
Short Message Service (SMS) 115, 243
signal flow
testing 237
Signaling Gateway (SGW) 141, 142
signaling server 346
Simple Traversal of UDP through NAT
(STUN) server 109
SIP 39
SIP application examples
Click to Dial 99
Find me Follow Me 99
Speed Dial 99
SIP Application Server 82, 346
SIP client
about 156
registering 156
SIP Dialog 159
SIPdroid 298
SIPJS
about 36
URL 36
sipML5 WebRTC client
about 36, 41
customized version, developing 46-49
minified webphone application, developing
with Tomcat 42-46
URL 36, 41, 195
using 41
sipml.js file 110
SIP over WebSocket
about 33
converting, to native SIP 59
using 33, 34
WebRTC2SIP gateway 59
WebRTC client, using with Brekeke SIP
server 64, 65
WebRTC client, using with Kamailio SIP
server 66
SIP phones
category 1 272
category 2 272
category 3 272
category 4 272
SIP programming, for Application Layer
CPL 127
JAIN SIP 126
SIP CGI 127
SIP Servlets 126
SIP Registration call flow
diagrammatic representation 156, 157
SIP requests, Presence service 168
SIP server
call, making from SIP-WS to SIP-WS 55
categorizing 53-55
SIP services
about 156
audio and video calls, making 159-165
online/offline status, obtaining 167-172
SIP client, registering 156-158
used, for text chats 165, 166
SIP softphones, with WebRTC support on
Android OS
Linphone 299
SIPdroid 298
SIP softphones, with WebRTC support on
Linux OS
about 286
Kapanga 286
Linphone 287
SFL 288, 289
Yate 288
SIP softphones, with WebRTC support on
Mac OS
about 291
iDoubs 292
Jitsi 293
[ 359 ]
SIP softphones, with WebRTC support on
Windows OS
about 280
Boghe 282
X-Lite 280, 281
Zoiper 281
SIP Transaction 159
SIP WebRTC calls
making, ways 39
SIP-WS to SIP-WS call
client, registering with SIP server 56
OfficeSIP server, using 57
SIP to SIP-WS 59
SIP-WS to SIP 58, 59
social networking
about 321
dating sites 323, 324
platforms 321, 322
Software as a Service (SAAS) 336
Software Development Life
Cycle (SDLC) 196
Spring 3 framework
features 225
Spring 3 MVC-based WebRTC web project
about 204, 223
building 227-231
code snippetAspect Oriented Programming
(AOP) 223
Data Access Objects (DAO) 223
Geolocation module 232
modules 226
Object Relational Mapping (ORM) 223
programming 223
Spring Context 223
Spring Web module 223
Spring Web MVC 223
Spring Context 223
Spring features
reference link 225
Spring MVC
components 224
Controller interface 224
HandlerAdapter interface 224
HandlerInterceptor interface 224
HandlerMapping interface 224
LocaleResolver interface 224
MultipartResolver interface 224
View interface 224
ViewResolver interface 224
Spring Web module 223
Spring Web MVC 223
Struts
URL 213
Struts- / Hibernate-based WebRTC web
project
about 204
building 215, 216
Business Logic Layer 214
Data Access Layer 214
modules, development 215
OtherAccount module 217-222
Presentation Layer 214
programming 213, 214
Red Hat Enterprise Linux 6 (RHEL 6) 214
STUN (Session Traversal
Utilities for NAT) 24
STUN/TURN Server 84
SUBSCRIBE message 168
SUBSCRIBE SIP request 167
subscription-based model 267
Supply Chain Management (SCM) 311
surveillance 339, 340
T
Team Communicator application 305-310
Telecom Application Server (TAS) 81, 125
Telecom server
about 96
Mobicents Telecom Application Server 96
Temasys plugin
about 283
URL 283
test cases, WebRTC client
validation 237-240
testing
about 236
signal flow 237
text chats
SIP used 165, 166
[ 360 ]
Third Generation Partnership
Project (3GPP) 81
Tomcat
used, for developing minified webphone
application 42-46
Transmission Medium
Requirement (TMR) 146
Traversal Using Relay
NAT (TURN) 10, 24, 110
TV experience, with WebRTC
about 343
IPTV integration 345, 346
live broadcasting 344, 345
movies, streaming 346, 347
streaming 345, 346
two-player games 341
V
U
W3C standard elements, Chrome 13
W3C standard elements, Mozilla Firefox 13
Watcher 168
web application, features
advertisements 192
contacts, importing 191
Geolocation 188-190
instant message, delivering as mail 193
OAuth-based logins 190, 191
web application infrastructure 204
web application server 203
WebRTC
about 7
admin console 194
integrating, with VOLTE and RCS 268
setting, over firewalls and proxies 109-111
TV experience 343
WebRTC2SIP gateway
functioning 60
installation, steps 61-64
modules 59
URL 61
webrtc4all plugin
about 282
URL 282
WebRTC API
URL 340
unified Communicator
building 306
Team Communicator application 306
Unified Modeling Diagrams (UMLs) 197
Universal Mobile Telecommunications
System (UMTS) device 116
use cases, WebRTC
CRM system 313
customized Communicator 310
financial services 334
games 340
health care 329
human resource management tool 319
NOC 318
remote management 338
retail services 325
services, interfacing 348
social networking 321
TV experience 343
unified Communicator 306
User Account module 207-209
user agent (UA) 83
User Availability Indication 253
UserDetails class 197
User Equipment (UE) 120
Value Added Services (VAS) 81
Video on Demand (VoD) 305
View interface 224
ViewResolver interface 224
Virtual Private Network (VPN) 125, 317
Voicemail class 198
voicemail, Media Server 184, 185
Voice over Internet Protocol (VoIP)
telephony 137
Voice over LTE (VOLTE)
about 268
integrating, with WebRTC and RCS 268
W
[ 361 ]
WebRTC architecture, with
RCS modules 266
WebRTC client
design 197
using, with Kamailio SIP server 66-74
WebRTC client project
Class diagram 197
Entity Relationship (ER) model 200
Hibernate mapping Class diagrams 199
WebRTC client-server model
about 40
infrastructure, setting up 40
jsSIP WebRTC client 49
sipML5 WebRTC client 41
WebRTC client validation
test cases 237-241
WebRTC-compliant browsers,
on Android OS
Chrome 295-297
Mozilla 297
WebRTC-compliant browsers, on Linux OS
Chrome 284, 285
Mozilla 285
Opera 286
WebRTC-compliant browsers, on Mac OS
Chrome 290
Mozilla 291
WebRTC-compliant browsers,
on Windows OS
Chrome 275, 276
Mozilla 277, 278
Opera 279
WebRTC contact centers 327
WebRTC for e-governance 350
WebRTC for e-learning 348, 349
WebRTC games
about 340
multiplayer games 342
two-player games 341
WebRTC gateway 81
WebRTC integration, with Intelligent
Network
about 115
circuit-switched voice network,
using 121-124
IMS connectivity, to Gateway GPRS
Support Node 118, 119
mobile packet-switched network,
using 116-118
SMS service, in GSM phone (SMSC) 130
WebRTC - Intelligent Network
integration 115
WebRTC online marketing centers 325, 326
WebRTC, running without SIP
about 10
media, sending over WebSockets 10
WebRTC, running with SIP
about 32
JavaScript-based SIP libraries 36
Session Initiation Protocol (SIP) 32
WebRTC SIP-based client
components 40
WebRTC SIP browser
call flow 142-144
WebRTC support
in Android OS for mobiles 295
in Apple iPhone 302
in Linux OS 283
in Mac OS 289
in various operating systems 273
in Windows OS 274
in Windows OS for mobiles 301
WebRTC, through WebSocket
signaling servers
about 24
Node.js 24
peer-to-peer audio call, making 26-32
WebRTC-to-IMS architecture
about 112
Application Layer 112
Media Server nodes 112
Network Control Layer 112
Transport Layer 112
WebRTC to IMS gateway 112
WebRTC to PSTN interconnection,
challenges
about 145
address mapping 145
call in progress 149
call setup 146
[ 362 ]
call termination 147, 148
translation, from SIP to ISUP 145
WebRTC unsupported browser, on Mac OS
Safari 294
WebRTC unsupported browser,
on Windows OS
Internet Explorer (IE) 282, 283
WebRTC user client 346
WebRTC Web Application
Server and client 84
WebRTC web project
environment setup 201
WebSocket API 7
Web Tools Platform (WTP)
about 202
URL 202
Windows OS
WebRTC clients support 274
WebRTC clients support, for mobiles 301
Wireless Application Protocol (WAP) 130
Work Force Management (WFM) 312
X
X-Lite 280, 281
XML Configuration Access
Protocol (XCAP) 247
XMLHttpRequest (XHR) 8
Y
Yate 288
Z
Zoiper 281
[ 363 ]
Thank you for buying
WebRTC Integrator's Guide
About Packt Publishing
Packt, pronounced 'packed', published its first book "Mastering phpMyAdmin for Effective
MySQL Management" in April 2004 and subsequently continued to specialize in publishing
highly focused books on specific technologies and solutions.
Our books and publications share the experiences of your fellow IT professionals in adapting
and customizing today's systems, applications, and frameworks. Our solution-based books
give you the knowledge and power to customize the software and technologies you're using
to get the job done. Packt books are more specific and less general than the IT books you have
seen in the past. Our unique business model allows us to bring you more focused information,
giving you more of what you need to know, and less of what you don't.
Packt is a modern, yet unique publishing company, which focuses on producing quality,
cutting-edge books for communities of developers, administrators, and newbies alike.
For more information, please visit our website: www.packtpub.com.
About Packt Open Source
In 2010, Packt launched two new brands, Packt Open Source and Packt Enterprise, in order
to continue its focus on specialization. This book is part of the Packt Open Source brand,
home to books published on software built around Open Source licenses, and offering
information to anybody from advanced developers to budding web designers. The Open
Source brand also runs Packt's Open Source Royalty Scheme, by which Packt gives a royalty
to each Open Source project about whose software a book is sold.
Writing for Packt
We welcome all inquiries from people who are interested in authoring. Book proposals should
be sent to author@packtpub.com. If your book idea is still at an early stage and you would like
to discuss it first before writing a formal book proposal, contact us; one of our commissioning
editors will get in touch with you.
We're not just looking for published authors; if you have strong technical skills but no writing
experience, our experienced editors can help you develop a writing career, or simply get some
additional reward for your expertise.
WebRTC Blueprints
ISBN: 978-1-78398-310-0
Paperback: 176 pages
Develop your very own media applications and
services using WebRTC
1.
Create interactive web applications
using WebRTC.
2.
Get introduced to advanced technologies
such as WebSocket and Erlang.
3.
Develop your own secure web applications
and services with practical projects.
Getting Started with WebRTC
ISBN: 978-1-78216-630-6
Paperback: 114 pages
Explore WebRTC for real-time peer-to-peer
communication
1.
Set up video calls easily with a low bandwidth
audio-only option using WebRTC.
2.
Extend your application using real-time
text-based chat, and collaborate easily by
adding real-time drag-and-drop file sharing.
3.
Create your own fully working WebRTC
application in minutes.
Please check www.PacktPub.com for information on our titles
Microsoft Lync 2013 Unified
Communications: From Telephony
to Real-time Communication in the
Digital Age
ISBN: 978-1-84968-506-1
Paperback: 224 pages
Complete coverage of all topics for a unified
communications strategy
1.
A real business case and example project
showing you how you can optimize costs
and improve your competitive advantage
with a Unified Communications project.
2.
The book combines both business and the
latest relevant technical information so it is
a great reference for business stakeholders,
IT decision makers, and UC technical experts.
Twilio Cookbook
Second Edition
ISBN: 978-1-78355-065-4
Paperback: 334 pages
Over 70 easy-to-follow recipes, from exploring
the key features of Twilio to building advanced
telephony apps
1.
Updated to include picture messaging,
call queuing, and Twilio Client;
all recommended by Twilio.
2.
The only book that teaches you how to set up
your own conference calling system or how to
build a PBX for your company.
3.
Each recipe is a carefully organized sequence of
instructions to complete the task as efficiently
as possible.
Please check www.PacktPub.com for information on our titles
Source Exif Data:
File Type : PDF
File Type Extension : pdf
MIME Type : application/pdf
PDF Version : 1.6
Linearized : No
Create Date : 2014:10:27 15:23:03+05:30
Creator : Adobe InDesign CS6 (Windows)
Modify Date : 2014:10:31 12:27:21+05:30
Has XFA : No
XMP Toolkit : Adobe XMP Core 5.4-c005 78.147326, 2012/08/23-13:03:03
Instance ID : uuid:1060c219-b621-40ad-8c98-28e7cce479ac
Original Document ID : adobe:docid:indd:4992da54-27df-11de-a18e-f5498a2a904f
Document ID : xmp.id:CAEB430BBF5DE4119C8AD742EA10E1E8
Rendition Class : proof:pdf
Derived From Instance ID : xmp.iid:D86ED0E5BD5DE4119C8AD742EA10E1E8
Derived From Document ID : xmp.did:E707A2D9A553E411B80ACDAE1EAFADE5
Derived From Original Document ID: adobe:docid:indd:4992da54-27df-11de-a18e-f5498a2a904f
Derived From Rendition Class : default
History Action : converted
History Parameters : from application/x-indesign to application/pdf
History Software Agent : Adobe InDesign CS6 (Windows)
History Changed : /
History When : 2014:10:27 15:23:03+05:30
Metadata Date : 2014:10:31 12:27:21+05:30
Creator Tool : Adobe InDesign CS6 (Windows)
Format : application/pdf
Producer : Adobe PDF Library 10.0.1
Trapped : False
Page Count : 382
EXIF Metadata provided by EXIF.tools
.