Application Layer Handover of VoIP Sessions in IMS Environments1

8/14/2019 Application Layer Handover of VoIP Sessions in IMS Environments1

1/97

Application Layer Handover ofVoIP Sessions in IMS

Environments

by

Tudor Golubenco

Berlin, 07.08.2006

Polytechnic University of BucharestComputer Science and Engineering Faculty

Professor: Prof. Dr. Valentin CristeaSupervisor: Prof. Dr. Thomas Magedanz (FOKUS Fraunhofer Institut)Co-Supervisor: Dr. John Williams Floroiu (FOKUS Fraunhofer Institut)


2/97

Abstract (Romana)

Acest document descrie arhitectura unui sistem care permite migrarea uti-lizatorilor VoIP ntre retele IP, permitand aleagerea celei mai convenabileinterfete si schimbarea acesteia conform preferintelor utilizatorilor si ale op-eratorului, fara a fi necesara ntreruperea convorbirilor. Documentul ofera

o descriere a conceptelor si posibilelor arhitecturi pentru realizarea migrariintre retele (handover) si se concentreaza asupra unei solutii de nivel aplicatiece foloseste Session Inititation Protocol (SIP) n retele de tipul IP Multime-dia Subsystem (IMS).

Sunt acoperite cele patru tipuri de migrare a convorbirilor: hard han-dover, soft handover, handover pentru continuitatea serviciilor si handoverpentru optimizarea utilizarii resurselor. De asemenea, este prezentata im-plementarea unei aplicatii ce permite monitorizarea interfet elor de retea,auto-configurarea lor si informarea applicatiilor care au nevoie de cunostintedespre interfetele de retea disponibile. Arhitectura librariei open-sourceOPAL si a aplicatiei client Ekiga precum si modificarea acestora pentru

demonstrarea conceptelor de handover, sunt detaliate. Sistemul propus esteindependent de tehnologiile de retea folosite, iar testarea s-a facut n conditiiapropiate de cele reale folosind echipamente mobile implementand standard-ele 802.11 si Bluetooth. Rezultatul proiectului este un sistem complet func-tional, bazat n totalitate pe standarde publice, n care terminalele alegcea mai buna retea pe baza preferintelor utilizatorilor, si auto-configureazainterfetele si comuta automat convorbirile active.

Aceasta lucrare reprezinta proiectul de absolvire a Facultatii de Au-tomatica si Calculatoare, din cadrul Universitatii Politehnice Bucuresti.Proiectul a fost realizat n cadrul centrului de competenta Next Genera-tion Network Infrastructures (NGNI) din Institutul Fraunhofer FOKUS din

Berlin.


3/97

Abstract (English)

This paper provides the description of a VoIP solution providing varioustypes of handover (handoff) techniques, allowing mobile terminals to se-lect and use the best network available, according to users and operatorspreferences, and change it when necessary, without call interruptions. The

document describes the main handover concepts and architectures, and fo-cuses on an application layer solution using Session Initiation Protocol (SIP)in IP Multimedia Subsystem (IMS) environments.

The main types of handover are covered: hard handover, soft han-dover, handover for service continuity and policy driven handover. Thedevelopment of a software application responsible for monitoring the net-work devices, for auto-configuring the network interfaces and for informingthe network aware applications is presented.The architecture of the OPALopen-source library and of the Ekiga VoIP client application along withthe enhancements added in order to prove the handover concepts, are alsodescribed.

This project resulted in an open-standard and fully functional VoIP sys-tem, in which the mobile terminals are able to select the best network,auto-configure their network interfaces and switch the active real-time mediasessions without discontinuities. The solution is independent of the networktechnologies used and it was tested with mobile equipments conformant withthe 802.11 and Bluetooth standards.

This work represents the graduating thesis for the Computer Scienceand Engineering Faculty from the Polytechnic University of Bucharest andit is accomplished as part of a research project at the Next Generation Net-work Infrastructures (NGNI) competence center, part of FOKUS FraunhoferInstitute, in Berlin.


4/97

Contents

1 Introduction 4

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Project requirements and goals . . . . . . . . . . . . . . . . . 5

1.3 Document overview. . . . . . . . . . . . . . . . . . . . . . . . 6

2 State of the Art 8

2.1 Multimedia sessions over the Internet Protocol . . . . . . . . 82.1.1 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Session Initiation Protocol . . . . . . . . . . . . . . . . . . . . 10

2.2.1 Message Fromat . . . . . . . . . . . . . . . . . . . . . 112.2.2 SIP Requests . . . . . . . . . . . . . . . . . . . . . . . 122.2.3 SIP Responses . . . . . . . . . . . . . . . . . . . . . . 132.2.4 Sample session . . . . . . . . . . . . . . . . . . . . . . 15

2.2.4.1 Registrations . . . . . . . . . . . . . . . . . . 152.2.4.2 Invitations . . . . . . . . . . . . . . . . . . . 172.2.4.3 Routing the requests. . . . . . . . . . . . . . 182.2.4.4 Routing the responses . . . . . . . . . . . . . 192.2.4.5 Acknowledgments . . . . . . . . . . . . . . . 202.2.4.6 Ending the session . . . . . . . . . . . . . . . 21

2.3 Session Description Protocol. . . . . . . . . . . . . . . . . . . 21

2.4 IP Multimedia Subsystem . . . . . . . . . . . . . . . . . . . . 232.4.1 Next Generation Network Architecture. . . . . . . . . 232.4.2 Standards . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4.2.1 Relationship with IETF . . . . . . . . . . . . 242.4.3 Architecture . . . . . . . . . . . . . . . . . . . . . . . 25

2.5 Available software technology . . . . . . . . . . . . . . . . . . 272.5.1 VoIP libraries . . . . . . . . . . . . . . . . . . . . . . . 27

2.5.1.1 VOCAL. . . . . . . . . . . . . . . . . . . . . 272.5.1.2 SipX family. . . . . . . . . . . . . . . . . . . 28

1


5/97

Contents Contents

2.5.1.3 Sofia-SIP Library . . . . . . . . . . . . . . . 28

2.5.1.4 OPAL . . . . . . . . . . . . . . . . . . . . . . 292.5.1.5 GNU oSIP and eXoSIP . . . . . . . . . . . . 292.5.1.6 DisSIPate2 . . . . . . . . . . . . . . . . . . . 292.5.1.7 Minisip libraries . . . . . . . . . . . . . . . . 302.5.1.8 Libraries Summary . . . . . . . . . . . . . . 30

2.5.2 SIP softphones . . . . . . . . . . . . . . . . . . . . . . 312.5.2.1 SIPSet . . . . . . . . . . . . . . . . . . . . . 312.5.2.2 sipXphone . . . . . . . . . . . . . . . . . . . 322.5.2.3 SSIP-GST . . . . . . . . . . . . . . . . . . . 322.5.2.4 Linphone . . . . . . . . . . . . . . . . . . . . 332.5.2.5 Ekiga . . . . . . . . . . . . . . . . . . . . . . 33

2.5.2.6 KPhone . . . . . . . . . . . . . . . . . . . . . 332.5.2.7 Minisip . . . . . . . . . . . . . . . . . . . . . 33

2.5.3 SIP softphones summary . . . . . . . . . . . . . . . . 332.5.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . 34

3 Handover Concepts 36

3.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

3.2 Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3 Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383.3.1 Enforced Service Continuity, soft handover,

intra-operator. . . . . . . . . . . . . . . . . . . . . . . 38

3.3.2 Enforced Service Continuity, soft handover,inter-operator . . . . . . . . . . . . . . . . . . . . . . . 38

3.3.3 Enforced Service Continuity, hard handover . . . . . . 393.3.4 Service optimization, intra-technology,

terminal triggered . . . . . . . . . . . . . . . . . . . . 393.3.5 Service optimization, inter-technology,

operator triggered . . . . . . . . . . . . . . . . . . . . 40

3.4 Current standardization efforts . . . . . . . . . . . . . . . . . 403.4.1 IEEE 802.21 Media Independence . . . . . . . . . . . 403.4.2 3GPP Voice Call Continuity. . . . . . . . . . . . . . . 403.4.3 Generic Access Network . . . . . . . . . . . . . . . . . 41

4 Application Layer Signaling for Handover 42

4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Enhanced registrations and theHandoverevent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3 Refreshing the network context . . . . . . . . . . . . . . . . . 47

4.4 The handover procedure . . . . . . . . . . . . . . . . . . . . . 47

2


6/97

Contents Contents

5 Client Architecture 50

5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

5.2 Software architecture . . . . . . . . . . . . . . . . . . . . . . . 51

5.3 The LinkMonitor and the IFfind modules . . . . . . . . . . . 53

