seamless handover in het ip multimedia...

Universiteit Gent

Faculteit Toegepaste Wetenschappen

Vakgroep Informatietechnologie

Voorzitter: Prof. Dr. Ir. P. Lagasse

Seamless Handover in het IP Multimedia Subsystem

door

Jan VERMEULEN

Promotor: Prof. Dr. Ir. I. MOERMAN

Scriptiebegeleiders: Ir. T. VAN LEEUWEN, Ir. M. STEENHUYSE

Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de

computerwetenschappen

Academiejaar 2006-2007

Voorwoord Vooreerst wil ik enkele mensen bedanken die mij het afgelopen jaar een handje (of zelf een grote

hand) hebben toegestoken.

Eerst en vooral wil ik mijn begeleiders Tom en Maarten bedanken voor de hulp en begeleiding die ze

me gedurende het ganse jaar hebben gegeven. Door omstandigheden kwam ik voor meer problemen

te staan dan ik me had kunnen voorstellen en steeds stonden zij daar om me uit de nood te helpen.

Naast mijn begeleiders wil ik ook prof. Ingrid Moerman bedanken voor de kritische blik die ze tijdens

de permanente evaluaties op mijn eindwerk wierp en de raad die ze bood wanneer het wat

moeilijker ging.

Bart De Smet wil ik ook speciaal bedanken voor de avonden die hij heeft vrijgemaakt om me wegwijs

te maken in de wereld van C++.

Graag wil ik ook Arne Bracke bedanken die mij gedurende het ganse jaar in raad en daad bijstond en

voor de nodige ontspanning zorgde.

Het schrijven van een thesisboek gaat uiteraard gepaard met herhaaldelijk nalezen ervan. Hiervoor

kon ik rekenen op Tom Van Leeuwen, Maarten Steenhuyse, André Vermeulen, Bieke Carpentier en

Arne Bracke.

Tenslotte wil ik nog graag mijn ouders en familie bedanken voor de steun die ze mij gedurende mijn

hele studiecarrière hebben gegeven.

Toelating tot bruikleen

De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de

scriptie te kopiëren voor persoonlijk gebruik.

Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking

tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze

scriptie.

Jan Vermeulen, mei 2007

Seamless Handover in het IP Multimedia Subsystem

door

Jan VERMEULEN

Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de

computerwetenschappen

Academiejaar 2006-2007

Promotor: Prof. Dr. Ir. I. MOERMAN

Scriptiebegeleiders: Ir. T. VAN LEEUWEN, Ir. M. STEENHUYSE

Faculteit Toegepaste Wetenschappen

Universiteit Gent

Vakgroep Informatietechnologie

Voorzitter: Prof. Dr. Ir. P. Lagasse

Samenvatting

Momenteel hebben mobiele toestellen steeds meer communicatiemogelijkheden. Ze zijn niet meer

beperkt tot het voeren van een telefoongesprek via de klassieke manier: nieuwe technologieën

openen de deur naar een goedkopere manier van telefoneren: Voice over IP.

Voor Voice over IP hebben we toegang tot het internet nodig. Het IP Multimedia Subsystem zorgt

ervoor dat we op 2 verschillende manieren het internet kunnen bereiken: 1. Via een draadloos

thuisnetwerk of 2. Via het (in het ideale geval) overal bereikbare mobiele datanetwerk.

Wanneer we het klassieke telefoonnetwerk willen vervangen door het internet en de Voice over IP

technologie, moeten we aan enkele vereisten voldoen. Ten eerste moet de kost van een

telefoongesprek met Voice over IP goedkoper zijn dan een telefoongesprek over de klassieke

telefoonlijnen. Bovendien moet een gebruiker altijd en overal een gesprek kunnen opzetten. De

toegang tot het mobiele datanetwerk is momenteel nog te duur om over een goedkopere oplossing

voor telefonie te kunnen spreken. Om deze kosten drastisch te verlagen zullen we zo vaak mogelijk

gebruik maken van het draadloze thuisnetwerk om toegang tot het internet te zoeken. Wanneer we

een gesprek voeren zullen we vaak moeten afwisselen tussen deze twee toegangswijzen: we starten

ons telefoongesprek op het moment dat we in de auto zitten en komen thuis voor het gesprek

afgelopen is. Bij het afwisselen mogen we geen verlies van kwaliteit ondervinden zodat het voor de

gebruiker lijkt alsof hij een constante verbinding met het internet heeft.

In deze scriptie stellen we een manier voor om deze naadloze overgang te realiseren en de

implementatie hiervan op client- en serverzijde.

Trefwoorden: Voice over IP, SIP, IMS, Handover

Lijst van afkortingen 3GPP Third Generation Partnership Project AS Application Server B2BUA Back To Back User Agent BGCF Breakout Gateway Control Function CAMEL Customized Applications for Mobile network Enhanced Logic CC CSRC count Codec Coder/decoder CSCF Call/Session Control Function CSRC Contributing SouRCe EDGE Enhanced Data Rates for GSM Evolution ETSI European Telecommunications Standards Institute FEC Forward Error Control GM GnomeMeeting GPRS General Packet Radio Service GSM Global System for Mobile communications HSS Home Subscriber System HTTP HyperText Transfer Protocol I-CSCF Interrogating-CSCF IMS IP Multimedia Subsystem IM-SSF IP Multimedia Service Switching Function IP Internet Protocol ISDN Integrated Services Digital Network ISUP ISDN User Part ITU International Telecommunications Union LAN Local Area Network MGCF Media Gateway Controller Function MGW Media Gateway MMS Multimedia Messaging Service MOS Mean Opinion Score MPEG Moving Pictures Experts Group MRF Media Resource Function MRFC Media Resource Function Controller MRFP Media Resource Function Processor MTP Message Transfer Part OSA Open Service Access OSA-SCS OSA-Service Capability Server PCM Pulse Code Modulation P-CSCF Proxy-CSCF PSTN Public Switched Telephone Network QoS Quality Of Service RFC Request For Comments RTP Real-Time Transport Protocol S-CSCF Serving-CSCF SDP Session Description Protocol SGW Signaling Gateway SIP Session Initiation Protocol SLF Subscriber Location Function SMS Short Message Service SMTP Simple Mail Transfer Protocol

SSRC Synchronization SouRCe TCP Transport Control Protocol ToS Type Of Service UDP User Datagram Protocol UMTS Universal Mobile Telephone System URI Uniform Resource Identifier URL Uniform Resource Locator URN Uniform Resource Name VoIP Voice over IP

Seamless Handover in the IP Multimedia Subsystem Jan Vermeulen

Promotor: Ingrid Moerman

Abstract – The IP Multimedia Subsystem (IMS) is a

network architecture which tries to combine the

strengths of fixed and mobile networks. Combining

these two networks leads to a new concept: seamless

mobility. The Sesssion Initiation Protocol (SIP) already

provides mobility support but the handover procedure

of SIP suffers from unwanted delay and packet loss. In

this article we present a seamless handover procedure

for Voice over IP (VoIP) calls based on SIP. The

seamless handover ensures that there will be no packet

loss and it keeps delay jitter under control. Keywords – VoIP, SIP, IMS, handover

I. INTRODUCTION

The IP Multimedia Subsystem (IMS) [1] is an architecture

that merges mobile packet-switched networks and the fixed

IP-networks of the internet into one packet-switched

network. Providing the necessary support for end-to-end

Quality of Service (QoS), the IMS allows us to access

internet developed services, such as VoIP, using our

interface to the 3G packet-switched network.

VoIP uses the packet-switched network to exchange

signalling and data information relative to the call.

Nowadays more and more mobile phones support two

ways to connect to packet-switched networks: GPRS [2]

and Wifi. Combining these two access resources with the

IMS could mean a breakthrough for the use of VoIP on

mobile phones.

Using only the GPRS-interface provides the same mobility

support as circuit-switched networks but leads to a much

higher cost for making a call. Using the Wifi-interface, on

the other hand, leads to a much lower cost than circuit

switched networks. The problem is that, in using the Wifi-

interface, it’s not always possible to make a VoIP call. It is

only within the range of the wireless (home) network,

limited to fifty meters, that we are able to connect to the

internet.

By using both access resources to the internet we can

combine their strengthts. Within the range of our home-

network, we use the Wifi-interface to reduce the cost of our

calls. Elsewhere we use the GPRS-interface to provide

mobility support.

At this point we have our two access resources and a

definition of when to use each access resource to connect

to the internet. However, when we start a VoIP call outside

the range of our home network (e.g. riding home from

work) but enter the range of our home network during the

same call (e.g. coming home), we should be able to switch

from the GPRS- to the Wifi-interface in order to reduce the

cost of the call. The user shouldn’t be aware of the fact that

he’s changing networkinterface and hence the quality of

the VoIP call should not drop during this handover: the

handover must be seamless.

II. THE IP MULTIMEDIA SUBSYSTEM

As we said before: the IMS is the key element for using

both interfaces to access the same internet resources. The

IMS combines the GPRS and fixed wireless network as

part of the IMS architecture. This means that we can access

the same network resources, using whatever network

interface.

Since the focus of this article is setup and handover of a

VoIP call, we describe a simplified IMS network

architecture. Figure 1 shows the four IMS network nodes

that we used in this project.

S-CSCF

P-CSCFP-CSCF

I-CSCF

HSS

Wireless

homenetwork

GPRS

network

SIP-AS

Figure 1: Simplified IMS-network

The Home Subscriber System (HSS) is the central

repository of user related information.

There are 3 types of Call/Session Control functions

(CSCF’s). They are all SIP-servers that provide different

functions:

• The P-CSCF is the first point of contact between the

IMS-terminal and the IMS network. From a SIP

point of view, it acts as an inbound/outbound proxy

server.

• The I-CSCF has an interface to the HSS through

which it retrieves user information to route a SIP-

request to the appropriate S-CSCF

• The S-CSCF is the central node in the signalling

plane of the IMS. It is essentially a SIP-server that

provides session control as well. The S-CSCF also

acts as a SIP-registrar. Which means that it maintains

a binding between a user’s SIP-address and his

location.

III. SEAMLESS HANDOVER

With the IMS, we have a network architecture that

supports network access through both GPRS and Wifi

interface. Next step is the definition of a handover

procedure between these two interfaces. The handover

should limit packet loss and keep delay jitter under control.

The handover we propose is based on the research of [3] as

we also define an extension to the standard SIP-protocol:

the join-header. The handover procedure can be split into 2

phases: the Join-fase and the ReINVITE-fase.

A.Join-fase

At first the reader must know that the proxy servers (P-

CSCF) act as Back to Back User Agent (B2BUA). This

means that all signalling and data packets that are sent

from and to the IMS-terminal will pass the P-CSCF. This

way the P-CSCF will be able to inspect, modify or even

replicate all packets from and to the IMS-terminal. The

ability to replicate data packets will be crucial to our

handover procedure.

Figure 2 shows the VoIP call between Alice and Bob.

Alice is a mobile user and will change interface during this

call. Bob is a fixed user and has only one interface at his

disposal.

Figure 2: Join-fase

The moment Alice’s new interface becomes available, she

will send a SIP INVITE message with an extra join-header

from the newly activated interface to the P-CSCF of the

domain of the first interface. This join-header contains all

relevant information about the ongoing call. The contact

information of this SIP-message contains the IP-address of

the new interface. Notice that at this point, Alice is able to

communicate through both her interfaces. When the P-

CSCF receives an INVITE with join-header, he will

duplicate the RTP-session between Alice and Bob. The P-

CSCF will replicate all RTP-packets coming from Bob and

send them to both of Alice’s interfaces. On the other hand,

Alice will send all of her RTP-packets through both of her

interfaces to P-CSCF 1. It’s obvious that both IMS-

terminal and P-CSCF have a RTP-packetfilter to eliminate

duplicates.

Figure 3: Duplicated RTP-Session

B. ReINVITE-fase

As soon as the first data packet reaches Alice through her

newly activated interface, she will send a re-INVITE

message (figure 4) to Bob. This reINVITE is essentially an

INVITE message with the IP address of the newly

activated interface as contact information. As a result the

parameters of the call will be renegotiated on an end to end

basis. P-CSCF 2 will be chosen as a b2bua for the newly

activated interface.

Figure 4: reINVITE-fase

Once the call renegotiations are complete, a BYE message

will be sent to P-CSCF 1 to terminate the call-leg through

the old interface. (figure 5)

Figure 5: BYE message

It is clear that the new RTP-session is set up before the old

one is released so as to avoid packet loss.

Finally, Alice registers its new location information with

the home networks S-CSCF by using a REGISTER

message.

IV. CONCLUSIONS

The combination of the IMS architecture and our extention

to the standard SIP-protocol offers a compatible alternative

to circuit-switched phone calls. The IMS provides the

packet-switched network architecture necessary to merge

3G and fixed networks into one network . The proposed

extention to SIP allows us to switch between network

interfaces during a call without suffering packet loss. This

way a VoIP client application will always be able to detect

and switch to the cheapest possible network interface to

connect to the IMS network without having to restart the

call or suffering any loss of quality.

V. REFERENCES

[1] G. Camerillo and M.A. Garcia-Martin. The 3G IP

Multimedia Subsystem (IMS), John Wiley & Sons Ltd,

2006

[2] J. R. Bates, GPRS:General Packet Radio Service,

McGraw and Hill Professional, 2001

[3]N.Banerjee, A, Acharya, S.K. Das, Seamless SIP-Based

Mobility for Multimedia Applications, IEEE network, 2006

Inhoudsopgave

HOOFDSTUK 1: INLEIDING .............................................................................................................1

HOOFDSTUK 2: HET 3G IP MULTIMEDIA SUBSYSTEM (IMS) .............................................................3

1. HET INTERNET EN CELLULAIRE NETWERKEN .......................................................................................3

2. WAAROM IMS ..........................................................................................................................3

3. ALGEMENE PRINCIPES VAN DE IMS-ARCHITECTUUR .............................................................................5

3.1 VAN CIRCUIT-SWITCHED NAAR PACKET-SWITCHED ........................................................................................ 5

3.2 VEREISTEN VOOR IMS ............................................................................................................................. 5

3.3 PROTOCOLS IN IMS................................................................................................................................. 6

HOOFDSTUK 3: HET SESSION INITIATION PROTOCOL (SIP) ..............................................................7

1. SITUERING ................................................................................................................................7

2. ALGEMEEN ................................................................................................................................8

3. TERMINOLOGIE ..........................................................................................................................8

4. SIP-BOODSCHAPPEN ................................................................................................................. 10

4.1 SIP-AANVRAAG .................................................................................................................................... 10

4.2 SIP-ANTWOORD................................................................................................................................... 10

5. REGISTRATIE ............................................................................................................................ 11

6. CALL SETUP ............................................................................................................................. 13

7. RECORD-ROUTE ....................................................................................................................... 17

HOOFDSTUK 4: VOICE OVER IP (VOIP) .......................................................................................... 19

1. INLEIDING ............................................................................................................................... 19

2. EISEN VOOR HET NETWERK .......................................................................................................... 19

3. REAL-TIME TRANSPORT PROTOCOL (RTP) ...................................................................................... 21

3.1 SITUERING ........................................................................................................................................... 21

3.2 DE RTP-HEADER ................................................................................................................................... 21

HOOFDSTUK 5: DE IMS-ARCHITECTUUR ....................................................................................... 24

1. ALGEMENE IMS-ARCHITECTUUR ................................................................................................... 24

1.1 DE DATABANKEN: HSS EN SLF ................................................................................................................ 25

2. IMS IN ONS PROJECT ................................................................................................................. 29

3. BASIC SESSION SETUP ................................................................................................................ 30

3.1 DE IMS-TERMINAL ZENDT DE INVITE AANVRAAG ...................................................................................... 31

3.2 DE INITIËRENDE P-CSCF VERWERKT DE INVITE AANVRAAG ......................................................................... 31

3.3 DE INITIËRENDE S-CSCF VERWERKT DE INVITE AANVRAAG ......................................................................... 32

3.4 DE TERMINERENDE I-CSCF VERWERKT DE INVITE AANVRAAG ..................................................................... 32

3.5 DE TERMINERENDE S-CSCF VERWERKT DE INVITE AANVRAAG .................................................................... 33

3.6 DE TERMINERENDE P-CSCF VERWERKT DE INVITE AANVRAAG .................................................................... 33

3.7 DE IMS-TERMINAL ONTVANGT DE INVITE AANVRAAG................................................................................ 33

HOOFDSTUK 6: SEAMLESS HANDOVER ......................................................................................... 34

1. EISEN VOOR APPLICATIES ............................................................................................................ 34

1.1 VERTRAGING ........................................................................................................................................ 34

1.2 PAKKET VERLIES .................................................................................................................................... 36

2. SEAMLESS HANDOVER: HOE GEREALISEERD ...................................................................................... 38

2.1 STANDAARD SIP: REINVITE ................................................................................................................... 38

2.2 ONZE OPLOSSING: INVITE MET JOIN-HEADER............................................................................................ 39

HOOFDSTUK 7: EKIGA .................................................................................................................. 43

1. STRUCTUUR ............................................................................................................................. 43

1.1 EKIGA ................................................................................................................................................. 44

1.2 OPAL .................................................................................................................................................. 45

1.3 PWLIB ................................................................................................................................................. 47

2. OPZETTEN VAN EEN CALL ............................................................................................................ 48

3. AANPASSINGEN VOOR DE HANDOVER ............................................................................................ 52

3.1 INVITE MET JOIN-HEADER ..................................................................................................................... 53

3.2 RTP-PAKKET FILTER ............................................................................................................................... 56

3.3 REINVITE ........................................................................................................................................... 58

3.4 AFSLUITEN OUDE VERBINDINGEN ............................................................................................................. 58

HOOFDSTUK 8: DE IMS-SERVER ................................................................................................... 60

1. DE BASIS IMS-SERVER ............................................................................................................... 60

2. BACK TO BACK USER AGENT ........................................................................................................ 61

2.1 SIP- EN SDP-BOODSCHAPPEN ................................................................................................................ 61

2.2 INVITE MET JOIN-HEADER ..................................................................................................................... 62

HOOFDSTUK 9: CONCLUSIES ........................................................................................................ 64

1. PROBLEMEN ............................................................................................................................ 64

2. TESTOPSTELLING ....................................................................................................................... 65

REFERENTIES ............................................................................................................................... 68

1 | Hoofdstuk 1 - Inleiding

Hoofdstuk 1: Inleiding

Momenteel ondersteunen mobiele toestellen steeds meer mogelijkheden om te communiceren.

Buiten het gewone bellen via het gsm netwerk kunnen we ondertussen ook al met ons mobiel toestel

toegang tot het internet verkrijgen via GPRS, UMTS of I-mode. De duurdere smart phones zijn zelfs

uitgerust met een draadloze netwerkinterface1. Om optimaal gebruik te kunnen maken van deze

mogelijkheden heeft men een nieuwe netwerkarchitectuur ontwikkeld: het IP Multimedia Subsystem

(IMS). Deze netwerkarchitectuur zorgt ervoor dat diensten die het internet zijn gebruikers met een

computer aanbiedt, ook beschikbaar worden via mobiele toestellen. Omgekeerd worden typische

mobiele diensten zoals SMS beschikbaar via het internet.

Eén van die diensten die we via IMS op mobiele toestellen beschikbaar willen maken, is Voice over IP

(VoIP). VoIP is een vorm van telefonie waarbij we gebruik maken van een packet-switched netwerk

(het internet) om ons gesprek te voeren. Dit brengt met zich mee dat alle informatie die tussen twee

gebruikers uitgewisseld wordt, aan de hand van IP-pakketten verstuurd wordt. Het werken met een

packet-switched netwerk heeft enkele belangrijke voordelen ten opzichte van het circuit-switched

telefonienetwerk waar we later verder op in zullen gaan.

Aan de andere kant zijn de kosten van een GPRS-verbinding op dit moment nog te hoog om VoIP als

concurrentie te zien voor klassieke telefonie met mobiele toestellen. De prijzen van GPRS-

verbindingen dalen echter snel en bovendien kunnen we, zoals eerder vermeld, op steeds meer

toestellen gebruik maken van een draadloze netwerkinterface om verbinding te maken met een

thuisnetwerk of hotspot. Zo hebben we ook toegang tot het internet en deze verbinding is gratis of

beter gezegd: een vast abonnement.

Wanneer we deze twee verbindingswijzen tot het packet-switched internet combineren, kunnen we

de concurrentie aangaan met de klassieke telefonie. Binnen het bereik van ons draadloos

thuisnetwerk maken we gebruik van de draadloze netwerkinterface en wanneer we weg van huis

zijn, gebruiken we de GPRS-interface om toegang tot het Internet te verkrijgen. Dit is echter nog niet

voldoende. Indien we thuis een VoIP telefoongesprek opzetten met behulp van onze draadloze

netwerkinterface en we willen ondertussen het huis verlaten, moeten we dit gesprek stopzetten,

verbinding maken met het Internet via de GPRS-interface en het gesprek opnieuw opstarten.

In deze thesis stellen we een oplossing voor dit probleem voor. We zorgen ervoor dat er “seamless”2

wordt overgeschakeld tussen de verschillende interfaces terwijl we aan het bellen zijn. Zo verkrijgen

we hetzelfde gebruiksgemak als bij de klassieke vorm van telefoneren waarbij we overal bereikbaar

zijn. Bovendien kunnen we de kosten drukken door thuis het draadloze netwerkinterface te

gebruiken om een verbinding met het internet op te zetten.

In wat volgt zullen we eerst een duidelijke uitleg over het IP Multimedia Subsystem geven. IMS

