UPTEC IT 13 015

Examensarbete 30 hpOktober 2013

Evaluating and tracking circuit-switched telephone calls using web browsers on mobile devices

Anders David Hassis

Teknisk- naturvetenskaplig fakultet UTH-enheten Besöksadress: Ångströmlaboratoriet Lägerhyddsvägen 1 Hus 4, Plan 0 Postadress: Box 536 751 21 Uppsala Telefon: 018 – 471 30 03 Telefax: 018 – 471 30 00 Hemsida: http://www.teknat.uu.se/student

Abstract

Evaluating and tracking circuit-switched telephonecalls using web browsers on mobile devices

Anders David Hassis

Current phone calls using the Public Switched Telephone Network (PSTN) involve costs for the end-user, provide limited call data for network operators and currently impose limitations on the type of devices that have PSTN connectability. This thesis implements and evaluates a system in which a mobile web browser connects a phone call from a smartphone to the PSTN utilizing Web Real-Time Communication (WebRTC) technology whilst maintaining sufficient audio quality and providing a non-obtrusive user interface. The methods for this thesis included, performing a literature study, the evaluation of existing solutions and software, and the implementation of a web-application prototype. The web application was successfully connected to the PSTN using preexisting software, sipML5 and Asterisk. WebSockets was used for signaling and the G.711 audio codec was used for the audio path. The ability to utilize real-time communication in a web browser proved successful. The use of real-time communication also made it possible to extract more extensive call data. Additional benefits were also noted and included, potential cost reduction for end-users, expansion of the type of devices with PSTN connectability, and the ability to gather greater call data such as browser history, environments and coordinates. The user experience was evaluated by performing interviews.

Tryckt av: Reprocentralen ITC

Sponsor: Freespee ABISSN: 1401-5749, UPTEC IT 13 015Examinator: Lars-Åke NordénÄmnesgranskare: Bengt SandbladHandledare: Tobias Lindgren

Populärvetenskaplig

sammanfattning

Att genomföra ett telefonsamtal på det publika telefonnätet innebär kostnader för slutan-vändaren, begränsade möjligheter att samla in samtalsdata samt begränsningar gällandeantalet enheter som kan användas.

Denna uppsats undersöker och jämför hur man kan ersätta en existerande telefonlösningdär två ändpunkter på det publika telefonnätet kopplas ihop, varav den ena är en smartp-hone. Denna smartphone har en webbläsare med stöd för WebRTC installerad. WebRTCär en teknik som tillåter användare att genomföra röst- och videosamtal i realtid. Genomatt utnyttja stödet för realtidskommunikation implementeras en lösning som möjliggöratt en användare kan ringa från en webbläsare i sin smartphone till en traditionell telefonpå det publika telefonnätet. De fördelar som erbjuds är bland annat att användaren fåren bättre användarupplevelse. Användaren behöver inte byta fokus från sin webbläsaretill det traditionella gränssnittet på en smartphone för att genomföra samtalet. En annanfördel är att användaren inte betalar uppkopplingsavgifter för att ansluta till det pub-lika telefonnätet, utan detta blir något som tillhandahållande operatör av denna tjänstbekostar och finansierar.

Det finns idag begränsad information att utvinna ur ett telefonsamtal anslutet genom detpublika telefonnätet. I uppsatsen undersöktes även vilka fördelar en WebRTC-baseradlösning har gentemot ett traditionellt samtal när det gäller samtalsdata som ursprung,historik samt position. Uppsatsen behandlade användarupplevelsen genom intervjuer föratt på så sätt validera det implementerade systemet.

Genom att använda existerande mjukvara som sipML5, Asterisk och traditionella webb-tekniker som HTML och JavaScript lyckades man koppla ihop webbläsaren med detpublika telefonnätet och tillhandahålla en angenäm användarupplevelse. Allt detta hargenomförts tillsammans med nyckelpersoner på Freespee AB för att undersöka vilka för-delar en WebRTC-lösning erbjuder och webbläsare gentemot en traditionell lösning pådet publika telefonnätet.

iii

Acknowledgements

I would like to thank my supervisor Tobias Lindgren at Freespee AB for answering allmy questions and guiding me. A big thank you to (in no specific order) Sharn, Kayleigh,Karunakar and Jonas for proof-reading.

v

Contents

Populärvetenskaplig sammanfattning iii

Acknowledgements v

List of Figures ix

Abbreviations x

1 Introduction 11.1 Motive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Who should read this report? . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Current problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Thesis goal and expected results . . . . . . . . . . . . . . . . . . . . . . . 21.5 Work flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.5.1 Theoretical Research . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.5.3 Evaluation and improvements . . . . . . . . . . . . . . . . . . . . . 3

1.6 Chosen path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.7 Previous work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.7.1 Web browser vendors . . . . . . . . . . . . . . . . . . . . . . . . . . 41.7.2 Other audio conversation applications . . . . . . . . . . . . . . . . 51.7.3 This thesis in relation to previous work . . . . . . . . . . . . . . . 5

1.8 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Theoretical Background 72.1 The public switched telephone network (PSTN) . . . . . . . . . . . . . . . 72.2 Web Browsers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2.1 History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Hypertext Markup Language (HTML) . . . . . . . . . . . . . . . . 9

2.2.2.1 Hypertext Markup Language (HTML) 5 . . . . . . . . . . 92.2.2.2 Web Real-Time Communication (WebRTC) . . . . . . . . 10

2.2.3 WebSockets - a bidirectional communication channel . . . . . . . . 112.3 Voice over Internet Protocol (VoIP) technology . . . . . . . . . . . . . . . 12

2.3.1 Voice over Internet Protocol (VoIP) History . . . . . . . . . . . . . 122.3.2 Session Initiation Protocol (SIP) . . . . . . . . . . . . . . . . . . . 132.3.3 SIP Proxy servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.4 Network Address Translation (NAT) . . . . . . . . . . . . . . . . . 15

vi

Contents vii

2.4 Interconnecting Web Browsers and Voice over Internet Protocol (VoIP) . . 152.4.1 SIP over WebSockets . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5 Codecs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5.1 G.711 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.5.2 G.729 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.6 Usability and User Experience . . . . . . . . . . . . . . . . . . . . . . . . . 182.6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.6.2 Designing an interface . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Method 203.1 Theoretical research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.1.1 Validity and Accuracy . . . . . . . . . . . . . . . . . . . . . . . . . 203.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.3 Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.1 Why conduct interviews? . . . . . . . . . . . . . . . . . . . . . . . 213.3.2 How were the interviews conducted? . . . . . . . . . . . . . . . . . 213.3.3 Interview reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4 Experiment setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.5 Technical setup and environment . . . . . . . . . . . . . . . . . . . . . . . 22

4 Making a telephone call with WebRTC technology and PSTN 244.1 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.2 Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

4.2.1 Authentication and security . . . . . . . . . . . . . . . . . . . . . . 254.2.2 Audio Codec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.3 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274.3.1 Running SIP in the browser with JavaScript . . . . . . . . . . . . . 284.3.2 WebRTC2SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3.3 Asterisk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3.4 Kamailio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.4 Evaluation and limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 Compare call data in a web browser to a circuit-switched one 325.1 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2 Existing methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.3 Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

5.3.1 Call info . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.3.2 Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.3.3 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.3.4 User browser history . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6 User experience in browser based phone calls 366.1 Goal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366.2 Design and evaluation process . . . . . . . . . . . . . . . . . . . . . . . . . 37

6.2.1 Interface design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376.2.2 Evaluation process . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.3 Result and discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Contents viii

6.4 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

7 Conclusions and future work 447.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.2.1 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457.2.2 Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.3 My contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 467.4 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

A Appendix 48

Bibliography 49

List of Figures

2.1 A simple WebRTC system . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.2 Basic scenario of a successful SIP call . . . . . . . . . . . . . . . . . . . . . 132.3 SIP over WebSockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 Scenario 1: Media Path transmitted through a SIP Proxy . . . . . . . . . 254.2 Scenario 2: Media Path is a Peer-To-Peer connection . . . . . . . . . . . . 254.3 Illustration of smartphone speakers . . . . . . . . . . . . . . . . . . . . . . 31

5.1 Lifecycle for a PSTN call . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

6.1 WebRTC prototype: Overview . . . . . . . . . . . . . . . . . . . . . . . . 376.2 WebRTC prototype asking for microphone permission . . . . . . . . . . . 386.3 WebRTC prototype asking for location permission . . . . . . . . . . . . . 396.4 Outline of enhanced protoype with dial pad . . . . . . . . . . . . . . . . . 426.5 Flow chart for serving client . . . . . . . . . . . . . . . . . . . . . . . . . . 43

A.1 Cellular network coverage on experiment setup . . . . . . . . . . . . . . . 48

ix

Abbreviations

AJAX Asynchronous JavaScript And XML, web techniques to create asynchronous

web applications building software applications.

API Application Programming Interface, a set of routines, protocols, and tools for

building software applications.

IP Internet Protocol, routing layer datagram service of the TCP/IP suite.

HTML Hyper Text Markup Language, a markup language for websites.

HTTP Hyper Text Transfer Protocol, an application protocol for data