5.4 Network Manager. . . . . . . . . . . . . . . . . . . . . . . . . 545.4.1 D-Bus Service. . . . . . . . . . . . . . . . . . . . . . . 545.4.2 Configuration File . . . . . . . . . . . . . . . . . . . . 555.4.3 Configuring network interfaces . . . . . . . . . . . . . 56

6 Programming with OPAL 57

6.1 Short Chronology. . . . . . . . . . . . . . . . . . . . . . . . . 57

6.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.3 Signaling plane . . . . . . . . . . . . . . . . . . . . . . . . . . 60

6.3.1 The SIP endpoint . . . . . . . . . . . . . . . . . . . . 616.3.2 SIP connection . . . . . . . . . . . . . . . . . . . . . . 626.3.3 SIP transactions . . . . . . . . . . . . . . . . . . . . . 63

6.4 Media plane . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

7 Handover implementation 67

7.1 Ekiga overview . . . . . . . . . . . . . . . . . . . . . . . . . . 67

7.2 Network device manager . . . . . . . . . . . . . . . . . . . . . 687.2.1 Devices . . . . . . . . . . . . . . . . . . . . . . . . . . 69

7.2.2 Interfaces window . . . . . . . . . . . . . . . . . . . . 71

7.3 SIP extensions to OPAL . . . . . . . . . . . . . . . . . . . . . 717.3.1 Registered profiles . . . . . . . . . . . . . . . . . . . . 717.3.2 INVITE with Replaces header (RFC 3891) . . . . . . 727.3.3 Handover event package . . . . . . . . . . . . . . . . . 727.3.4 Bandwidth control with SDP . . . . . . . . . . . . . . 73

7.4 Media handover support . . . . . . . . . . . . . . . . . . . . . 737.4.1 Hard handover . . . . . . . . . . . . . . . . . . . . . . 737.4.2 Fast hard handover. . . . . . . . . . . . . . . . . . . . 757.4.3 Soft handover . . . . . . . . . . . . . . . . . . . . . . . 76

8 Testing, Conclusions and Further Work 78

8.1 The testbed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

8.2 Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

8.3 Conclusions and further work . . . . . . . . . . . . . . . . . . 80

A Sample Configuration File for the Network Manager 82

B Shell script for creating network testbeds with QEmu 85

C CD-ROM content 90

3


7/97

Chapter1Introduction

The concept of sending voice over the Internet Protocol it is not very new.The history starts more than fifteen years ago, in 1993, when Lior Haramatyand Alon Cohen founded VocalTec Communications. Two years later theyreleased what is known as worlds first software Internet Phone. The reducedspread of Internet (only 20% of US homes had Internet access at that time,and only dial-up), the lack of full-duplex sound cards and the slow CPUs ofthat time made it hard for VoIP technologies to grow. Om Malik and TomKeating, two senior VoIP journalists, have webblogs ([33] and [34]) wherethey give more detailed information about those early VoIP times.

Ten years later, the environment is much more appropriate for VoIPdevelopment: Internet broadband access is rather common, the backbonedelays are considerably smaller (according to [33], a connection from New-York to Hong-Kong had a 500ms round-trip delay in 1996 and only 150msdelay in 2005), WiFi wireless networks are wide spreaded, outdoor wire-less standards are ready and VoIP protocols are mature. The year 2005 isconsidered the take-off year for the VoIP industry.

Nevertheless, VoIP still has a long way to go. By its nature, the Internetis best-effort; a maximum delay between the caller and the callee cannot beguaranteed, and variation of the delay creates a jittereffect [43], which canmake the communication almost impossible. The reduced number of end-to-end QoS mechanisms available and the reduced scale of their deploymentdoesnt allow the delay-sensible VoIP traffic to be prioritized, and bandwidthhigh-consuming applications can easily make VoIP connections unusable.

The 3GPP [28] group aims to give solutions to these problems by in-troducing a set of technical specifications defining theNext Generation Net-workingarchitecture namedIP Multimedia Subsystem(IMS). The IMS takescare of synchronizing session establishment with the QoS provisioning, giv-ing the operators the ability to prioritize delay and bandwidth sensitiveservices.

4


8/97

1. Introduction

IMS goal is to provide not only new services, but all the services, current

and future, that the Internet provides. In addition, the IMS will give networkoperators and service providers the ability to control and charge for eachservice, while the users will receive the QoS guarantees they need. To achievethese goals, IMS uses open standard IP protocols, defined by the IETF[26].

1.1 Motivation

One of the essential features that users expect from the Next GenerationNetworksis the ability to freely move from one network to another withoutservice interruptions. As an example, imagine the following scenario:

You are coming back by plane from your dream vacation: right after thesmooth landing, you are opening your phone and call your best friendto tell her all about your fantastic trip. As the airport has WiMaxcoverage, you can have a quality video call and show your friend theexotic hat you bought. Because you havent talked to your friend for awhile, you dont hang-up verry soon. You get in your car and when youput the phone in its car-kit slot, the audio stream is transfered to thespeakers and the video is displayed on the cars LCD screen. As youleave the airport and the WiMax signal is becoming weaker, the videoreduces its frame rate to save bandwidth and keep the voice quality high.When the the signal is too low, your call is smoothly handovered to theUMTS interface. To save costs and to keep the good audio quality, the

video stream is turned off. However, nothing stops you from chattingwith your friend while driving, When you arrive at your home, the callis handovered again, this time to your Bluetooth home network. Thiswill probably save you costs and reduce battery consumption. And thevacation was perfect.

The above story exemplifies some use cases that the handover technolo-gies might have in IMS. In addition, conforming to the IMS goals, theseservices are available while roaming, too, so there is no need to wait to getback from your trip to use them. Other use cases are presented in a moresystematic view in Section3.3.

1.2 Project requirements and goals

The main goal of this thesis is to offer the necessary mechanisms to allowthe handover of the real-time media sessions. The following items were setas requirements for the final solution:

Openness: The importance of vendor independent inter-communicationprotocols and standards was proven to be crucial in the Internet his-tory. They bring both smaller prices for the users and more researchin the field.

5


9/97

1. Introduction

This project is fully based on open VoIP protocols and can be inte-

grated with freely available technical specifications. The testbed thatwill demonstrate the project will use and extend open-source applica-tions.

Performance: The terminal needs to adapt as fast as possible tonetwork changes, to avoid human-noticeable delays and jitter.

Network changing predictions, based on the wireless signal strength,and soft media handover mechanisms can make the handoff delay in-existent or unnoticeable. When the link loss can not be predicted, thesignaling scheme must contain a minimal number of messages beforethe establishment of the media session on its new path.

Flexibility: The system must make possible various handover sce-narios, transferring the media sessions between different network tech-nologies and between different service providers . The solution coversthe inter-operator and intra-operator handover, the intra-technologyand the inter-technology handover, the terminal initiated handoverand the network initiated handover.

Usability: An average user does not have the details about network,about the configuration of the interfaces or about the VoIP infrastruc-ture. The solution proposes applications capable of auto-configuringthe devices and capable of discovering the available networks and thenetwork elements.

Layering: Layers are a key concept in the design of network architec-tures. They can hide complexity by limiting the scope of each protocoland software application.

The solution is independent of the physical and data-link layer tech-nologies used. Vertical triggers from the low layers are used by theapplication layer to make the handover decision.

In order to accomplish these goals, a SIP based application layer solutionwas chosen. The target environments are the Next Generation Networks, like

the IMS.

1.3 Document overview

Chapter 2 is an introduction to the Voice over Internet Protocol (VoIP)technologies, to the Session Initiation Protocol (SIP) and to the IP Multi-media Subsystem (IMS) technical specifications. It also presents compar-isons between the available open-source SIP implementations stacks and theopen-source SIP based soft-phones.

6


10/97

1. Introduction

Chapter3presents the concepts related to handovering, providing sce-

narios for the main handover classes. The main standardization efforts aresummarized.

Chapter4describes the proposed signaling sequence for handover. Thecoverage of the scenarios and handoff types is discussed, along with theefficiency issues.

Chapter5describes the overall software architecture of the client part ofthe project and will focus on the Network Managermodule which is respon-sible for monitoring the network devices from the system, auto-configurethem and give the information about them to the network-aware applica-tions.

Chapter6 is an overview of the open-source libraries Portable Windows

Library (PwLib) and Open Phone Abstraction Library (OPAL). PwLib pro-vides a C++ OS abstraction layer for portability. OPAL provides SIP andH.323 stacks, codecs and implementations of other complementary proto-cols.

Chapter 7 presents the enhancements brought to OPAL and Ekiga, aVoIP GUI application based on OPAL, in order to make the handover sce-narios possible.

Chapter 8 presents the IMS testbed created for this project and usedfor testing the handover scenarios, the tests results, the authors conclusionsafter the project and the identified further work.

7


11/97

Chapter2State of the Art