gebruikt SIP (Session Initiation Protocol) als signaling protocol voor het opzetten, afbreken en

wijzigen van VoIP sessies. De werking van SIP en enkele andere bij VoIP gebruikte protocols zullen we

toelichten. Daarna geven we een duidelijke definitie van het begrip “seamless handover” op gebied

1 Toegang tot een draadloos netwerk.

2 Een uitgebreide definitie van “seamless” volgt later.

2 | Hoofdstuk 1 - Inleiding

van pakketverlies, etc. Vervolgens zullen we een uitbreiding op SIP voorstellen die aan deze definitie

voldoet. Eerst verduidelijken we de theoretische kant van deze oplossing en tenslotte bespreken we

de implementatie ervan.

3 | Hoofdstuk 2 - Het 3G IP Multimedia Subsystem

Hoofdstuk 2: Het 3G IP Multimedia

Subsystem (IMS)

Derde generatie (3G)netwerken trachten de twee grootste paradigma’s van de communicatiewereld

samen te voegen: cellulaire netwerken en het internet. Het IP (internet protocol) Multimedia

Subsystem (IMS) is het sleutelelement in de 3G architectuur dat het mogelijk maakt om

alomtegenwoordige toegang te bieden tot alle diensten die het internet aanbiedt. In dit hoofdstuk

geven we een algemene inleiding en situering van IMS. We baseren ons hierbij op (Camerillo &

Garcia-Martin, 2006)

1. Het Internet en Cellulaire netwerken Het internet is in de laatste 20 jaar van een klein onderzoekersnetwerk uitgegroeid tot een

wereldwijd netwerk dat toegang biedt tot tal van diensten. De belangrijkste reden voor deze groei is

de mogelijkheid om enorm veel nuttige diensten die miljoenen mensen willen gebruiken aan te

bieden. Het internet heeft de mogelijkheid om zoveel verschillende diensten aan te bieden omdat

het gebruik maakt van tal van open protocollen die beschikbaar zijn voor elke ontwikkelaar die een

nieuwe dienst wil ontwikkelen. Wanneer deze protocollen niet voor het grote publiek beschikbaar

zouden zijn, zouden slechts de enkele experts die een protocol ontwikkeld hebben op dit protocol

verder kunnen bouwen.

Op dit moment bieden cellulaire telefonienetwerken diensten aan aan meer dan een miljard

gebruikers wereldwijd. Deze diensten bevatten uiteraard het opzetten van telefoongesprekken maar

moderne cellulaire netwerken bieden ook diensten aan die te maken hebben met het uitwisselen

van boodschappen. Deze boodschappen variëren van eenvoudige tekst boodschappen (SMS) tot

multimedia boodschappen (MMS) die foto’s of zelfs filmpjes bevatten. Cellulaire gebruikers kunnen

tegenwoordig ook surfen op het internet en hun mail checken. Toch zijn deze diensten niet de reden

van de populariteit van deze cellulaire netwerken. Hun belangrijkste troef is het feit dat we overal

bereikbaar zijn. Niet enkel in de stad maar ook op het platteland en zelfs in het buitenland, gebruik

makend van roaming3 diensten.

2. Waarom IMS Het idee van IMS is om internetdiensten overal en op elk tijdstip aan te kunnen bieden, gebruik

makende van de cellulaire technologieën. We hebben echter net vermeld dat cellulaire netwerken

reeds een brede waaier van diensten aanbieden. Een cellulaire gebruiker kan toegang tot het

internet verkrijgen aan de hand van een dataverbinding en op die manier gebruik maken van bijna

alle internetdiensten. Waarom hebben we dan IMS nog nodig?

Om dit duidelijk te maken, leggen we eerst de twee verschillende domeinen uit in 3G-netwerken,

namelijk het circuit-switched en packet-switched domein. Het circuit-switched domein is afkomstig

3 Roaming is een algemene term in draadloze telecommunicatie waarbij een bepaalde dienst wordt voorgezet

hoewel de gebruiker zich niet in het netwerk bevindt waarin deze geregistreerd staat. Voor verdere informatie over roaming zie (ETSI, 2004)


uit de technologie van 2G-netwerken. De circuits in dit domein worden geoptimaliseerd voor het

transport van spraak en video maar kunnen ook gebruikt worden voor het versturen van

boodschappen. Circuit-switched netwerken worden reeds gebruikt sinds de geboorte van de

telefonie maar worden steeds meer vervangen door de meer efficiënte packet-switched technologie.

Het packet-switched domein biedt IP-toegang aan tot het internet. Terwijl 2G terminals als een

modem acteren om IP-pakketten over een circuit te sturen, gebruiken 3G terminals “native” packet-

switched technologie voor hun datacommunicatie. Dit heeft tot gevolg dat datatransmissies veel

sneller zijn en dat de gebruikte bandbreedte voor internet toegang drastisch vergroot. Zo kan elke

gebruiker een VoIP client installeren op zijn 3G-terminal en VoIP-gesprekken (die een aanzienlijke

hoeveelheid bandbreedte vereisen) opzetten over het packet-switched domein. Zo’n gebruiker kan

bovendien gebruik maken van alle diensten die dienstverleners op het internet aanbieden zoals

voicemail en videoconferencing.

Opnieuw stelt zich de vraag: waarom hebben we IMS nodig wanneer al deze internetdiensten reeds

beschikbaar zijn voor 3G-gebruikers via het packet-switched domein? Het antwoord is drieledig: QoS

(Quality Of Service), charging en integratie van verschillende diensten.

Een belangrijke eigenschap van het packet-switched netwerk is dat het een best-effort service

aanbiedt zonder QoS. Dat betekent dat er geen garantie wordt geboden op de hoeveelheid

bandbreedte die de gebruiker ter beschikking krijgt en op de vertraging die de pakketten zullen

oplopen. Op die manier kan een VoIP-gesprek drastisch in kwaliteit schommelen tijdens de duur van

het gesprek. Een van de bestaandsredenen van MS is het aanbieden van QoS die noodzakelijk is voor

real-time multimediasessies.

Een tweede bestaansreden van IMS is het in staat zijn om multimediasessies op een gepaste manier

aan te rekenen. Bij gewone 3G netwerken betalen gebruikers vaak per byte omdat de operator zich

niet bewust is van de inhoud van de data die wordt verstuurd. Wanneer de operator zich echter wel

bewust is van deze inhoud kan hij datatransmissie op verschillende manieren aanrekenen. VoIP

gesprekken kunnen bijvoorbeeld op basis van tijdsduur aangerekend worden, ongeacht het aantal

bytes dat verstuurd wordt. IMS verplicht geen specifiek business model maar laat de operatoren vrij

om de manier waarop ze verschillende diensten aanrekenen zelf in te vullen.

Het aanbieden van geïntegreerde diensten aan gebruikers is een derde grote bestaansreden voor

IMS. Hoewel grote contentaanbieders en operatoren sommige multimediadiensten volledig zelf

ontwikkelen, willen operatoren zichzelf niet beperkten tot deze diensten. Ze willen de mogelijkheid

hebben om diensten te gebruiken die ontwikkeld zijn door derde partijen. Stel dat een operator een

voicemail service heeft ontwikkeld die spraakboodschappen kan opslaan en een derde partij

ontwikkelde een service om tekst om te zetten in spraak. Als de operator de tekst-naar-spraak

service koopt van de derde partij kan hij spraakversies van binnenkomende tekst boodschappen

aanbieden aan blinde gebruikers. IMS definieert standaard interfaces die gebruikt moeten worden

door service ontwikkelaars. Op die manier wordt de samenwerking tussen verschillende services

vergemakkelijkt en kunnen operatoren voordeel halen uit het feit dat ze niet gebonden zullen zijn

aan één verkoper om nieuwe services te kunnen ontwikkelen.


3. Algemene principes van de IMS-architectuur In dit onderdeel zullen we een beeld geven van de design principes die achter de IMS-architectuur en

zijn protocols liggen. Bovendien zullen we kort het IMS-netwerk bekijken en de verschillende

netwerk elementen bespreken.

3.1 Van circuit-switched naar packet-switched

Laten we eerst even bekijken hoe cellulaire netwerken geëvolueerd zijn van circuit-switched naar

packet-switched netwerken en hoe IMS de volgende stap in deze evolutie is. Het derde generatie

partnership project (3GPP) (3GPP, 1998) gebruikt de GSM (GSM Association, 1987)specificaties als

een design basis voor een 3G mobiel systeem. GSM heeft twee manieren van opereren: circuit-

switched en packet-switched. De twee 3G domeinen zijn op deze GSM-modes van opereren

gebaseerd.

Circuit-switched netwerken hebben twee verschillende “planes”: het signaling plane en het media

plane. Het signaling plane omvat de protocollen die gebruikt worden om een circuit op te zetten

tussen terminals. Ook het oproepen van services gebeurt in het signaling plane. Het media plane

bevat de data die verstuurd wordt over het circuit-switched pad tussen de terminals. Signaling en

media planes volgden hetzelfde pad in de eerste circuit-switched netwerken. Op een gegeven

moment is men in PSTN (ITU-T, 1992) gestart met het definiëren van verschillende paden voor het

signaling en media plane. In IMS worden signaling en media paden ook volledig gescheiden

gehouden. De enige gebruikers die zowel signaling als media moeten behandelen zijn IMS-terminals.

Geen enkele netwerkknoop hoeft beiden te behandelen.

Het GSM packet-switched netwerk, ook wel gekend als GPRS (Bates, 2001)was de basis voor het

packet-switched domein van 3GPP. Ondanks verschillende programma’s (WAP) die ontwikkeld

werden voor het verhogen van het gebruik van dit domein, heeft men toch niet de interesse van het

grote publiek kunnen wekken. Zo kon men de enorme kosten voor het opstellen van packet-switched

mobiele netwerken niet rechtvaardigen.

3.2 Vereisten voor IMS

Net voor de geboorte van IMS was de situatie die de operatoren onder ogen zagen dus niet

bemoedigend. Spraak over circuit-switched netwerken was een gewoonte geworden en operatoren

konden moeilijk extra winst halen uit het aanbieden en aanrekenen van telefoongesprekken.

Bovendien waren packet-switched diensten nog niet echt ingeburgerd en hier konden operatoren

dus ook niet veel geld aan verdienen.

Operatoren hadden bijgevolg nieuwe attractieve diensten nodig om gebruikers aan te trekken tot het

packet-switched domein. Het mobiele internet moest dus aantrekkelijker worden gemaakt voor zijn

gebruikers. Op deze manier ontstond IMS en met de visie uit het eerste deel van dit hoofdstuk in

gedachten begonnen materiaalverkopers en operatoren het IP Multimedia Subsystem te ontwerpen.

IMS mikt dus op:

• Het combineren van de laatste trends in technologie

• Het waarmaken van het mobiele internet paradigma

• Het creëren van een gemeenschappelijk platform voor het ontwikkelen van diverse

multimediadiensten


• Het creëren van een mechanisme om het gebruik van packet-switched netwerken te

vergroten.

Laten we nu de vereisten bekijken die geleid hebben tot het ontwikkelen van IMS. In deze

requirements wordt IMS gedefinieerd als een architecturaal raamwerk dat gecreëerd werd voor het

leveren van IP multimediadiensten aan eindgebruikers. Dit raamwerk moet voldoen aan de volgende

vereisten:

• Ondersteuning voor het opzetten van IP-multimediasessies

• Ondersteuning voor een mechanisme om te onderhandelen over Quality of Service(QoS)

• Ondersteuning voor samenwerking tussen het Internet en circuit-switched netwerken

• Ondersteuning voor roaming

• Ondersteuning voor strenge controle, opgelegd door de operator met betrekking tot de

diensten die aan de eindgebruiker worden geleverd.

• Ondersteuning voor snelle ontwikkeling van nieuwe diensten zonder voorafgaande

standaardisatie

3.3 Protocols in IMS

IMS maakt gebruik van verschillende reeds bestaande protocols om de communicatie in het signaling

en media plane te verzorgen. Het belangrijkste protocol in het signaling plane is het SIP (Session

Initiation Protocol). Het feit dat SIP een end-to-end protocol is en vele eigenschappen erft van de

meest succesvolle internet protocols (SMTP (Postel, 1982) en http (Berners-Lee, Fielding, & Frystyk,

1996)) heeft ervoor gezorgd dat SIP als signaling protocol werd verkozen boven H323 en andere

signalling protocols. In het volgende hoofdstuk geven we een uitgebreid overzicht van SIP.

Een ander protocol dat gebruikt wordt in het signaling plane is het Diameter protocol (Calhoun,

Loughney, Guttman, Zorn, & Arkko, 2003). Dit protocol wordt gebruikt voor authenticatie,

autorisatie en accounting, wat erop neerkomt dat de communicatie tussen netwerk knopen en de

HSS aan de hand van dit protocol zal gebeuren.

In het media plane worden verschillende protocols gebruikt voor het overbrengen van data. Welk

protocol er gebruikt wordt hangt af van de applicatie. Voor real-time toepassingen zoals Voice over

IP wordt vaak het RTP (Schulzrinne, Casner, Frederick, & Jacobson, 1996) protocol gebruikt.

7 | Hoofdstuk 3 - Het Session Initiation Protocol

Hoofdstuk 3: Het Session Initiation

Protocol (SIP)

In dit hoofdstuk zullen we een overzicht geven dan het Session Initiation Protocol. SIP wordt in het

IMS gebruikt voor de communicatie in het signaling plane. Meer specifiek gebruiken we SIP voor het

opzetten en afbreken van Voice over IP gesprekken. We baseren ons in dit hoofdstuk op informatie

uit (Demeester & Pickavet, 2006), (Rosenberg, et al., 2002) en (Banerjee K. , 2005).

1. Situering Het doel van VoIP is het verzenden van een spraaksignaal over het internet met een acceptabele

kwaliteit. In tegenstelling tot het vaste telefonie netwerk zullen we hier geen gebruik maken van

gereserveerde ciruits die een vaste brandbreedte ter beschikking hebben. We groeperen de

spraakdata in pakketten die we afzonderlijk van bron naar bestemming sturen. Om een gesprek van

acceptabele kwaliteit te bekomen moeten we rekening houden met de specifieke problemen die we

tegenkomen bij het versturen van pakketten over het internet: delay, jitter, pakketverlies,

connection less4 netwerk,… . Voor het opzetten, afbreken en wijzigen van de call hebben we

controlefuncties nodig. De pakketten die verzonden worden om deze controlefuncties uit te oefenen

maken deel uit van het “control plane”.

Control Voice

SDP

SIP RTP/RTCP

TCP/UDP UDP

IP

Data-Link

Fysische Laag

Bovenaan de protocol stack van het control plane zien we het SDP (Session Description Protocol)

protocol. Dit protocol wordt gebruikt om de sessie te beschrijven. In het geval van VoIP hebben we

het dus over een audio-sessie. Eventueel kan hier ook de beschrijving van een video-sessie aan

toegevoegd worden. In deze beschrijvingen worden onder andere het IP-adres en de poort

gedefinieerd waar pakketten moeten naartoe gestuurd worden. Ook het protocol waarmee de data

zullen worden verstuurd, wordt vermeld in deze SDP-boodschap. Vaak gebruiken we hiervoor het

RTP (Real-time Transfer Protocol) protocol.

4 In tegenstelling tot de klassieke telefonie: connection oriented. Hierbij gaan we op voorhand een verbinding

opzetten en bandbreedte reserveren voor ons telefoongesprek.


Eenvoudig voorbeeld SDP-boodschap

v=0 o=- 1073055600 1073055600 IN IP4 10.10.5.50 s=- c=IN IP4 10.10.5.50 t= 23456 23456 m=audio 5000 RTP/AVP 112 113 a =rtpmap:112 L16/48000/2 a=rtmap:113 DAT12/32000/4 a=fmtp:113 contents:DV L/R/C/WO

We zien in dit voorbeeld dat we audio kunnen verzenden. Naar het IP-adres 10.10.5.50 op poort

5000. Deze audio wordt verzonden aan de hand van RTP-payload type 112 en 113. Payload type 112

zendt L16 audio, payload type 113 zendt DAT12 audio. DAT12 audio bevat 4 kanalen audio: links,

rechts, centraal en woofer.

Meteen onder SDP hebben we het Session Initiation Protocol. SIP is een application-layer protocol

waarmee men multimedia sessies (zoals een VoIP gesprek) kan opzetten, wijzigen en beëindigen. SIP

maakt hierbij gebruik van SDP om de parameters van het gesprek te specificeren. Een SIP-boodschap

bestaat enerzijds uit een verzameling van headers die gedefinieerd worden door het SIP-protocol en

anderzijds uit de inhoud van de boodschap: de SDP-sessie beschrijving.

2. Algemeen Zoals eerder gezegd is het doel van het SIP-protocol het creëren en onderhouden van een sessie. Met

een sessie bedoelen we uitwisseling van data tussen twee of meerdere deelnemers. Deelnemers aan

een sessie kunnen zich verplaatsen tussen verschillende eindstations, geadresseerd worden door

meerdere namen en bovendien communiceren gebruik makend van verschillende media (soms zelfs

tegelijkertijd zoals in het geval van een videogesprek).

SIP ondersteunt de volgende facetten van het opzetten en beëindigen van multimediasessies:

• User location: het bepalen van waar de eindgebruiker zich op het huidige moment bevindt

• User availability: het bepalen of de gebelde partij deel wil/kan nemen aan de communicatie

• User capabilities: vaststellen welke media en media parameters5 er gebruikt kunnen worden

• Session setup: het instellen van session parameters bij de gebelde en bellende partij

• Session management: omvat de transfer en het beëindigen van sessies, wijzigen van parameters van de sessie en het uitvoeren van services

3. Terminologie Voor we uitleggen hoe het SIP-protocol in zijn werk gaat, geven we een korte beschrijving van enkele

vaak gebruikte termen.

Uniform Resource Identifiers bieden een eenvoudige en uitbreidbare manier om resources zoals

gebruikers of servers te identificeren. Een URI kan verder nog geklasseerd worden als een locator,

een naam of beide. Een Uniform Resource Locator refereert naar het deel van de URI dat resources

5 Bijvoorbeeld welke codec’s gebruikers ter beschikking hebben voor het comprimeren van voice-data.


identificeert aan de hand van een representatie van hun primair toegangsmechanisme (vb: netwerk

locatie). De Uniform Resource Name wijst naar het deel van de URI dat ervoor moet zorgen dat hij

globaal uniek en persistent blijft.

Een address-of-record is een SIP-URI die naar een domein met een location service wijst die een URI

kan mappen op een andere URI waar de gebruiker beschikbaar kan zijn. Vaak is deze AOR het

publieke adres van de gebruiker en de URI waarop hij gemapt wordt het huidige IP-adres van deze

gebruiker. We beschouwen als voorbeeld de SIP-URI “sip:[email protected]” . Het is duidelijk dat

atlanta.com het domein is waar de location service zich bevindt en de URI kan omvormen naar

“sip:[email protected]” waarbij 192.168.1.100 het IP-adres is waar Alice zich op dit moment heeft

aangemeld.

Een server is een netwerkelement dat aanvragen ontvangt om ze te processen en een passend

antwoord terug te sturen. Een User Agent is een logische entiteit die zowel als client als server

acteert. De client creëert en verstuurt nieuwe aanvragen. De rol van client is geldig voor de duur van

die transactie. Een User Agent Server genereert een antwoord op een ontvangen aanvraag. Hij kan

deze aanvraag accepteren, afwijzen of doorverwijzen.

Een proxy server is een tussenliggende entiteit die zowel server als client taken op zich neemt met als

doel aanvragen te sturen in naam van andere clients. Een proxy server vervult voornamelijk de rol

van router. Hierbij zal hij aanvragen proberen door te sturen naar entiteiten die zich dichter bij de

bestemming bevinden. Bovendien kunnen proxies ingezet worden om een bepaald beleid door te

voeren. Zo kunnen we een proxy zo instellen dat hij bepaalde gebruikers verhindert om een gesprek

op te zetten. Een proxy interpreteert aanvragen en herschrijft indien nodig specifieke delen ervan

voordat hij ze doorstuurt. Bovendien kan een proxy zowel in statefull- als stateless-mode werken.

Wanneer hij in stateless-mode acteert, zal hij alle informatie die hij heeft gebruikt voor het

doorsturen van een boodschap meteen verwijderen nadat de boodschap verzonden is. In statefull-

mode zal hij deze informatie onthouden engebruiken om latere boodschappen die met deze

boodschap te maken hebben te interpreteren.

Een redirect server is een user agent server die 3XX-antwoorden genereert als antwoord op

aanvragen die hij ontvangt. Een 3XX-antwoord vertelt de client dat hij zich moet richten tot een

andere URI.

De registrar server accepteert REGISTER aanvragen en plaatst de informatie die hij hierbij ontvangt

(vb: het IP-adres van de computer waar de gebruiker zich op heeft aangemeld) in de location service

van het domein dat hij behandelt. De location service wordt door een SIP redirect- of proxyserver

gebruikt om informatie op te vragen over de huidige locatie van de gebelde partijen. Het bevat een

lijst van address-of-record-sleutels die verbonden zijn met nul of meerdere contact adressen. Een

REGISTER aanvraag zorgt voor een update van een element uit deze lijst. Merk wel op dat het

protocol gebruikt voor de uitwisseling van informatie tussen proxy/redirect/registrar en de location

service niet gespecificeerd is door SIP. We zullen verder dus ook dummy-boodschappen gebruiken

indien deze communicatie verder nog aan bod komt.


4. SIP-Boodschappen

4.1 SIP-Aanvraag