communication on the World Wide Web.

IETF Internet Engineering Task Force, large open international community

of network designers, operators, vendors, and researchers concerned with the

evolution of the Internet architecture.

ICE Interactive Connectivity Establishment, a mechanism to permit media

streams to flow between two peers in a NAT environment.

IMS IP Multimedia System, a telecom architecture to build and deliver IP based

services in mobile phones.

ISDN Integrated Services Digital Network, a standard for digital telephones.

One channel for speech, one channel for signaling.

NAT Network Address Translation, the translation of an IP address used within one

network to a different IP.

PSTN Public Switched Telephone Network, a network of telephone lines that

allows any two telephones in the world to connect to each other.

QoS Quality of Service, resource reservation control mechanisms in network traffic.

REST REpresentational State Transfer, this basically means that each unique URL is a

representation of some object.

RFC Request For Comments, a publication of IETF and the Internet Society,

x

Glossary xi

the principal technical development and is a document that describes a certain

Internet technology.

RTP Real Time-Protocol, standard packet format for sending audio and video over

IP networks.

SIP Session Initiation Protocol, signaling protocol for global voice

communication.

SRTP Secure Real-Time Protocol, a profile of RTP providing encryption, message

authentication and integrity.

SVG Scalable Vector Graphics, XML-based vector image format for two-dimensional

graphics that has support for interactivity and animation.

TCP Transmission Control Protocol, provides reliable, ordered delivery of data.

UDP User Datagram Protocol, provides unreliable, possibly unordered delivery of data.

VoIP Voice over Internet Protocol, a collection of techniques for delivering voice

calls over IP networks.

WebGL Web Graphics Library, javascript API for rendering interactive and 2D

graphics.

WebRTC Web Real-Time Communication, technology which enables

plugin-less voice calling, video chat and file sharing in the web browser.

Chapter 1

Introduction

1.1 Motive

WebRTC is a technology for transmitting real-time voice, video and data in web browsers,

released and open sourced by Google in 2011 [1]. WebRTC enables web browsers to have

native support for real-time voice, video, and data capabilities. As such, end-users do not

require additional add-ons or plug-ins to utilize real-time voice and video communication.

This thesis explores and evaluates if a mobile web browser application on a smart-phone

using the 3G network can be used to inter-operate with the PSTN regarding the ad-

vantages and disadvantages involved. This thesis also evaluates the user experience and

interaction.

1.2 Who should read this report?

This report was written for those with a basic understanding of Voice over Internet

Protocol (VoIP) technology or web development, who are interested in connecting their

existing PSTN solutions for use in conjunction with web browsers, such as WebRTC

technology.

1

Chapter 1. Introduction 2

1.3 Current problems

Today, connecting a phone call from a mobile phone involves several problems:.

• The user interface is difficult to follow, the user is required to switch to the native

dialer application when connecting a call from the web browser.

• Users can not make calls in absence of carrier coverage.

• Calls can only be from phone devices, and not tablets.

• Costs associated when making calls, both domestic and foreign.

• Limited capabilities to collect call data on the circuit-switched phone network, from

service providers perspective. [2]

1.4 Thesis goal and expected results

The goal of this thesis and the results expected were:

• Connect a phone call from a mobile based web browser to a phone number utilizing

a 3G network connection.

• Collect call data when performing a phone call utilizing web browser technologies.

• Provide a sufficient user experience for the end user, similar to a native phone

application.

1.5 Work flow

This thesis followed an academic work flow that contained theoretical research, imple-

mentation work, evaluation and highlighted additional areas of/for improvement.

Chapter 1. Introduction 3

1.5.1 Theoretical Research

The theoretical research consisted of two defined goals. Firstly, existing telecommunica-

tion systems were explored and evaluated, the use of VoIP today and how it will be used

in future applications.

WebRTC enables real time plug-in-less voice calling, video chat and data transmission in

the web browser. The second goal studied and evaluated web browser capabilities that

make use of WebRTC technology. This resulted in a pre-study for the latter implemen-

tation phase.

1.5.2 Implementation

Implementation was based on the information gathered from the literature review and

the infrastructure provided by the sponsor. The constructed web application allows a

user to make a phone call from a web browser on a mobile phone to a phone on the PSTN.

The goal for this application was defined as a call without lag with a user interface that

provides ease of use.

1.5.3 Evaluation and improvements

Based on the results from the implementation phase. The web application was evaluated

and improvements were made as necessary. The application was evaluated by answering

the following questions

• Would customers use this product based on WebRTC technology?

1. Is the experience smooth and consistent?

2. Does the application disturb the user with plenty of dialogues?

• What call data does a call through WebRTC allow an application to collect?

• What kind of network connectivity does the application require to provide a suffi-

cient user experience?

1. Is a fall-back required if the connectivity is bad?

• How can we improve the application?

Chapter 1. Introduction 4

1.6 Chosen path

WebRTC is currently the only technology available for real time, plugin-less voice-, video-

and data communication in web browsers that does not force developers to use a specific

signaling mechanism that connects the peers. The thesis will use the thesis sponsor´s

current infrastructure, where signaling is done by using the Session Initiation Protocol

(SIP). Therefore, the sponsor could use their existing infrastructure and a battle-tested

protocol instead of constructing a new one.

The application is available in a web browser. The mobile browsers supporting WebRTC

today are Google Chrome (beta release), Mozilla Firefox (beta release) and Ericsson

Bowser [3]. The target platform for this application was a smart-phone, but the same

technology can be applied to any device utilizing a WebRTC-enabled web browser. The

application was written using existing web techniques such as Hyper Text Markup Lan-

guage (HTML), Cascading Style Sheets (CSS) and JavaScript. Existing SIP implemen-

tations in JavaScript are evaluated. The server software connects two endpoints and

investigate which call data that can be extracted in a click-to-call (where the end-user

only press a button to connect a call) application.

The server uses a SIP Proxy software such as Asterisk or Kamailio and connects two

endpoints, a WebRTC application and a phone on the PSTN to establish a phone call

between them. The SIP Proxy server will act as a intermediary connection, connecting

the two endpoints.

1.7 Previous work

1.7.1 Web browser vendors

This thesis was based on previous research and development done by Ericsson Research

Labs, Google and other participants in the WebRTC project. The WebRTC project

was open sourced by Google June 2011 [1], which was followed by an ongoing work to

standardize the relevant protocols and browser APIs. In October 2012, Ericsson released

their project Bowser [4], the worlds first WebRTC-enabled mobile browser. Ericsson

Research Labs explored inter-working WebRTC with traditional telephony services in

Chapter 1. Introduction 5

February 2012. However, Ericsson only performed this experiment with proprietary

software and on a broadband Internet connection [5].

1.7.2 Other audio conversation applications

Skype, Rebtel, Viber and FaceTime are all examples of well-known applications for per-

forming video and audio conversations. The requirements for all the above mentioned

includes installation procedures and execution in a specific operating system and envi-

ronment. Click2Dial is currently the only web service identified that enables registered

users to call a phone on the PSTN with a single click [6].

1.7.3 This thesis in relation to previous work

WebRTC technology is platform-agnostic, implemented and inter-operated on multiple

computer platforms, allowing the same functionality as the aforementioned video and

audio applications. Click2Dial is based on open source code and technologies [6]. The

Click2Dial software was obtained and the installation was performed and tried in this

thesis but requires a registered user in order to use the service and another solution was

needed. This thesis focuses on providing access to unregistered users, so it would be hard

to integrate using Click2Dial.

Even though Click2Dial was unsuccessful, the author of the library, Doubango Telecom,

has provided many libraries and resources that have been used in this thesis and promote

WebRTC technology.

1.8 Delimitations

This report does not include any source code for implementation, though different imple-

mentations are discussed throughout the report. The discussions will be strictly regarding

their suitability for connecting a web browser to a circuit-switched phone network.

Though video transportation is popular, this thesis chose to focus only on audio trans-

portation using SIP as the signaling protocol. Usability where only one platform is

Chapter 1. Introduction 6

applicable is therefore to be interpreted as only for mobile smart phones and not desktop

platforms.

Chapter 2

Theoretical Background

2.1 The public switched telephone network (PSTN)

The first primitive telephone was invented in 1876 [7]. During 1876-1878 there was no

record of interconnected telephones, only physically connected telephones. To make a

call, one whistled in the transmitter until the callee could hear it and answered. Tele-

phone exchanges were introduced from 1878 and phones were connected to be able to

make calls that spanned cities, countries and continents [7]. This marked the start of

the telephone network which is referred to as the PSTN. The PSTN is the telephone

circuit-switched network that interconnects telephones worldwide [7]. Today the PSTN

uses telephone lines, fiber optic cables, cellular networks and undersea telephone cables,

that are all inter-connected by switching centers [8]. Through the physical connection

of telecommunication mechanisms, one can use a telephone anywhere in the world to

communicate with other PSTN subscribers [8].

The PSTN uses dedicated channels between two endpoints for the call duration and

is today converted to digital signals instead of analog signals. PSTN was found to be

exposed to security issues and needed barriers to provide security and keep the network