This chapter presents the VoIP technologies currently available, startingwith the main VoIP protocols and specifications and ending with the open-source VoIP tools for real-time audio and video sessions. It focuses on theSIP protocol and on the IMS technical specifications.

2.1 Multimedia sessions over the Internet Protocol

The Voice over the Internet Protocol (VoIP) [12] term is used to define

the set of technologies and protocols which creates the framework for thedelivery of voice based audio data from a sender party to a least one receiverparty using the IP [17]protocol. In time, the term was extended to coverother real-time types for the transfered data, including video, graphics andtext.

VoIP technologies offer more flexibility then the classic Public SwitchedTelephone Network (PSTN), which is standardized by the ITU-T[30]. PSTNworks using thecircuit-switchedparadigm: when user A calls user B, a con-nection is made between the two parties and kept alive until A or B hangsup. Because you need to connect A with B and B with A, these connec-tions form a circuit. A circuit has allocated a fixed rate of 64 kilobits in

each direction. If A and B do not talk and listen continuously, it is obvi-ous that a lot of this bandwidth is wasted. In contrast, the packet-switchednetworks used by the VoIP technologies only transmit packets that containuseful data, and these packets are routed along the least congested lines. Inaddition, more bandwidth can be saved by compressing the packets.

The circuit-switched technologies are generally associated with the nameof Second Generation (2G) networks, while the packet-switched technologiesare used in Third Generation (3G) networks. While the 2G terminals canact as modems to transmit data over the Internet, the 3G terminals nativelysend data packets, offering much higher rates for data transmissions.

8


12/97

2. State of the Art

2.1.1 Protocols

The VoIP networks have two main planes [1]:

The signaling plane includes the protocols used to establish a pathbetween the caller and the callee. A signaling protocol will take careof call initiation and will be used by the terminals to agree on theprotocols that will be used in the media plane.

Themedia plane includes the data transmitted over the path betweenthe terminals. The encoded voice and video belong to the media plane.Media plane protocols define how the audio and video data is encodedand how the encoded data is sent over the path established by a sig-

naling protocol.

In early circuit-switched networks, the signaling and media planes fol-lowed the same path. The introduction of the services based on IntelligentNetworks (IN) made it necessary to allow the media and signaling plane totake different paths. The current trend is to separate as much as possiblethe two planes, and, in IMS networks [1], the only nodes that need to handleboth are the terminals.

The following protocols are considered to be the main protocols currentlyused in VoIP networks:

Session Initiation Protocol (SIP)[2] is a signaling protocol devel-oped by IETF [26] and standardized by RFC 3261. It shares manydesign principles with HTTP and SMTP, the two most successful ap-plication layer protocols. It is human readable, request-response struc-tured and uses many status codes familiar from HTTP. It is consideredsimpler then its main rival, H.323, and it completely separates the sig-naling and media planes. It acts as a carrier for the Session DescriptionProtocol (SDP) [5] that describes the media content of the session.

H.323 is a protocol developed by ITU-T [30] but natively supportsIP technologies and the media doesnt need to take the same path as

signaling does. It uses a binary representation for its messages basedon ASN.1. Like SIP, it can run over both TCP and UDP, but whilemost SIP implementations use UDP, the H.323 implementations seemto prefer TCP. An in-depth comparison between H.323 and SIP canbe found in [42].

Inter-Asterisk eXchange protocol (IAX) [60] is an all in oneprotocol for handling multimedia in Internet Protocol (IP) networks.It combines both control and media services in the same protocol.IAXs compact encoding decreases bandwidth usage and since IAX

9


13/97

2. State of the Art

uses a single, static, UDP port, it facilitates native support for Network

Address Translation (NAT) transparency.

IAX now most commonly refers to IAX2, the second version of theprotocol, as the first version was deprecated.

Skypeis a proprietary protocol used in the well-known Skype applica-tion. The application is closed-source, so there is not much informationavailable about the protocol. It is, however, known that it uses peer-to-peer strategies to combat NAT problems and to increase the scalabilityof the network. The application automatically selects the users withfast-CPUs and direct broadband to Internet to become super-nodes.Then, other skype clients can connect to this super-nodes, and thus,

consume some of their bandwidth.

Jingle is an extension of Jabber/XMMP protocol, to allow peer-to-peer signaling, and multimedia interactions. It was designed by Googleand Jabber Software Foundation.

Real-Time Transport Protocol (RTP) was developed by the Audio-Video Transport Working group of the IETF and published in 1996as RFC 3550 [8]. RTP does not have a standard associated port forcommunications. It uses an even UDP port for data transmissions andthe next higher odd port for the RTP Control Protocol (RTCP) com-munications. The fact that RTP uses a dynamic port range makes itdifficult to traverse NAT firewalls. Therefore, it is usually used in con-

junction with STUN[10]. It can be used over TCP, but the multimediaapplications are generally more sensitive to delay and less sensitive topacket loss, so UDP is a better option.

RTP provides payload-type identification, sequence numbers, timestamping and delivery monitoring. It doesnt ensure timely deliveryand doesnt provide any QoS guarantees. These have to be providedby external mechanisms.

Secure Real-Time Transport Protocol (SRTP) defines a pro-file of RTP intended to provide encryption, message authenticationand replay protection. It was published by IETF in RFC 3711 [11].The encryption transformations specified in [11] are based on AES.Message authentication and integrity is done using HMAC-SHA1 andkey-derivation transformations are specified.

2.2 Session Initiation Protocol

The Session Initiation Protocol[2] is a protocol developed by IETF MMU-SIC Working Group[45] and a proposed standard for initiating, modifying,

10


14/97

2. State of the Art

and terminating an interactive user session. SIP is primarily used in setting

up and tearing down voice or video calls, but it can be used in any appli-cation where session initiation is a requirement.The scope of SIP is to makecommunication possible, while the communication itself must be achievedby other means, typically RTP.

SIP has been designed in conformance with the Internet model as anend-to-end oriented protocol. It has protocol design similar with HTTP:It is human readable and request-response structured. It is considered astatelessprotocol which makes it highly distributed and scalable. From thesignaling perspective, the state of each end device is changed atomicallywith the arrival of one SIP message. Because of this property SIP is usu-ally transmitted over UDP, making SIP a protocol based on retransmission

timers. SIP shares many HTTP status codes, such as the familiar 404 notfound.

SIP transparently supports name mapping and redirection services, pro-viding personal mobility: the users can maintain a single externally visibleidentifier regardless of their network location. SIP can also invite partici-pants to already existing sessions, such as multicast conferences. SIP makesuse of elements calledproxy serversto route the requests to the users currentlocation, authenticate and authorize users for services, implement providercall-routing policies, and provide features to users.

Each request-response transaction consists of a request that invokes aparticular method, or function of the server and at least one response. Re-

quests are sent from an User Agent Client (UAC) to an User Agent Server(UAS). The SIP responses, which generally indicate whether a request suc-ceeded or failed, and in the latter case, why it failed, are sent from the UASto the UAC.

SIP entities are identified using Uniform Resource Identifiers (URI)starting with the string sip: and consisting of a username and anInternet location delimited by the @ character.

For example, sip:[email protected]:5060specifies tudor asusername, fokus.fraunhofer.de as domain name and 5060 the UDP portwhere SIP request must be sent.

2.2.1 Message Fromat

Two sample SIP messages are presented in Figure 2.1. 2.1 a) presents atypical request, while2.1 b) presents a possible response to that request. ASIP message consists of three parts: the start line, the header fields and thebody. A blank line separates the header fields from the body section. TheSIP messages are text-encoded and all lines are terminated by the sequence.

The start lineof a SIP message determinates wether the message is arequest or a reply. If it is a requests, the the start line contains the method

11


15/97

2. State of the Art

Figure 2.1: Examples of SIP messages: a) request b) response

name followed by the protocol name and version. If it is a response, thefirst line of the message starts with the protocol name and version, followedby the response status code. The main method names and response statuscodes are presented in Sections2.2.2,respectively2.2.3.

After the start line, both requests and responses contain a set ofheaderfields. A header field consists of a header fields name, a colon, and a headerfields value.

The message bodyis separated from the header fields by an empty line.The type of the body is indicated by the MIME value of the Content-Typeheader, while its length is specified by theContent-Lengthheader. Messagebodies are optional, and, if they are missing, the Content-Lengthwill havea zero value.

2.2.2 SIP Requests

The core SIP RFC[2]uses six types of requests:

REGISTER - Registers a users current location. The registration mes-sage associate the users URI with the address of the machine into

which he is currently logged.

INVITE - Indicates a user or service is being invited to participate ina call session. This request may carry session description information.

ACK - Confirms that the client has received a final response to anINVITE request. It is used to create a three-way-handshake sessionestablishment.