De layout van een SIP-aanvraag is gestandaardiseerd aan de hand van enkele velden. Men heeft

hierbij hetzelfde formaat gekozen als boodschappen van het http-protocol. De onderstaande figuur

illustreert de samenstelling van de velden.

method SP URI SP Version CR/LF

Header field name : Value CR/LF

…


CR/LF

Message Body

De aanvraag lijn bevat de methode (REGISTER, INVITE, ACK,…), de Uniform Resource Identifier die de

bestemming van de boodschap specificeert (vb: de SIP-URI van de gebruiker die je wil bellen) en de

versie van het SIP-protocol (in ons geval steeds SIP/2.0). De velden onder de aanvraaglijn noemen we

de headerlijnen. De aanwezigheid van specifieke headervelden varieert van aanvraag tot aanvraag.

Enkele voorbeelden van headers zijn:

• To: de logische identiteit van de ontvanger van de aanvraag

• From: de logische identiteit van de verzender van de aanvraag

• Call-ID: unieke identifier om een reeks boodschappen te groeperen

• CSeq: wordt gebruikt om transacties te identificeren en te ordenen

• Via: definitie van het transportprotocol dat we gebruiken voor deze aanvraag (UDP, TCP,…)

en identificatie van het IP-adres en de poort waar het antwoord naartoe moet gezonden

worden.

• Contact: contact SIP-adres van de verstuurder van de aanvraag

• …

De message body is optioneel en bevat vaak de SDP beschrijving maar kan vaak ook om het even

welke MIME header bevatten zoals een foto, betalingsinfo,… .

4.2 SIP-Antwoord

Een SIP-antwoord is zeer gelijkend aan een SIP-aanvraag maar er worden andere velden gebruikt. De

antwoordlijn start met de versie van het SIP-protocol en geeft vervolgens statusinformatie weer via

een status code en een uitdrukking die de code uitlegt. Hier volgt een lijst met mogelijke statuscodes

• 1xx: Informative (vb: 100 trying, 181 Ringing,…)

• 2xx: Success (vb: 200 OK)

• 3xx: Redirection (vb: 301 Moved Permanently)

• 4xx: Client error (vb: 401 Unauthorized)

• 5xx: Server error (vb: 500 internal server error)

• 6xx: Global Failure (vb: 600 busy everywhere)


Daarna zijn er net zoals bij een SIP-aanvraag verschillende headerlijnen mogelijk. Het laatste deel van

het SIP-antwoord bevat de gevraagde informatie (vb: SDP van de ontvanger). De onderstaande figuur

illustreert de samenstelling van een SIP-antwoord.

Version SP Status Code SP phrase CR/LF


…


CR/LF

Entity Body

5. Registratie Om het opzetten, afbreken of wijzigen van een gesprek te ondersteunen gebruikt SIP verschillende

types SIP-aanvragen en SIP-antwoorden. Enkele voorbeelden van SIP-aanvraag types zijn INVITE,

ACK, STATUS en REGISTER.

De combinatie van een SIP-aanvraag en het daarop volgende SIP-antwoord noemen we een SIP-

transactie. De opeenvolging van verschillende SIP-transacties die samen één geheel vormen, zoals

het opzetten van een VoIP sessie, noemen we een SIP-dialoog. De registratieprocedure is slechts een

SIP-transactie vermits ze slechts uit een SIP-aanvraag en het daaropvolgende SIP-antwoord bestaat.

Om user location te ondersteunen moet elke SIP-gebruiker zich, telkens hij van locatie verandert,

registreren bij een registrar server. Hiervoor maakt hij gebruik van een REGISTER-aanvraag. In een

eenvoudig voorbeeld tonen we hoe deze registratie procedure in zijn werk gaat.

Stel dat Alice met Bob wil communiceren. Alice bevindt zich in het atlanta.com-netwerk en Bob in het

biloxi.com-netwerk. Alice en Bob zullen zich eerst registreren en doen dit door een REGISTER-

aanvraag te sturen naar hun respectievelijke SIP-registrar server. Voor de eenvoud bekijken we enkel

de uitwisseling van boodschappen voor de registratie van Alice. De registratie van Bob gebeurt

analoog.

Figure 6: Registratie Alice


Alice stuurt dus een REGISTER-aanvraag naar de registrar-server van atlanta.com (1). Deze REGISTER-

aanvraag bevat verschillende velden die alle informatie bevatten die nodig is om ervoor te zorgen dat

andere gebruikers Alice kunnen vinden. De registar-server zal deze informatie opslaan in de Location

service databank (2) en dit bevestigen aan Alice aan de hand van een OK-antwoord(3).

1. REGISTER 2. Opslaan data 3. OK

REGISTER sip:atlanta.com SIP/2.0

From: sip:[email protected]

To: sip:[email protected]

Contact:<sip:[email protected]>

[email protected] SIP/2.0 200 OK

We zien dat zowel het From- als het To-veld de SIP-URI bevatten van Alice. Bovendien zien we in het

Contact-veld de huidige locatie van Alice. Merk op dat we voor de eenvoud de boodschappen niet

volledig hebben weergegeven.

Figure 7: Versturen Invite

Wanneer Bob nu een gesprek wil opzetten met Alice. Zal hij een INVITE (4) naar zijn proxy-server

sturen. Het adres van deze proxy vindt hij via DNS of een configuratiebestand. De proxy zal op zijn

beurt via DNS de location service van atlanta.com opzoeken en deze vragen waar [email protected]

zich momenteel bevindt (5). De location service geeft het huidige IP-adres van [email protected]

aan de proxy (6) en deze kan uiteindelijk de INVITE naar Alice doorsturen (7).6

6 De manier van werken die we hier gebruiken heet de Redirect methode. Een andere mogelijkheid is dat de sip

server van boston.com de INVITE doorstuurt naar de sipserver van atlanta.com (welke hij via normale DNS heeft gevonden). De sip server van atlanta.com zal de INVITE dan uiteindelijk aan Alice bezorgen.

4. INVITE 5. Waar is Alice 6. Antwoord 7. INVITE

INVITE [email protected] SIP/2.0


From: sip:[email protected]

Call-ID:call1

Contact: sip:[email protected]

[email protected]? 192.168.1.100 Idem boodschap 4


Na enkele antwoorden aanvraagboodschappen zal de communicatie tussen Bob en Alice starten.

Hierbij zullen de user agents van Alice en Bob rechtstreeks informatie uitwisselen en niet meer via

hun respectievelijke SIP-servers werken7. Zo zal het mogelijk zijn voor Bob en Alice om hun VoIP

gesprek op te zetten. Merk wel op dat het de registrar, location service database en de proxy

logische functies zijn. In praktijk worden ze vaak op een zelfde server geimplementeerd.

Het is nu duidelijk dat de REGISTER-aanvraag voor user mobilitity zorgt. Wanneer een gebruiker een

SIP-applicatie opstart op een computer zal deze applicatie meteen een REGISTER-aanvraag versturen

met de gebruikersnaam van de gebruiker en het IP-adres van de computer. Zo wordt de informatie

over de huidige locatie van de gebruiker voortdurend geupdate en is hij overal bereikbaar.

6. Call Setup In wat volgt geven we een voorbeeld hoe een gesprek wordt opgezet aan de hand van SIP-

boodschappen. Eerst geven we een schets van de situatie: Alice (sip:[email protected]) bevindt zich

in het atlanta.com domein. Bob (sip:[email protected]) in het biloxi.com domein. De toewijzing van de

IP-adressen is weergegeven in Figure 8. Merk op dat we in een testopstelling private adressen

gebruiken. In een reële situatie hoeven de proxy servers ook niet in hetzelfde domein als Alice of Bob

te liggen.

Figure 8: Call Setup netwerk

We onderstellen nu dat Alice naar Bob wil bellen. Opdat Bob gevonden zou kunnen worden door

andere SIP-gebruikers moet hij zich eerst registreren bij de registrar van biloxi.com. Deze registrar is

onderdeel van de biloxi.com server.

7 Dit is echter niet altijd zo. Indien we het Record-Route veld gebruiken kunnen we ervoor zorgen dat een

bepaalde SIP server alle pakketten van de communicatie kan inspecteren en eventueel wijzigen. We zullen in ons project gebruik maken van deze Record-route. Meer info volgt verder in de tekst.


REGISTER

REGISTER sip:registrar.biloxi.com SIP/2.0

Via: SIP/2.0/UDP 192.168.2.100:5060


From: sip:[email protected];tag=001

Call-ID: [email protected]

CSeq: 1 REGISTER

Contact: <sip:[email protected]>

Expires: 7200

Content-Length: 0

Alice zal de call-setup starten door een uitnodiging tot gesprek voor Bob (INVITE) naar haar proxy

server te sturen in atlanta.com. De atlanta.com server zal deze aanvraag doorsturen naar de proxy

server van Bob8. Tegelijkertijd zal hij aan Alice laten weten dat de INVITE-boodschap wordt verwerkt

door een SIP-antwoord terug te sturen. De biloxi.com server zal een gelijkaardige actie ondernemen.

Hij stuurt de INVITE door naar Bob en stuurt een trying-antwoord naar atlanta.com. We merken

hierbij wel op dat de proxy servers de INVITE-boodschap wel zullen aanpassen. Ze voegen steeds een

Via- veld toe. Op die manier kan men op een hop-by-hop basis de weg terug naar Alice vinden.

INVITE Trying


Via: SIP/2.0/UDP 192.168.1.100:5060



Call-ID:call1

Cseq: 1 INVITE


Content-Type: application/sdp

Content-Length: 142

(hier komt SDP van Alice)

SIP/2.0 100 Trying Via: SIP/2.0/UDP 192.168.1.100:5060 To: sip:[email protected] From: sip:[email protected] Call-ID: call1 Cseq: 1 INVITE Contact: sip: [email protected] Content-length: 0

Wanneer de INVITE uiteindelijk aankomt bij Bob zal de telefoon van Bob beginnen rinkelen. Op dat

moment wordt er een 180 Ringing antwoord gestuurd naar Alice (via de twee SIP-servers). Wanneer

Bob zijn telefoon opneemt wordt er een 200 OK antwoord gestuurd naar Alice (wederom via de twee

SIP-servers). Deze OK-boodschap bevat ondermeer de SDP informatie van Bob die nodig is om een

akkoord te sluiten over welk audio-codec en dergelijke er gebruikt zal worden tijdens het gesprek.

Alice zal bevestigen aan Bob dat zij deze boodschap heeft ontvangen door een ACK rechtstreeks naar

Bob te sturen. Vanaf dit moment worden de SIP-servers dus niet meer in de communicatie

betrokken9.

8 Merk op dat we in dit voorbeeld niet volgens de redirect-methode werken.

9 Tenzij we met het Record-route veld werken. Maar in dit voorbeeld laten we dit achterwege.


Ringing OK

SIP/2.0 180 Ringing

Via: SIP/2.0/UDP 192.168.2.1:3040;branch=002; Via: SIP/2.0/UDP;192.168.1.1:2030;branch=001

Via: SIP/2.0/UDP 192.168.1.100:5060

To: Bob <sip:[email protected]>;tag=002

From: Alice <sip:[email protected]>;tag=001

Call-ID: call1

Contact: <sip:[email protected]>

CSeq: 1 INVITE

Content-Length: 0

SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.2.1:3040;branch=002 Via: SIP/2.0/UDP 192.168.1.1:2030;branch=001 Via: SIP/2.0/UDP 192.168.1.100:5060 To: sip:[email protected];tag=002 From: sip:[email protected];tag=001 Call-ID:call1 Cseq: 1 INVITE Contact: sip:[email protected] Content-Type: application/sdp Content-Length: 131 (Hier komt SDP van Bob)

ACK

ACK [email protected] SIP/2.0

Via: SIP/2.0/UDP 192.168.1.100:5060

To: sip:[email protected];tag=002


Call-ID:call1

Cseq: 1 ACK


Zodra de ACK door Bob is ontvangen, kan de communicatie starten. Deze communicatie bestaat uit

één of meerdere RTP-mediasessies.

Wanneer Bob de sessie wil stoppen verstuurt hij een BYE aanvraag naar Alice. Deze aanvraag wordt

rechtstreeks verstuurd en Alice zal het einde van de sessie bevestigen met een 200 OK antwoord.

BYE OK

BYE sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 192.168.1.100:5060

From: Bob <sip:[email protected]>;tag=002

To: Alice <sip:[email protected]>;tag=001

Call-ID: call1

CSeq: 1 BYE

Content-Length: 0

SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.100:5060 From: Bob <sip:[email protected]>;tag=002 To: Alice <sip:[email protected]>;tag=001 Call-ID: call1 CSeq: 1 BYE Content-Length: 0

Figure 9 geeft het volledige sequentiediagram weer van een call setup.


Figure 9: Sequentie Diagram Call Setup


7. Record-Route Zoals reeds eerder vermeld communiceren de twee user agents Bob en Alice rechtstreeks met elkaar

vanaf het moment dat Bob het gesprek accepteert (200 OK). Er is echter een mogelijkheid om ervoor

te zorgen dat één of meerdere tussenliggende servers alle SIP-aanvragen en antwoorden die tussen

Alice en Bob verzonden worden, kunnen zien en inspecteren.

Wanneer de twee proxy servers in bovenstaand voorbeeld de SIP-boodschappen die tussen Alice en

Bob verstuurd worden willen zien gedurende de hele sessie moeten ze een veld toevoegen aan de

initiële INVITE. Dit veld, Record-Route genaamd, bevat de URI die wijst naar de hostname of het IP-

adres van de proxy die zich in het pad van de SIP-boodschappen wil plaatsen. Wanneer Bob de

INVITE ontvangt met het Record-Route-veld zal hij de informatie opslaan voor de duur van de sessie.

Ook Alice zal deze informatie ontvangen omdat het Record-Route-veld ook in de 200 OK-boodschap

wordt gekopieerd. Bob en Alice zullen dus op die manier te weten komen dat ze hun pakketten naar

de proxy servers moeten sturen in plaats van rechtstreeks naar elkaar.

INVITE OK


Via: SIP/2.0/UDP 192.168.1.100:5060



Call-ID:call1

Cseq: 1 INVITE


Record-Route:<sip:atlanta.com;1r>,<sip:biloxi.com;1r>

Content-Type: application/sdp

Content-Length: 142

(hier komt SDP van Alice)

SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.2.1:3040;branch=002 Via: SIP/2.0/UDP 192.168.1.1:2030;branch=001 Via: SIP/2.0/UDP 192.168.1.100:5060 To: sip:[email protected];tag=002 From: sip:[email protected];tag=001 Call-ID:call1 Cseq: 1 INVITE Contact: sip:[email protected] Record-Route:<sip:atlanta.com;1r>,<sip:biloxi.com;1r> Content-Type: application/sdp

Content-Length: 142

(hier komt SDP van Bob)

Figure 10 geeft de uitwisseling van boodschappen weer wanneer we werken met het Record-route-

veld.


Figure 10: Sequentie Diagram Record Route

19 | Hoofdstuk 4 - Voice over IP

Hoofdstuk 4: Voice over IP (VoIP)

Na een algemeen overzicht van IMS en een bespreking van SIP, het signaling protocol van IMS, kijken

we nu naar het media plane van IMS. Voice over IP (VoIP) is een mogelijke toepassing die door IMS

ondersteund wordt en waar we in deze thesis gebruik van zullen maken. In dit hoofdstuk lichten we

VoIP kort toe en daarbij vermelden we de eisen aan welke een netwerk moet voldoen om VoIP te

kunnen ondersteunen. Vervolgens zullen we een overzicht geven van het Real-time Transport

Protocol dat gebruikt wordt om de data van een VoIP-gesprek doorheen het media plane van IMS te

sturen. We baseren ons op gegevens uit (Schulzrinne, Casner, Frederick, & Jacobson, 1996),

(Demeester & Pickavet, 2006), (NeoNova bv, 2006), (OzVoIP.com, 2004)

1. Inleiding In tegenstelling tot de klassieke manier van telefoneren maken we bij VoIP gebruik van een

connectionless verbinding in een packet-switched netwerk: het internet. Dit betekent dat we op

voorhand geen bandbreedte zullen reserveren in het pad tussen de twee gebruikers. Bovendien

splitsen we het spraaksignaal op en versturen we het in IP-pakketten over het internet.

Door het feit dat we op een pakketgebaseerde manier te werk gaan, zullen we veel efficiënter

gebruik maken van de beschikbare bandbreedte. Bij een connection-oriented verbinding (zoals in het

circuit-switched domein van de klassieke telefonie) zullen we een vaste hoeveelheid bandbreedte

voor een gesprek reserveren. Deze hoeveelheid kan niet meer gebruikt worden door andere

toepassingen. De hoeveelheid data die voor een gesprek moet verzonden worden is echter niet

constant (vb: stiltes in een gespek). Bijgevolg wordt de gereserveerde bandbreedte voor het grootste

deel van de tijd niet volledig benut. Bij VoIP zullen we geen bandbreedte reserveren en dus enkel de

hoeveelheid bandbreedte innemen die effectief nodig is om de pakketten met spraakdata te

verzenden.

Bij klassieke telefonie is het bovendien noodzakelijk dat ieder telefoontoestel een fysieke eigen

aansluiting bezit op een telefooncentrale. Dit maakt het moeilijk om een toestel te verplaatsen, de

lijn moet namelijk mee verplaatst worden. Bij VoIP maakt het in principe niet uit waar het toestel of

de softphone10 aangesloten is op het netwerk. Dit maakt dat VoIP een stuk flexibeler is dan de

klassieke variant.

Net zoals IMS houdt VoIP het signalling en media plane gescheiden. Binnen IMS zullen we SIP

gebruiken voor het opzetten, wijzigen en afbreken van VoIP-gesprekken (signalling plane).

2. Eisen voor het netwerk Om de kwaliteit van een VoIP gesprek te kunnen garanderen moet het netwerk aan enkele vereisten

voldoen. De belangrijkste vereiste is dat het netwerk voldoende bandbreedte kan voorzien om een

VoIP-gesprek te ondersteunen. De bandbreedte die men nodig heeft voor het voeren van een VoIP-

gesprek hangt af van de codec die gebruikt wordt. Een codec zal bijdragen tot een efficiënt

bandbreedtegebruik door het spraaksignaal te comprimeren. Hierbij wordt een afweging gemaakt

10

Software programma dat telefoontoestel implementeert.


tussen gebruikte bandbreedte en kwaliteit van het spraaksignaal. De kwaliteit van een spraaksignaal

wordt uitgedrukt in een MOS score11.

Table 1 geeft de overzicht van enkele codecs, hun MOS score en hun vereiste bandbreedte.

Codec MOS-score Vereiste Bandbreedte (Kbps)

G.711 (64 Kbps) 4,1 87,2

G.726 (32 Kbps) 9,85 55,2

G.729 (8 Kbps) 3,92 31,2

GSM (13 Kbps) 3.85 35

Table 1: Bandbreedte en MOS-score van VoIP codecs

Als we de vereiste bandbreedte vergelijken met de maximale beschikbare bandbreedte voor

verschillende draadloze technologieën (Table 2) zien we dat zowel GPRS/UMTS, EDGE als WLAN

(802.11b/g) over voldoende bandbreedte beschikken om VoIP-gesprekken te ondersteunen.

Technologie Maximaal beschikbare bandbreedte

GPRS/UMTS 384 Kbps

EDGE 200 Kbps

WLAN (wifi of 802.11b/g) 11 Mbps (b), 54 Mbps(g)

Table 2: Maximale bandbreedte voor verschillende draadloze technologieën

De bandbreedte die deze verschillende technologieën ter beschikking stellen wordt echter over

verschillende diensten verdeeld. Het IP-protocol is een best-effort protocol wat betekent dat het

geen enkele garantie biedt op het afleveren van een pakket en de eventuele vertraging ervan. Dit is

niet toelaatbaar voor real-time toepassingen zoals VoIP. Niet alleen moeten we zekerheid hebben

dat (bijna) alle pakketten afgeleverd worden, bovendien mogen deze pakketten geen te grote

vertraging oplopen.

Aan de hand van de type of service (ToS) bit van de IP-header kan men er wel voor zorgen dat

pakketten van real-time toepassingen, zoals VoIP, voorrang krijgen op andere pakketen wanneer ze

door een router verwerkt worden. Dit is echter niet voldoende. Om ervoor te zorgen dat het

kwaliteitsniveau van het spraaksignaal hoog genoeg blijft zal men verschillende

voorzorgsmaatregelen treffen. Een van die maatregelen is het Real-time Transport Protocol (RTP).

11

Score van 0 tot 5 om de kwaliteit van een gesprek aan te duiden.


3. Real-Time Transport Protocol (RTP) In deze sectie geven we een korte situering van het RTP-protocol en bespreken we de RTP-header.

We baseren ons hierbij op de informatie uit (Schulzrinne, Casner, Frederick, & Jacobson, 1996) en

(Demeester & Pickavet, 2006).

3.1 Situering

Zoals we reeds vermeldden in de inleiding van dit hoofdstuk gebruiken we SIP voor het opzetten,

wijzigen en afbreken van VoIP-gesprekken. Nu kijken we naar de manier waarop de pakketten met

spraakdata over het internet worden verstuurd. Hierbij houden we in het achterhoofd dat vertraging

van pakketten en het verlies van pakketten nefast is voor de kwaliteit van ons VoIP gesprek. Vermits

vertragingen en pakket verlies vaak voorkomen bij het versturen van data over het internet zullen we

op verschillende manieren proberen de invloed van deze vertragingen en pakket verlies te beperken.

Om variatie in vertragingen, jitter genaamd, op te vangen gebruiken vele VoIP-clients een jitter-