stabilized. In addition, PSTN enlists Quality of Service (QoS) to avoid problems such

as:

• Signal loss, an event when voice clipping occurs in a call.

• Signal-to-noise ratio, level of a desired signal to the level of background noise.

7

Chapter 2. Background 8

• Cross-talk, a situation when a signal transmitted on one circuit or channel of a

transmission system creates an undesired effect in another circuit or channel.

• Echo, when the voice signal is repeated on the line. [9]

2.2 Web Browsers

2.2.1 History

The first web browser was released in 1990 by Tim Berners-Lee was known as World-

WideWeb [10]. In 1990 the Internet usage was not globally recognized, however by 1995

the browser with the biggest market share was Netscape Navigator. Netscape Navigator

had 10 million downloads, which gave them 85% of the worldwide Internet usage[11].

In combination with popularity of Netscape Navigator, Microsoft released their first

version of Internet Explorer in 1995. Internet Explorer was bundled with all computers

that was sold with Windows 95 [12]. In the following years, both Netscape Navigator and

Internet Explorer released new versions, where in 1998, Internet Explorer had increased

their market share and caught up with Netscape Navigator [11].

In March 2001 Microsoft released Internet Explorer 6, bundled within the operating

system Windows XP. In early 2002 Microsoft had over 85% of the worldwide Internet

usage [13]. However, the development of Internet Explorer stagnated, the next version of

Internet Explorer was released five years later [14]. Netscape open sourced their browser

source code in 2003 and founded the Mozilla Foundation. The purpose was to coordinate

further development of the browser. The initiative succeeded and they released the first

version of Mozilla Firefox late 2004 [15]. Many users switched from Internet Explorer to

Mozilla Firefox during those years. A significant event for Firefox was December 2009,

when Firefox had a 46% worldwide usage and Internet Explorer had 37% [13].

Google released their web browser Google Chrome in September 2008 [16]. As of February

2013, Google Chrome had 39% worldwide usage which makes it the most widely used

web browser in the world today [13].

The worldwide usage numbers show in the last five years, web browsers underwent sig-

nificant changes. Many vendors switched to an automated updating model, Google for

Chapter 2. Background 9

example wanted to use the automated updating model because it shortens the release

cycle and make sure users utilize great features as soon as they are ready. By adding

automated updating models, the vendors can keep their browsers up-to-date with new

features and security patches [17].

2.2.2 Hypertext Markup Language (HTML)

HTML is a markup language for websites. HTML specifies webpage structure and the

different constituting elements. The first version of HTML was released in the beginning

of 1990 [18]. The World Wide Web Consortium (W3C) initiated a process in 1998

to convince people to follow the new standard for data, XML. Extensible HyperText

Markup Language (XHTML) version 1.0, still allowed older HTML tags to ensure it was

backwards compatible. XHTML 1.0 was made a recommendation in January 2000 by

W3C [19].

A group called WHATWG was founded in 2004 by individuals from Apple, The Mozilla

Foundation and Opera Software. WHATWG was concerned about the lack of interest in

HTML from W3C, wanted to keep working on HTML and not a HTML version based

of XML [20].

The W3C announced in 2006 that the working groups that were working on the new

version of XHTML, would not be renewed [21]. The consortium would start working

together with the WHATWG community. A group was announced to work on the next

version of HTML, version 5 [22].

2.2.2.1 Hypertext Markup Language (HTML) 5

WHATWG began working on the next version of HTML in 2004, ensuring a new version

of HTML4, XHTML1, and Document Object Model (DOM) Level 2 [20]. The Internet

applications uses more features and functionality from the web browsers. HTML5 offers

a number of benefits such as:

• Offline storage.

• Vector graphics with canvas and SVG, WebGL for 3D graphics.

Chapter 2. Background 10

• Rich audio Application Programming Interfaces (API).

• WebSockets and WebRTC for real-time communication without plug-ins and pro-

prietary technologies. [23]

Although the HTML5 definition was completed in December 2012 [24], work has already

continued with HTML5.1 incorporating more features to the browsers.

2.2.2.2 Web Real-Time Communication (WebRTC)

WebRTC was announced and open sourced by Google in May 2011 [25] and was an effort

started by the industry to add real time video and voice communications capabilities to

browsers. The specification is currently not finalized and is still undergoing work to

standardize the browser APIs and relevant protocols. An increasing number of web

browsers announce their time-lines for implementation and support for the WebRTC

technology.

Unlike other traditional real-time systems, such as SIP-based soft phones, WebRTC

communication is directly controlled by a web server through a JavaScript (JS) API [26]

as shown in figure 2.1

Figure 2.1: A simple WebRTC system

Chapter 2. Background 11

Browser vendors Google and Mozilla Foundation announced interoperability for WebRTC

in February 2013 [27] as they demonstrated a video where a video conference call was

transmitted between the browsers.

Johnston, Yoakum and Singh [28] believe that WebRTC will have a major impact on the

way enterprises communicates and how it communicates with consumers. This makes

WebRTC a very promising technology.

The WebRTC technology reuses existing standards such as mandatory Secure Real-time

Transport Protocol (SRTP) for media transmission and mandatory Interactive Connec-

tivity Establishment (ICE) traversal through Network Address Translations (NAT) and

firewalls [29]. The signaling method is unspecified and left to the developer to decide

which is most suited. Common methods when developing pure web applications are

Hypertext Transfer Protocol (HTTP) and WebSockets (WS). The HTTP and WS pro-

tocols are responsible for exchanging the call control and transmitting session description

information among the participants.

Table 2.1 below shows specific implementation details in WebRTC.

Property WebRTC supportMedia Transport New RTP profilesSession negotiation SDP, trickleMedia transport path/connection Same path with all media and controlSecurity Model User trust browser, but not web siteAudio codecs Mandatory Opus and G.711, optionally othersVideo codecs Undefined yet, but likely VP8 and/or H.264 [29]

Table 2.1: Implementation details in WebRTC.

2.2.3 WebSockets - a bidirectional communication channel

WebSocket is a protocol specified by The Internet Engineering Task Force (IETF) and

is a part of the HTML5 API mentioned in part 2.2.2.1. It creates a bidirectional client-

server connection from the JavaScript code in the browser to the web server. Any data

with a packet boundary can be sent over Transmission Control Protocol (TCP) in either

direction, once the connection is established.

The current attempts to provide real-time data communication on the web involves

polling and server-side push technologies. These solutions often involve keeping two dif-

ferent connections running, which restricts the sent data to data that has been explicitly

Chapter 2. Background 12

approved. Alternatively, a WebSocket connection on the other hand, allows the server

to send data whenever it wants with lower latency than using long polling [30].

A client and server can establish a WebSocket connection by upgrading from the HTTP

protocol to the WebSocket protocol in the initial handshake, see example below:

Browser request and server response

GET /text HTTP/1.1\r\n

Upgrade: WebSocket\r\n

Connection: Upgrade\r\n

Host: www.websocket.org\r\n

...\r\n

HTTP/1.1 101 WebSocket Protocol Handshake\r\n

Upgrade: WebSocket\r\n

Connection: Upgrade\r\n

...\r\n

Once the connection is established, data frames can be sent in the bidirectional commu-

nication channel. Where both text and binary frames, can be sent in either direction

and at the same time. [31]

2.3 Voice over Internet Protocol (VoIP) technology

2.3.1 Voice over Internet Protocol (VoIP) History

VoIP is a technology that emerged in the beginning of 1990 and enables phone calls

over the Internet protocol. The problems that existed when using telephones over an

analog network, also existed on the VoIP network [32]. The biggest advantage using IP

networks is the costs, as the toll charges can be skipped. Another big advantage is that

it can carry 5 - 10 times the number of phone calls over the same bandwidth compared

to PSTN [33].

Problems such as data loss, jitter and echo that could exist on the analog network now

exist in VoIP calls. The biggest issue is that current IP networks were not intended to

Chapter 2. Background 13

carry real time traffic. VoIP is trying to reconcile this problem, sending real-time data

over a non-real-time network [34].

2.3.2 Session Initiation Protocol (SIP)

SIP is a standard for maintaining, establishing and terminating Internet sessions, includ-

ing voice and video calls and conferences [35]. Global voice communication use the SIP

for signaling.

Figure 2.2: Basic scenario of how a successful SIP call can be established and termi-nated

The figure 2.2 describes a very basic SIP call flow case where Alice is the caller and Bob

is the recipient [36]. Alice and Bob connects the call directly and does not make use a

SIP Proxy.

Caller Alice wants to initiate a call and sends a initial “INVITE” to Bob. The “INVITE”

contains signaling information in various headers such as phone numbers and SIP path.

The “INVITE” also contains a Session Description Protocol (SDP) that describes which

media settings that A supports and prefers, those media settings can be codecs and

media addresses. When Bob‘s receives the “INVITE”, it will respond with a “100 Trying”

Chapter 2. Background 14

SIP response which means that it has accepted the “INVITE” from A and is processing

it. When the phone at Bob‘s starts to ring, a “180 Ringing” is sent back to notify Alice.

Callee Bob answers the phone and responds with a “200 OK” SIP message to Alice.

This also contains a SDP body with media settings that Bob supports and prefers. It is