BYE - Terminates a call between users. It can be sent by either thecaller or the callee.

12


16/97

2. State of the Art

CANCEL - Cancels pending request or searches. It is used if a client

sends an INVITEand then changes its decision to call the recipient. Itdoesnt terminate a call that has already been accepted.

OPTIONS - Queries the capabilities of servers. This allows a clientto discover information about the supported methods, content types,extensions, codecs, etc. without ringing the other party.

Other methods where added to SIP by various IETF documents, in orderto increase its functionality. The IETF document that summaries the SIPrelated RFCs is currently an Internet draft [13], and can be used as guidefor existing SIP extensions. Some of the relevant SIP extension methods

are:

REFER - The UAC is asking the UAS to send a SIP request. It is aform of SIP remote control, and is the primary tool used for calltransfer in SIP. Defined in RFC 3515 [22].

SUBSCRIBE - Subscribes for an event of notificationfrom the Notifier.By subscribing, the UAC informs the UAS that it is interested in theeventspecified in the request. Defined in RFC 3265 [4].

NOTIFY - Notify the subscriber of a new event. It is sent to all sub-scribers when the state of the event has changed. Defined in RFC 3265

[4]. PUBLISH - It is used as a mechanism for pushing an event into the

system, that will generate notifications to subscribers. Defined in RFC3903[23].

UPDATE - This method is meant as a mean for updating session infor-mation prior to the completion of the initial INVITE transaction. Itwas developed primarily to support capabilities checks prior to sessionestablishment.

PING- The PING method is intended to confirm that the UAS is alive

and verify that a signaling path is still valid. It is currently defined byan Internet draft [24]at its third version.

The following subsection will present the responses that can be generatedby the UAS when one of these requests is received.

2.2.3 SIP Responses

The SIP responses start with a status code, which indicates if the requestwas successful or not, and a short description of the code. SIP status codeshave similar semantics with the HTTP status codes:

13


17/97

2. State of the Art

1xx: Informational Responses. Examples:

100 Trying sent by proxies to indicate that the requests wasforwarded;

180 Ringing sent by the UAS to indicate that the phone hasstarted ringing.

183 Session Progressis used to convey information about theprogress of the call that is not otherwise classified.

2xx: Successful Responsesindicate that the request was accepted andexecuted successfully. Examples:

200 OK is the general purpose o.k. response. 202 Acceptedused by the UAS upon receiving of aREFERrequest

to announce that the requested action is to be taken.

3xx:Redirection Responses give information about the users new lo-cation, or about alternative services that might be able to satisfy thecall. Examples:

301 Moved Permanently is sent when the user has changed itslocation and he/she will not be available at this UAS anymore.The new location will be present in the Contact header of theresponse.

302 Moved Temporarily is sent when the user has changed itslocation for a limited amount of time. The new location will bepresent in the Contact header of the response, and the durationof the validity of the new address can be specified in an Expiresheader.

4xx: Client Failure Responses are definite failure responses from aparticular server. The client should not retry the same request withoutmodification. Examples:

400 Bad Request is sent when the request could not be under-stood due to malformed syntax.

401 Unauthorized is sent when the requests requires user au-thentication.

404 Not Foundis sent when the callee is not currently registeredat the recipient of the request.

408 Request Timeoutis sent when the server could not producea response within a suitable amount of time, for example, if itcould not determine the location of the user in time.

14


18/97

2. State of the Art

5xx: Server Failure Responsesare failure responses given when a server

itself has erred. Example:

500 Server Internal Error is sent when the server encoun-tered an unexpected condition that prevented it from fulfillingthe request. If the error is temporary, the server may include aRetry-After header field.

6xx: Global Failures Responses indicate that a server has definitiveinformation about a particular user, not just the particular instanceindicated in the request. Examples:

600 Decline is sent when the callees machine was successfullycontacted but the user explicitly rejected the call.

606 Not Acceptableis sent when the users agent was contactedsuccessfully but some aspects of the session description such asthe requested media, bandwidth, or addressing style were notacceptable.

2.2.4 Sample session

A typical SIP session is presented in Figure 2.2. This minimal example isknow as the SIP Trapezoid [2], in which Alice ([email protected]) calls Bob

([email protected]). However, SIP permits signaling chains with an arbitrarynumber of proxies and, of course, more users.

2.2.4.1 Registrations

The signaling sequence from Figure2.2starts with the registrations of Al-ices and Bobs phones to the atlanta.com and biloxi.com registrar servers.Registration creates bindings in a location service for a particular domainthat associates an address-of-record URI with one or more contact addresses.Thus, when a proxy for that domain receives a request whose Request-URImatches the address-of-record, the proxy will forward the request to thecontact addresses registered to that address-of-record.

The REGISTER (message 1 in Figure2.2) might look like this:

REGISTER sip:atlanta.com SIP/2.0

CSeq: 1 REGISTER

From: ;tag=a2afcb9b-0023

To:

Contact:

Max-Forwards: 70

Via: SIP/2.0/UDP 192.168.32.2:5060;branch=wqekla0i98a

Call-ID: [email protected]

15


19/97

2. State of the Art

Figure 2.2: Typical session setup with SIP

Max-Forwards: 70

Expires: 3600

Content-Length: 0

This message requests the atlanta.com registrar to bind the URI [email protected](contained in theToheader) to the address (contained in the Contact header).TheExpiresheader indicates how long the UA would like the binding to

be valid. The UA can later refresh the registrations, by issuing a REGISTERrequest before the expiration interval has elapsed.

Registrations are soft state and expire unless refreshed, but can also beexplicitly removed. When the UA wants to remove the binding (e.g. message3 in Figure 2.2), it will send a REGISTER request specifying an expirationinterval of 0:

Expires: 0

16


20/97

2. State of the Art

The servers response saying that the binding was created (message 2 inFigure2.2) might be:

SIP/2.0 200 OK

CSeq: 1 REGISTER

From: ;tag=a2afcb9b-0023

To: ;tag=2561b4

Contact:

Max-Forwards: 70

Via: SIP/2.0/UDP 192.168.32.2:5060;branch=wqekla0i98a

Call-ID: [email protected]: 70

Expires: 3600

Content-Length: 0

2.2.4.2 Invitations

After both user agents are registered with their registrar servers, the sessioninitiation can begin. The INVITErequest (message 4 from Figure2.2) mightlook like this:

INVITE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 192.168.32.2;branch=z9hG4bK776asdhds

Max-Forwards: 70

To: Bob

From: Alice ;tag=1928301774


CSeq: 2 INVITE

Contact:

Content-Type: application/sdp

Content-Length: 142

v=0

o=- 1154960631 1154960631 IN IP4 192.168.11.30

s=Opal SIP Session

c=IN IP4 192.168.32.2

b=AS:344

t=0 0

m=video 5000 RTP/AVP 31

a=rtpmap:31 H261/90000

17


21/97

2. State of the Art

ThisINVITEmessage carries as body the description of the media (codecs,

sampling rates, addresses and ports) that Alices phone supports. The pro-tocol that defines the format of these descriptions is, most often and in thisexample, the Session Description Protocol (SDP) [5], which is detailed inSection2.3.

2.2.4.3 Routing the requests

Since Alices phone does not know the location of Bob (i.e. IP address) orthe SIP server in the biloxi.com domain, the softphone sends the INVITE tothe SIP server that serves Alices domain, atlanta.com. The address of theatlanta.com SIP server could have been configured in Alices softphone, or it

could have been discovered by DHCP, for example. The atlanta.com proxyserver locates the SIP proxy server responsible for the biloxi.com domain,possibly by doing a DNS lookup for a SRV record. Before forwarding therequest, atlanta.com sends a 100 Trying response Alices phone. This way,the phone will know that its request was successfully received and is beingprocessed so there is no need to retransmit it. The forwarded INVITErequest from atlanta.com to biloxi.com (message 5 in image 2.2) will looksimilar with this:

INVITE sip:[email protected] SIP/2.0


Via: SIP/2.0/UDP 192.168.1.1;branch=b234ijofw8

Max-Forwards: 69

To: Bob



CSeq: 2 INVITE

Contact:

Content-Type: application/sdp

Content-Length: 142

v=0

o=- 1154960631 1154960631 IN IP4 192.168.11.30

s=Opal SIP Session

c=IN IP4 192.168.32.2

b=AS:344

t=0 0


a=rtpmap:31 H261/90000

The atlanta.com adds an additionalViaheader field value that containsits own address (assumed to be 192.168.1.1 in this example). This header will

18


22/97


23/97

2. State of the Art

Alices phone capabilities received in the body of the INVITE. This offer-

answermodel is presented in RFC 3264 [21].

SIP/2.0 180 Ringing


Via: SIP/2.0/UDP 192.168.1.1;branch=b234ijofw8