buffer voor hun dataverkeer. Een voorbeeld van een toepassing om de invloed van pakketverlies te

verminderen is Forward Error Correction (FEC).

Het Real-time Transport Protocol biedt een hulp bij het detecteren en opvangen van beide

problemen. We zien dat RTP in de protocol stack net boven UDP staat. Dit betekent dat we na de

UDP header nog een extra RTP-header zullen plaatsten met informatie over de verzonden spraakdata

(de payload van het RTP-pakket). Door de informatie (zoals een timestamp en sequence number) in

deze extra header zullen we pakketten beter kunnen plaatsen in de stream en pakketverlies of

vertraging opvangen.

3.2 De RTP-header

We bespreken kort de samenstelling van de RTP-header en hoe sommige velden kunnen bijdragen

tot het opvangen van pakketverlies of vertraging.

Het version (V) veld geeft de versie van RTP weer. Het Padding (P) veld vertelt ons of er padding

gebruikt is in de payload. Padding is een vorm van opvullen van een pakket zodat we een totale

Signaling plane Media plane

SDP

SIP RTP/RTCP

TCP/UDP UDP

IP

Data-Link

Fysische Laag

V P X CC M payload type sequence number

timestamp

SSRC

CSRC


grootte van het pakket krijgen, gelijk aan een veelvoud van de blokgrootte die bijvoorbeeld door

encryptie algoritmen wordt gebruikt. Dit veld is slechts 1 bit groot. Wanneer padding aanwezig is

wordt deze bit op 1 gezet. In het laatste octet van de padding staat hoeveel padding-octetten er

toegevoegd zijn en dus moeten genegeerd worden bij het interpreteren van de payload. De

eXtention (X) bit geeft aan of er eventuele uitbreidingen van het protocol gebruikt worden.

De CSRC count (CC) geeft aan hoeveel CSRC identifiers er nog volgen in de vaste header. Hij is 4 bit

groot en bijgevolg kunnen er maximaal 15 CSRC identifiers toegevoegd worden. De Marker (M) bit

geeft het belang aan voor de bovenliggende applicatie. Als hij gezet wordt, dan is het pakket van

belang voor deze applicatie. Het payload type identificeert de inhoud van de RTP payload en

definieert bijgevolg hoe het geïnterpreteerd moet worden door de applicatie.

De “sequence number” bestaat uit 16 bits en wordt met 1 verhoogd voor elk verzonden RTP-pakket.

Dit veld kan door de applicatie gebruikt worden om pakketten te ordenen en eventueel pakket

verlies te detecteren. Vermits elk pakket afzonderlijk verstuurd wordt (UDP) en er dus geen

verbinding wordt opgezet (connectionless) kunnen alle pakketten een andere route nemen van bron

naar bestemming. Bijgevolg kan het voorkomen dat een pakket dat later verstuurd wordt, eerder

aankomt. Het sequence number zorgt ervoor dat deze pakketten toch in de juiste volgorde aan de

applicatie kunnen afgeleverd worden. Bovendien duidt een ontbrekend sequence number op een

verloren pakket dat zal moeten opgevangen worden door het programma.

De timestamp geeft aan wanneer het eerste octet van het RTP data pakket werd gesampled. Dit

samplen moet gebeuren aan de hand van een klok met een resolutie die hoog genoeg is zodat ze

jitter bij het aankomen van pakketten kan detecteren. Vele voice codecs sturen geen data door

wanneer er stilte is aan die kant van de verbinding (om zo het dataverkeer zo laag mogelijk te

houden). Wanneer na de stilte het volgende pakket verzonden wordt, is de sequence number slechts

met 1 toegenomen. De ontvanger kan op die manier onmogelijk weten of er al dan niet een periode

van stilte is geweest aan de andere kant van de lijn. Door gebruik te maken van de timestamp weet

de ontvanger echter perfect op welk moment hij welk datapakket moet afspelen.

Figure 11 geeft een voorbeeld12 van het gebruik van de timestamp bij een voice stream met een

constante bitrate. Het geluid wordt gesampled aan 8 bits per 125µsec. Deze samples worden

gegroepeerd in RTP-pakketten van 160 bytes. Dit komt overeen met een periode van 20msec. De

timestamp wordt per pakket verhoogd met 160. Wanneer er een stilte valt van 20msec zal de

sequence nummer van het volgende pakket slecht met 1 zijn toegenomen maar de timestamp wordt

verhoogd met 320 zodat de ontvanger weet dat pakketten 3 en 4 niet meteen achter elkaar moeten

afgespeeld worden.

12

Gebaseerd op (Demeester & Pickavet, 2006)


Figure 11: Voorbeeld timestamp

Het SSRC-veld identificeert de synchronisation source. De identifier moet random gekozen zijn om te

voorkomen dat twee synchronisation sources binnen dezelfde RTP sessie dezelfde SSRC identifier

zouden hebben. De CSRC lijst kan 0 tot 15 elementen bevatten (bepaald door het CC-veld). Een

Contributing SouRCe draagt bij tot de creatie van de payload van dit RTP-pakket. Bijvoorbeeld

wanneer bij een audio pakket het geluid van verschillende gebruikers werd gemixt (vb:

groepsgesprek).

24 | Hoofdstuk 5 - De IMS-architectuur

Hoofdstuk 5: De IMS-architectuur

Nadat we in hoofdstuk 2 de situering en algemene principes van het IP Multimedia Subsystem

aanraakten, zullen we in dit hoofdstuk dieper ingaan op de architectuur. Daarbij geven we eerste en

algemene architectuur die we vervolgens zullen vereenvoudigen tot een architectuur die we in dit

onderzoek zullen gebruiken. Om dit hoofdstuk te besluiten beschrijven de rol van enkele belangrijke

netwerkcomponenten bij het opzetten van een VoIP-sessie. Voor de samenstelling van dit hoofdstuk

baseerden we ons op de volgende referenties: (Camerillo & Garcia-Martin, 2006), (Repiquet, 2005)

1. Algemene IMS-architectuur Voordat we dieper ingaan op de algemene architectuur van IMS moeten we in gedachten houden dat

3GPP geen knopen maar functies standaardiseert. Dit betekent dat de IMS-architectuur een

verzameling is van functies die onderling verbonden zijn via gestandaardiseerde interfaces. De

netwerkontwerpers zijn vrij om verschillende functies te combineren in één knoop, of één functie te

verdelen over verschillende knopen. Figure 12 geeft een overzicht van de IMS-architectuur zoals ze is

gestandaardiseerd door 3GPP. Ze bevat niet alle maar enkel de meest relevante interfaces die

gedefinieerd zijn volgens IMS.

Figure 12: Overzicht IMS-architectuur

Op de figuur zien we de netwerkelementen die deel uitmaken van het zogehete IP Multimedia Core

Network Subsystem.

• Één of meerdere gebruikersdatabanken, HSSen genaamd (Home Subscriber Servers) en SLFs

(Subscriber Location Functions)

• Één of meerdere SIP-servers die we gezamenlijk CSCFs noemen (Call/Session Control

Functions)

• Één of meerdere ASs (Application Servers)

• Één of meerdere MRFs (Media Resource Functions), elk van hen verder onderverdeeld in een

MRFC (Media Resource Function Controllers) en MRFP(Media Resource Function Processors)


• Één of meerdere BGCFs (Breakout Gateway Control Functions);

• Één of meerdere PSTN-gateways, elk van hen verder onderverdeeld in een SGW (Signaling

Gateway), een MGCF (Media Gateway Controller Function) en een MGW (Media Gateway)

Merk op dat deze figuur geen referentie bevat naar betalingsfuncties. Deze laten we achterwege

omdat ze van minder belang zijn voor ons onderzoek.

1.1 De databanken: HSS en SLF

De Home Subscriber Server is een centrale bewaarplaats voor gebruikersgerelateerde informatie.

Technisch gezien is de HSS een evolutie van de HLR (Home Location Register) uit het GSM netwerk.

De HSS bevat alle gebruikersgerelateerde inschrijvingsdata die nodig zijn voor het behandelen van

multimediasessies. Deze data bevatten ondermeer informatie over de locatie van de gebruiker,

beveiligingsinformatie (zowel authenticatie- als authorisatieinformatie), informatie over het profiel

van de gebruiker (voor welke diensten hij zich heeft ingeschreven,…) en de S-CSCF (Serving-CSCF) die

aan deze gebruiker werd toegewezen.

Een netwerk kan meer dan één HSS bevatten indien het aantal abonnees te groot is om door 1

enkele HSS behandeld te worden. In elk geval wordt alle data over één specifieke gebruiker binnen

éénzelfde HSS bewaard. Netwerken met slechts één HSS hebben geen SLF nodig. Netwerken met

meer dan één HSS vereisen er een.

De SLF is een eenvoudige databank die gebruikersadressen mapt op een HSS. Een knoop die de SLF

bevraagt met een gebruikersadres als input, krijgt als antwoord de HSS die alle informatie bevat over

deze gebruiker. Zowel de HSS als de SLF gebruikt het Diameter-protocol om te communiceren met

andere netwerk elementen.

1.2 De CSCF

De CSCF (Call/Session Control Function), een SIP-server, is een essentiële knoop in het IMS-netwerk.

De CSCF verwerkt de SIP-signalisatie in IMS. Er zijn drie verschillende types CSCF’s, afhankelijk van de

functionaliteit die ze bieden. Samen worden zijn ze gekend als CSCF’s maar elk van hen behoort tot

een van de volgende categorieën.

• P-CSCF (proxy - CSCF)

• S-CSCF (Serving - CSCF)

• I-CSCF (Interrogating - CSCF)

De P-CSCF

De P-CSCF is het eerste contactpunt13 tussen de IMS-terminal en het IMS-netwerk. Vanuit een SIP-

standpunt bekeken acteert de P-CSCF als een outbound/inbound SIP-proxyserver. Dit betekent dat

alle aanvragen die door de IMS-terminal geïnitieerd worden of die de IMS-terminal als bestemming

hebben de P-CSCF passeren. De P-CSCF stuurt SIP-aanvragen en antwoorden door in de juiste

richting.

De P-CSCF wordt toegewezen aan een IMS-terminal tijdens de registratie en wijzigt niet meer voor de

duur van die registratie. Een IMS-terminal communiceert dus maar met één P-CSCF tijdens zijn

registratieperiode.

13

In het signalling plane


De P-CSCF omvat verschillende functies. Ten eerste realiseert hij een aantal IPsec

beveiligingsassociaties naar de IMS-terminal toe. Deze IPSec beveiligingsassociaties bieden

integriteitsbescherming14. Eens de P-CSCF de gebruiker geauthenticeerd heeft, staat hij garant voor

de identiteit van de gebruiker naar de andere knopen van het IMS-netwerk toe. Op deze manier

moeten andere knopen geen verdere authenticatie van de gebruiker uitvoeren. Ze vertrouwen de P-

CSCF. Bovendien controleert de P-CSCF de correctheid van de SIP-aanvragen die door de IMS-

terminal worden verstuurd. Deze verificatie zorgt ervoor dat de IMS-terminal geen SIP-

boodschappen kan creëren die niet volgens de SIP-regels opgebouwd zijn. De P-CSCF bevat ook een

compressor en decompressor van SIP-boodschappen (IMS-terminal bevat deze ook). SIP-

boodschappen kunnen aanzienlijk groot zijn aangezien SIP een tekst gebaseerd protocol is. Wanneer

deze boodschappen dus over een smallband verbinding verstuurd worden (zoals sommige

radionetwerken) kan dat enkele seconden duren. Het (de)compressie-mechanisme moet ervoor

zorgen dat de verzendtijd tussen IMS-terminal en P-CSCF klein genoeg blijft.

De P-CSCF kan ook een PDF (Policy Decision Function) bevatten. Deze authoriseert media plane

resources en behandelt Quality of Service over het media plane. Tenslotte genereert de P-CSCF ook

betalingsinformatie die gebruikt kan worden door een “charging collection” knoop.

Het IMS-netwerk werkt om redenen van schaalbaarheid en redundantie meestal met een aantal P-

CSCFs. Elke P-CSCF dient een aantal IMS-terminals, afhankelijk van de capaciteit van de knoop. De P-

CSCF kan zich overal in het bezochte netwerk bevinden of in het thuisnetwerk. In het geval dat het

onderliggende packet-switched netwerk gebaseerd is op GPRS zal de P-CSCF altijd gelegen zijn in het

zelfde netwerk als de GGSN (Gateway GPRS Support Node). P-CSCF en GGSN kunnen dus beide in het

bezochte of het thuisnetwerk gelokaliseerd zijn.

De I-CSCF

De I-CSCF is een SIP-proxy die zich aan de rand van het administratieve domein bevindt. Het adres

van de I-CSCF staat in de DNS records (Mockapetris, 1983) van het domein. De I-CSCF is het

toegangspunt voor externe toegang tot het home netwerk. Een SIP-server zal SIP-boodschap steeds

doorsturen naar de I-CSCF uit het domein van de bestemming.

Naast zijn SIP-proxyserver functionaliteit bevat de I-CSCF ook een interface naar de SLF en HSS. Deze

interface is gebaseerd op het Diameter protocol. De I-CSCF verkrijgt hiermee informatie over de

locatie van de gebruiker en routeert de SIP-aanvraag naar de juiste bestemming (typisch een S-CSCF).

Een I-CSCF kan eventueel ook delen van de SIP-boodschappen encrypteren.

Een netwerk bevat meestal verschillende I-CSCF’s om redenen van schaalbaarheid en redundantie.

De I-CSCF bevindt zich normaal gezien in het thuisnetwerk hoewel hij in enkele speciale gevallen

soms ook in het bezochte netwerk gelokaliseerd kan zijn.

De S-CSCF

De S-CSCF is de centrale knoop in het signaling plane. In essentie is de S-CSCF een SIP-server, maar hij

voert ook sessiecontrole uit. Bovendien acteert de S-CSCF naast zijn taken als SIP-server ook als SIP-

registrar. Dit betekent dat hij een verband onderhoudt tussen het address of record van een

gebruiker (ook bekend onder de naam Public User Identity) en zijn locatie.

14

De mogelijkheid om te detecteren of een boodschap gewijzigd is sinds zijn creatie


Net zoals de I-CSCF heeft de S-CSCF een Diameter interface naar de HSS. Deze interface gebruikt de

S-CSCF voor het downloaden van informatie over de gebruiker die nodig is om hem te kunnen

authenticeren. Bovendien downloadt de S-CSCF het publieke profiel van een gebruiker van de HSS.

Dit publieke profiel bevat een service profiel, bestaande uit een aantal triggers die ervoor kunnen

zorgen dat de SIP-boodschappen gerouteerd worden naar één of meer Application Servers. Tenslotte

informeert de S-CSCF de HSS dat hij de S-CSCF is waaraan de gebruiker is toegewezen voor de duur

van de registratie.

Alle SIP-boodschappen die een IMS-terminal zendt en alle SIP-boodschappen die de IMS-terminal

ontvangt passeren langs de toegewezen S-CSCF. De S-CSCF inspecteert elke SIP-boodschap en besluit

of de SIP-boodschap één of meerdere Application Servers moet bezoeken voordat hij naar z’n

uiteindelijke bestemming kan gerouteerd worden. Deze Application Servers kunnen eventueel extra

diensten verlenen aan de gebruiker.

Één van de belangrijkste functies van een S-CSCF is het verzorgen van routeringsdiensten. Wanneer

de gebruiker bijvoorbeeld een telefoonnummer opgeeft in plaats van een SIP-URI zal de S-CSCF

vertalingsdiensten verlenen.

De S-CSCF legt ook het netwerkbeleid van de netwerkoperator op. Wanneer het voor een gebruiker

bijvoorbeeld niet toegelaten is om bepaalde sessietypes op te zetten, zal de S-CSCF dit verhinderen.

De S-CSCF zal gebruikers dus weerhouden om niet toegelaten acties uit te voeren.

Een netwerk bevat meestal enkele S-CSCF’s voor schaalbaarheid en redundantie redenen. Elke S-

CSCF dient een aantal IMS-terminals, afhankelijk van de capaciteit van de knoop en bevindt zich

steeds in het thuisnetwerk.

1.3 De Application Server

De AS is een SIP-entiteit die SIP-diensten omvat en ze zelf ook uitvoert. Afhankelijk van de eigenlijke

dienst kan de AS opereren in SIP-proxy mode, SIP-UA (user agent)mode of SIP-B2BUA (back-to-back

user agent) mode. De AS communiceert met de S-CSCF gebruik makend van het SIP-protocol. IMS

bevat de volgende drie verschillende types van Application Servers:

• SIP-AS (Application Server): dit is een gewone Application Server die IP Multimedia diensten

gebaseerd op SIP, huisvest en uitvoert. Nieuwe IMS-specifieke diensten zullen ontwikkeld

worden in deze SIP-Application Servers.

• OSA-SCS (Open Service Acces-Service Capability Server): dit is een Application Server die een

interface biedt naar de Application server van het OSA raamwerk (The Parlay Group, 2001).

• IM-SSF (IP Multimedia Service Switching Function): deze gespecialiseerde Application Server

laat in IMS het hergebruik toe van CAMEL15 (Customized Applications for Mobile network

Enhanced Logic) (3GPP, 1994) diensten die ontwikkeld werden voor GSM.

Deze drie types Application Servers gedragen zich als SIP Application Servers naar IMS toe. De IMS-

SSF AS en de OSA-SCS AS hebben ook andere rollen wanneer ze de koppeling met respectievelijk

15

CAMEL werd ontwikkeld om intelligente netwerk functionaliteit te voorzien in het GSM-netwerk. Bijgevolg is CAMEL een netwerk feature en geen extra dienst. Het is een middel voor de netwerk operator om abonnees specifieke diensten aan te kunnen bieden, zelfs wanneer ze roamen vanuit een ander netwerk. Je kan CAMEL als een voorlope van IMS beschouwen.


CAMEL of OSA verzorgen. Buiten de SIP-interface kan een AS ook een Diameter interface bevatten

naar de HSS toe om gebruikers informatie op te vragen.

De AS kan zich zowel in het thuisnetwerk als in netwerk van een derde partij bevinden. Wanneer hij

zich buiten het thuis netwerk bevindt, bevat hij geen interface naar de HSS.

1.4 De MRF

De Media Resource Function is een bron van media in het thuisnetwerk. Zo biedt het de mogelijkheid

om meldingen af te spelen, mediastreams te mixen, te transcoderen tussen verschillende codecs, … .

Verder is de MRF nog onderverdeeld in een signaling plane knoop, MRFC (Media Resource Function

Controller) genoemd, en een media plane knoop: MRFP (Media Resource Function Processor).

De MRFC gedraagt zich als SIP User Agent en bevat een SIP-interface naar de S-CSCF. Hij controleert

bovendien de resources van de MRFP via een H.248 interface. De MRFP implementeert alle media

gerelateerde functies zoals het afspelen en het mixen van media.

De MRF bevindt zich steeds in het thuisnetwerk.

1.5 De BGCF

De BGCF is in essentie een SIP-server die routeringsfunctionaliteiten bevat die gebaseerd zijn op

telefoonnummers. De BGCF wordt enkel gebruikt in sessies die opgezet worden door een IMS-

terminal en gericht zijn naar een gebruiker in een circuit-switched netwerk zoals PSTN of PLMN16.

1.6 De PSTN/CS Gateway

De PSTN gateway voorziet een interface met het circuit-switched netwerk zodat IMS-terminals in

staat zijn telefoongesprekken op te zetten en te ontvangen met en van PSTN (of een ander circuit-

switched netwerk) gebruikers. In Figure 13 zien we de BGCF en de PSTN gateway die communiceert

met het PSTN. We zien dat de PSTN gateway opgesplitst wordt in 3 functies:

• SGW (Signaling Gateway): de Signaling Gateway maakt de koppeling tussen het signaling

plane van IMS en dat van het circuit-switched netwerk (in dit geval PSTN)

• MGCF (Media Gateway Control Function): De MGCF is de centrale knoop van de PSTN/CS

gateway. Het zorgt voor de conversie tussen de verschillende protocols: SIP (het call control

protocol aan de IMS zijde) wordt bijvoorbeeld omgezet naar ISUP (een call control protocol

voor circuit-switched netwerken) over IP (Internet Engineering Task Force, 2002). Bovendien

controleert hij de resources in de MGW. Hiervoor gebruikt hij het H.268 (ITU-T, 2002)

protocol.

• MGW (Media Gateway): de Media Gateway maakt de koppeling tussen het media plane in

IMS en dat van het PSTN. Dat komt in praktijk neer op de omzetting van RTP-pakketten naar

PCM17 time slots en omgekeerd.

16

Public Land Mobile Network 17

Pulse Code Modulation


Figure 13: PSTN/CS Gateway

2. IMS in ons project Het is de lezer ondertussen wel duidelijk dat IMS een zeer uitgebreide architectuur heeft die voor

vele verschillende diensten een oplossing biedt. Zoals we echter in de inleiding verteld hebben zullen

wij ons enkel bezig houden met VoIP. Dit heeft als gevolg dat vele netwerkfuncties niet van

toepassing zijn op ons project. In wat volgt zullen we IMS herleiden tot een eenvoudig beeld van wat

wij nodig hebben.

Vooreerst werken we met slechts enkele gebruikers in een klein test netwerk. We zullen dus slechts

één HSS instantie nodig hebben en bijgevolg geen SLF. Bovendien zetten we geen gesprekken op

tussen een VoIP gebruiker en een klassieke telefonie gebruiker. Dit brengt met zich mee dat de