important to note that Alice and Bob are negotiating which media settings will be used

during the call. Finally Alice replies with an “ACK” to acknowledge and confirm that

the “200 OK” were received successfully. From this point, the two parties can speak to

each other using the negotiated media parameters.

When one party ends the calls, a “BYE” message is sent to the other party, which

responds with a “200 OK” confirming call termination.

2.3.3 SIP Proxy servers

SIP user-agents can communicate directly with each other without the involvement of

other devices. Despite this, an SIP Server is often added to create a more practical

system which facilitates end-to-end communication utilized as a public service. [37]

The Request For Comments (RFC) document 3261, SIP: Session Initiation Protocol,

describes an SIP Proxy server as a entity that acts both as a server and a client, to make

requests on behalf of other clients. The proxy server primarily handles routing, ensuring

a request is sent to another entity closer to the intended user. The proxy also enforces

policies and allows users to make calls. [35]

The RFC 3261 also specifies that “It is an important concept that the distinction between

types of SIP servers is logical, not physical”. With that quote in mind, a SIP proxy server

can have several purposes:

• Application server

• Call routing

• Presence server

• Location server/registrar

• Outbound proxy

Chapter 2. Background 15

Each of these parts is responsible for different functions. Where the proxy server can

combine and provide one or multiple of the aforementioned functions.

2.3.4 Network Address Translation (NAT)

NAT is a technique that enables several devices to be connected to a single Internet

connection with one or many IP addresses. NAT is the functionality, built into the

firewall or router, connecting the local network with the Internet.

NAT can be used so that every internal IP address permanently, or temporarily, matches

an outer IP address. A typical scenario would be a router with NAT functionality that

translates the local connection (LAN), with the Internet (WAN). The internal addresses

are translated in the router by the NAT function to an external valid IP address. [38]

2.4 Interconnecting Web Browsers and Voice over Internet

Protocol (VoIP)

WebRTC is independent of WebSockets and you can use AJAX, a concept like server

push, WebSockets or plain HTTP for signaling. This is because the authors at IETF

decided early that they did not want SIP to be a part of the browser. Developers

therefore, had to do the signaling in JavaScript, the authors wanted to keep the signaling

part outside the scope of the browser. [39]

There are two ways to inter-work SIP systems and WebRTC enabled browsers. One can

either do translation at the SIP Proxy server or implement SIP in JavaScript. SIP Proxies

already supports several underlying transports such as TCP and User Datagram Protocol

(UDP) and can be extended to support WebSockets as another transport mechanism if

needed.

The flow for using SIP over WebSockets (see figure 2.3) can be recognized from above in

chapter 2.2.3.

Chapter 2. Background 16

Figure 2.3: SIP over WebSockets typical flow

The SIP over WebSockets protocol allows developers to implement SIP in JavaScript,

whilst promoting end-to-end media paths if possible. Translating at the gateway requires

both the signaling and media path go through the gateway. SIP over WebSockets is not

affected by NAT translations the same way as traditional SIP is, since it is sending data

over TCP sockets.

By using SIP over WebSockets one can communicate with the server software and bridge

existing telecommunication SIP infrastructure.

2.4.1 SIP over WebSockets

As mentioned before, prior to sending SIP requests, a SIP WebSocket Client connects

to a SIP WebSocket Server and performs the connection handshake. Each SIP message

must be carried within a single WebSocket message where a WebSocket message must

not contain more than one SIP message [40]. First, lets define two new terms:

• SIP WebSocket Client - A SIP entity capable of opening outbound connections

to WebSocket servers and communicating using the WebSocket SIP sub-protocol.

• SIP WebSocket Server - A SIP entity capable of listening for inbound con-

nections from WebSocket clients and communicating using the WebSocket SIP

sub-protocol

Chapter 2. Background 17

Examples of SIP WebSocket Clients implemented in web browsers is JsSIP, SIPML5 and

sip-js. More information about these will follow in chapter 4.3.1.

SIP Proxy Servers with support for incoming WebSockets connections on the market

today are OfficeSIP, Kamailio, Asterisk and FreeSwitch. More about these in chapter

4.3.3 and 4.3.4.

2.5 Codecs

A codec is a technology to encode and decode streams of information, in this case audio.

Two different codecs, G.711 and G.729 were chosen for this application for their ability

to inter operate with legacy PSTN and SIP systems and the perception of QoS is not

significantly different between the two of them [41]. This report focuses on two methods

utilizing the frequency ranges, narrow band and wide band audio codecs. A narrow band

carries voice information in a narrow band of frequencies, using a specific frequency range

set aside by United States Federal Communication Commission (FCC). In comparison a

wide band audio codec, uses more than one voice channel, where you are limited. [41]

2.5.1 G.711

G.711 first released for usage in 1972 by Bell systems, was designed to carry audio at

a fixed bit rate of 64 Kbps using narrow band technology. G.711 is referred to as the

“grandfather of digital telephony” because of its interoperability with the PSTN and

ISDN lines [42]. G.711 is therefore supported by most VoIP providers.

2.5.2 G.729

G.729 is a compressed audio codec released in 1996 that utilizes compressing techniques

that make it tolerant of packet loss and jitter. The G.729 codec has a low bit rate at

8 Kbps and offers decent audio quality in relation to the bandwidth usage and bit rate.

Despite the low bit rate, it is a “expensive” codec in terms of CPU processing power

[43]. The G.729 was initially narrowband, but has “spawned” another audio codec using

wideband technology, G.729.1. G.729.1 is a scalable wideband speech audio codec with

bit rates between 8-32 Kbps and is bitstream interoperable with the G.729.

Chapter 2. Background 18

2.6 Usability and User Experience

2.6.1 Introduction

Usability is defined by ISO 9241-11 as “the extent to which a product can be used by

specified users to achieve specified goals with effectiveness, efficiency, and satisfaction in

a specified context of use” [44]. The definition can be interpreted as creating a product

and service which is as simple and as pleasant to use as possible.

ISO 9241-210 defines User Experience (UX) as “a person’s perceptions and responses that

result from the use or anticipated use of a product, system or service” [44]. It relates

in this context, to how a web site or a web application is fulfilling the expectations and

goals of the user in an efficient and satisfying way. Similar to usability, a UX can be

measured.

To summarize, the difference between usability and UX, usability can be interpreted as

“can the user accomplish their goal with reasonable effort and satisfaction?” whereas UX

is interpreted as “did the user have as delightful an experience as possible”.

2.6.2 Designing an interface

Usability consultant Jakob Nielsen and Rolf Molich have developed a short list of general

heuristics guidelines [45]:

• Simple and natural dialog - Simple means no irrelevant or rarely used informa-

tion. Natural means an order that matches the task.

• Speak the user’s language - Use words and concepts from the user’s world. Do

not use system-specific engineering terms.

• Minimize user memory load - Do not make the user remember points from one

action to the next. Leave information on the screen until it’s not needed.

• Be consistent - Users should be able to learn an action sequence in one part of

the system and apply it again to get similar results in stages.

• Provide feedback - Let users know what effect their actions have on the system.

Chapter 2. Background 19

• Provide clearly marked exits - If users get into part of the system that does

not interest them, they should always be able to get out quickly without damaging

anything.

• Provide shortcuts - Shortcuts can help experienced users avoid lengthy dialogs

and informational messages that they do not need.

• Good error messages - Good error messages let the user know what the problem

is and how to correct it.

• Prevent errors - Whenever you write an error message you should also ask, can

this error be avoided?

Designing and evaluating a UX is the process of understanding and investigating how a

user feels about using a system (product, service, non-commercial item or a combination

of them). Performing a UX evaluation is a non-trivial task, especially when it applies on

coming up with solid results, as the area is subjective, context-dependent and dynamic

over time [46].

Chapter 3

Method

This chapter discusses the working process and how the goals could be reached. Methods

verifying and evaluating the results as well as the environment and metrics are described.

3.1 Theoretical research

3.1.1 Validity and Accuracy

A duscission on the validity and accuracy of all material contained within this report,

including the choice of sources and any potentially occurring accuracy problems.

Blogs

In a few cases, blogs have been used as sources. The credibility of each author has

been examined and deemed to be reliable and accurate enough. The VoIP community is

mature and has many skilled and experienced contributors, which made validating the

authors a trivial task.

Abbreviations

For abbreviations and simple technical terms, fact sites such as Abbreviations[47] has

been used. After comparing those abbreviations with literature, it was decided that these

sources was appropriate to be used as a source throughout the report.

Company websites

20

Chapter 3. Method 21

Describing tools and their functionality, the tools creator websites have been used as

sources. An occurring problem is the vendors do not write objectively about their product

in comparison to others. This has been noted and the information has not been used.

Instead it has been used to list features and implementation details.

3.2 Implementation

The implementation was performed in collaboration with employees at the thesis spon-

sor’s office. It involved configuring and installing servers and software, and constructing

an application to use the mobile web browser. The web application was built to fit a

template for an existing customer of the sponsor. This was done to replicate a real use

case scenario.

3.3 Interviews

3.3.1 Why conduct interviews?

It was important for the sponsor of this thesis to know if end-users would be willing to