Via: SIP/2.0/UDP 192.168.5.1;branch=addsa3234ag

To: Bob ;tag=a6c85cf



CSeq: 314159 INVITE

Contact:

Content-Type: application/sdpContent-Length: 142

v=0

o=- 1154960631 1154960631 IN IP4 192.168.11.30

s=Opal SIP Session

c=IN IP4 192.168.21.28

b=AS:344

t=0 0


a=rtpmap:31 H261/90000

The 180 Ringingresponse is routed back through the two proxies in thereverse direction. Each proxy uses the Via header field to determine whereto send the response and removes its own address from the top. As a result,the responses can be returned to the caller without lookups or without statebeing maintained in the proxies. This also means that a response will alwaystraverse the same set of proxies, but in reverse order.

When Bob answers the phone, it will generate a final 200 OK responsethat will be routed identically with the provisional response. This response

will have the same headers as the 180 Ringingresponse, as it is based onthe same requests. However, because the session description was alreadysent, the response will have no body.

2.2.4.5 Acknowledgments

When Alices phone receives the 200 OK message, it will indicate to Alicethat the call has been answered and it will send an acknowledgment message,with the ACK method, to Bobs phone. This message will confirm that thefinal answered was received and completes the SIPs three way handshake.

20


24/97

2. State of the Art

TheINVITEmethod is the only one that needs this kind of acknowledgment.

This is because the length of time before Bob answers the phone can be largerthen can be predicted by any retransmission timers and Alices phone cantknow if the response was lost or Bob never answered.

In this example, the ACK is sent directly from Alices softphone to BobsSIP phone, bypassing the two proxies. This occurs because the endpointshave learned each others address from the Contactheader fields of previousmessages.

Other scenarios might need that all subsequent messages will pass througha set of particular proxies, for charging purposes as one example. This canbe accomplished by using the Record-Routeand Routeheaders. If a proxywants to receive the subsequent messages for a dialog, it will add its address

in the Record-Route header of the forwarded requests. These headers willbe copied in the responses generated by the callee. The caller receives themand, when it wants to send a new message it will copy the values from theRecord-Route headers in Route fields. The proxies will then route the re-quest based on the Route headers. Each proxy can independently decideto receive subsequent messages, and those messages will pass through allproxies that elect to receive it. This capability is frequently used for proxiesthat are providing mid-call features.

Alice and Bobs media session has now begun, and they send mediapackets using the format to which they agreed in the exchange of SDP. Ingeneral, the end-to-end media packets take a different path from the SIP

signaling messages.

2.2.4.6 Ending the session

At the end of the call, Bob hangs up first and generates a BYE message(numbered 8 in Figure2.2). This BYE is routed directly to Alices softphone,bypassing the proxies. Alice confirms the receipt of the BYE with a 200 OKresponse, which terminates the session. This time, no acknowledgment isneeded as simple retransmission timers for messages can solve the reliabilityproblems.

2.3 Session Description Protocol

TheSession Description Protocol(SDP)[5] is a text based protocol intendedfor describing multimedia sessions for the purpose of session establishmentor session modification. It is usually carried in the body of SIP messages.

A SDP session descriptor consists in a number of lines of text, eachstarting with a one letter identifier followed by an equal sign and some iden-tifier dependent fields that represent the values of the session parameters.Example:

21


25/97

2. State of the Art

v=0

o=alice 1151667314 1151667314 IN IP4 192.168.1.3s=Opal SIP Session

c=IN IP4 192.168.1.3

t=0 0

m=audio 5000 RTP/AVP 101 114

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-15

a=rtpmap:114 SPEEX/16000


a=rtpmap:31 H261/90000

The most important identifiers are:

v= Protocol version.

o= Owner/creator and session identifier. It contains the originator ofthe session (their username and the address of the users host) plus asession id and session version number.

s= Session name.

c= Connection Data. It contains the network type (IN for Internet),

the address type (IP4 for IP version 4 and IP6 for IP version 6) andthe connection address.

m=Media Announcement. A session description may contain a numberof media descriptions. Each media description starts with an m=field,and is terminated by either the next m= field or by the end of thesession description. It contains the media type (audio, video,application, data or control), the port number, the transportprotocol and the media formats (payload types). The payload typescan be defined statically or dynamically. If a payload-type is defineddynamically, an a= line must describe it.

a= Attribute. It contains the number of the payload type that mustmatch one of the fields from the corresponding m= line, the name ofthe codec used, and some of its parameters, like the sampling rate.

b= Bandwidth information. It is an optional identifier that containsthe bandwidth to be used in the session. It is formed by a modifier(CT- Conference Total orAS- Application-Specific) and the bandwidthvalue in kilobits per second.

22


26/97

2. State of the Art

2.4 IP Multimedia Subsystem

The IP Multimedia Subsystem(IMS) is aNext Generation Network (NGN)architecture standardized by 3GPP [28]. The IMS architecture was origi-nally designed to merge the Internet and the cellular worlds with the purposeof creating a platform able to enhance and diversify the process of serviceprovisioning. Subsequently, the IMS has evolved towards encompassing alarge variety of access networks including WiFi and WiMax and even achiev-ing convergence with nonIP networks like PSTN, as well as including manyother services like IPTV, gaming, etc.

2.4.1 Next Generation Network Architecture

ITU-T defines a NGN as[32]:

A Next Generation Network (NGN) is a packet-based network ableto provide services including Telecommunication Services and able tomake use of multiple broadband, QoS-enabled transport technologiesand in which service-related functions are independent from underly-ing transport-related technologies. It offers unrestricted access by usersto different service providers. It supports generalized mobility whichwill allow consistent and ubiquitous provision of services to users.

The key concepts of a NGN architecture are:

Packet-based: All information is transmitted via packets labeled ac-cording to their type (data, voice, web, etc.) and handled differentlyfor QoS and security purposes.

Decoupling of service provision from network: An NGN clearly sep-arates between the connectivity portion of the network and the ser-vices that run on top of that transport. This means that whenever aprovider wants to enable a new service, they can do so by defining itdirectly at the service layer without considering the transport layer

Support for a wide range of services, applications and mechanisms

based on service building blocks (including real time/ streaming/ non-real time services and multi-media)

Generalized mobility allowing users to roam between networks andhave continuous access to services.

Unrestricted access of users to different service providers

23


27/97

2. State of the Art

2.4.2 Standards

The 3rd Generation Partnership Project (3GPP) [28] is a collaborationagreement between ETSI (Europe), ARIB/TTC (Japan), CCSA (China),ATIS (North America) and TTA (South Korea).

The 3rd Generation Partnership Project 2 (3GPP2) is a collaborationagreement between ARIB/TTC (Japan), CCSA (China), TIA (North Amer-ica) and TTA (South Korea).

Both 3GPP and 3GPP2 have standardized their version of IMS. The twovariants are fairly similar, but, nevertheless, have a few differences[1].

3GPP and 3GPP2 documents cover not only the radio part (Air Inter-face) and Core Network, but also billing information, speech coding and

cryptographic aspects. The 3GPP standards are structured asReleases:

Release 98and earlier releases specify pre-3G GSM networks

Release 99specify the first UMTS 3G networks, incorporating a CDMAair interface

Release 4 adds features including an All IP Core Network

Release 5 introduces IMS

Release 6 integrates operation with Wireless LAN networks and addsenhancements to IMS such as Push to talk over Cellular (PoC),

Release 7and onwards are still in the early stages, and work towardsbetter integration with wired networks

2.4.2.1 Relationship with IETF

Both 3GPP IMS and 3GPP2 IMS aim to use Internet protocols, which havebeen traditionally standardized by IETF. The preferred approach is to usethe Internet standards unchanged, if feasible. However, some of the chosenprotocols were not completely suitable for the IMS environment. There wereeven cases where the IETF did not have any solution to address some of theissues that IMS was facing.

Modifying Internet protocol was not an option as this would mean loosinginteroperability with future services created for the Internet. Instead, theyestablished collaborations with the IETF to create common standards. Theterms of these collaborations are documented in RFC 3113 [14] (3GPP-IETF) and in RFC 3131[20] (3GPP2-IETF). The goal was to find solutionsthat addressed the requirements of the IMS and that, at the same time, weregeneral enough to be used in other environments.

24


28/97

2. State of the Art

2.4.3 Architecture

IMS follows an approach called functional decomposition, which is far supe-rior to the traditional vertical integration model, in which common functionsare replicated for each application. By contrast, IMS offers a layered archi-tecture consisting of an access layer, a transport layer, a control layer andan application/services layer. This brings a number of benefits:

Higher degree of interoperability is achieved using standard interfaces.

Scalability and redundancy can be easily built in.

New applications can be provided such as presence, conferencing, push-

totalk, multiparty gaming, community services, content sharing.