PSTN/CS-gateway en de BGCF overbodig zijn voor ons project. We beperken ons strikt tot het packet-

switched netwerk.

Op gebied van Application Servers zullen we enkel de gewone SIP Application Server gebruiken. Later

zal de taak van deze SIP AS duidelijk worden. Ook de MRF laten we achterwege vermits we geen

codec transformaties of het mixen van verschillende media nodig zullen hebben.

Dat laat ons nog de verschillende Call/Session Control Functions over. Deze behouden we

vanzelfsprekend in ons netwerk wegens hun belang als SIP-servers. Wanneer we al deze

vereenvoudigingen doorvoeren krijgen we de volgende architectuur.


Figure 14: Vereenvoudigde IMS-architectuur

Merk op dat Figure 14 de netwerkarchitectuur van het signaling plane weergeeft. In het media plane

zullen we ook gebruik maken van een pakketreplicator. Een verdere uitleg volgt in de hoofstukken

over de handover.

3. Basic Session Setup Om beter te begrijpen wat deze netwerkelementen van ons vereenvoudigd IMS-model in praktijk

doen, zullen we een deel van de setup van een VoIP gesprek bespreken. Hierbij staan we stil bij de

rollen die de verschillende netwerkelementen vervullen. We veronderstellen Alice en Bob, beide

aangemeld op een IMS-terminal. Alice wil Bob bellen en verstuurt een SIP INVITE-boodschap. We

zullen het pad van deze boodschap doorheen het IMS-netwerk volgen en uitleg geven bij de acties

die genomen worden door de verschillende netwerkelementen wanneer de INVITE voorbij komt.

We nemen aan dat zowel Alice als Bob zich niet in hun thuisnetwerk bevinden. Ze roamen met

andere woorden vanuit hun bezocht netwerk. Bovendien hebben Alice en Bob ook een verschillend

thuisnetwerk. Deze veronderstellingen nemen we omdat we zo het meest complete en complexe

scenario hebben. Alle andere scenario’s zijn slechts vereenvoudigingen van dit scenario. We merken

op dat de P-CSCF’s van beide gebruikers zich in het bezochte netwerk bevinden. De S-CSCF’s

bevinden zich zoals eerder reeds vermeld steeds in het thuisnetwerk. Dit om de diensten steeds

beschikbaar te houden voor de gebruiker, waar hij zich ook bevindt.

De I-CSCF is de enige netwerk knoop18 die tijdens de session setup in contact staat met de HSS. Hij zal

met de HSS communiceren aan de hand van het Diameter-protocol. Op deze manier wordt de HSS

niet bij het verwerken van alle extra boodschappen betrokken. Dit is een groot voordeel, rekening

houdend met het feit dat een HSS meestal informatie over honderdduizenden gebruikers bevat.

18

Merk op dat we nu over knopen spreken maar dat de I-CSCF en dergelijke eigenlijk als functie gedefinieerd zijn. In dit voorbeeld veronderstellen we voor de eenvoud dat elke functie in een andere knoop geïmplementeerd is.


Tenslotte herhalen we dat alle boodschappen19 van een gebruiker de P-CSCF en S-CSCF die op dat

moment aan deze gebruiker zijn toegewezen passeren. De P-CSCF en S-CSCF maken hiervoor gebruik

van het Record-route-veld van de SIP-aanvraag.

Figure 15: Basic Session Setup

3.1 De IMS-terminal zendt de INVITE aanvraag

Wanneer Alice een gesprek met Bob wil opzetten zal ze een SIP INVITE aanvraag opstellen met de

SIP-URL van Bob als Request-URI. Het zou ons te ver leiden om alle headervelden van de SIP INVITE

aanvraag opnieuw te overlopen. We beperken ons tot de belangrijkste.

In het Via-veld geven we het IP-adres en het poortnummer mee waar de antwoorden op de INVITE

aanvraag naartoe gestuurd moeten worden. Het poortnummer is van belang omdat deze dezelfde

moet zijn als de poort waarmee een beveiligingsassociatie is opgezet met de P-CSCF. Wanneer de P-

CSCF ontdekt dat het meegegeven poortnummer niet datgene is waarmee hij een

beveiligingsassociatie heeft, zal hij het pakket laten vallen.

De IMS-terminal stuurt de SIP INVITE aanvraag naar de P-CSCF van zijn bezochte netwerk. De locatie

van deze P-CSCF is hij tijdens de P-CSCF discovery procedure (Camerillo & Garcia-Martin, 2006) te

weten gekomen.

3.2 De initiërende P-CSCF verwerkt de INVITE aanvraag

Wanneer de initiërende20 P-CSCF de INVITE aanvraag ontvangt zal hij meteen controleren of deze

juist gevormd is en alle velden wel een toegelaten waarde bevatten. Bovendien zal hij de SDP-inhoud

controleren. De initiërende P-CSCF is ingesteld volgens het plaatselijke netwerkbeleid. Zo’n beleid

kan bijvoorbeeld het gebruik van sommige media parameters niet toelaten in het netwerk. Een

beleid kan bijvoorbeeld aanduiden dat G.711 niet als audio codec gebruikt mag worden omdat deze

een bandbreedte van 64kb/s vereist terwijl de maximaal toegelaten bandbreedte van het netwerk

slechts 14 kb/s bedraagt. Wanneer de SDP niet voldoet aan deze voorwaarden zal de initiërende P-

CSCF een 488 (Not Acceptable Here) antwoord versturen naar de IMS-terminal.

De initiërende P-CSCF zal vervolgens controleren of er voldaan is aan de beveiligingseisen en de

beveiligingsheaders van de boodschap verwijderen. In plaats daarvan zal hij headers toevoegen die

te maken hebben met betaling. Op deze procedure gaan we niet dieper in omdat dit van weinig

belang is voor ons onderzoek.

19

In het signaling plane 20

P-CSCF in het netwerk van de IMS-terminal die het gesprek wil opzetten


Tenslotte zal de P-CSCF een Record-route-veld toevoegen met zijn SIP-URI als inhoud. Daarmee zorgt

hij ervoor dat hij in het pad wordt opgenomen van alle toekomstige SIP-boodschappen van deze

sessie. Dit is noodzakelijk omdat de initiërende P-CSCF de beveiligingsassociatie met de gebruiker

onderhoudt. Bovendien is het mogelijk dat SIP-boodschappen gecomprimeerd worden tussen IMS-

terminal en de initiërende P-CSCF. De initiërende P-CSCF zal voor de compressie/decompressie van

de boodschappen moeten zorgen.

3.3 De initiërende S-CSCF verwerkt de INVITE aanvraag

Bij het ontvangen van de INVITE aanvraag zal de initiërende S-CSCF de gebruiker, Alice, identificeren

en het gebruikersprofiel gebruiken dat bij de registratie reeds werd gedownload. Dit

gebruikersprofiel bevat buiten informatie ook zogenoemde filtercriteria. Deze filtercriteria bevatten

een verzameling triggers die bepalen of een aanvraag één of meerdere Application Servers moet

passeren die diensten aan de gebruiker leveren. Merk op dat de initiërende S-CSCF de diensten niet

zelf uitvoert, maar de diensten laat uitvoeren door de Application Servers.

Ook de initiërende S-CSCF zal de SDP-inhoud controleren. Net zoals de initiërende P-CSCF controleert

hij of de SDP media parameters voldoen aan het lokale netwerkbeleid. De initiërende S-CSCF zal

hierbij echter ook gebruikersgerelateerde informatie gebruiken uit de HSS (het gebruikers profiel). Zo

kan men zich bijvoorbeeld op een goedkoper tarief abonneren dat het gebruik van codecs met een

hoge bandbreedte verbiedt.

De initiërende S-CSCF is het eerste netwerkelement dat rekening houdt met de aanvraag-URI van de

INVITE aanvraag. De IMS-terminal en initiërende P-CSCF sturen de INVITE automatisch door naar de

next hop21 zonder rekening te houden met de uiteindelijke bestemmeling. De initiërende S-CSCF zal

uit de aanvraag-URI de naam van het domein van de bestemmeling extraheren. Aan de hand van

deze domeinnaam zal hij enkele DNS-opvragingen uitvoeren om zo het adres van de I-CSCF van Bob’s

domein te verkrijgen.

De S-CSCF zal tenslotte nog zijn SIP-URI aan het Record-route-veld toevoegen voordat hij de INVITE

doorstuurt naar de I-CSCF van het thuis netwerk van Bob.

3.4 De terminerende I-CSCF verwerkt de INVITE aanvraag

De terminerende22 I-CSCF zal nu de INVITE aanvraag moeten doorsturen naar de juiste S-CSCF. Dat

wil zeggen, de S-CSCF die op dit moment aan Bob is toegewezen. Tijdens de registratie van Bob werd

deze informatie in de HSS weggeschreven. De terminerende I-CSCF zal de HSS voor deze informatie

bevragen aan de hand van een Diameter Location-Information-Request (LIR)boodschap. Wanneer hij

een Location-Information-Answer (LIA) boodschap terug krijgt met het adres van de S-CSCF zal hij de

INVITE naar dit adres doorsturen.

Merk op dat de I-CSCF in normale omstandigheden niet meer in het pad van de volgende

boodschappen moet betrokken worden. Hij zal bijgevolg het Record-route-veld niet wijzigen.

21

Deze next hop wordt gedefinieerd aan de hand van de route-header van de SIP aanvraag. Hier gaan we echter niet verder op in. + verwijzing naar SIP uitleg voer route header 22

De I-CSCF uit het thuisnetwerk van de gebelde gebruiker


3.5 De terminerende S-CSCF verwerkt de INVITE aanvraag

De terminerende S-CSCF zal eerst de gebelde gebruiker identificeren aan de hand van de aanvraag-

URI. Vervolgens evalueert hij de filtercriteria van de gebelde gebruiker. Deze evaluatie is hetzelfde als

bij de initiërende S-CSCF met dit verschil dat er nu gekeken wordt naar de diensten die moeten

toegepast worden bij sessies naar een gebruiker toe en niet vanuit een gebruiker.

Na het wijzigen van enkele headervelden van de INVITE (de meeste met betrekking tot routering:

aanvraag-URI, Record-Route,…) stuurt de terminerende S-CSCF de boodschap door naar de

terminerende P-CSCF.

3.6 De terminerende P-CSCF verwerkt de INVITE aanvraag

Wanneer de terminerende P-CSCF de INVITE aanvraag ontvangt hoeft hij geen routeringsbeslissing te

nemen omdat de aanvraag-URI zo is aangepast dat de SIP-URI reeds het IP-adres van Bob bevat. De

terminerende P-CSCF moet de gebruiker wel identificeren om de juiste beveiligingsassociatie te

gebruiken die werd opgezet met de IMS-terminal.

De terminerende P-CSCF zal ook steeds in het pad van de volgende SIP-boodschappen moeten

voorkomen en daarom zal hij zijn SIP-URI toevoegen aan het Record-Route-veld. De P-CSCF voert ook

nog een aantal taken uit in verband met betalingen en beveiliging. Zijn SIP-specifieke functies zijn

echter beperkt tot het acteren als SIP-proxy.

3.7 De IMS-terminal ontvangt de INVITE aanvraag

Wanneer de IMS-terminal de INVITE aanvraag ontvangt, zal hij de deze onderzoeken en een gepast

antwoord genereren. Ondertussen zal hij ook aan de hand van de SDP-inhoud trachten een media

sessie op te zetten. We gaan hier niet dieper op in omdat dit ons te ver zou leiden. Uit deze bondige

uitleg over het versturen van de INVITE doorheen het IMS-netwerk zou de lezer een betere kijk

moeten hebben gekregen op de functies van de verschillende netwerkelementen.

34 | Hoofdstuk 6 - Seamless Handover

Hoofdstuk 6: Seamless Handover

1. Eisen voor Applicaties Vooraleer we een protocol kunnen definiëren om seamless handover te realiseren moeten we een

goede kijk hebben op de betekenis van het woord seamless. Een voor de hand liggende definitie is

dat we bij een seamless handover gedurende het handover proces geen vermindering van kwaliteit

krijgen. De vraag is dus welke factoren kunnen bijdragen aan kwaliteitsverlies en welke beperkingen

we deze factoren moeten opleggen. Hoeveel pakketten mogen we verliezen, hoeveel vertraging

mogen pakketten maximaal oplopen,…? Gelden voor video dezelfde beperkingen of zijn ze nog

zwaarder? We baseren ons in dit hoofdstuk op onderzoek uit (Demeester & Pickavet, 2006) en

1.1 Vertraging

Vertragingsproblemen kunnen we opsplitsten in verschillende soorten: algemene vertraging van een

pakket(delay) en variatie in vertraging van verschillende pakketten (jitter). Jitter treedt vaak op bij

pakketten die over UDP verstuurd worden. Aangezien alle pakketten afzonderlijk en onafhankelijk

van elkaar verstuurd worden, kunnen zij ook verschillende paden over het netwerk nemen. Doordat

ze verschillende paden afleggen zullen ze dus ook een andere vertraging meekrijgen. Deze variatie in

vertraging noemen we jitter. Er zijn verschillende manieren om de invloed van deze jitter te

beperken. Een dejitter buffer en het RTP-protocol zijn er enkele voorbeelden van.

De algemene vertraging van een pakket is de som van allemaal verschillende soorten vertraging. De

packetization delay is de vertraging die nodig is om een pakket te vullen met spraak data. Als we een

pakket met standaardgrootte van 1500byte willen vullen aan een snelheid van 8kbit per seconde zou

het 1,5 seconde duren voor we een pakket kunnen versturen. Dit is vanzelfsprekend niet toelaatbaar

in real-time toepassingen zoals een VoIP gesprek. Bijgevolg zal men bij VoIP kleinere pakketten

gebruiken van 10byte wat resulteert in een aanvaardbare vertraging van 10msec. Om de

netwerkbelasting zo laag mogelijk te houden, zullen we de gespreksinformatie ook coderen aan de

hand van een voice codec zodat we dezelfde informatie (of met beperkt kwaliteitsverlies) door een

kleiner aantal bits kunnen beschrijven. Het coderen van de spraak samples brengt vanzelfsprekend

ook een extra vertraging met zich mee. Table 3 geeft een overzicht van de codeervertragingen van

enkele veel gebruikte codecs.

Codec Codeervertraging (msec)

G.711 0.125

G.726 0.125

G.729 15

GSM 20

Table 3: Codeervertragingen

Bovenstaande vertragingen zijn gevolg van acties die aan de client-zijde gebeuren. Wanneer een

pakket over het netwerk wordt verstuurd zijn er nog enkele aspecten die voor vertraging zorgen. De


transmission delay is de tijd die nodig is om een pakket over een link met een bepaalde bandbreedte

te sturen. Deze kan zeer variëren naargelang de soort link die wordt gebruikt. In het geval van een

ISDN-lijn van 64kbit/s bedraagt de transmission delay voor een pakket van 1kByte 125msec.

Wanneer we echter een link naar een GEO-satelliet van 1Gbit/s gebruiken is de transmission delay te

verwaarlozen. Table 4 geeft een overzicht van de transmission delays van enkele draadloze

technologieën. Maar de tranmission delay is niet de enige vertraging waar we rekening mee moeten

houden bij het versturen van een pakket tussen twee netwerkelementen. De propagation delay is de

snelheid die beperkt is door de propagatiesnelheid van elektromagnetische golven. De snelheid van

het licht bedraagt 3.108 m/sec in lucht en 2.108 in een optische fiber. Deze component wordt dus

belangrijk bij transmissie over grote afstanden. Bij onze ISDN-lijn van 100m zal de propagation delay

verwaarloosbaar zijn maar bij het verkeer over de GEO satelliet (waarbij we afstanden tot 70.000 km

afleggen) krijgen we al snel een propagation delay van 250msec.

Technologie Transmission delay voor het versturen van 1kByte (msec)

UMTS (384kbit/s) 20.8

GPRS (384kbit/s) 20.8

EDGE (200kbit/s) 40

802.11b (11Mbit/s) 0.73

802.11g (54Mbit/s) 0.15

Table 4: Transmission delays van draadloze technologieën

Wanneer we een pakket van onze bron naar de bestemming willen sturen zal dit echter zelden of

nooit rechtstreeks gebeuren. Pakketten worden gerouteerd door routers die verschillende links

verbinden. Deze routers bevatten voor elke output poort een buffer die pakketten moet opvangen

die niet meteen verstuurd kunnen worden. Wanneer een pakket bij zijn aankomst in de router in zo’n

buffer terecht komt, zal hij vanzelfsprekend een extra vertraging oplopen.

IP-Router

Space

switch

Output

buffers

Figure 16: IP-router


Het is duidelijk dat jitter veroorzaakt wordt door de verschillen in transmission delay, propagation

delay en de vertraging opgelopen in de routers. De packetization en coding delay zijn hetzelfde voor

alle pakketten van een bepaalde VoIP datastroom.

De vraag is nu hoeveel de maximale vertraging is die onze pakketten mogen ondervinden om nog

steeds een gesprek van goede kwaliteit te behouden. De maximale eenrichtingsvertraging voor een

VoIP gesprek van goede kwaliteit is door de ITU (ITU, 1992) gezet op 150 msec. Bij in software

geïmplementeerde toepassingen is dit echter zeer moeilijk te realiseren (als gevolg van buffering) en

accepteren we waarden van 150msec tot 400msec.

Wanneer we te maken hebben met video conferencing moet deze delay onder de 250msec blijven

om de kwaliteit van de video te garanderen.

1.2 Pakket verlies

Pakketverlies kan op verschillende manieren tot stand komen. IP-pakketten bevatten een CRC

checksum die gebruikt wordt om te kijken of er geen transmissiefouten zijn gebeurd. Bij een

transmissiefout zal dit resulteren in bitfouten (of een burst van bits). De CRC checksum wordt op elke

router nagekeken en geeft een fout wanneer er bitfouten (of een burst van bits) zijn opgetreden. In

dat geval zal de router het pakket laten vallen.

Om een andere manier van pakketverlies uit te leggen moeten we eerst een eenvoudige uitleg geven

van de basiswerking van een IP-router. Zoals we in Figure 16 zien, betaat een IP-router uit een space

switch en output buffers. Wanneer een pakket binnenkomt wordt het door de space switch naar de

juiste output buffer gestuurd. Wanneer er reeds pakketten in deze buffer zitten zal het pakket zoals

eerder besproken vertraging oplopen. Zit de buffer echter vol, dan laat de router het pakket vallen

en krijgen we pakketverlies.

Een laatste vorm van pakketverlies heeft te maken met de werking van de dejitter buffer. Om de

variaties in algemene vertraging van pakketten op te vangen zal een dejitter buffer alle pakketten

een extra, variabele vertraging toekennen. Deze extra vertraging wordt per pakket aangepast zodat

de variatie in de vertraging tegenover andere pakketten teniet wordt gedaan. Zo zullen pakketten

aan de uitgang van de buffer aan een vast tempo aan de applicatie afgeleverd worden. Een dejitter

buffer kan echter slechts een beperkte vertraging opvangen. Indien een pakket zo veel vertraging

heeft opgelopen dat het niet meer in het tijdsschema past aan de uitgang van de buffer, laat de

buffer het pakket vallen en gaat het dus verloren.


Verzend tijd

Vaste algemene

vertraging

IP-Netwerk

Pakket gaat

verloren

Pakketten juist

geordend

Ontvang tijd Afspeeltijd

DeJitter Buffer

Figure 17: Dejitter Buffer

We willen nu de daling van de kwaliteit van ons gesprek uitdrukken in functie van het pakketverlies.

De kwaliteit van een spraaksignaal wordt vaak uitgedrukt gebruik makend van de MOS-score23.

Wanneer we naar verschillende codecs kijken, zien we dat bij een pakketverlies van meer dan 1% de

MOS-scores van de verschillende codecs steeds dichter bij elkaar komen te liggen. Hierbij hebben we

het wel over uniform pakketverlies. In dit project zullen we echter meer te maken hebben met bursty

pakketverlies. Indien we een voice sample van 2000 pakketten beschouwen zal de MOS-score pas bij

een burst verlies van 100 pakketten sterk dalen. De kwaliteit van het gesprek is dan nagenoeg perfect

op uitzondering van het punt waar de pakketten zijn verloren, daar is er stilte. Dit willen we

natuurlijk vermijden want aan die stilte kan de gebruiker merken dat hij van netwerk verandert en

dat is niet de bedoeling.

Bij videoconferencing heeft pakketverlies nog een grotere invloed op de kwaliteit. Een pakketverlies

van 1% resulteert al in een zichtbaar mindere beeldkwaliteit. Bovendien kunnen we bij pakketverlies

van beeldframes een propagatie van fouten krijgen. Om het dataverkeer te beperken worden frames

vaak voorspeld op basis van vorige of verdere frames. Wanneer we een frame verliezen waarop

andere frames hun voorspelling hebben gebaseerd, zullen we die frames dus niet kunnen

reconstrueren. Zo verliezen we niet enkel het huidige frame, maar ook deze waarvan de voorspelling

van het huidige frame afhangt . Meer uitleg vindt u hierover in een MPEG-4 tutorial (Moving Picture

Experts Group (MPEG), 1998).

23

Mean Opinion Score: schaal van 1 tot 5 om de kwaliteit van een spraaksignaal uit te drukken


2. Seamless handover: hoe gerealiseerd In deze sectie zullen we twee voorstellen bespreken om een handover te realiseren. We zullen deze

verschillende voorstellen evalueren op basis van hun mogelijkheid om aan de bovenstaande

vereisten voor seamless handover te voldoen.

2.1 Standaard SIP: ReINVITE