use this sort of system to make phone calls. Interviews were conducted to identify user

concerns and provide insights on daily interactions of users and their smart phones.

3.3.2 How were the interviews conducted?

Interviews were conducted with a number of users who had performed a search on a smart

phone for any company within the last week. Users that were selected were between the

age of 20 to 40 years old and consisted of both men and women. About 2/5 of the users

were considered advanced mobile users. The interviewees were handed a smart phone

with the web application, on a 3G network, and asked to make a phone call. The phone

call was to last for one minute and when the phone call had ended, they were asked a

series of questions reflecting on their experience.

Chapter 3. Method 22

3.3.3 Interview reliability

Using interviews as a source requires one to take a few things into account when evalu-

ating the answers. The biggest problem is the interviewer misinterprets what the inter-

viewee says. The interviews were in this case conducted in both Swedish and English,

which could lead to translation problems when combining results.

Despite these issues, it was still decided interviews were the best way to gather the re-

quired information. The purpose is to find out if the experience was a positive or a

negative one, not gathering specific facts. This means that individual language misin-

terpretations and errors are negligible.

3.4 Experiment setup

After implementation of the web application, tests were conducted on a 3G network in

central Uppsala. According to the operator Tre, the 3G coverage where the tests were

performed has a bandwidth of 20Mbit/s - 32 Mbit/s (see figure A.1). The latency on

the 3G network averaged to 120 ms in 10 measurements using the tool Ookla Speedtest

[48], using a server in Stockholm provided by the company SpaceDump IT AB. The

International Telecommunication Union recommends a maximum of 150 ms one-way

latency to avoid callers noticing the round-trip voice delay [49].

The experiment goal was to find out if it was possible to provide a sufficient user expe-

rience without interferences.

3.5 Technical setup and environment

The mobile phone used in the experiment was a Google Nexus 4, because of its perfor-

mance and ability to execute Google Chrome (Beta 28.0.1500.64) on Android 4.2.2. The

server infrastructure was running Debian Linux (Stable 7.1).

In August 2013, the only browsers supporting WebRTC were:

• PC: Google Chrome 23, Mozilla Firefox 22, Opera 12.

Chapter 3. Method 23

• Android: Google Chrome 28, Mozilla Firefox 24, and Opera Mobile 12.

• iOS: Ericsson Bowser. [3]

Chapter 4

Making a telephone call with

WebRTC technology and PSTN

This chapter describes the phone call connection to the PSTN.

4.1 Requirements

Our goal was to design and implement a web application that uses WebRTC technology.

Using a mobile browser, the client was able to make a phone call from a WebRTC enabled

browser to a PSTN cell phone number. The web application could make calls in absence

of carrier coverage, using a WAN connection and provide toll-free calls.

4.2 Design

Two connectivity solutions that would allow a connection from a mobile phone to the

PSTN were identified and focused on, where figure 4.1 shows a scenario which the media

path was relayed through the SIP Proxy.

In this case, the role of the SIP proxy convert the SIP transport from WebSocket protocol

to UDP, TCP or TLS, all of which are supported by legacy SIP networks.

24

Chapter 4. WebRTC and PSTN connectivity 25

Figure 4.1: Scenario 1: Media Path transmitted through SIP Proxy

Relaying the media path through the SIP Proxy, requires the proxy to have a larger band-

width rate and handle less active connections. Given this a second solution, described

in figure 4.2, shows a scenario in which the media path is done Peer-To-Peer.

Figure 4.2: Scenario 2: Media Path is a Peer-To-Peer connection

4.2.1 Authentication and security

Authentication

The very nature of a web application requires all applications client side logic is open

for anyone to access. The SIP protocol requires authentication. The application imple-

mented on the other hand, does not require authentication, because the application is a

click-to-call one, where the end-user only press a button to connect a call.

Chapter 4. WebRTC and PSTN connectivity 26

A solution to this problem is offered by the SIPCORE Working Group in the “The

WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)” specification

[40]. When a user enters the website, the provider do not want to expose any SIP

passwords into the web for security and privacy reasons.

The website provides the user with a SIP identity and a temporary token (valid only

for a short time). The web server then stores the SIP identity and temporary token in

a database. During the WebSocket handshake request, the web application sends the

SIP identity and token as extra parameters in the URL query. The web server then

reviews the details in the URL query and compares them to the stored values in the

database. When the values match, the WebSocket will receive an “authenticated” for

that SIP identity. Once the connection is confirmed and validated, the user can register

and make calls. The web server needs to verify the identity in the SIP requests to make

sure a user is not already authenticated with that token and SIP identity, otherwise the

request should be rejected.

When the user closes its browser or logs out of the system, the web server will remove

the SIP identity and the token from the database. That will notify the SIP WebSocket

Server to revoke and close the WebSocket connection. SIP authentication is not needed

nor does it take place in this scenario.

Another possible implementation, is to always send the same credentials when authen-

ticating, as most SIP Proxy Servers can handle multiple signed in users with the same

credentials.

Security

WebRTC communication uses the RTP protocol (Real-time Transport Protocol), more

specifically a profile of it called SRTP, Secure Real-time Transport Protocol. SRTP

provides a framework for encryption and authentication of RTP and RTCP streams.

SRTP helps you achieve high throughput and low packet expansion. Secure media is a

requirement of WebRTC and as a result, SRTP must be available. The built-in Asterisk

HTTP server is used to provide the WebSocket support.

To allow a peer, user, or friend access using the WebSocket transport it must be added to

their transport options. To restrict access to clients using only an HTTPS connection, the

Chapter 4. WebRTC and PSTN connectivity 27

SIP Proxy server need to be configured to allow the secure WebSockets (WSS) transport

only. As of now, the Asterisk version 11.5.0 does not support WSS connections [50].

4.2.2 Audio Codec

The two codecs focused on, in 2.5, G.711 and G.729 are compared for their bandwidth

usage in table 4.1.

Codec Bandwidth EthernetG.711 (64 Kbps) 87.2 KbpsG.729 (8 Kbps) 31.2 Kbps

Table 4.1: Codec bandwidth comparison

During a call, the following data would be used with the G.729 codec:

31.2Kbps up and 31.2Kbps down= 62.4Kbps in total

62.4 Kbps = .0076MBps

60seconds x .0076= .456MB per minute.

So the G.729 codec uses roughly .5MB/min during a VoIP call.

During a call, the following data would be used with the G.711 codec:

87.2Kbps up and 87.2Kbps down= 174.4Kbps in total

174.4 Kbps = .021MBps

60seconds x .021= 1.26MB per minute.

So the G.711 codec uses roughly 1.26MB/min during a VoIP call.

The G.711 codec requires a connection almost 3 times faster than that required by the

G.729 codec. Therefore, this thesis focused on using G.729 codec instead of G.711.

4.3 Implementation

The infrastructure was a server running Debian Linux (Stable 7.1).

Chapter 4. WebRTC and PSTN connectivity 28

The WebRTC technology is independent of WebSockets, therefore a number of tech-

nologies can be used for signaling; Asynchronous JavaScript and XML (AJAX), server

push or plain HTTP. The sponsor’s current infrastructure involved a solution based on

Asterisk and Kamailio (described in 2.3.3)

4.3.1 Running SIP in the browser with JavaScript

Two major SIP libraries for the web browsers were identified, JsSIP[51] and sipML5[52].

They are both built in JavaScript and use SIP over WebSocket (see previous chapter

2.4.1). Since the author of sipML5 also released the project WebRTC2SIP (see section

4.3.2), it was decided that the web application would utilize this library.

sipML5 supports the desktop and mobile version of Google Chrome and Mozilla Firefox.

The library enables developers to connect to any SIP or IMS network from the web

browser to make and receive audio and video calls.

4.3.2 WebRTC2SIP

WebRTC2SIP is a smart SIP and Media Gateway connecting WebRTC endpoints to any

SIP-legacy network, first released in December 2012 by Doubango Telecom, and has since

had six major releases.

The gateway consists of four different modules, an SIP Proxy, RTCWeb Breaker, Media

Coder and a click-to-call service.

The purpose of the SIP proxy (chapter 2.3.3) is to convert the SIP transport from Web-

Socket protocol to UDP, TCP or TLS to support all networks. The WebRTC specification

make support for ICE and DTLS/SRTP mandatory. SIP-legacy endpoints do not sup-

port these features, which remains a problem. The RTCWeb Breaker negotiates and

converts the media stream to allow these two worlds to inter-operate. The click-to-call

service is a complete SIP click-to-call solution, based on the aforementioned components.

4.3.3 Asterisk

Asterisk is an open source software, first released in 2004. Asterisk can be used as a

SIP Proxy Server, SIP registrar and a location server. Asterisk can therefore be best

Chapter 4. WebRTC and PSTN connectivity 29

described as a “back-to-back user agent” (B2BUA). B2BUAs are often implemented in

media gateways to bridge media streams for full control over the session (useful during

call recording). We will, however, describe it as a SIP Proxy Server, to have a common

name for the back end software used.

Asterisk provided us with the functionality needed in figure 4.1, functionality to listen

for incoming WebSocket connections and support for WebRTC. A major disadvantage