Functions can be shared across several applications; more complexservice logic can be easily implemented; service composition can beeasily achieved.

Authentication, authorization and security functions are integratedinto the architecture.

Flexible charging schemes based on content become feasible;

Independence from the access technology; access to services from anylocation at any time.

Figure2.3depicts thesignaling planein a typical IMS configuration thatinvolves two roaming users which are subscribed to different operators. Themain entities are the:

Home Subscriber Server(HSS) which is the central repository for user-related information, which includes location information, security in-formation (including authentication and authorization information),user profile information (including the services the user is subscribedto and preferences).

Call Session Control Functions (CSCFs) which are essentially SIPservers handling the signaling in IMS. There are three types of CSCFs,depending on their functionality:

TheP-CSCF(Proxy-CSCF) is the first point of contact betweenthe terminal and the IMS network. All request generated by theterminal towards the IMS network traverse the P-CSCF. It im-plements security functions, controls the access to local resources,initiates QoS resource reservations in the core network and gen-erates charging information.

25


29/97

2. State of the Art

Figure 2.3: IMS components typically involved in a call between two roamingusers from different operators

TheS-CSCF(Serving-CSCF) is the central point of the signalingplane. It provides session control and acts as a SIP registrar. Inaddition to this, the S-CSCF retrieves from the HSS security in-formation which it distributes to the P-CSCFs enabling the latterto authenticate the users. Finally, the S-CSCF downloads userprofiles from the HSS and routes the SIP messages through one or

more Application Servers. TheI-CSCF (Interrogating-CSCF) is a SIP proxy located at the

border of an IMS administrative domain. Its address is listed inthe DNS records of the domain. When a SIP server follows theprocedures described in RFC 3263 [16]to find the next SIP hop,it will find the address of an I-CSCF of the destination domain.Then, the I-CSCF retrieves user location information from theHSS and routes the SIP request to the appropriate S-CSCF.

Application Server (AS) implement various services. Depending on

26


30/97

2. State of the Art

the implemented service, the AS can act as a SIP proxy, as a SIP user

agent or as a SIP B2BUA (Back-to-Back User Agent concatenationof two SIP User Agents).

Media Resource Function Controller (MRFC) which has a counter-part in the media plane (Media Resource Function Processor) andprovides the home network the ability to play announcements mixmedia streams, transcode between different codecs, obtain statistics,etc.

Other entities include:

Breakout Gateway Control Function (BGCF) which is a SIP server

that includes routing functionality based on telephone numbers.

PSTN/CS Gatewayswhich provide an interface toward circuit-switchednetwork, allowing IMS terminals to to make and receive calls to andfrom PSTN or any other circuit-switched network.

The media generally takes a different path then the signaling, and itcan be exchanged end-to-end between the caller and the callee. However,a number of intermediate entities may be included along end-to-end path(RTP relays for NAT traversal, IPv4/IPv6 translation, media transoders,etc.).

2.5 Available software technology

Multiple open VoIP stacks and softphones are available at the moment ofthis writing. Online lists of VoIP implementations are maintained by KlausDarilion [50]and by the Columbia University[51].

The following subsections present a comparing view of the available open-source SIP stack libraries, respectively open-source SIP phones.

2.5.1 VoIP libraries

This section presents some of the open-source VoIP libraries that can useSIP as signaling protocol.Only the stacks that are currently considered stableand used in at least one user agent were chosen to be presented.

2.5.1.1 VOCAL

VOCAL (Vovida Open Communication Application Library) project is main-tained by the Vovida organization [52], a communication community sitefounded by Cisco which targets to help the developers to build VoIP appli-cations and services. VOCAL provides not only a VoIP library, but a SIPredirect server, a provisioning server, marshal server, etc.

27


31/97

2. State of the Art

The SIP stack is available as a C++ library, it is fully compliant with

RFC 2543, but not with RFC 3261. The VOCAL libraries also provideclasses for RTP streams. It is licensed under the VOCAL license which is aBSD like license.

The API is documented using CppDoc and UML architecture diagramsare available on the Vovida website [53]. The latest VOCAL, version 1.5.0,was released on April 1, 2003. Currently, the mailing list has a very lowtraffic.

It can be used only under Linux. The SIPSet user agent is based on thislibrary.

2.5.1.2 SipX family

SipXtackLib is a member of the SipX family of projects hosted by SIP-foundry [54]. The SipX family of projects was originally contributed byPingtel Corp. They are now open-source projects distributed under theLGPL license.

SipXtackLib is a feature rich SIP stack written in C++ and build upona small footprint HTTP stack. It claims compliance with the RFC 3261 andoffers full security support with SIPS, TLS and SDP SRTP key exchange.A RTP stack is provided by the sister sipXmdeiaLib project.

It can run on Windows, Linux and MacOS as it make use of the sipX-portLib OS abstraction layer library. WinCE, Symbian and VxWorks ports

are currently in progress.The current stable release is 3.2. The current development release is 3.5,

which will become stable release 4.0.The API documentation is generated using DoxyGen and the mailing

lists can be used for additional informations.The sipXphone UA is based on this library.

2.5.1.3 Sofia-SIP Library

Sofia-SIP[55] is a stack started by the Nokia Research Center. Unlike otherlibraries, it doesnt try to provide a full VoIP stack but focuses on SIP andmanyof its extensions.

It has SIMPLE support, STUN support, TLS for signaling and HTTPbasic and digest authentication methods. It implements some rare SIP ex-tensions like including 100rel, reg state event and preconditions.

Sofia-SIP is licensed LGPL and hosted on the SourceForge. The API iswell documented and code examples are provided.

The latest release is 1.12.1 from July 2006. It is rather a new library,but some projects are already using it. The SSIP-GST (SIP/SIMPLE Gaimplugin) is one of the softphones using it.

28


32/97

2. State of the Art

2.5.1.4 OPAL

OPAL (Open Phone Abstraction Library)[56]is a VoIP library originatingfrom the OpenH323 project.

It provides SIP and H.323 stacks, RTP streams and audio/video codecs.It uses PwLib for OS related operations which makes it portable to Windowsand most Unix environments.

It is licensed under the MPL (Mozilla Public License) allowing commer-cial codecs to be used with OPAL and in the same time forcing the changesto the released code to be contributed back to the community.

It supports a long list of audio codecs, including the patent-free codecSpeex. It has video capabilities based on the H.261 and H.263 codecs.

The documentation consists in DoxyGen generated pages and a few pa-pers describing the OPAL architecture.The main beneficiary of the OPAL code is the Ekiga project (former

GnomeMeeting).The latest version is 2.3.1, dated July 2006. Despite that it is an old

project, the development rhythm is quite alert now, thanks to the Ekigaproject.

2.5.1.5 GNU oSIP and eXoSIP

oSIP is a SIP library part of the GNU project. It is written in C and itsonly dependency is the standard C library.

It has threads support but it can be compile without it, which may berequired in some embedded systems.

oSIP gives the maximum flexibility to the programmer by implementingonly the low levels of SIP, and letting the user to control the transactionsstate machines.

The eXoSIP (eXtended oSIP) library is a higher level library based onOSIP. It makes it easier for users to create SIP applications by implementingthe higher levels of SIP.

The oSIP library is LGPL, while the eXoSIP library is GPL meaningthat any program that makes use of it must also be GPL.

Both oSIP and eXoSIP have reached their second major version, be-

ing renamed oSIP2 and eXoSIP2 by their author. The antisip website[57]provides documentation and (paid) support for these libraries.

The Linphone softphone is using oSIP.

2.5.1.6 DisSIPate2

The Dissipate2 library is part of the KPhone project. Dissipate2 and KPhoneare currently developed by a group of volunteers and are hosted on Sourceforge[58],under the name of KPhoneSI.

29


33/97

2. State of the Art

It is written in C++, has SRTP support and call forwarding. The license

is LGPL and is ported only to Linux as it depends on the Qt libraries.Its architecture isnt very well documented and the mailing list traffic is

low.The Iptel team has developed an IpV6 version of the Kphone.

2.5.1.7 Minisip libraries

The Minisip softphone[59] is based on a series of VoIP libraries: libmutil,libmnetutil, libmikey, libmsip. They are developed by Ph.D and Masterstudents at Royal Institute of Technology (KTH, Stockholm, Sweden).

The main focus is on security: TLS for SIP messages, MIKEY and SRTP

for voice encryption. OpenSSL library is used for encryption.Written in C++, they can be used on Linux, Windows and PocketPC.The libraries are released under the LGPL.

On the website there are some VoIP papers published by the developersand on the SVN repository there are DoxyGen generated htmls and a richdeveloper guide.

2.5.1.8 Libraries Summary

The following table compares these libraries from the points of view of porta-bility, SIP features and extensions, security features, media support anddocumentation.