In het standaard SIP-protocol is er reeds ondersteuning aanwezig om over te schakelen tussen twee

interfaces van een client. Voor deze handover maken we gebruik van een specifieke boodschap:

ReINVITE. In de volgende uitleg veronderstellen we twee gebruikers die met elkaar in gesprek zijn:

Alice en Bob. Alice heeft twee interfaces ter beschikking.

Nadat de RTP-sessie tussen Bob en Alice is opgezet waarbij Alice gebruik maakt van interface 1, wil

Alice overschakelen naar interface 2. Ze zal de verbinding op interface 1 afsluiten en een ReINVITE-

boodschap sturen naar Bob van op interface 2. Deze ReINVITE is identiek aan de oorspronkelijke

INVITE-boodschap24 met dit verschil dat het Contact- en het Via-veld aangepast zijn met de gegevens

van de nieuwe interface.

Originele INVITE reINVITE

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 10.10.5.50:5060 To: <[email protected] > From: <[email protected] >;tag=001 Call-Id: call1 CSeq 1 INVITE Contact: <sip:[email protected]>

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.32.4:5060 To: < [email protected] >;tag=002 From: <[email protected]>;tag=001 Call-Id: call1 CSeq 2 INVITE Contact: <sip:[email protected]>

Figure 18: Standaard SIP: Versturen ReINVITE

Wanneer Bob dit bericht ontvangt zal hij al zijn RTP-pakketten vanaf dat moment naar de nieuwe

locatie (interface) sturen.

24

In de veronderstelling dat de mobiele host het gesprek heeft opgezet en de oorspronkelijke INVITE dus gestuurd heeft.


Figure 19: Standaard SIP: Nieuwe RTP Sessie

De totale vertraging van deze zogenaamde mid-call handoff is de tijd die nodig is voor het

doorzenden van de reINVITE-boodschap van Alice naar Bob. Alle pakketten die Bob stuurt tijdens

deze vertraging gaan dus verloren omdat Alice enkel nog luistert op Interface 2. Bij een vertraging

van 1s verliezen we 4 tot 5 pakketten bij een 16kb/s stream met voice pakketten van 64 bytes. Indien

we echter met een 1,5Mb/s MPEG-4 stream werken, verliezen we zelfs 2x105 pakketten van 1050

bytes. Zo’n pakketverlies heeft vanzelfsprekend een nefaste invloed op de kwaliteit van het gesprek.

Bij een MPEG-4 stream kan er bovendien een propagatie van fouten optreden indien het gaat om het

verlies van I- of P-frames (Moving Picture Experts Group (MPEG), 1998). Bovendien zal het

detecteren van het netwerk voor de nieuwe interface en de toewijzing van een geldig IP-adres

bijdragen tot deze vertraging.

Het is dus duidelijk dat deze manier van handover niet in aanmerking komt voor het realiseren van

een seamless handover. Door de grote hoeveelheid pakketten die tijdens het overgangsproces

verloren gaan zal de kwaliteit van het gesprek een duidelijke daling vertonen. Bijgevolg zal Alice

duidelijk merken dat ze van interface is overgeschakeld.

2.2 Onze oplossing: INVITE met join-header

De oplossing die wij voorstellen voor het realiseren van een seamless handover maakt gebruik van

het soft-handoff principe. We baseren ons hierbij op het onderzoek van (Banerjee, Acharya, & Das,

2006). We zetten de nieuwe datastroom op voordat we de originele datastroom hebben afgesloten.

We zullen er dus rekening mee moeten houden dat RTP-pakketten dubbel ontvangen worden.

De IMS-server25 zal bij deze procedure een belangrijke rol spelen. Hij zal naast zijn taken in het

signaling plane ook de taak van mediagateway vervullen. Als media-gateway zal de IMS-server tijdens

het handover proces pakketten repliceren en naar beide actieve interfaces sturen. Om alle RTP-

pakketten te kunnen verdubbelen zal de IMS-server deze pakketten wel moeten ontvangen. In een

normaal VoIP gesprek is dit echter niet het geval. Door gebruik te maken van het Record-route-veld

kunnen we er wel voor zorgen dat alle signaling boodschappen de IMS-server passeren. Daarbij blijft

echter het probleem dat de datapakketten van de RTP-sessie rechtstreeks tussen de gebruikers

verstuurd worden. Om dit probleem te omzeilen zullen we gebruik maken van het Back to Back User

Agent principe (B2BUA). Hierbij zal de IMS-server zich tegenover beide gebruikers gedragen als een

User Agent. Hij zal SIP- en SDP-boodschappen zo aanpassen dat beide gebruikers al hun informatie

25

Die de rol van P-CSCF, S-CSCF, I-CSCF, HSS, Application Server en mediagateway uitoefent


via de IMS-server zullen sturen. Bij de bespreking van de IMS-server zullen we dieper ingaan op de

details van deze procedure.

Om te beginnen zetten we het originele VoIP gesprek op. Alice stuurt een INVITE-boodschap naar

Bob vanaf interface 1.

INVITE

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 10.10.5.50:5060 To: <[email protected]> From: <[email protected]>;tag=001 Call-Id: call1 CSeq 1 INVITE Contact: <sip:[email protected]>

Wanneer dit gesprek is opgezet en we willen overschakelen naar de nieuwe interface, sturen we een

INVITE met join-header naar de IMS-server uit het domein van de 1e interface. Deze boodschap bevat

alle relevante informatie van het huidige gesprek. Merk op dat de CSeq-nummer volgt op die van de

oorspronkelijke INVITE.

INVITE met join-header

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.32.4:5060 To: [email protected] From: <[email protected]>;tag=003 Call-Id: call1 CSeq: 2 INVITE Contact: <sip:[email protected]> Join: call1;to-tag=002;from-tag=001

Figure 20: Versturen INVITE met Join

Zodra deze IMS-server de INVITE met join-header heeft ontvangen, zal hij het gesprek identificeren

aan de hand van zijn call-ID. Vervolgens dupliceert hij alle RTP-pakketten van dit gesprek en stuurt hij

ze naar beide interfaces. Tijdens deze overgangsperiode zal de mobiele host alle RTP-pakketten dus


via zijn beide interfaces ontvangen. Er is dus een pakket filter nodig om de dubbele RTP-pakketten te

verwerpen. Op de IMS-server is er een gelijkaardige filter nodig vermits de client nu ook zijn RTP-

pakketten twee maal verstuurt. Eén maal van op elke interface.

RTP-Sessie

Figure 21: Replicatie RTP pakketten

Wanneer het eerste RTP-pakket op de nieuwe interface wordt ontvangen, stuurt Alice via deze

interface een reINVITE-boodschap naar Bob naar analogie met het standaard SIP-protocol. Deze

ReINVITE bevat een SDP-boodschap als payload net als het OK-antwoord dat we van Bob krijgen.

Deze SDP-boodschappen worden opnieuw gebruikt om de parameters van de RTP-sessie te

definiëren.

ReINVITE

INVITE sip: [email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.32.5:5060 To: < [email protected] >;tag=002 From: <[email protected]>;tag=001 Call-Id: call1 CSeq 2 INVITE Contact: <sip:[email protected]>

RTP-Sessie

Figure 22: Versturen ReINVITE


Bob zal na het versturen van zijn OK-boodschap naar de nieuwe interface van Alice al zijn RTP-

pakketten die richting uit sturen. Vervolgens stuurt Alice een BYE-boodschap via de oude interface

naar de P-CSCF uit het domein van interface 1 om het gesprek over deze lijn af te sluiten.

Figure 23: Nieuwe RTP-sessie

Tenslotte registreert Alice zich met haar nieuwe locatie (nieuwe interface) bij de registrar service in

het domein van de nieuwe interface met de REGISTER-boodschap.

We kunnen besluiten dat we met de soft-handoff een elegante manier hebben gevonden om het

probleem van pakketverlies ten gevolge van vertraging bij hard handoff op te lossen. Zo kunnen we

de kwaliteit van onze voice- en videostreams hoog houden. Door het feit dat we de oude RTP-sessie

pas afbreken op het moment dat we onze nieuwe sessie hebben opgezet, kunnen we pakketverlies

en bijhorend kwaliteitsverlies vermijden.

43 | Hoofdstuk 7 - Ekiga

Hoofdstuk 7: Ekiga

Ekiga is een open source VoIP en videoconferencing client voor Gnome (Sandras, 2003). Het maakt

gebruik van zowel het SIP als het H323 protocol. Dit heeft als gevolg dat het programma veel meer

kan (en dus ook ingewikkelder is) dan nodig. Bij de keuze van de client die we zouden gebruiken voor

de implementatie van onze aanpassingen kwam Ekiga echter als beste optie naar voren.

In dit hoofdstuk geven we eerst een beschrijving van de structuur van Ekiga zelf. Vervolgens zullen

we dieper ingaan op de aanpassingen die we aan de code hebben gemaakt om de seamless handover

te implementeren.

1. Structuur Ekiga maakt gebruik van 2 onderliggende bibliotheken: Opal en Pwlib. In de Opal-bibliotheek zit de

volledige implementatie van het SIP- en H323-protocol. Aan de hand van klassen zoals “SIPEndPoint”

en “SIPConnection” worden er gegevens over huidige SIP-gesprekken bijgehouden.

Deze Opal-bibliotheek maakt dan weer gebruik van de Pwlib-bibliotheek. In Pwlib zijn zaken zoals

sockets geïmplementeerd. Bovendien gebruiken Ekiga en Opal weinig standaard types. Een gewone

string komt bijvoorbeeld niet voor in de code. In de plaats daarvan werken Ekiga en Opal met een

PString. Deze speciale klassen zijn ook allemaal in de Pwlib-bibliotheek geïmplementeerd.

Figure 24: Structuur bibliotheken

Het is duidelijk dat, vermits wij een uitbreiding op het SIP-protocol willen implementeren, de meeste

van onze aanpassingen zich in de Opal-bibliotheek zullen bevinden.


1.1 Ekiga

De code van Ekiga is opgesplitst in 5 verschillende modules: gui, endpoints, devices, clients en

components. De gui-module bevat alle klassen en functionaliteit die te maken hebben met de

grafische gebruikersinterface van Ekiga. Eén van de belangrijkste bestanden in deze module is het

callbacks-bestand. Hierin zitten alle functies die worden opgeroepen wanneer er bijvoorbeeld een

knop is ingedrukt, een instelling is gewijzigd, … . Via deze functies zal de verbinding naar de rest van

het programma gemaakt worden.

In de Endpoints-module staan bestanden die de motor van het programma vormen. Zo is er het

Ekiga-bestand dat algemene functionaliteit bevat door middel van functies zoals connect, disconnect

en detect_interfaces. In het SIP-bestand wordt de klasse: GMSIPEndPoint geïmplementeerd. Deze

klasse erft van SIPEndPoint en EndPoint in de Opal bibliotheek. De high level functionaliteit van het

SIP-protocol wordt dus wel in deze klasse gedefinieerd, maar zodra we concreter naar de

implementatie van het SIP-protocol gaan, worden we automatisch doorverwezen naar de code van

de Opal-bibliotheek. Zo zijn er gelijkaardige klassen voor het H323 protocol en voor de algemene

manager.

In de clients en components module staan implementaties van componenten die onder meer met

het omzeilen van netwerkproblemen te maken hebben. De STUN-klasse bijvoorbeeld biedt een

oplossing voor de NAT-problemen die kunnen voorkomen bij het gebruik van het SIP-protocol26.

Tenslotte hebben we nog de devices-module. Hierin wordt de samenwerking van Ekiga met audio- en

video-drivers geïmplementeerd aan de hand van klassen zoals GMAudioEvent en VideoInput.

Figure 25: Structuur Ekiga

26

Voor meer informatie zie: hier een link naar website of naar bibliografie


1.2 Opal

De verschillende VoIP-protocols worden geïmplementeerd in de Opal-bibliotheek. We zullen ons in

de bespreking van Opal beperken tot de implementatie van het SIP-protocol en de klassen die van

belang zijn voor onze aanpassingen. Opal is net zoals Ekiga opgedeeld in verschillende modules. De

opal-module zorgt voor algemene functionaliteit en kan beschouwd worden als een toegangspunt

voor de bibliotheek van waaruit de functionaliteit van de andere modules wordt opgeroepen. Andere

modules zijn h323, sip, rtp,… . In wat volgt zullen we ons enkel concentreren op het bespreken van

de opal-, sip- en rtp-module.

Figure 26: Structuur Opal

Opal

De Opal-module kunnen we ruwweg onderverdelen in 4 soorten klassen. De klassen uit de eerste

groep vormen de implementatie van alles wat te maken heeft met het opzetten van een gesprek. Ze

worden voor de verschillende protocollen verder geïmplementeerd in andere modules en hebben

dus enkel basisfunctionaliteit. Een OpalConnection bijvoorbeeld, bevat functies die te maken hebben

met het opzetten van een verbinding. De SIPConnection klasse (uit de sip-module) is een kindklasse

van deze OpalConnection die de functionaliteit ervan projecteert op het SIP-protocol. Een analoge

uitleg kunnen we geven voor de H323Connection klasse.

Figure 27: OpalConnection

Naast deze eerste groep onderscheiden we een 2e groep van klassen die geen kindklassen hebben in

andere protocolspecifieke modules maar wel worden gebruikt door de verschillende protocols.

Zowel op hoger als op lager niveau. Een OpalCall bevat bijvoorbeeld informatie over een gesprek, SIP

of H323, zoals de identificatie van de gesprekspartners (aan de hand van een SIP-URI), de starttijd en


een verzameling van verbindingen die voor dit gesprek zijn opgezet. Wanneer we met het SIP-

protocol werken wordt zo’n verbinding geïmplementeerd door een SIPConnection-object. Omdat

groepsgesprekken met meerdere partners mogelijk zijn, kan één OpalCall meerdere verbindingen

bevatten. In Figure 28 zien we drie Connections die deel uitmaken van dezelfde OpalCall tussen Alice

en Bob.

[email protected]

Interface 2

192.168.32.4

PCSCF 2

192.168.32.5

PCSCF 1

10.10.5.301

1

2

3

3

Interface 1

10.10.5.50

[email protected]

Figure 28: OpalCall en OpalConnection

Naast deze OpalCall kunnen we ook de Transport klassen in deze groep indelen. De transport klassen

zijn een implementatie van de verschillende transport protocollen zoals TCP en UDP. Ze voorzien

functionaliteit waar de Connections gebruik van maken om pakketten te versturen. Enkele

voorbeelden van klassen en functies zijn: OpalTransportAddress (samenstelling van een IP-adres,

poort en een definitie van het tranportprotocol), OpalListenerUDP en OpalTransportUDP waarin

functies als ConnectTo() zijn geïmplementeerd.

Figure 29: OpalCall en OpalTransportUDP

Een derde soort klassen uit de opal-module verzorgen de implementatie van mediastreams. Ze

maken met andere woorden de verbinding tussen het ontvangen van een UDP-pakket met

spraakdata en het afspelen van geluid door een audio-device dat geïmplementeerd is in de Ekiga-

bibliotheek.

Tenslotte hebben we nog enkele klassen die minder belangrijk zijn voor ons onderzoek. Het betreft

hier klassen om een unieke identifier te genereren, een antwoordapparaat te implementeren, etc.

Hier zullen we bijgevolg ook niet dieper op ingaan.


SIP

In de sip-module staan, zoals de naam het zelf zegt, de klassen die de implementatie van het SIP-

protocol verzorgen. We onderscheiden 4 bestanden in deze module: sipep, sipcon, sippdu en sdp. In

het SDP-bestand staan alle klassen en functies die te maken hebben met het Session Description

Protocol, een protocol dat door het SIP-protocol gebruikt wordt om over parameters van een

mediasessie te negotiëren27.

Bij het opstarten van Ekiga wordt er automatisch een instantie van de SIPEndPoint aangemaakt. Dit

object moet alle zaken die met het SIP-protocol te maken hebben delegeren. Bij het opzetten van

een gesprek zal hij een nieuwe SIPConnection aanmaken die alle zaken voor één bepaald SIP-gesprek

zal regelen. Om een SIP-gesprek op te zetten moeten er, zoals in het protocol beschreven staat,

controleboodschappen28 verstuurd worden. Al deze boodschappen zijn geïmplementeerd als

kindklasse van een SIPPDU (SIP protocol data unit).

Figure 30: Structuur SIP module

RTP

Wanneer een SIP-gesprek is opgezet zullen de spraakdata aan de hand van RTP-pakketten

uitgewisseld worden tussen de twee eindgebruikers. In de RTP-module wordt de functionaliteit

voorzien die deze RTP-pakketten in een juiste context kan plaatsen en afleveren aan een

mediastream die de informatie verder zal verwerken. Bovendien is de anti-jitter buffer29 ook in deze

module geïmplementeerd.

1.3 Pwlib

Zoals eerder vermeld bestaat de Pwlib-bibliotheek voornamelijk uit definities en implementaties van

PString en andere eigen gebruikte basisklassen. Aangezien we hier geen wijzigingen in zullen

aanbrengen is het ook een beetje zinloos om hier lang bij stil te staan. Het enige wat we van Pwlib

hoeven te weten is welke klassen we kunnen gebruiken en hoe deze klassen zijn opgebouwd om ze

te kunnen onderzoeken tijdens het debuggen.

27

cfr hoofdstuk 3 28

INVITE, BYE, OK, … 29

Zie hoofdstuk over pakketverlies en vertraging.


2. Opzetten van een Call Om een betere kijk op de werking van Ekiga (het programma, niet de bibliotheek) te krijgen zullen we

nu het geval beschrijven waarbij we een gesprek willen opzetten met een andere gebruiker. We

beschrijven hierbij het pad dat we door de code volgen. Alsof we stap voor stap het programma

uitvoeren met behulp van een debugger. Hierbij proberen we niet te veel stil te staan bij de details

om zo een overkill aan informatie te vermijden en een duidelijk beeld te scheppen van de werking

van het programma.

Figure 31: Call knop met SIP-url

We veronderstellen dat we aangemeld zijn onder de account van [email protected] en willen bellen

met [email protected]. Vooreerst vullen we [email protected] in als SIP-URL die we willen

contacteren. Wanneer we vervolgens op de call-knop klikken komen we in de callback-functie van

deze knop terecht. In deze functie zullen we eerst de SIP-URL die we willen bellen uit het tekstvak

lezen. Vervolgens checken we of we al een gesprek aan het voeren zijn.

Figure 32: Callback functie van "call"-knop

In dat geval zou een klik op de call-knop betekenen dat we het gesprek willen beëindigen. Dit is niet

het geval en dus zullen we een nieuw gesprek trachten op te zetten. We roepen de functie connect()

van de Ekiga-klasse op en geven de SIP-URL van Bob als parameter mee.

Druk op call-knop

CallBacks

connect_cb ()

1. Lees SIP-URL uit tekstvak

2. Controle of we reeds gesprek voeren

3. Roep Connect()-functie op

GnomeMeeting

Connect()

Figure 33: Connect_cb()-functie

In deze connect()-methode controleren we of de meegegeven SIP-URL niet leeg is, updaten we de gui

zodat de gebruiker kan zien dat er een poging wordt gedaan om het gesprek op te zetten en starten

we een nieuwe URLHandler op met opnieuw de SIP-URL als parameter. Een URLHandler is een thread

die ervoor zorgt dat het opzetten en onderhouden van het gesprek (verzenden van pakketten en


wachten op inkomende pakketten) het programma niet blokkeert maar toch voldoende processortijd

ter beschikking krijgt.

In de constructor van de URLHandler wordt de SIP-URL eerst geparst. Dit komt erop neer dat we

spaties voor en achter de PString die we uit het tekstvakje hebben uitgelezen weghalen en ook

controleren welk protocol we moeten gebruiken om dit gesprek op te zetten. Wanneer we met SIP

willen werken zullen we dit aangeven door als url “sip:[email protected]” op te geven. Het resultaat

van het parsen van deze PString is dat we een object van de klasse GMURL30 krijgen met als inhoud

de PString “[email protected]”. Nadat we een GMURL-object hebben aangemaakt verlaten we de

initialisatie en starten we de thread met het commando this.resume(). Vanaf nu zal de thread dus,

wanneer hij processortijd krijgt toebedeeld, de instructies van zijn main()-functie afwerken.

Figure 34: Opzetten van een URLHandler

In deze main()-functie zetten we de setup van ons gesprek voort met behulp van de functie

SetUpCall() uit de GMManager klasse. Hierbij geven we weer het adres van Bob mee als parameter.

De GMManager klasse is onderdeel van de endpoints-module in de Ekiga-bibliotheek en is bovendien

een kindklasse van de OpalManager klasse uit de Opal-bibliotheek. De SetUpCall()-method van de

GMManager-klasse zal bijgevolg ook de parameters doorgeven naar de SetUpCall()-method van de

OpalManager. Op die manier verlaten we de Ekiga-bibliotheek. Merk op dat we op dit punt nog geen

enkele “SIP-actie” ondernomen hebben en dat, zoals reeds eerder vermeld werd, de volledige

functionaliteit van het SIP-protocol zich in de Opal-bibliotheek bevindt.

Het eerste wat we doen in de SetUpCall()-method van de OpalManager is het opstellen van een

OpalCall object. Zo’n OpalCall-object stelt een gesprek voor en zal dus ook alle informatie over dat

gesprek bevatten. Elk OpalCall-object wordt geïdentificeerd door z’n call_token. Deze heeft op zich

geen enkele betekenis (in tegenstelling tot de call-ID van een SIP-gesprek) maar zal later gebruikt

worden om de gegevens van het huidige gesprek te kunnen opvragen. Nadat we het OpalCall-object

hebben gecreëerd en enkele variabelen ervan hebben gezet, gaan we verder met het oproepen van

de MakeConnection()-method van dezelfde OpalManager. Hierbij geven we de net aangemaakte

OpalCall mee als parameter.

30

GM komt van Gnome Meeting, de vroegere naam van Ekiga.


Figure 35: SetupCall() en MakeConnection()-functie

In de MakeConnection()-method zullen we aan de hand van de url van Bob uitmaken met welk soort

protocol we te maken hebben. Het endpoint van het desbetreffende protocol zal de setup van het

gesprek verder regelen. Merk hierbij op dat het OpalManager-object verschillende endpoints bevat.

Eén voor elk beschikbaar protocol. In ons geval zullen we verder gaan met de MakeConnection()-

method van de SIPEndPoint-klasse.

Figure 36: MakeConnection in OpalManager

Vanaf nu zijn we specifiek met het SIP-protocol bezig en bevinden we ons in de sip-module van de

Opal-bibliotheek. Het eerste wat we doen in de MakeConnection()-method van het SIPEndPoint is

een nieuwe call-ID aanmaken. Dit is een unieke identifier waarmee we ons gesprek lokaal en op het

netwerk zullen identificeren. We maken bovendien een SIPConnection aan en slaan deze op in een

tabel met zijn call-ID als index. Ook dit is belangrijk vermits we later de gegevens van deze

SIPConnection moeten opvragen om de handover te realiseren. Wanneer de SIPConnection is

aangemaakt en opgeslagen, roepen we de SetUpConnection()-method op.


Figure 37: MakeConnection()-functie van SIPEndpoint

In deze methode zullen we concreet de INVITE-boodschap van het SIP-protocol trachten te

versturen. Zoals eerder vermeld hebben we hier een Transport-object voor nodig. Er zijn

verschillende Transport klassen naar analogie met de verschillende transportprotocols. Ze bevatten

sockets waarover we pakketten zullen sturen. Wij zullen uiteraard gebruik maken van een

UDPTransport. Deze bevat een WriteConnect()-method. Hierin worden twee acties gecombineerd.

Vooreerst worden de sockets opgezet en de tweede actie wordt gedefinieerd door een function-

pointer die als parameter wordt meegegeven aan de WriteConnect()-method. In dit geval geven we

een pointer mee naar een functie die ervoor zorgt dat er een INVITE-boodschap verstuurd zal

worden over het UDPTransport. Deze functie is de WriteINVITE()-method van de SIPConnection

klasse.

Tenslotte zullen we in de WriteINVITE-method een nieuwe SIPTransaction aanmaken. We werken

met transacties omdat binnenkomende boodschappen gemakkelijker herkend zullen worden als

antwoord op een eerder verzonden boodschap. Een SIPTransaction bevat een INVITE-boodschap die

zal worden samengesteld door middel van de attributen die het SIPConnection en UDPTransport

bevatten. Zo zal het contact-veld worden opgesteld aan de hand van het IP-adres van de socket die

het UDPTransport heeft opgezet. De start()-method van de SIPTransaction zorgt ervoor dat de

aangemaakte INVITE-boodschap over het UDPTransport wordt verstuurd.

SIPConnection

WriteINVITE()

1. Creeer SIPTransaction-object

3. Roep Start()-functie op

SIPTransaction

Start()

1. Verstuur INVITE over Transport

SetUpConnection()

1. Creer UDPTransport

2. Roep WriteConnect()-functie op

UDPTransport

WriteConnect()

1. Activeer Sockets

2. Roep WriteINVITE()-functie op

Figure 38: Creatie van UDPTransport en verzenden INVITE-boodschap


Het opzetten van een VoIP-gesprek aan de hand van het SIP-protocol houdt natuurlijk niet op bij het

verzenden van een INVITE-boodschap. De code bespreken die de andere boodschappen ontvangt en

interpreteert is op dit moment echter van minder belang. Begrijpen hoe een INVITE-boodschap

wordt verstuurd is belangrijker voor de implementatie van de handover. Dit omdat we bij de

handover-procedure zullen starten met het versturen van een INVITE (met een extra join-header).

Figure 39 toont het volledige pad voor het verzenden van een INVITE.

Figure 39: Versturen van een INVITE, het volledige pad

3. Aanpassingen voor de handover Om het overzicht te bewaren is dit hoofdstuk opgesplitst in de verschillende fases van de handover-

procedure die we hebben vooropgesteld. De eerste fase is het versturen van een INVITE met join-

header naar de IMS-server31 van het oorspronkelijke gesprek. Vervolgens sturen we bij het

ontvangen van het eerste RTP-pakket op de nieuwe interface een ReINVITE-boodschap naar de

gebruiker waar we een gesprek mee voeren. Tenslotte zullen we nog een BYE-boodschap sturen naar

de IMS-server van het oorspronkelijke domein om die verbinding af te sluiten.

31

Die op dat moment als back to back user agent fungeert


3.1 INVITE met join-header

We hebben ons tot nu toe enkel geconcentreerd op het beschrijven van de handover-procedure op

zich en niet op het triggeren ervan. Een trigger voor het uitvoeren van de handover-procedure zou

bijvoorbeeld kunnen zijn dat de sterkte van het draadloze netwerk verzwakt en we moeten

overschakelen naar een GPRS-verbinding. Voor de eenvoud gebruiken we in ons project een extra

knop in de menubalk van Ekiga. We zullen bij de implementatie de overgang van de reeds aanwezige

verbinding (GPRS of in onze testopstelling LAN) naar het draadloze netwerk realiseren.

Figure 40: Join knop

Het eerste wat we toegevoegd hebben aan de code van Ekiga is een knop waarmee we de handover-

procedure in gang kunnen zetten. Wanneer we deze knop indrukken komen we naar analogie met

het indrukken van de call-knop terecht in de callbackfunctie van deze knop. In deze functie roepen

we de functie WifiAvailable() op uit de GnomeMeeting-klasse.

Figure 41: JoinButton callbackfunctie

In deze WifiAvailable()-functie stellen we een tabel op met alle beschikbare interfaces en hun

toegewezen IP-adres. Uit deze tabel zoeken we de interface met naam “eth1”. Dit is de interface van

ons draadloos netwerk. Wanneer we deze interface gevonden hebben, en er dus een IP-adres is

toegewezen aan deze interface, kunnen we de handover-procedure starten. We geven het

toegewezen IP-adres mee als parameter in de HandOver()-functie van de GMManager-klasse.

Figure 42: WifiAvailable functie

Naar analogie met het opzetten van een gesprek geven we het IP-adres als parameter door naar de

gelijknamige functie in de ouderklasse van de GMManager: OpalManager. Met deze stap verlaten we

de Ekiga-bibliotheek en komen we in de Opal-bibliotheek terecht. We merken meteen op dat net

zoals bij het opzetten van een gesprek, het grootste deel van de functionaliteit van de handover-

procedure zich in de Opal-bibliotheek bevindt.


Figure 43: Overgang van Ekiga- naar Opal-bibliotheek

In de HandOver()-functie van de OpalManager zoeken we eerst de OpalCall van het huidige gesprek

op. Dit object gebruiken we om gegevens van het huidige gesprek op te vragen. Bovendien zullen we

wijzigingen aan deze OpalCall aanbrengen omdat we nieuwe verbindingen zullen gebruiken voor het

sturen van SIP-boodschappen. We geven de OpalCall mee als parameter van de SwitchConnection()-

functie die zich in dezelfde OpalManager bevindt.

Figure 44: HandOver functie

De SwitchConnection()-functie heeft een gelijkaardige taak voor de handover-procedure als de

MakeConnection()-functie voor het opzetten van een gesprek. Eerst schrijven we het IP-adres van de

nieuwe interface weg naar een plaatselijke variabele zodat we het later nog kunnen gebruiken. Bij

het opzetten van een gesprek onderzoeken we in de MakeConnection()-functie welk protocol we

moeten gebruiken en roepen we de MakeConnection()-functie op van het gepaste endpoint. In de

handover-procedure weten we echter dat we met het SIP-protocol te maken hebben. We kunnen

meteen de MakeConnection()-functie van het SIPEndpoint oproepen. Hierbij geven we de OpalCall

en het IP-adres van de nieuwe interface als parameters mee.

Figure 45: SwitchConnection, van OpalManager naar SIPEndpoint

De eigenlijke functionaliteit van de handover-procedure is volledig gelokaliseerd in het SIPEndpoint.

Aan de hand van een drietal functies wordt ervoor gezorgd dat nieuwe verbindingen worden

opgezet, oude verbindingen worden verbroken en de nodige boodschappen worden verstuurd. De

eerste van deze functies is de SwitchConnection()-functie. In deze functie zullen we ervoor zorgen

dat er een SIP INVITE-aanvraag met join-header wordt verstuurd naar de IMS-aanvraag van het

huidige gesprek. Deze aanvraag sturen we van uit onze nieuwe interface. Bovendien zorgen we

ervoor dat de RTP-pakketten die de P-CSCF zal sturen goed opgevangen worden.


Vooreerst nemen we het adres van de IMS-server (voor de eenvoud hard gecodeerd) en zetten we

het om naar een SIP-URL. Deze zullen we gebruiken als bestemming voor de INVITE met join-header.

Vervolgens zoeken we de SIPConnection op die de informatie bevat over de verbinding die

geassocieerd is met het huidige gesprek. Deze hebben we nodig omdat we een juiste CSeq moeten

meegeven aan de SIP-boodschap die we gaan versturen. Aan de hand van een extra toegevoegde

constructor maken we een nieuwe SIPConnection aan. Hierbij zorgen we ervoor dat deze

SIPConnection gebruik maakt van de nieuwe interface om haar berichten te sturen. Via de

SendJOIN()-functie van de SIPConnection-klasse activeren we de eerste fase van de handover-

procedure: het versturen van de INVITE met join-header. Extra uitleg over de SendJOIN()-functie

volgt zo meteen.

Nadat de SIP-boodschap met succes verstuurd is moeten we er nog voor zorgen dat RTP-pakketten

ontvangen en verwerkt kunnen worden. Bij de standaard setup van een SIP-gesprek wordt dit in

twee fases geregeld. Bij het opstellen van de SDP-inhoud van de INVITE-boodschap worden de RTP-

mediastreams voorbereid. Wanneer we de SDP-beschrijving van de gesprekspartner in de OK-

boodschap ontvangen, gebruiken we deze om de RTP-mediastreams definitief op te zetten. De eerste

fase wordt bij het versturen van de INVITE met join-header ook uitgevoerd. We krijgen echter geen

OK-boodschap met een SDP-beschrijving terug van de server. We zullen de rest van de setup van de

RTP-mediastreams dus op een andere manier moeten uitvoeren. We hebben voor een oplossing

gekozen waarbij we een doen alsof we een SDP-beschrijving ontvangen. Aan de hand van deze fake-

SDP zal de setup van de RTP-mediastreams vervolledigd worden. We stellen de fake-SDP samen door

het contact IP-adres en de mediapoorten van de verzonden SDP-beschrijving aan te passen. Nadat de

RTP-mediastreams zijn opgezet is Ekiga in staat om RTP-pakketten via beide interfaces te ontvangen.

Daarmee ronden we de eerste fase van de handover-procedure af.

Figure 46: SwitchConnection()-functie in SIPEndpoint

We komen nog even terug op het samenstellen en versturen van de INVITE met join-header in de

SendJOIN()-functie van SIPConnection. Het samenstellen van de INVITE met join-header en het

versturen ervan over de juiste interface is verspreid over verschillende functies. We zullen niet te

diep ingaan op de manier waarop de functionaliteit over deze functies werd verdeeld. In de plaats

daarvan zullen we enkele belangrijke acties toelichten. Zoals reeds vermeld in de algemene uitleg van

de Opal-bibliotheek hebben we een Transport-object nodig om een boodschap over te versturen.

Om te verzekeren dat de INVITE over de nieuwe interface wordt verstuurd, zullen we bij de creatie

van het Transport-object ervoor zorgen dat het geassocieerd wordt met deze interface. Dit doen we

door het IP-adres van de nieuwe interface als parameter aan de constructor mee te geven.

Het samenstellen van de INVITE met join-header komt grotendeels overeen met het samenstellen

van normale INVITE aanvraag. Het enige verschil is dat we een extra header zullen toevoegen: de


join-header. Deze header zullen we aanmaken in de SIPConnection omdat de gegevens die we nodig

hebben om deze join-header samen te stellen in deze klasse beschikbaar zijn. De join-header bestaat

uit de call-ID van het huidige VoIP gesprek, gevolgd door de tag’s van beide gebruikers32. Nadat we

de INVITE met join-header hebben samengesteld zorgen we er met de functie start() voor dat de

boodschap verstuurd wordt.

Figure 47: Verzenden INVITE met join-header

Figure 48 geeft het volledige pad van het verzenden van de INVITE met join-header weer.

Figure 48: Verzenden INVITE met join-header, volledige pad

3.2 RTP-pakket filter

De P-CSCF zal op het moment dat hij de INVITE met join-header ontvangt alle RTP-pakketten die van

vaste gebruiker (Bob) komen verdubbelen en naar beide interfaces van de mobiele gebruiker (Alice)

sturen. We zullen aan de zijde van Alice dus een filter moeten plaatsen om er voor te zorgen dat de

32

Vb: “join:123456;to-tag=001;from-tag=002”


pakketten niet tweemaal verwerkt worden. Als basis voor deze filter gebruiken we de sequence-

nummer33 van de RTP-pakketten. Wanneer een RTP-pakket toekomt zullen we de sequence-nummer

van dit pakket vergelijken met het volgende sequence-nummer dat we verwachten. Indien ze gelijk

zijn is dit pakket het eerste dat is toegekomen van de twee verstuurde versies. We verwerken het

pakket en verhogen het verwachte sequence-nummer.

Wanneer we de tweede versie van hetzelfde pakket ontvangen, vergelijken we het sequence-

nummer opnieuw met het volgende sequence-nummer dat we verwachten. Deze zijn nu niet gelijk

en bijgevolg laten we het pakket vallen. Op die manier zullen nooit twee dezelfde versies van een

pakket verwerkt worden.

Figure 49: RTP-pakket filter

We hebben door het versturen van de INVITE met join-header en het implementeren van de RTP-

pakket filter er nu voor gezorgd dat we geen pakketten zullen verliezen tijdens de overgang van de

oude naar de nieuwe interface. Om onze handover-procedure verder te zetten moeten we nu echter

nog een ReINVITE-boodschap sturen naar de vaste host. Deze boodschap mag pas verstuurd worden

op het moment dat we het eerste RTP-pakket via de nieuwe interface binnenkrijgen. Dit RTP-pakket

is dus afkomstig van de P-CSCF. Deze ReINVITE-boodschap zorgt ervoor dat we een nieuw gesprek

opzetten met de vaste host, gebruik makend van de nieuwe interface. Hiervoor zullen we bijgevolg

ook nieuwe SIPConnection entiteiten voor aanmaken. Wanneer deze verbinding is opgezet zullen we

een BYE-boodschap naar de PCSCF van de oorspronkelijke verbinding sturen om de deze af te sluiten.

Deze BYE-boodschap mag pas verstuurd worden op het moment dat het eerste RTP-pakket via de

nieuwe verbinding toekomt. Merk op dat dit een verbinding is tussen de twee eindgebruikers, en niet

tussen de P-CSCF en de nieuwe interface.

Om de handover-procedure voort te zetten zullen we dus nieuwe functies moeten oproepen vanuit

de threads die de RTP-pakketten ontvangen. Naast de filter implementeren we ook een trigger die

ervoor zorgt dat de handover-procedure verder gezet wordt. De trigger is gebaseerd op twee feiten:

1. de handover fase waarin we ons bevinden

2. het feit dat het pakket dat we ontvangen het eerste is binnen deze thread.

Er bestaan 3 verschillende handover fases: join, reinvite en done. De join-fase gaat in zodra we de

INVITE met join-header verstuurd hebben. Wanneer we de ReINVITE-aanvraag verstuurd hebben

gaan we over naar de reinvite-fase. Voor het versturen van de INVITE met join-header en na het

ontvangen van het eerste RTP-pakket op nieuwe verbinding bevinden we ons in de done-fase.

33

Verwijzing naar hoofdstuk over RTP


Wanneer we ons in de join-fase bevinden en we krijgen het eerste pakket binnen in een thread34,

betekent dit dat de P-CSCF de nieuwe interface bereikt heeft en dat we de ReINVITE mogen sturen.

Bovendien schakelen we over naar de reinvite-fase. Bij het ontvangen van het eerste pakket in een

thread35 in de reinvite-fase vervolledigen we de handover door een BYE-boodschap naar de PCSCF te

sturen en komen we terug in de done-fase terecht.

Eerste ontvangen pakket in de thread?

1.Verstuur ReINVITE

2.Verander naar reinvite-fase

3.pas filter toe op pakket


Ja Nee

In welke fase bevinden we ons?

1.Vervolledig handover

2.Verander naar done-fase



join reinvite done

Figure 50: Beslissings diagram trigger

3.3 ReINVITE

Zoals we in hoofdstuk 6 reeds aanhaalden is een ReINVITE-boodschap eigenlijk een gewone INVITE-

aanvraag waarbij de via- en contact-header aangepast zijn met de gegevens van de nieuwe

verbinding. De implementatie hiervan is bijgevolg zeer eenvoudig. Het versturen van de ReINVITE is

vrijwel analoog aan het versturen van de INVITE met join-header. In de ReInvite()-functie van de

SIPEndpont-klasse zoeken we de SIPConnection-entiteit op om ervoor te zorgen dat de CSeq van de

ReINVITE-boodschap juist is. We creëren een nieuwe SIPConnection om de ReINVITE te versturen.

Deze SIPConnection zal de enige zijn die overblijft nadat de handover-procedure volledig uitgevoerd

werd. We roepen vervolgens de SendReInvite()-functie van deze SIPConnection op. In deze functie

creëren we een nieuw Transport waarover we de ReINVITE zullen sturen, maken we de ReINVITE-

boodschap aan en versturen we deze over het Transport.

Figure 51: ReInvite

3.4 Afsluiten oude verbindingen

Wanneer er door het sturen van de ReINVITE een nieuwe verbinding is opgezet tussen de vaste

gebruiker en de nieuwe interface kunnen we de oorspronkelijke verbinding (tussen de oude interface

en de vaste host) en de tijdelijke verbinding (tussen de nieuwe interface en de P-CSCF) afsluiten. We

34

Merk hierbij op dat er voor elke SIPConnection een thread wordt opgezet om RTP-pakketten te verwerken. De thread die we hier bedoelen is die de pakketten van de P-CSCF naar de nieuwe interface moet opvangen. 35

Deze thread is diegene die geassocieerd is met de SIPConnection tussen Bob en de nieuwe interface.


laten de P-CSCF weten dat hij mag stoppen met het verdubbelen van pakketten door een BYE-

boodschap te versturen. Daarna verwijderen we de twee SIPConnections die de oorspronkelijke en

tijdelijke verbinding voorstellen. Tenslotte zorgen we ervoor dat de nieuwste verbinding (tussen de

nieuwe interface en vaste gebruiker) door het programma beschouwd wordt als ‘oorspronkelijke

verbinding’. Op deze manier zorgen we ervoor dat een volgende handover-procedure mogelijk blijft.

Figure 52: CompleteHandover functie

60 | Hoofdstuk 8 - De IMS-Server

Hoofdstuk 8: De IMS-Server

Nu we de client-zijde onder handen hebben genomen, kunnen we onze focus verschuiven naar de

server. Zoals blijkt uit onze voorgestelde handover-strategie zullen we de standaard functionaliteit

van de P-CSCF moeten uitbreiden. Zo zal de SIP-server een INVITE met join-header moeten kunnen

interpreteren. Bovendien zal de server zich als B2BUA positioneren tussen beide gesprekspartners.

Dit houdt in dat SIP- en SDP-boodschappen aangepast moeten worden en er een RTP-pakket

replicator zal moeten worden voorzien. In dit hoofdstuk gaan we wat dieper in op de manier waarop

deze extra functionaliteit werd geïmplementeerd.

1. De basis IMS-server In hoofdstuk 2 hebben we een kort overzicht gegeven van IMS. Hieruit bleek dat de SIP-

functionaliteit over verschillende netwerkknopen wordt verdeeld. Voorbeelden zijn de verschillende

CSCF-servers en de HSS. We herinneren dat IMS eigenlijk geen netwerkknopen definieert maar

functies. Op die manier is de netwerkontwerper vrij om te kiezen of hij elke functie in een aparte

netwerkknoop implementeert of ze allemaal onderbrengt onder één en dezelfde machine. Voor dit

onderzoek hebben wij voor de tweede optie gekozen.

In paragraaf 2 van hoofdstuk 5 stelden we een vereenvoudigde architectuur van IMS voor waar we in

dit project gebruik van zullen maken. Deze architectuur omvat de drie CSCF servers (P-CSCF, S-CSCF

en I-CSCF), een SIP Application Server (die ook de functie van mediagateway vervult) en een HSS.

Deze 5 netwerkfuncties zullen allen op dezelfde machine geïmplementeerd worden. De SIP

Application Server is voor de basiswerking van de server nog niet aanwezig maar komt aan bod

wanneer we de standaardserver zullen uitbreiden met de functionaliteit die we voor de handover-

procedure nodig hebben. Vanaf nu zullen we geen onderscheid meer maken tussen de verschillende

functies. Wanneer we het over de IMS-server hebben, bedoelen we de machine waarop de 5 functies

geïmplementeerd zijn. Dit komt overeen met de totale functionaliteit van het vereenvoudigde IMS-

netwerk.

Tot slot merken we nog op dat we JAIN SIP (NIST, 2001)gebruikt hebben voor de implementatie van

de IMS-server. JAIN SIP is een gestandaardiseerde API voor de SIP-stack.

Figure 53: IMS-Server


2. Back to Back User Agent De eerste functionaliteit die we aan de standaard IMS-server toevoegen is de mogelijkheid om op te

treden als B2BUA. In paragraaf 2.2 van hoofdstuk 6 hebben we reeds aangehaald dat dit noodzakelijk

is voor het realiseren van onze handover. De bedoeling van een B2BUA is om ervoor te zorgen dat hij

al het data- en signalisatieverkeer tussen de twee gesprekspartners ontvangt en bijgevolg alle

pakketten kan onderzoeken of wijzigen. Als B2BUA zal de IMS-server zich in het pad tussen de twee

gesprekspartners positioneren. Hij zorgt ervoor dat beide gesprekspartners denken dat ze met de

IMS-server een gesprek aan het voeren zijn, en bijgevolg alle SIP-boodschappen en RTP-pakketten

naar de IMS-server sturen en niet naar de hun eigenlijke gesprekspartner. Om dit te realiseren zullen

we de inhoud van SIP- en SDP-boodschappen wijzigen.

Figure 54: Back to Back user agent

2.1 SIP- en SDP-boodschappen

We veronderstellen opnieuw Alice en Bob, twee gebruikers die een gesprek willen opzetten.

Wanneer Alice naar Bob wil bellen zal ze een INVITE-boodschap versturen naar haar P-CSCF server (in

dit geval de IMS-server). In het Contact- en Via-veld van de SIP-header zal de contactinformatie (IP-

adres en poortnummer) van Alice opgenomen worden. Op deze manier zal Bob weten waar hij zijn

antwoord op de INVITE-boodschap naartoe moet sturen. De IMS-server zal het Contact- en Via-veld

van de INVITE-aanvraag echter aanpassen. In plaats van de het IP-adres van Alice zal de IMS server

zijn eigen IP-adres plaatsen en ook de poort van Alice wordt vervangen door de poort van de IMS-

server. Dit heeft tot gevolg dat Bob zijn antwoord naar de IMS-server zal sturen en niet naar Alice. Op

dezelfde manier zal de IMS-server het Contact- en Via-veld van het antwoord van Bob aanpassen

zodat Alice al haar volgende SIP-boodschappen naar de IMS-server in plaats van naar Bob zal sturen.

INVITE van Alice naar IMS-server INVITE van IMS-server Bob


Via: SIP/2.0/UDP 10.10.5.50:5060

To: sip:bob@ jan-ims.test From: sip:alice@ jan-ims.test



Via: SIP/2.0/UDP 10.10.5.30:5060

To: sip:bob@ jan-ims.test From: sip:alice@ jan-ims.test


De IMS Server zal echter wel een tabel moeten bijhouden met de werkelijke IP-adressen van Alice en

Bob. Wanneer hij het antwoord van Bob krijgt zal hij in de tabel opzoeken wat het IP-adres is van

Alice zodat hij de boodschap kan doorsturen.

Het wijzigen van de SIP-headers is echter niet voldoende om ervoor te zorgen dat alle dataverkeer

tussen Alice en Bob via de IMS-server gaat. Zoals vermeld in 5.2.2 worden de RTP-pakketten op dit

moment nog steeds rechtstreeks verstuurd tussen Alice en Bob. De afspraken die gemaakt worden

betreffende het dataverkeer tussen beide gesprekspartners worden verwoord in de SDP-

boodschappen die als inhoud van de SIP-boodschappen worden uitgewisseld. In de SDP-boodschap

vermeldt de gebruiker niet enkel de codecs die hij ondersteunt maar ook de IP-adressen en poorten


waarop hij luistert naar inkomende datapakketten. Net als bij de wijziging van de SIP-boodschappen

zal de IMS-server deze IP-adressen en poorten in de SDP-boodschap aanpassen. Op deze manier

zullen ook de RTP-pakketten niet rechtstreeks maar via de IMS-server uitgewisseld worden.

SDP van Alice naar IMS-server SDP van IMS-server Bob

o= 1073055600 1073055600 IN IP4 10.10.5.50 c=IN IP4 10.10.5.50 t= 23456 23456 m=audio 5000 RTP/AVP 112 113 a =rtpmap:112 L16/48000/2 a=rtmap:113 DAT12/32000/4 a=fmtp:113 contents:DV L/R/C/WO


SDP van Bob naar IMS-server SDP van IMS-server Alice



Het feit dat de IMS-server acteert als b2bua heeft natuurlijk alles te maken met onze handover-

procedure. Op het moment dat de IMS-server de INVITE met join-header van Alice ontvangt zal hij

alle RTP-pakketten van Bob moeten verdubbelen en naar beide interfaces van Alice sturen. Hiervoor

gebruiken we het Application Server gedeelte van de IMS-server. De poorten die we invullen in plaats

van de locale poorten van Alice en Bob in de SDP-boodschappen zijn dus de poorten waarop de

Application Server luistert. De Application Server zal zelf de juiste poorten van de gesprekspartners in

een tabel bijhouden om de binnenkomende pakketten juist door te sturen.

Figure 55: Back to Back user agent: data

2.2 INVITE met join-header

Op dit moment heeft de IMS-server zich volledig als back to back user agent gemanifesteerd in het

netwerk. Alle SIP-setupboodschappen en alle RTP-datapakketten die tussen twee gebruikers worden

uitgewisseld, komen voorbij de IMS-server. Nu hebben we echter nog niets extra geïmplementeerd

dat rechtstreeks met de handover te maken heeft. De belangrijkste taak van de server tijdens de

handover-procedure is het verdubbelen van pakketten die van Bob komen en deze naar de

verschillende interfaces sturen van Alice sturen. Dit zal de server doen zodra hij de INVITE met join-


header van Alice heeft ontvangen. In deze SIP-boodschap staat alle informatie die de server nodig

heeft om het verdubbelen van de pakketten te starten.

INVITE met join-header

INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.32.5:5060 To: [email protected] From: <[email protected]>;tag=003 Call-Id: call1 CSeq 1 INVITE Contact: <sip:[email protected]> Join: call1;to-tag=002;from-tag=001

Uit het Via-veld van de INVITE kan de server het IP-adres en de poort halen waar hij de verdubbelde

pakketten naartoe moet sturen. De join-header levert informatie over welk gesprek het gaat. De IMS-

server zal de nodige informatie uit de boodschap halen en op basis van deze informatie de nodige

instructies geven aan de Application Server. In dit geval moeten alle pakketten van het VoIP gesprek

met call-ID “call1” die van de gebruiker met “tag=00236” komen, verdubbeld worden waarbij het

verdubbelde pakket naar 192.168.32.5 gestuurd moet worden. De poort waar de RTP-pakketten

moeten worden gestuurd, haalt de server uit de SDP-inhoud van de boodschap. Bovendien zal Alice

vanaf het moment dat ze de INVITE met join-header heeft verstuurd, alle gespreksdata via haar twee

interfaces naar de server sturen. Dit heeft als gevolg dat de Application Server één op twee

pakketten zal moeten wegfilteren.

Samengevat zal de IMS-server bij het ontvangen van de INVITE met join-header ervoor zorgen dat de

Application Server alle pakketten van Bob zal verdubbelen en naar beide interfaces van Alice zal

sturen. Bovendien zal hij een filter plaatsen op de pakketten die hij van Alice krijgt om te vermijden

dat Bob alle data dubbel toegestuurd krijgt.

Figure 56: Pakket Replicator in join-fase

36

Extra uitleg over tag: worden bij setup meegegeven en worden gebruikt als identifier van gesprekspartners zonder dat het IP-adres moet gebruikt worden.

64 | Hoofdstuk 9 - Conclusies

Hoofdstuk 9: Conclusies

In de voorbije hoofdstukken hebben we gezien dat IMS de nodige netwerkondersteuning biedt om

de handover te realiseren. De client en de server zijn aangepast aan de specificaties van de handover

procedure. Volgende stap is nu het testen van de performantie van onze handover procedure op

gebied van pakketverlies en jitter. Door omstandigheden en hardnekkige hardware problemen is de

implementatie van de handover op de client echter niet af geraakt. In dit hoofdstuk lichten we deze

problemen toe en stellen we een testplan op dat kan gebruikt worden om de performantie van de

seamless handover te controleren en te optimaliseren.

1. Problemen Zoals vermeld hebben enkele onvoorziene omstandigheden het verloop van de thesis sterk

bemoeilijkt. In de beschrijving van deze thesis op Plato werd duidelijk gemaakt dat men iemand zocht

die ervaren was in het programmeren in Java. Dit was een van de hoofdredenen waarom ik deze

thesis gekozen heb. Na enkele maanden onderzoek over IMS kwamen we echter tot de conclusie dat

de Java client die we zouden gebruiken nog in een vroege staat van ontwikkeling was. Dit maakte het

onmogelijk om deze client aan te passen aan de behoeften van de handover procedure. In onze

zoektocht naar een nieuwe open source SIP VoIP client ondervonden we dat de mogelijkheden zeer

beperkt waren. Ekiga was de enige client die voldoende basis ondersteuning gaf maar bovendien ook

open source was. De keuze voor Ekiga ging echter gepaard met 2 problemen. Ekiga is een VoIP client

die in C++ geschreven werd. Met C++ had ik tot op dat moment echter nog geen enkele ervaring.

Laat staan met network programming in C++. Bovendien is Ekiga een Linux client en mijn ervaring

met Linux was op dat moment ook uitermate beperkt.

Ik moet u niet vertellen dat deze onvoorziene omstandigheden de nodige vertraging met zich mee

brachten. Een basiscursus C++ kon me slechts op weg helpen met het begrijpen van de code van

Ekiga aangezien alle aspecten van (netwerk)programmeren in de verschillende bibliotheken37 aan

bod kwamen. Maar niet enkel de kennis van het besturingssysteem of de programmeertaal zorgden

voor problemen. Het zoeken naar een ontwikkelomgeving die voldoende ondersteuning gaf voor

debugging ging ook niet van een leien dakje. Voor het ontwikkelen onder C++ geeft Visual C++ de

beste ondersteuning. Aangezien dit echter een programma voor Windows is, konden we Visual C++

niet gebruiken. Een andere mogelijke oplossing is Eclipse. Aan de hand van een extra plugin biedt

deze, voor Java gemaakte ontwikkelomgeving, de nodige ondersteuning voor C++. Bovendien is

Eclipse platformonafhankelijk en kan het dus ook onder Linux gebruikt worden.

Al snel bleek echter dat de stabiliteit van deze plugin onder Linux niet vanzelfsprekend was. Het

duurde bovendien tot februari voor we de debugger werkende kregen. Het ontbreken van een

werkende debugger zorgde ervoor dat ik veel te veel tijd heb moeten steken in het begrijpen van de

code van Ekiga. Dit ook omdat Ekiga zo’n uitgebreide functionaliteit bevat.

In het tweede semester kon het echte programmeren beginnen maar ook hier stootten we op

aanzienlijk wat problemen. Uiteindelijk ben ik moeten stoppen op een hardware probleem dat ik niet

37

Ekiga, Opal en Pwlib


tijdig opgelost kreeg. Dit probleem bestond erin dat het programma geen tweede mediastream wilde

opzetten tussen een interface en de ‘reeds gebruikte’ audio output. Ik heb het probleem kunnen

lokaliseren tot een functie in de Pwlib-bibliotheek. De debugger werkt echter enkel in de Ekiga en

Opal-bibliotheek en bijgevolg is ook niet duidelijk of het gaat om een hardware probleem, zoniet een

software probleem in de Pwlib-bibliotheek.

Om het onderzoek toch af te krijgen zou dit probleem dus eerst moeten opgelost worden. Het

probleem situeert zich op het moment dat er na het versturen van de INVITE met join-header media

streams moeten opgezet worden met de P-CSCF. Dit is nog in de eerste fase van de handover maar

de code voor de RTP-filter en het versturen van ReINVITE en BYE boodschappen is reeds geschreven

naar analogie met het versturen van de INVITE met join-header. Problemen die we daar eventueel

zouden tegenkomen zullen analoog zijn aan die van het versturen van deze eerste boodschap en

zouden dus snel opgelost moeten kunnen worden.

2. Testopstelling Wanneer de beschreven code af is en client en server zijn in staat om de handover procedure uit te

voeren, is het werk echter nog niet af. In paragraaf 3.1 van hoofdstuk 7 beschreven we hoe de

handover procedure momenteel manueel gestart wordt door een extra join-knop. Dit is echter niet

voldoende. In de probleemstelling hebben we gesteld dat de handover automatisch moet gebeuren.

Wanneer we ons binnen het bereik van het draadloze thuisnetwerk bevinden moeten we

automatisch op dat netwerk overschakelen. In het andere geval gebruiken we de GPRS-verbinding38.

Er moet dus extra code geschreven worden om de sterkte van het draadloze netwerk te controleren.

Wanneer de sterkte van het draadloze netwerk te laag wordt, zullen we een handover van het

draadloze netwerk naar de LAN-verbinding moeten triggeren. Wanneer we verbonden zijn met de

LAN-verbinding en de sterkte van het draadloze netwerk overschrijdt een vooraf gedefinieerde

drempelwaarde zullen we een handover van de LAN-verbinding naar het draadloze netwerk moeten

triggeren.

Om nu testen uit te voeren om een ideale drempelwaarde te bepalen zullen we de sterkte van het

draadloze netwerk moeten varieren. Dit kan op verschillende manieren.

Een voor de hand liggende methode is de computer waarop de Ekiga client geïmplementeerd is

verder van en dichter bij het draadloze toegangspunt39 te brengen. Dit brengt echter de nodig

problemen met zich mee. Vermits we een LAN-verbinding gebruiken in plaats van een GPRS-

verbinding zullen we een lange LAN-kabel moeten voorzien om onze verplaatsingen te kunnen

volgen. Bovendien kunnen andere draadloze netwerken voor interferentie zorgen en onze resultaten

beïnvloeden.

We kunnen echter ook gebruik maken van een speciaal toestel: de qosmotec. De qosmotec is een

cabine waar we de computer met de Ekiga client in kunnen onderbrengen. Het toestel beschermt

onze testopstelling tegen interferenties van andere draadloze netwerken en biedt de mogelijkheid

om de sterkte van ons eigen draadloos netwerk te regelen. Op deze manier kunnen we zonder

38

In onze testopstelling: LAN-verbinding 39

Vb: een draadloze router


ingewikkelde acties en zonder storing van andere netwerken de drempelwaarde voor de handover

bepalen. Figure 57 geeft een beeld van de opstelling.

Figure 57: Testopstelling

Met deze testopstelling kunnen we nu de situatie waarin onze handover zich voordoet simuleren. De

drempelwaarde voor de handover is echter niet de enige parameter die invloed heeft op het slagen

van onze seamless handover.

In theorie mogen we inderdaad geen pakketverlies ondervinden maar de delay jitter moet ook onder

controle gehouden worden. De variatie in vertraging van pakketten wordt opgevangen door de

dejitter buffer van Ekiga zelf. De grootte van deze buffer kunnen we instellen. Zoals we reeds in

hoofdstuk 5 aanduidden gaat het opvangen van delay jitter gepaard met het invoeren van een vaste,

extra vertraging. We zullen een afweging maken tussen de hoeveelheid variatie in vertraging die we

kunnen opvangen, en de grootte van de extra vertraging. Hoe groter de extra vertraging, hoe meer

delay jitter we kunnen opvangen.

Een parameter die zeker ook zijn invloed heeft op de mogelijke jitter is het verschil in vertraging

tussen de verschillende netwerken (LAN en draadloos). We weten dat het versturen van een pakket

door een netwerk een vertraging met zich meebrengt. Deze vertraging hangt af van het pad dat het

pakket volgt en dus ook van de netwerktechnologie zelf40. Een groot verschil tussen de vertragingen

die beide netwerken met zich meebrengen kan leiden tot een grote delay jitter en zal bijgevolg de

keuze van de grootte van de dejitter buffer van Ekiga beïnvloeden.

Ook de end-to-end vertraging tussen de verschillende clients en de vertraging tussen de twee

netwerken heeft zijn invloed op de handover. Deze vertragingen bepalen namelijk te tijd die de SIP-

boodschappen er over doen om uitgewisseld te worden tussen de verschillende

netwerkcomponenten. Is deze vertraging groot, en duurt het dus lang om de INVITE met join-header,

ReINVITE en andere SIP-boodschappen uit de handover te versturen, dan zal de handover procedure

op zich ook lang duren. Dit brengt met zich mee dat de drempelwaarde voor het overschakelen naar

het vaste netwerk (LAN in de testopstelling) hoger moet zijn. Op die manier zullen we de handover

sneller initialiseren. Doen we dit niet, dan kan het zijn dat de handover procedure te traag verloopt

40

Zie sectie 1.1 Vertraging uit hoofdstuk 5


en dat we ons al buiten het bereik van ons draadloos netwerk bevinden voordat de handover

vervolledigd werd.

Tenslotte zal het gebruik van verschillende codecs ook een verschillende bandbreedte, packetisation

delay, coding delay, etc met zich meebrengen. Bijgevolg zal de keuze van de codec ook zijn invloed

hebben op parameters van de handover.

In de testfase van dit project zullen we dus al deze parameters moeten variëren om zo de

drempelwaarde en grootte van de dejitter buffer voor verschillende omstandigheden te bepalen. We

evalueren de parameters steeds op basis van de kwaliteit van het gevoerde gesprek. Dit natuurlijk op

het moment dat we overschakelen van netwerk. Aan de hand van een MOS-score kunnen we deze

kwaliteit uitdrukken en vergelijken.

68 | Referenties

Referenties

3GPP. (1998). 3GPP home page. Opgehaald van http://www.3gpp.org/

3GPP. (1994). CAMEL Specifications. Opgehaald van http://www.3gpp.org/ftp/Specs/html-

info/22078.htm

Banerjee, K. (2005). Opgehaald van SIP Introduction:

http://www.geocities.com/intro_to_multimedia/SIP/registration.html

Banerjee, N., Acharya, A., & Das, S. K. (2006). Seamless SIP-Based Mobility for Multimedia

Applications. IEEE Network , 6-13.

Bates, R. ". (2001). GPRS: General Packet Radio Service. McGraw-Hill Professional.

Berners-Lee, T., Fielding, R., & Frystyk, H. (1996). Hypertext Transfer Protocol -- HTTP/1.0. RFC 1945.

Opgehaald van http://www.w3.org/Protocols/rfc1945/rfc1945

Calhoun, P., Loughney, J., Guttman, E., Zorn, G., & Arkko, J. (2003). Diameter Base Protocol. RFC

3588. Internet Engineering Task Force.

Camerillo, G., & Garcia-Martin, M. A. (2006). The 3G IP Multimedia Subsystem (IMS). John Wiley &

Sons,Ltd.

Demeester, P., & Pickavet, M. (2006). Multimedia Networks.

ETSI. (2004). European Telecommunications Standards Institute. Opgehaald van http://www.etsi.org/

GSM Association. (1987). GSM World - the website of the GSM Association. Opgehaald van

http://www.gsmworld.com/index.shtml

Internet Engineering Task Force. (2002). ISUP to SIP mapping. RFC 3398. Opgehaald van

http://www.ietf.org/rfc/rfc3398.txt

ITU. (1992). International Communications Union. Opgehaald van

http://www.itu.int/net/home/index.aspx

ITU-T. (2002). Gateway control Protocol. Recommendation H.248. Opgehaald van

http://www.itu.int/ITU-T/index.phtml

ITU-T. (1992). The ITU Telecommunication Standardization Sector. Opgehaald van

http://www.itu.int/ITU-T/index.phtml

Mockapetris, P. (1983). Domain Names - Concepts and Facilities. RFC 882. Internet Engineering Task

Force.

Moving Picture Experts Group (MPEG). (1998). MPEG home page. Opgehaald van

http://www.chiariglione.org/mpeg/

69 | Referenties

NeoNova bv. (2006). Wat is VoIP. Opgehaald van www.Astium.nl:

www.astium.nl/nl/download/wat_is_voip.pdf

NIST. (2001). jain-sip: JAVA API for SIP Signaling. Opgehaald van java.net: https://jain-

sip.dev.java.net/

OzVoIP.com. (2004). VoIP Codecs Clients Compare Codecs. Opgehaald van www.ozvoip.com:

http://www.ozvoip.com/codecs.php

Postel, J. B. (1982). Simple Mail Transfer Protocol. RFC 821. Opgehaald van

http://www.ietf.org/rfc/rfc0821.txt

Repiquet, J. (2005). IMS Call Flows. Opgehaald van Tech-Invite: http://www.tech-invite.com/Ti-ims-

regflow-2.html

Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., et al. (2002). SIP:

Session Initiation Protocol. RFC 3261. Opgehaald van http://www.ietf.org/rfc/rfc3261.txt

Sandras, D. (2003). Ekiga: Free your speech. Opgehaald van http://www.gnomemeeting.org/

Schulzrinne, H., Casner, S. L., Frederick, R., & Jacobson, V. (1996). RTP: A Transport Protocol for Real-

Time Applications. RFC 1889. Internet Engineering Task Force.

The Parlay Group. (2001). Parlay :: Parlay/OSA Specifications. Opgehaald van

http://www.parlay.org/en/specifications/apis_archives.asp

seamless handover in het ip multimedia...

Documents