with this software is that Asterisk does not support secure WebSockets as of today. This

means we cannot use SRTP, as it requires a secure channel to send the keys. One cannot

have secure symmetric encryption and send the keys in the clear, so we will have to use

regular RTP combined with Asterisk.

Configuration

To enable WebRTC support in Asterisk (in a Linux environment), according to Asterisk

documentation [53], one needs to do the following.

• Build and install SRTP; download and configure SRTP and its development

headers.

• Configure WebSocket module; enable the WebSocket module in the configura-

tion file http.conf and ensure it is running on port 8088

• Configure chan_sip module

– Add WebSocket as a transport layer the sip.conf configuration file

– Enable RTP Audio-Visual Profile with Feedback (AVPF) in the sip.conf con-

figuration file

– Enable encryption in the sip.conf configuration file to support media encryp-

tion

4.3.4 Kamailio

Kamailio is a open source SIP server released under GPL. It can handle thousands of

calls per second with features such as TCP, UDP and SCTP, WebSocket support for

WebRTC and many others. The WebSocket and WebRTC support was integrated into

Kamailio by Peter Dunkley on July 9th, 2012 [54].

Chapter 4. WebRTC and PSTN connectivity 30

4.4 Evaluation and limitations

All three server solutions were tried, WebRTC2SIP was highly anticipated but unfor-

tunately, the WebRTC2SIP system was never successfully functionally. The call came

through, but once the phone answered, there was not any sound.

The reason we wanted to use WebRTC2SIP was because we hoped to have the media

path go peer-to-peer instead of proxying it over the SIP Proxy Server. After additional

research and a trial and error approach, it was discovered that it was not possible. The

WebRTC media cannot go directly to PSTN because it is encrypted (SRTP) and SR-

C/DST addresses are from the ICE negotiation. The final version of the web application,

therefore had the media path go through the SIP Proxy Server (figure 4.1)

The only SIP Proxy Server that could transmit the call successfully was Asterisk. Due

to time constraints and issues with G.729, the only codec that was successfully used in

the call was G.711. The SIP Proxy Server software with the best documentation was

Asterisk, and due to the previously mentioned time constraints, it was also the reason

more time was spent on Asterisk than Kamailio. Asterisk was also ultimately chosen.

To prevent abuse of these services, a white list of numbers allowed to call to, should be

put in place. The use of a white list, makes sure users can not call any number they

desire, national or international.

Comparing the stated goals and problems in chapter 1, the use of web browser and call

transmission solves the inconsistent user interface allowing users to employ whichever

device they want, given it has a WebRTC enabled web browser installed. This call will

only be dependent on Internet access, and not carrier coverage. It also provides toll-free

phone calls for the end users, the service provider pay the same amounts.

A limitation in the mobile version of the WebRTC enabled browsers was found, as there

is no way to direct the speaker in which the audio output will come from (4.3).

Chapter 4. WebRTC and PSTN connectivity 31

Figure 4.3: Illustration of smartphone speakers

The WebRTC implementations on mobile browsers does not include a way of directing