VOCAL SipX-tacklib

Sofia-SIP

OPALoSIP

& eX-oSIP

DisSIP-ate2

Mini-sip

Lan-guage

C++ C++ C C++ C C++ C

License VOCAL LGPL LGPL MPL LGPL LGPL LGPL

Operating Systems ports

GNU/Linuxport

+ + + + + + +

Win32port

- + - + + - +

MacOSport

- + - - + - +

WinCEport

- - - + + - +

SIP related features

SDP + + + + + + +

30


34/97

2. State of the Art

Offer-answer

? + + + + + +

Pre-conditions

- ? + - + + +

SIMPLE - + + + + + +

STUN + + + + - + +

Security features

TSLsignaling

+ + + + - - +

HTTPdigest

+ + + + + + +

SRTP - + - - - + +MIKEY - - - - - - +

SIP Extensions

100rel - - + - - - -

REFER + + + + + + +

UPDATE - - + - + - -

Presence + + + + + + +

Media features

RTP + + - + - - +

Codecs + + - ++ - - +

Jitter

buffers + + - + - - +

Echocancel-

ation- + - + - - +

Documentation and support

Docs + + ++ + + - +

Mailinglists

- - + + - - +

2.5.2 SIP softphones

This section presents and compare SIP phones applications based on thelibraries depicted in the previous section.

2.5.2.1 SIPSet

SIPSet is part of the VOCAL project, using the SIP stack and media partsfrom VOCAL. It uses Gtk libraries for building the GUI. It has video supportby using MPEG4J and has a pluggable interface for codecs.

31


35/97

2. State of the Art

Figure 2.4: Screenshots with some of the tested SIP phones: a) KPhone b) Ekigac) MiniSip d) Linphone

2.5.2.2 sipXphone

The sipXphone was formerly known as the Instant Xpressa softphone. Itwas contributed to the SIPfoundry by Pingtel together with the sipX familyof libraries.

Its GUI is written in Java and its portable to Windows and Linux. It

is released under the LGPL.

2.5.2.3 SSIP-GST

SSIP-GST is a GAIM plugin build using the Sofia-SIP library. It was alsodeveloped in the Nokia Research Center. Audio support is integrated usingthe GStreamer library, which can provides many codecs as plug-ins.

SSIP-GST is a very thin layer connecting some of the best open-sourceproducts: GAIM for the GUI, Sofia-SIP for the signaling and GStreamer formedia.

32


36/97

2. State of the Art

2.5.2.4 Linphone

The Linphone uses the eXoSIP library for SIP signaling. It implements nu-merous audio codecs and video support is currently under development. Lin-phone comes with oRTP, a C written RTP stack licensed under the LGPL.The graphical part uses GTK.

It has a longer history then other projects, so it is tested for compatibility.

2.5.2.5 Ekiga

The Ekiga project was formerly known as GnomeMeeting. Since it has SIPsupport, it was renamed to mark the fact that it is not just a clone of theMicrosoft Meeting program. This phone seems to be quickly adopted by the

Linux users. An Windows release is currently being prepared. Being part ofthe Gnome project, it uses GTK+ for widgets and it has a very good userinterface.

2.5.2.6 KPhone

KPhone uses the Dissipate2 library (which is part of the KPhone distribu-tion) for SIP signaling and the Qt libraries for the UI.

It has been recently forked and moved to Sourceforge. The first version ofthis spinoff is just released under the name of KPhoneSI. The UI is improvedand the Speex codec was added on. It is licensed under the GPL.

2.5.2.7 Minisip

The Minisip softphone consists of the Minisip libraries and a rather slim toplayer application. The graphical part has GTK and QT variants. It canbe successfully used under the Familiar Linux distribution on iPAQ PDAs.The minisip libraries are LGPL, but the application is GPL.

2.5.3 SIP softphones summary

The following table compares the phones presented in the last sections. TheGeneral section of the table is subjective and is based on the authors per-

sonal opinions.

SIPSet SipX-

phoneSSIP-GST

Ekiga Lin-

phone Kphone

Mini-sip

SIP stack VOCAL SipX SIP-

Sofia OPAL oSIP

DiSSip-ate2

Mini-sip

Lan-guage

C++ C++

Java C C++ C C++

C/C++

License VOCAL LGPL GPL GPL GPL GPL GPL

33


37/97

2. State of the Art

GUI Lib GTK Java GTK+(GAIM)

GTK+ GTK QT GTKQT

Operating Systems ports

GNU/Linuxport

+ + + + + + +

Win32port

- + + + + - +

MacOSport

- - - - + - +

WinCE

port - - - + + - +

Audio codecs

SPEEX - - + + + + +

G.711u + + + + + + +

G.711a - + + + + + +

G.723.1 - - + + - - -

G.729 - + + + - - -

GSM - - + + + + +

Video codecs

MPEG + - - - - - -

H.261 - - - + - + -

H.263 - - - + - + +General

Widelyspread

- + + ++ ++ ++ +

Stable - - + ++ ++ ++ +

Maintained - ++ + ++ ++ ++ +

Extendable - - + ++ ++ + +

GUI eval-uation

- - + ++ + + +

2.5.4 ConclusionsThere are many good open-source SIP phones implementations, most ofthem based on powerful libraries for SIP and media stacks. Some of thelibraries have a lot of signaling features (e.g. Sofia-SIP, oSIP), others havegood media capabilities (Opal, sipX), while others have strong security fea-tures (miniSIP). The software design varies from high levels of object inher-itance and abstraction (like in Opal) to low level SIP libraries (oSIP).

All siphones projects presented are in close connection with the SIPstacks used, either they are developed by the same team either the softphone

34


38/97

2. State of the Art

developers make important contributions to the libraries. As a result, the

phones usually share the software design ideas of the associated library.Ekiga, KPhone, Linphone and Minisip have good and stable user inter-

faces and provide a wide range of audio codecs. Ekiga, KPhone and Minisipsupport video at this moment. Ekiga has some interesting and potentiallyuseful features like having more registered accounts and sending a movie-logoinstead of real video.

35


39/97

Chapter3Handover Concepts

This chapter presents the mainhandoverconcepts, classifications and possi-ble scenarios. The current research and standardizations efforts for handoverprocedures in packet-based networks are also summarized.

3.1 Definition

In cellular telecommunications, the term handoverrefers to the process oftransferring an ongoing call from one channel connected to the core network

to another. The most basic form of handover is that used in GSM andanalog cellular networks, where a phone call in progress is redirected fromone cell to another. The transmit/receive frequency pair is changed withoutinterrupting the call.

In the context of packet based communications andNext Generation Net-works, thehandoverterm must be generalized for any type of service (eitheraudio, video or other multimedia sessions), for networks under potentiallydifferent administrations and using different technologies. Moreover, thehandover may be done not only to ensure the continuation of the mediasession, but also to provide a better experience for the user or to optimizethe resource consumption.

We define the handoveras the process of migrating a multime-dia session from one network to another in order to improve userexperience, optimize resource usage or to provide service conti-nuity, without interrupting the media session and without userintervention.

A synonymous term for handover is handoff, with roughly equal usage.In this document, the term handover is preferred.

36


40/97

3. Handover Concepts

3.2 Classification

Depending on the purposeof the handover, there are two classes of possiblescenarios:

For service continuity, if the connectivity of the network that is cur-rently used is either lost or predicted to be lost in the near future. Thehandover procedure must be minimal, to avoid human noticeable in-terruptions and must not depend on the connectivity of the currentlyused network.

For service optimization, if the handover is triggered by the discoveryof a network offering a better option in terms defined by operatorsand users policies (e.g. bandwidth, delay, network load).

From the administrativepoint of view the handover procedure can be:

Intra-operator when the initial network and the destination networkare owned by the same operator.

Inter-operator when the initial network and the destination networkare not owned by the same operator.

From the technologypoint of view, the handover procedure can be:

Intra-technologyif the wireless technology used in the initial networkis the same used in the destination network.

Inter-technologyif the wireless technology used in the initial networkis not the same as the one used in the destination network.

Based on what entity makes the handover decision, we have:

Terminal initiatedhandover, if the handover is triggered by the termi-nal. This type of handover is usually related withservice continuity,because the terminal can detect the loss of connectivity.

Operator initiatedhandover, if the handover is triggered by the opera-tor. This type of handover is usually related with service optimization,because the operator has more information about the network load andpolicies.

Finally, form the media interruptionpoint of view, there are:

Hard handoverif the old media session is stopped before the new mediasession is started (Break before make). It has the disadvantage ofreveling interruptions to the user. However, in some situations, it is

37


41/97


the only solution for continuing the service (e.g. the signal level drops

very fast or the Ethernet cable is plugged out). It is usually relatedwith the service continuity scenarios, when the connectivity lost cannot be predicted.

