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
80
Embed
Seamless Handover in het IP Multimedia Subsystemlib.ugent.be/fulltxt/RUG01/001/312/195/RUG01-001312195...Seamless Handover in het IP Multimedia Subsystem door Jan VERMEULEN Scriptie
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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
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
3.2 DE RTP-HEADER ................................................................................................................................... 21
HOOFDSTUK 5: DE IMS-ARCHITECTUUR ....................................................................................... 24
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.
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
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
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
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: