Upload
trinhdung
View
214
Download
0
Embed Size (px)
Citation preview
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
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)
4 | Hoofdstuk 2 - Het 3G IP Multimedia Subsystem
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.
5 | Hoofdstuk 2 - Het 3G IP Multimedia Subsystem
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
6 | Hoofdstuk 2 - Het 3G IP Multimedia Subsystem
• 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.
8 | Hoofdstuk 3 - Het Session Initiation Protocol
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.
9 | Hoofdstuk 3 - Het Session Initiation Protocol
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 proxy- server
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.
10 | Hoofdstuk 3 - Het Session Initiation Protocol
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
…
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)
11 | Hoofdstuk 3 - Het Session Initiation Protocol
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
Header field name : Value CR/LF
…
Header field name : Value 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
12 | Hoofdstuk 3 - Het Session Initiation Protocol
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
To: sip:[email protected]
From: sip:[email protected]
Call-ID:call1
Contact: sip:[email protected]
[email protected]? 192.168.1.100 Idem boodschap 4
13 | Hoofdstuk 3 - Het Session Initiation Protocol
Na enkele antwoord- en 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.
14 | Hoofdstuk 3 - Het Session Initiation Protocol
REGISTER
REGISTER sip:registrar.biloxi.com SIP/2.0
Via: SIP/2.0/UDP 192.168.2.100:5060
To: sip:[email protected]
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
INVITE [email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060
To: sip:[email protected]
From: sip:[email protected];tag=001
Call-ID:call1
Cseq: 1 INVITE
Contact: sip:[email protected]
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.
15 | Hoofdstuk 3 - Het Session Initiation Protocol
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
From: sip:[email protected];tag=001
Call-ID:call1
Cseq: 1 ACK
Contact: sip:[email protected]
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.
17 | Hoofdstuk 3 - Het Session Initiation Protocol
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
INVITE [email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060
To: sip:[email protected]
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 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.
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.
20 | Hoofdstuk 4 - Voice over IP
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.
21 | Hoofdstuk 4 - Voice over IP
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
22 | Hoofdstuk 4 - Voice over IP
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)
23 | Hoofdstuk 4 - Voice over IP
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)
25 | Hoofdstuk 5 - De IMS-architectuur
• Éé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
26 | Hoofdstuk 5 - De IMS-architectuur
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
27 | Hoofdstuk 5 - De IMS-architectuur
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.
28 | Hoofdstuk 5 - De IMS-architectuur
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
29 | Hoofdstuk 5 - De IMS-architectuur
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.
30 | Hoofdstuk 5 - De IMS-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.
31 | Hoofdstuk 5 - De IMS-architectuur
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
32 | Hoofdstuk 5 - De IMS-architectuur
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
33 | Hoofdstuk 5 - De IMS-architectuur
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
35 | Hoofdstuk 6 - Seamless Handover
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
36 | Hoofdstuk 6 - Seamless Handover
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.
37 | Hoofdstuk 6 - Seamless Handover
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
38 | Hoofdstuk 6 - Seamless Handover
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.
39 | Hoofdstuk 6 - Seamless Handover
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
40 | Hoofdstuk 6 - Seamless Handover
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
41 | Hoofdstuk 6 - Seamless Handover
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
42 | Hoofdstuk 6 - Seamless Handover
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.
44 | Hoofdstuk 7 - Ekiga
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
45 | Hoofdstuk 7 - Ekiga
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
46 | Hoofdstuk 7 - Ekiga
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.
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
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.
47 | Hoofdstuk 7 - Ekiga
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.
48 | Hoofdstuk 7 - Ekiga
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
49 | Hoofdstuk 7 - Ekiga
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.
50 | Hoofdstuk 7 - 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.
51 | Hoofdstuk 7 - Ekiga
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
52 | Hoofdstuk 7 - Ekiga
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
53 | Hoofdstuk 7 - Ekiga
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.
54 | Hoofdstuk 7 - Ekiga
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.
55 | Hoofdstuk 7 - Ekiga
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
56 | Hoofdstuk 7 - Ekiga
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”
57 | Hoofdstuk 7 - Ekiga
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
58 | Hoofdstuk 7 - Ekiga
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
1.pas filter toe op pakket
Ja Nee
In welke fase bevinden we ons?
1.Vervolledig handover
2.Verander naar done-fase
3.pas filter toe op pakket
1.pas filter toe op pakket
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.
59 | Hoofdstuk 7 - Ekiga
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
61 | Hoofdstuk 8 - De 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
INVITE [email protected] SIP/2.0
Via: SIP/2.0/UDP 10.10.5.50:5060
To: sip:bob@ jan-ims.test From: sip:alice@ jan-ims.test
Contact: sip:[email protected]
INVITE [email protected] SIP/2.0
Via: SIP/2.0/UDP 10.10.5.30:5060
To: sip:bob@ jan-ims.test From: sip:alice@ jan-ims.test
Contact: sip:[email protected]
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
62 | Hoofdstuk 8 - De IMS-Server
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
o= 1073055600 1073055600 IN IP4 10.10.5.30 c=IN IP4 10.10.5.30 t= 23456 23456 m=audio 7001 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
o= 1073055600 1073055600 IN IP4 10.10.5.51 c=IN IP4 10.10.5.51 t= 23456 23456 m=audio 6000 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
o= 1073055600 1073055600 IN IP4 10.10.5.30 c=IN IP4 10.10.5.30 t= 23456 23456 m=audio 7000 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
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-
63 | Hoofdstuk 8 - De IMS-Server
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
65 | Hoofdstuk 9 - Conclusies
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
66 | Hoofdstuk 9 - Conclusies
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
67 | Hoofdstuk 9 - Conclusies
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