Soft handoverif the new media session is started before the old mediasession is stopped (Make before break). It is important in serviceoptimization scenarios, were media interruption are unacceptable. Itcan be used in service continuityscenarios if the connectivity lost canbe predicted.

3.3 Scenarios

This section will presents the list of target handover scenarios, in orderto identify the requirements for a handover solution. While not all thepossible scenarios are presented, the set of chosen scenarios is consideredrepresentative and was used in the development of the solution and in theevaluation of the architecture. The scenarios are presented in terms definedby the classifications presented in the previous section.

3.3.1 Enforced Service Continuity, soft handover,intra-operator

A user who is using 802.11 goes out of the hot spot coverage, buta WiMax base station offered by the same operator is available.The terminal detects the degradation of the wireless signal andseamlessly handovers the media session from the 802.11 interfaceto the WiMax interface without user intervention.

This scenario is a service continuity scenario because the handover istriggered by the degradation of the signal on the 802.11 interface. Thefact that the loss of connectivity is predicted in time, permits a soft mediahandover. The scenario involves an intra-operator handover because the802.11 and WiMax networks are provided by the same operator.

3.3.2 Enforced Service Continuity, soft handover,inter-operator

A user who is using 802.11 goes out of the hot spot coverage, buta WiMax base station offered by a different operator is available.The terminal detects the degradation of the wireless signal andseamlessly handovers the media session from the 802.11 interfaceto the WiMax interface without user intervention.

38


42/97


This scenario is a service continuity scenario because the handover is

triggered by the degradation of the signal on the 802.11 interface. Thefact that the loss of connectivity is predicted in time, permits a soft mediahandover. The scenario involves an inter-operator handover because the802.11 and WiMax networks are provided by different operators.

3.3.3 Enforced Service Continuity, hard handover

A user who is using 802.11 goes out of the hot spot coverage. AWiMax base station offered by a different operator is available,but because of the high speed movement and short overlappingdistance the loss of connectivity cannot be predicted. The ter-

minal handovers the media session from the 802.11 interface tothe WiMax interface with very short latency.

This scenario is a service continuity scenario because the handover istriggered by the loss of connectivity on the 802.11 interface. As the predic-tion is not possible, ahard handoverprocedure is made. In this scenario, thehandover procedure is time critical, as any delay results in a larger mediainterruption.

The scenario involves an inter-operator handover because the 802.11 andWiMax networks are provided by different operators.

3.3.4 Service optimization, intra-technology,terminal triggered

A user who is using 802.11 goes into an area covered with sev-eral 802.11 and WiMax base stations. Some are owned by thesame operator that provides the initial network, while others areowned by a different operator. The terminal detects the avail-ability of multiple networks, and the decision maker selects an802.11 network as the optimal one based on a set of policies. Themedia session is handovered seamlessly from the initial 802.11network to the optimal one without user intervention.

This scenario is a service optimization scenario because the handoveris triggered by the availability of new networks. It is an intra-technologyhandover because the initial and the new network are accessible via thesame network interface. The scenario involves an inter-operator handoverbecause the 802.11 and the optimal network might be provided by differentoperators.

The decision maker is left unidentified in the scenario. Depending onthe selection policies, it can be either the terminal or the operator. However,the handover is terminal triggered because the terminal detects the signaldegradation.

39


43/97


3.3.5 Service optimization, inter-technology,

operator triggered

A user is using 802.11 in an area covered with several 802.11 andWiMax base stations. Some are owned by the same operatorthat provides the initial network, while others are owned by adifferent operator. Thenetwork monitordetects a high load inthe network that the terminal is using now, and the decisionmaker selects a WiMax network as the optimal one based on aset of policies. The media session is handovered seamlessly fromthe initial 802.11 network to the optimal WiMax network.

This scenario is a service optimizationscenario because the handover istriggered by a policy of the operator. It is an inter-technology handoverbecause the initial and the new network are accessible via different networkinterfaces. The scenario involves an inter-operator handover because the802.11 and the optimal network might be provided by different operators.

The network monitor and decision maker elements are left unidentifiedin the scenario. They will be owned by the operators involved, hence, it isa operator triggered scenario.

3.4 Current standardization efforts

This section summarizes the main standardization efforts for handover tech-nologies:

3.4.1 IEEE 802.21 Media Independence

The IEEE 802.21 working group[27] is developing standards to enable han-dover and interoperability between heterogeneous network types includingboth 802 and non 802 networks.

The main approach is to use level 2 events (e.g. link up, link down,link going down, better access point available) to trigger level 3 han-dover (for example, based on Mobile IP[19]) and to announce the applica-tions about imminent handovers.

The IEEE 802.21 working group started work in March 2004, and hasmore than 30 contributing companies. A first draft [3]of the standard wasreleased.

3.4.2 3GPP Voice Call Continuity

On December 2005, the 3GGP TSG SA working group 2 has released theTechnical Report (TR) 23806[6], which is a feasibility study into the possibleapproaches toVoice Call Continuitybetween circuit switched networks andIMS.

40


44/97


The technical report identifies two functional entities directly involved

in handover:

TheCall Continuity Control Functions(CCCF) provides functions forcall continuity between the GSM/UMTS Circuit Switch domain andIMS domain using an IP Connectivity Access Network. It receives andprocesses call continuity requests caused by radio related events (e.g.loss of radio coverage) and initiates the handover between the circuitswitched domain and the IMS domain.

TheNetwork Domain Selection(NeDS) is the control point for select-ing which domain to use for terminating a call. This function is the

point where the decision is taken to deliver a call either in the CSdomain or in the IMS domain. While it is logical for a call that wasoriginated in the CS domain to remain CS end-to-end, and similarlyfor an IMS-originated call to remain IMS throughout, there are cir-cumstances when a change of domain is appropriate. The NeDS entitywill interact either with the S-CSCF or with the CCCF.

3.4.3 Generic Access Network

The Generic Access Network (GAN)[7]was formerly known as UnlicensedMobile Access (UMA), until it was adopted by the 3GPP in April 2005. Itdescribes a telecommunication system allowing seamless roaming and han-

dover between local area networks (802.11 or Bluetooth) and wide area net-works (GSM/GPRS or UMTS) using the same dual-mode mobile phone.

GAN is an extension of GSM/GPRS mobile services providing tunnelingfor certain GSM/GPRS protocols over a broadband IP network, and relayingthem through an unlicensed radio link. UMA is a complement to traditionalGSM/GPRS radio coverage, used to enhance customer premises coverage,increase network capacity and potentially lower costs.

41


45/97

Chapter4Application Layer Signaling for

Handover

This chapter presents the proposed application layer solution enabling han-dover. The solution uses SIP for the handover singaling and it is desingedfor easy integration with the IMS networks. section4.1documents the mainsolution design options and the reasons behind the choices, with referencesto the scenarios presented in Section3.3. The following sections present themain steps of the solution.

4.1 Overview

In order to enable the scenarios presented in Section 3.3, an applicationlayer solution for handover is proposed. A lower layer solution (e.g. basedon Mobile IP [19]) would have the potential of obtaining a better perfor-mance in the case ofhard handover scenarios (3.3.3), but it would make theinter-operator scenarios (3.3.2) harder because of the administration andsecurity issues. It would also make harder the implementation ofsoft han-dover scenarios (3.3.1, 3.3.2, 3.3.4 and 3.3.5), as the user agent softwareapplication would not know when the interfaces are changed. While the

issue of using lower layer techniques for hard handover remains open, thisdocument focuses on an application layer solution.

Because the integration with the IMS networks was one of the main pur-poses of the project, the use of SIP for signaling the handover was natural.Although there is no standard mechanism for handover in SIP, the mid ses-sion negotiations, the call transfer mechanisms and the event notificationsupport may be used for signaling the handover.

The handover decision makermentioned in scenarios3.3.4and3.3.5 ischosen to be on the operator side. This is in concordance with the sugges-tions from TR 23806 [6], in which the domain selection decision is made by

42


46/97

4. Application Layer Signaling for Handover

theNetwork Domain Selection(NeDS) element, which receives the informa-

tion from the Serving-CSCF.We define the Service Handover Control Function (SHCF) as the func-

tional entity responsible for:

Receiving and processing the requests caused by the radio relatedevents;

Selecting the most appropriate network for continuing the call, basedon operators QoS policies and users preferences;

Triggering the mechanisms that lead to switching the multimedia ses-sions to different endpoints;

Adapting the service parameters according to the new network andservice context;

The SHCF may be implemented as an Application Server, as a self con-tained entity or as part of the S-CSCF.

Date post:	04-Jun-2018
Category:	Documents
Upload:	dung-pham
View:	230 times
Download:	0 times

Application Layer Handover of VoIP Sessions in IMS Environments1

Documents