the audio output. The current solution uses the regular speaker (speaker #2 figure 4.3),

where the only way to use another speaker is to plug in a wireless or corded headset that

utilizes an external set of speakers.

There was a commit related to this in the source code for Chrome web browser for

Android, on June 21th 2013, that changed the audio output to the speaker instead of

the ear-piece: “Turn on speakerphone by default for WebRTC on Android. This routes

audio to speaker, instead of earpiece, by default for WebRTC on Android.” [55].

Until Asterisk implement support for secure WebSockets, this solution is not secure.

Chapter 5

Compare call data in a web browser

to a circuit-switched one

This chapter assumes that the phone call has been successfully established. A regular,

circuit-switched phone call over the PSTN today, allows only a few things for a callee or

a caller to extract and analyze. The available data for a network operator on a PSTN, is

the duration of the call, whether a call was answered and the numbers of the callee and

caller.

This chapter compares call data extractable in a PSTN phone call with one made using

WebRTC technology.

5.1 Goal

To investigate the data a browser can extract from its web browser session and its

comparison to a circuit-switched session.

5.2 Existing methods

A regular, circuit-switched phone call over the PSTN, has the life cycle shown in figure

5.1 below.

32

Chapter 5. Compare call data on WebRTC technology and PSTN 33

Figure 5.1: Lifecycle for a PSTN call

5.3 Comparison

The transport layer for WebRTC is the Internet Protocol (IP) and the PSTN uses circuit

layers. One can, therefore, expect to use more of the information being transmitted. By

using functionality standardized in web browsers, one can see that through the use of

different APIs and functionality we can gather a comprehensive list on the user ID and

call execution.

5.3.1 Call info

Calls transmitted through, both the circuit-switched network and WebRTC technology

are able to track duration, timestamps, callee and caller numbers, and whether a phone

call remained unanswered [2].

Chapter 5. Compare call data on WebRTC technology and PSTN 34

5.3.2 Location

Using a client side language such as JavaScript (and in a HTML5 enabled browser, see

2.2.2.1), one can fetch user properties from the web browser. In this case, the object

containing the information is called window.navigator.geolocation, which when requested

accesses the users location. Once an application has access to a users longitude and

latitude, it can easily connect a user to a city and country.

If you are not willingly allowing your location to be shared, the application estimates on

your location based on your IP address.

5.3.3 Environment

Through the same window.navigator object, an application can retrieve data to extrap-

olate information such as;

• Operating system.

• User-agent (UA), browser identification. Although, doing browser identification

based on the User-agent is not recommended.

• Network connection. [56]

The points stated above is the only information standardized that web browsers are

expected to implement. Other suggested APIs include attributes to avoid tracking com-

pletely and power status (for mobile devices).

5.3.4 User browser history

The Request For Comments (RFC) document 2616, HTML defines a request-header

field (Referrer) containing the referrer [57], the previously visited website. There are few

situations where the HTTP Header field will be empty though, among these:

• The user entered the URL immediately in the address bar of the web browser.

• The website is used as a start page for the web browser.

Chapter 5. Compare call data on WebRTC technology and PSTN 35

• Opening a new browser window.

• If the user has installed anti-virus software, browser plugin or firewall that strips

the header field from all requests done in the browser.

5.4 Conclusion

A comparison between data collected from a circuit-switched phone call over a web

browser, highlights that there is more useful data retrievable from using the mobile web

browser. Whether users are comfortable sharing this information will be discussed in

chapter 6.

In the introduction of chapter 1, a few goals and problems were stated. This chapter

has showed that more call data can be collected in the web browser call than over a

circuit-switched call.

Chapter 6

User experience in browser based

phone calls

This chapter expects that a call has been successfully established from the web browser

to a phone connected to the PSTN. It is also assumed that data was collected from the

web browser.

This chapter focuses on evaluating the user experience, including which permissions

users are comfortable sharing and perceptions of the overall experience using the web

application.

6.1 Goal

To evaluate the user experience of performing a phone call using the Google Chrome

mobile browser, on a smart phone running the Android operating system.

The web application consists of a logotype, a short introduction text, and three buttons.

The top button is the one that indicates “Call” and will place the actual call. The two

other buttons are informative and are not relevant.

The web application layout and base was provided by the thesis sponsor. Their main

focus lay in how a user would interact with an existing web page of theirs. It was decided

that the best results would be reached by using a real use case.

36

Chapter 6. User Experience 37

6.2 Design and evaluation process

6.2.1 Interface design

Figure 6.1: WebRTC web application. The URL is blurred by request of the thesissponsor.

Chapter 6. User Experience 38

Figure 6.2: WebRTC web application asking for microphone permissions. The URLis blurred by request of the thesis sponsor.

Chapter 6. User Experience 39

Figure 6.3: WebRTC web application asking for location permissions. The URL isblurred by request of the thesis sponsor.

6.2.2 Evaluation process

The evaluation was done among a group of users to determine if the audio quality and user

interface is sufficient. During the evaluation, topics such as audio quality, permissions,

privacy concerns, and user experience was raised.

The following interview questions were identified as relevant by the thesis sponsor and

asked to the group of interviewees:

1. Do you feel comfortable sharing your location?

2. Do you feel comfortable sharing your microphone?

Chapter 6. User Experience 40

3. Is the audio quality sufficient?

4. Would you use this product again?

The test group was required to have performed a product search on a mobile smart phone

within the last month and have ended up on a retailers website.

Interview no. 1

1. No, the interviewee would press “Deny”.

2. Yes, the interviewee would press “Allow”. To perform the action intended, the inter-

viewee felt comfortable sharing the microphone.

3. Very satisfying, could not notice a difference in quality to a ordinary PSTN call.

4. Yes, it is a great execution and you get to call for free.

The goal was achieved.

Interview no. 2

1. No, the interviewee would press “Deny”.

2. Yes, the interviewee would press “Allow”.

3. Very satisfying, audio volume could be raised.

4. Yes, as long as it is a free service.

The goal was achieved.

Interview no. 3

1. No, the interviewee would press “Deny”.

2. Yes, the interviewee would press “Allow”.

3. Yes.

4. Yes.

The goal was achieved.

Interview no. 4

Chapter 6. User Experience 41

1. Yes, the interviewee would press “Allow”.

2. Yes, the interviewee would press “Allow”.

3. Yes, it is satisfying, but it is not perfect.

4. Yes, as long as it is a free service.

The goal was achieved.

Interview no. 5

1. No, the interviewee would press “Deny”.

2. Yes, the interviewee would press “Allow”.

3. Yes.

4. Yes.

The goal was achieved.

6.3 Result and discussion

The interviewees almost unanimously agreed on the majority of the questions. It was,

therefore, expected that completing more interviews would not change this result. All

interviewees seemed to be sufficiently satisfied with the web application.

This chapter proved that a consistent and employable user interface for connecting phone

calls could be constructed, with total user satisfaction.

Analyzing the web application in regards to guidelines stated by Nielsen and Rolf Molich

in chapter 2.6.2, we can see that the web application follows their guidelines regarding

a scaled down interface and providing a natural and descriptive actions. The web appli-

cation has a minimal amount of actions and most of all, it is consistent because it does

not remove the user from the current application they were using. The web application

guides the user to describe which part of the user interface they are in and where the next

action would take them. During the interviews, there was no hardship in understanding

the user interface.

Chapter 6. User Experience 42

6.4 Future work

The initial web application outlines a basic user interface with only the most necessary

functionality implemented, and there is plenty of room for improvement. As such a

number of updates and improvements on the base system have already been identified,

some of these are listed (figure 6.4);

Figure 6.4: Outline of enhanced prototype with dial pad and other buttons

The figure 6.4 shows what could be used as an overlay once the user presses the “Call”

button. By using the JavaScript language with HTML5 APIs such as WebSockets, you

can use the client to:

• Create a dial pad.

• Hold the call.

• End the call.

Chapter 6. User Experience 43

A few of these are already constructed and demonstrated in the library employed in the

web application, sipML5 [52]. As mentioned in the end of chapter 4, there are issues with

which speaker being used in the mobile browsers. This is something that will, hopefully,

be patched and offered in the API.

Assuming the call is conducted in a web browser, a limitation of this application once a

user has bad Internet coverage, the call will disconnect or fail to connect. A mechanism

to provide a fallback would, therefore, be appropriate (described in figure 6.5). The

mechanism would enlists some sort of bandwidth measuring tool. This tool would return

to connect using the regular PSTN if the bandwidth does not meet the requirements

(chapter 4.2.2). Such a solution could be implemented where the user would download

a payload, of a given size, from a server and measure the download time.

Figure 6.5: Flow chart for bandwidth testing

Chapter 7

Conclusions and future work

7.1 Summary

In the introduction, a number of goals and problems were listed. These goals have been

examined throughout the report and this chapter will include a summary of the results.

This thesis has proved that by using WebRTC technology and performing the call through

a web browser on a mobile smart-phone, whilst utilizing the 3G network, a user can call

to a phone connected to the PSTN. The performed call provides a user experience similar

to a native solution, with superior tracking, than one made on the PSTN. This thesis

involved evaluating and utilizing server software such as Asterisk, WebRTC2SIP and

Kamailio.

Web browser technology enlists a number of benefits over PSTN, the web browser employs

a consistent user interface where calls can be made free of charge from a number of devices

whereas the only requirement is a WebRTC enabled web browser and Internet access. To

prevent abuse of these services, a safeguard should exist on the server, that allows only

white listed numbers to be put through. If such a safety mechanism is in place (or some

sort of authentication as suggested in chapter 4) users are making free phone calls to

the PSTN. There will still be an associated cost, however, this one can now be charged

to the service provider. The web application in this thesis used the library sipML5 to

connect and perform the call.

44

Chapter 7. Conclusions and future work 45

This thesis showed that the call data collected by a web browser based application is

more extensive from a identification standpoint. It also showed, however, that users are

very cautious when it comes to privacy and sharing their location on their device.

7.2 Evaluation

In this section, a final evaluation of the objectives and learning outcomes will be reviewed,

along with the thesis and the work performed.

7.2.1 Goals

Connect a secure phone call from a mobile based web browser to a phone

number utilizing a 3G network connection

A connection was made from a mobile phone, Google Nexus 4 (Android, version 4.3), to

the PSTN. The mobile phone was connected to a 3G network provided by the Swedish

operator, Tre. The network had a measured latency of 120 ms. The low latency rating

allowed the completion of the goal, in part not affecting the user experience during calls.

However, the calls performed during the implementation process were not secure. It was

not possible to use secure WebSockets to connect the calls.

Collect call data when performing a phone call utilizing web browser tech-

nologies

By using the Internet as a transport layer, it was expected that one could extract call

data from a phone call utilizing web browser technologies. This proved to be correct.

It was also shown that one could extract more data from a call performed with web

browsers than a call performed only in the PSTN.

Provide a sufficient user experience for the end user, similar to a native phone

application.

The objective was to provide a user interface that would satisfy users and have the

potential to replace the native phone application that exists on mobile smartphones

today. The implementation was successful providing a user interface that users would

use, though it was not ready to replace the native phone application functionality-wise.

Chapter 7. Conclusions and future work 46

7.2.2 Thesis

The thesis was successful. The expectations before the start of the thesis were that most

of the work would focus on constructing new and modifying existing software. It turned

out to be mostly configuration issues that needed to connect phone calls from the web

browser to the PSTN. The thesis also proved to require most time spent on connecting

the calls, and not evaluating the calls and the user interface.

7.3 My contribution

My contribution proved one can successfully replace an existing PSTN service based on

the native caller in a mobile device, with the WebRTC technology in a mobile browser

on a smart-phone whilst utilizing a 3G mobile network. The call was connected and

performed whilst keeping users satisfied. The 3G mobile network had a latency below

the recommended 150 ms by the International Communication Union (3.4) to avoid

callers noticing the round-trip time and delay.

The thesis also showed that users were reluctant to share their location, raising interesting

questions regarding privacy concerns whilst connecting phone calls in a web browser.

This report showed users are satisfied with the result and highlighted some of the benefits

using WebRTC technology and HTML5 would provide. It also explained the benefits of

using WebRTC technology when collecting call information.

7.4 Future work

As the WebRTC specification stabilizes and is being implemented on a large scale, there

will be an increasing amount of tools developed. There is still a long way to go at this

point until WebRTC will be available on all major browsers and platforms. Until then,

implementing the functionality described by this report, one needs to provide backward

compatibility with the PSTN.

Future work includes implementing a fully featured native browser similar to the “Outline

of enhanced protoype with dial pad” (figure 6.4) to further enhance the functionality of

Chapter 7. Conclusions and future work 47

the dialer implemented. To connect a phone call for users with insufficient bandwidth,

the web application also need to implement a bandwidth tester described in 6.5 and

provide a fallback to the PSTN.

The user experience in this thesis was quite limited, there is more work and evaluations

that can be performed in that area. The questions identified and evaluated in this thesis

was only to find out if users would use a system like this.

The focus so far, when developing the APIs and standards, seem to have been on desk-

top browsers, as seen with the speaker issues described earlier (chapter 4.4), as such I

would expect work will be done stabilizing and adjusting mobile browsers will soon be

forthcoming. After all, the WebRTC functionality is still not in the stable versions in

any of the leading mobile browsers, only in beta and bleeding edge releases.

I expect most software interacting with another peer on the Internet, will be utilizing

WebRTC technology in some way in the future. As of now, most of the use cases seem

to be through video and voice chat, with the ability to chat, share your screen and send

files. WebRTC offers true interoperability between devices so that a range of devices and

real-time data, audio and video will become the natural state of Internet applications.

This is because during an interview, Daniel Enstrom, the director for Ericsson Research

Multimedia Technologies, said that they believe by the end of 2013, there will be one

billion WebRTC-enabled devices in the world. This is accomplished by the automatic

release model that browser vendors are using, where users get access to WebRTC as

soon as the vendors are done implementing it. Ericsson is the vendor of the worlds first

WebRTC web browser for mobile devices [58].

Appendix A

Appendix

Figure A.1: Cellular network coverage on experiment setup

48

Bibliography

[1] Inc Harald Alvestrand Google. Google release of webrtc source code from harald

alvestrand on 2011-05-31, August 2013. URL http://lists.w3.org/Archives/

Public/public-webrtc/2011May/0022.html.

[2] Chief Technical Officer at Freespee AB Tobias Lindgren. Personal Communication,

August 2013. URL http://www.freespee.com.

[3] Inc Wikimedia Foundation. Webrtc - wikipedia, the free encyclopedia, August 2013.

URL http://en.wikipedia.org/wiki/WebRTC#Support.

[4] Stefan Ålund Ericsson Labs. Ericsson labs | bowser – the world’s first webrtc-

enabled mobile browser, August 2013. URL https://labs.ericsson.com/blog/

bowser-the-world-s-first-webrtc-enabled-mobile-browser.

[5] Tomas Mecklin Nicklas Sandgren and Ericsson Research Labs

Jouni Mäenpää. Webrtc interworking with traditional telephony ser-

vices, September 2013. URL http://labs.ericsson.com/blog/

webrtc-interworking-with-traditional-telephony-services.

[6] Doubango Telecom. click-to-call, receive calls on your sip softphone, mobile or fixed

line from your website visitors, August 2013. URL http://click2dial.org/.

[7] D.G. Tucker. Beginnings of the telephone service. Electrical Engineers, Proceedings

of the Institution of, 123(6):561–568, 1976.

[8] Jeff Hewett Lee Dryburgh. Signaling System No. 7 (SS7/C7): Protocol, Architec-

ture, and Services. Cisco Press, 2004.

[9] Inc Wikimedia Foundation. Quality of service - wikipedia, the free encyclopedia,

October 2013. URL http://en.wikipedia.org/wiki/Quality_of_service.

49

References 50

[10] Tim Berners-Lee. Tim berners-lee: Worldwideweb, the first web client, August 2013.

URL http://www.w3.org/People/Berners-Lee/WorldWideWeb.html.

[11] M. A. Cusumano and D. B. Yoffie. Competing on Internet time : lessons from

Netscape and its battle with Microsoft. London: Touchstone, 2000.

[12] Inc Wikimedia Foundation. United states v. microsoft corporation - wikipedia, the

free encyclopedia, August 2013. URL http://en.wikipedia.org/wiki/United_

States_v._Microsoft_Corporation.

[13] W3Schools. Browser statistics, June 2013. URL http://www.w3schools.com/

browsers/browsers_stats.asp.

[14] Microsoft Corporation. Msdn blogs, October 2006.

URL http://blogs.msdn.com/b/ie/archive/2006/10/18/

internet-explorer-7-for-windows-xp-available-now.aspx.

[15] Mozilla. Mozilla — history of the mozilla project — mozilla.org, August 2013. URL

http://www.mozilla.org/en-US/about/history/.

[16] Sundar Pichai Google Inc. Official blog: A fresh take on the browser, August 2013.

URL http://googleblog.blogspot.se/2008/09/fresh-take-on-browser.html.

[17] Program Manager Anthony Laforge. Release early, release often, July 2010. URL

http://blog.chromium.org/2010/07/release-early-release-often.html.

[18] Tim Berners-Lee. The original proposal of the www, htmlized, August 2013. URL

http://www.w3.org/History/1989/proposal.html.

[19] W3C HTML working group. XhtmlTM 1.0: The extensible hypertext markup lan-

guage, August 2013. URL http://www.w3.org/TR/2000/REC-xhtml1-20000126/.

[20] WHATWG community. Faq - whatwg wiki, June 2013. URL http://wiki.whatwg.

org/wiki/FAQ#The_WHATWG.

[21] W3 Consortium. Frequently asked questions (faq) about the future of xhtml, June

2009. URL http://www.w3.org/2009/06/xhtml-faq.html.

[22] Mark Pilgrim. HTML5: Up and Running. O´Reilly Media, 2010.

[23] HTML5 Rocks by Google. Why html5 rocks - html5 rocks, June 2013. URL http:

//www.html5rocks.com/en/why.

References 51

[24] W3 Consortium. Html5 definition complete, w3c moves to interoperability testing

and performance, December 2012. URL http://www.w3.org/2012/12/html5-cr.

[25] Harald Alvestrand. Google release of webrtc source code, June 2011. URL http:

//lists.w3.org/Archives/Public/public-webrtc/2011May/0022.html.

[26] Inc. E. Rescorla, RTFM. Security considerations for webrtc, August 2013. URL

http://tools.ietf.org/html/draft-ietf-rtcweb-security-05.

[27] Serge Lachapelle. Firefox and chrome interop achieved., February 2013. URL http:

//www.webrtc.org/blog/firefoxandchromeinteropachieved.

[28] J. ; Singh K. Johnston, A. ; Yoakum. Taking on webrtc in an enterprise. Internet

Computing, IEEE, 51(4):48–54, 2013.

[29] V. Singh, K. ; Krishnaswamy. A case for sip in javascript. Internet Computing,

IEEE, 51(4):28–33, 2013.

[30] Kaazing Corporation. Html5 web sockets: A quantum leap in scalability for the

web, September 2013. URL http://www.websocket.org/quantum.html.

[31] Inc A. Melnikov Isode Ltd. I. Fette, Google. The websocket protocol, August 2013.

URL http://tools.ietf.org/html/rfc6455.

[32] P. Arden G. Hunt. Qos requirements for a voice-over-ip pstn. BT Technology

Journal, 23(2):37–47, 2005.

[33] Morris Edwards. Ip telephony ready to explode into corporate world. (industry

trend or event). Communications News, 38(5):96–97, 2001.

[34] Dr. Deepti Mehrotra Nidhi Goel. Emerging new trends in transmission of real time

application(voip) to ngn by rtp. International Journal of Advanced Research in

Computer Science and Software Engineering, 3(5):226–231, 2013.

[35] J. Rosenberg et al. Sip: Session initiation protocol. ietf rfc 3261. June 2002.

[36] S. Donovan R. Sparks C. Cunningham dynamicsoft K. Summers Sonus A. Johnston,

MCI. Session initiation protocol (sip) basic call flow examples, September 2013. URL

http://tools.ietf.org/html/rfc3665.

[37] Junction Networks. Sip proxy server | onsip, August 2013. URL http://www.onsip.

com/about-voip/sip/sip-proxy-server.

References 52

[38] M. Holdrege P. Srisuresh, M. Holdrege. Ip network address translator (nat) ter-

minology and considerations, August 2013. URL http://tools.ietf.org/html/

rfc2663.

[39] S. Loreto and Simon Pietro Romano. Real-time communications in the web: Issues,

achievements, and ongoing standardization efforts. Internet Computing, IEEE, 16

(5):68–73, 2012.

[40] Versatica V. Pascual Acme Packet I. Baz Castillo, J. Millan Villegas. The websocket

protocol as a transport for the session initiation protocol (sip), June 2013. URL

http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-09.

[41] King Mongkut”s Univ. of Technol. North Bangkok Bangkok Thailand ; Wutiwi-

watchai C. ; Preechayasomboon-A. ; Sukparungsee S. Daengsi, T. ; Fac. of Inf. Tech-

nol. A study of voip quality evaluation: User perception of voice quality from g.729,

g.711 and g.722. Consumer Communications and Networking Conference (CCNC),

2012 IEEE, pages 342–345, 2012.

[42] VOIP-Info.org LLC. Itu g.711 - voip-info.org, August 2013. URL http://www.

voip-info.org/wiki/view/ITU+G.711.

[43] VOIP-Info.org LLC. Itu g.729 - voip-info.org, August 2013. URL http://www.

voip-info.org/wiki/view/ITU+G.729.

[44] ISO: International Organization for Standardization. Ergonomics of human-system

interaction – part 210: Human-centred design for interactive systems. ISO: Inter-

national Organization for Standardization, 1, 2010.

[45] J. Nielsen and R Molich. Heuristic evaluation of user interfaces, proc. ACM CHI’90

Conf. (Seattle, WA, 1–5 April), 1990.

[46] Roto V. Hassenzahl M. Vermeeren A. Kort J Law, E. Understanding, scoping and

defining user experience: A survey approach. In Proceedings of Human Factors in

Computing Systems conference, CHI’09. 4–9 April 2009, Boston, MA, USA (2009),

2009.

[47] STANDS4 LLC. Abbreviations.com, July 2013. URL http://www.abbreviations.

com/.

References 53

[48] Ookla. Speedtest.net by ookla, September 2013. URL http://www.speedtest.

net/.

[49] VOIP-Info.org LLC. Qos - voip-info.org, September 2013. URL http://www.

voip-info.org/wiki/view/QoS.

[50] Inc Digium. [asterisk-21930] webrtc over wss is not working. - digium/as-

terisk jira, August 2013. URL https://issues.asterisk.org/jira/browse/

ASTERISK-21930.

[51] Versatica. Jssip - the javascript sip library, June 2013. URL http://jssip.net/.

[52] Doubango Telecom. sipml5 - the world’s first open source html5 sip client, June

2013. URL http://sipml5.org/.

[53] Inc Digium. Asterisk webrtc support - asterisk project - asterisk project wiki, August

2013. URL https://wiki.asterisk.org/wiki/display/AST/Asterisk+WebRTC+

Support.

[54] Olle E. Johansson. Sip over websocket support integrated into kamailio, July 2012.

URL http://www.kamailio.org/w/2012/07/websockets/.

[55] [chrome] revision 207876, August 2013. URL https://src.chromium.org/viewvc/

chrome?revision=207876&view=revision.

[56] Mozilla Developer Network. window.navigator.useragent, May 2013. URL https:

//developer.mozilla.org/en-US/docs/Web/API/window.navigator.

[57] J. Gettys Compaq/W3C J. Mogul Compaq H. Frystyk W3C/MIT L. Masinter Xerox

P. Leach Microsoft T. Berners-Lee W3C/MIT R. Fielding, UC Irvine. Hypertext

transfer protocol – http/1.1, June 1999. URL https://tools.ietf.org/html/

rfc2616.

[58] Director for Ericsson Research Multimedia Technologies Daniel Enstrom. Personal

Communication, August 2013.