Seamless Handover in het IP Multimedia Subsystem

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 AS B2BUA BGCF CAMEL CC Codec CSCF CSRC EDGE ETSI FEC GM GPRS GSM HSS HTTP I-CSCF IMS IM-SSF IP ISDN ISUP ITU LAN MGCF MGW MMS MOS MPEG MRF MRFC MRFP MTP OSA OSA-SCS PCM P-CSCF PSTN QoS RFC RTP S-CSCF SDP SGW SIP SLF SMS SMTP

Third Generation Partnership Project Application Server Back To Back User Agent Breakout Gateway Control Function Customized Applications for Mobile network Enhanced Logic CSRC count Coder/decoder Call/Session Control Function Contributing SouRCe Enhanced Data Rates for GSM Evolution European Telecommunications Standards Institute Forward Error Control GnomeMeeting General Packet Radio Service Global System for Mobile communications Home Subscriber System HyperText Transfer Protocol Interrogating-CSCF IP Multimedia Subsystem IP Multimedia Service Switching Function Internet Protocol Integrated Services Digital Network ISDN User Part International Telecommunications Union Local Area Network Media Gateway Controller Function Media Gateway Multimedia Messaging Service Mean Opinion Score Moving Pictures Experts Group Media Resource Function Media Resource Function Controller Media Resource Function Processor Message Transfer Part Open Service Access OSA-Service Capability Server Pulse Code Modulation Proxy-CSCF Public Switched Telephone Network Quality Of Service Request For Comments Real-Time Transport Protocol Serving-CSCF Session Description Protocol Signaling Gateway Session Initiation Protocol Subscriber Location Function Short Message Service Simple Mail Transfer Protocol

SSRC TCP ToS UDP UMTS URI URL URN VoIP

Synchronization SouRCe Transport Control Protocol Type Of Service User Datagram Protocol Universal Mobile Telephone System Uniform Resource Identifier Uniform Resource Locator Uniform Resource Name 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

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.

GPRS network

I.

Wireless homenetwork

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 Wifiinterface, 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 homenetwork, 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

P-CSCF

P-CSCF

I-CSCF

S-CSCF

SIP-AS

HSS 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 SIPrequest 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.

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

A.Join-fase At first the reader must know that the proxy servers (PCSCF) 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 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 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 PCSCF receives an INVITE with join-header, he will duplicate the RTP-session between Alice and Bob. The PCSCF 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 IMSterminal 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

It is clear that the new RTP-session is set up before the old one is released so as to avoid packet loss. Finally, Alice registers its new location information with the home networks S-CSCF by using a REGISTER message. IV. CONCLUSIONS The combination of the IMS architecture and our extention to the standard SIP-protocol offers a compatible alternative to circuit-switched phone calls. The IMS provides the packet-switched network architecture necessary to merge 3G and fixed networks into one network . The proposed extention to SIP allows us to switch between network interfaces during a call without suffering packet loss. This way a VoIP client application will always be able to detect and switch to the cheapest possible network interface to connect to the IMS network without having to restart the call or suffering any loss of quality. V. REFERENCES [1] G. Camerillo and M.A. Garcia-Martin. The 3G IP Multimedia Subsystem (IMS), John Wiley & Sons Ltd, 2006 [2] J. R. Bates, GPRS:General Packet Radio Service, McGraw and Hill Professional, 2001 [3]N.Banerjee, A, Acharya, S.K. Das, Seamless SIP-Based Mobility for Multimedia Applications, IEEE network, 2006

Inhoudsopgave HOOFDSTUK 1: INLEIDING .............................................................................................................1 HOOFDSTUK 2: HET 3G IP MULTIMEDIA SUBSYSTEM (IMS) .............................................................3 1. HET INTERNET EN CELLULAIRE NETWERKEN .......................................................................................3 2. WAAROM IMS ..........................................................................................................................3 3. ALGEMENE PRINCIPES VAN DE IMS-ARCHITECTUUR .............................................................................5 3.1 VAN CIRCUIT-SWITCHED NAAR PACKET-SWITCHED ........................................................................................ 5 3.2 VEREISTEN VOOR IMS ............................................................................................................................. 5 3.3 PROTOCOLS IN IMS................................................................................................................................. 6 HOOFDSTUK 3: HET SESSION INITIATION PROTOCOL (SIP) ..............................................................7 1. SITUERING ................................................................................................................................7 2. ALGEMEEN ................................................................................................................................8 3. TERMINOLOGIE ..........................................................................................................................8 4. SIP-BOODSCHAPPEN ................................................................................................................. 10 4.1 SIP-AANVRAAG .................................................................................................................................... 10 4.2 SIP-ANTWOORD................................................................................................................................... 10 5. REGISTRATIE ............................................................................................................................ 11 6. CALL SETUP ............................................................................................................................. 13 7. RECORD-ROUTE ....................................................................................................................... 17 HOOFDSTUK 4: VOICE OVER IP (VOIP) .......................................................................................... 19 1. INLEIDING ............................................................................................................................... 19 2. EISEN VOOR HET NETWERK .......................................................................................................... 19 3. REAL-TIME TRANSPORT PROTOCOL (RTP) ...................................................................................... 21 3.1 SITUERING ........................................................................................................................................... 21 3.2 DE RTP-HEADER................................................................................................................................... 21 HOOFDSTUK 5: DE IMS-ARCHITECTUUR ....................................................................................... 24 1. ALGEMENE IMS-ARCHITECTUUR ................................................................................................... 24 1.1 DE DATABANKEN: HSS EN SLF ................................................................................................................ 25 2. IMS IN ONS PROJECT ................................................................................................................. 29 3. BASIC SESSION SETUP ................................................................................................................ 30 3.1 DE IMS-TERMINAL ZENDT DE INVITE AANVRAAG ...................................................................................... 31 3.2 DE INITIËRENDE P-CSCF VERWERKT DE INVITE AANVRAAG ......................................................................... 31 3.3 DE INITIËRENDE S-CSCF VERWERKT DE INVITE AANVRAAG ......................................................................... 32

3.4 DE TERMINERENDE I-CSCF VERWERKT DE INVITE AANVRAAG ..................................................................... 32 3.5 DE TERMINERENDE S-CSCF VERWERKT DE INVITE AANVRAAG .................................................................... 33 3.6 DE TERMINERENDE P-CSCF VERWERKT DE INVITE AANVRAAG .................................................................... 33 3.7 DE IMS-TERMINAL ONTVANGT DE INVITE AANVRAAG................................................................................ 33 HOOFDSTUK 6: SEAMLESS HANDOVER......................................................................................... 34 1. EISEN VOOR APPLICATIES ............................................................................................................ 34 1.1 VERTRAGING ........................................................................................................................................ 34 1.2 PAKKET VERLIES .................................................................................................................................... 36 2. SEAMLESS HANDOVER: HOE GEREALISEERD ...................................................................................... 38 2.1 STANDAARD SIP: REINVITE ................................................................................................................... 38 2.2 ONZE OPLOSSING: INVITE MET JOIN-HEADER............................................................................................ 39 HOOFDSTUK 7: EKIGA.................................................................................................................. 43 1. STRUCTUUR ............................................................................................................................. 43 1.1 EKIGA ................................................................................................................................................. 44 1.2 OPAL .................................................................................................................................................. 45 1.3 PWLIB ................................................................................................................................................. 47 2. OPZETTEN VAN EEN CALL ............................................................................................................ 48 3. AANPASSINGEN VOOR DE HANDOVER ............................................................................................ 52 3.1 INVITE MET JOIN-HEADER ..................................................................................................................... 53 3.2 RTP-PAKKET FILTER ............................................................................................................................... 56 3.3 REINVITE ........................................................................................................................................... 58 3.4 AFSLUITEN OUDE VERBINDINGEN ............................................................................................................. 58 HOOFDSTUK 8: DE IMS-SERVER ................................................................................................... 60 1. DE BASIS IMS-SERVER ............................................................................................................... 60 2. BACK TO BACK USER AGENT ........................................................................................................ 61 2.1 SIP- EN SDP-BOODSCHAPPEN ................................................................................................................ 61 2.2 INVITE MET JOIN-HEADER ..................................................................................................................... 62 HOOFDSTUK 9: CONCLUSIES ........................................................................................................ 64 1. PROBLEMEN ............................................................................................................................ 64 2. TESTOPSTELLING ....................................................................................................................... 65 REFERENTIES ............................................................................................................................... 68

1 | Hoofdstuk 1 - Inleiding

Hoofdstuk 1: Inleiding Momenteel ondersteunen mobiele toestellen steeds meer mogelijkheden om te communiceren. Buiten het gewone bellen via het gsm netwerk kunnen we ondertussen ook al met ons mobiel toestel toegang tot het internet verkrijgen via GPRS, UMTS of I-mode. De duurdere smart phones zijn zelfs uitgerust met een draadloze netwerkinterface1. Om optimaal gebruik te kunnen maken van deze mogelijkheden heeft men een nieuwe netwerkarchitectuur ontwikkeld: het IP Multimedia Subsystem (IMS). Deze netwerkarchitectuur zorgt ervoor dat diensten die het internet zijn gebruikers met een computer aanbiedt, ook beschikbaar worden via mobiele toestellen. Omgekeerd worden typische mobiele diensten zoals SMS beschikbaar via het internet. Eén van die diensten die we via IMS op mobiele toestellen beschikbaar willen maken, is Voice over IP (VoIP). VoIP is een vorm van telefonie waarbij we gebruik maken van een packet-switched netwerk (het internet) om ons gesprek te voeren. Dit brengt met zich mee dat alle informatie die tussen twee gebruikers uitgewisseld wordt, aan de hand van IP-pakketten verstuurd wordt. Het werken met een packet-switched netwerk heeft enkele belangrijke voordelen ten opzichte van het circuit-switched telefonienetwerk waar we later verder op in zullen gaan. Aan de andere kant zijn de kosten van een GPRS-verbinding op dit moment nog te hoog om VoIP als concurrentie te zien voor klassieke telefonie met mobiele toestellen. De prijzen van GPRSverbindingen dalen echter snel en bovendien kunnen we, zoals eerder vermeld, op steeds meer toestellen gebruik maken van een draadloze netwerkinterface om verbinding te maken met een thuisnetwerk of hotspot. Zo hebben we ook toegang tot het internet en deze verbinding is gratis of beter gezegd: een vast abonnement. Wanneer we deze twee verbindingswijzen tot het packet-switched internet combineren, kunnen we de concurrentie aangaan met de klassieke telefonie. Binnen het bereik van ons draadloos thuisnetwerk maken we gebruik van de draadloze netwerkinterface en wanneer we weg van huis zijn, gebruiken we de GPRS-interface om toegang tot het Internet te verkrijgen. Dit is echter nog niet voldoende. Indien we thuis een VoIP telefoongesprek opzetten met behulp van onze draadloze netwerkinterface en we willen ondertussen het huis verlaten, moeten we dit gesprek stopzetten, verbinding maken met het Internet via de GPRS-interface en het gesprek opnieuw opstarten. In deze thesis stellen we een oplossing voor dit probleem voor. We zorgen ervoor dat er “seamless”2 wordt overgeschakeld tussen de verschillende interfaces terwijl we aan het bellen zijn. Zo verkrijgen we hetzelfde gebruiksgemak als bij de klassieke vorm van telefoneren waarbij we overal bereikbaar zijn. Bovendien kunnen we de kosten drukken door thuis het draadloze netwerkinterface te gebruiken om een verbinding met het internet op te zetten. In wat volgt zullen we eerst een duidelijke uitleg over het IP Multimedia Subsystem geven. IMS gebruikt SIP (Session Initiation Protocol) als signaling protocol voor het opzetten, afbreken en wijzigen van VoIP sessies. De werking van SIP en enkele andere bij VoIP gebruikte protocols zullen we toelichten. Daarna geven we een duidelijke definitie van het begrip “seamless handover” op gebied 1 2

Toegang tot een draadloos netwerk. Een uitgebreide definitie van “seamless” volgt later.

2 | Hoofdstuk 1 - Inleiding van pakketverlies, etc. Vervolgens zullen we een uitbreiding op SIP voorstellen die aan deze definitie voldoet. Eerst verduidelijken we de theoretische kant van deze oplossing en tenslotte bespreken we de implementatie ervan.

3 | Hoofdstuk 2 - Het 3G IP Multimedia Subsystem

Hoofdstuk 2: Het 3G IP Multimedia Subsystem (IMS) Derde generatie (3G)netwerken trachten de twee grootste paradigma’s van de communicatiewereld samen te voegen: cellulaire netwerken en het internet. Het IP (internet protocol) Multimedia Subsystem (IMS) is het sleutelelement in de 3G architectuur dat het mogelijk maakt om alomtegenwoordige toegang te bieden tot alle diensten die het internet aanbiedt. In dit hoofdstuk geven we een algemene inleiding en situering van IMS. We baseren ons hierbij op (Camerillo & Garcia-Martin, 2006)

1. Het Internet en Cellulaire netwerken Het internet is in de laatste 20 jaar van een klein onderzoekersnetwerk uitgegroeid tot een wereldwijd netwerk dat toegang biedt tot tal van diensten. De belangrijkste reden voor deze groei is de mogelijkheid om enorm veel nuttige diensten die miljoenen mensen willen gebruiken aan te bieden. Het internet heeft de mogelijkheid om zoveel verschillende diensten aan te bieden omdat het gebruik maakt van tal van open protocollen die beschikbaar zijn voor elke ontwikkelaar die een nieuwe dienst wil ontwikkelen. Wanneer deze protocollen niet voor het grote publiek beschikbaar zouden zijn, zouden slechts de enkele experts die een protocol ontwikkeld hebben op dit protocol verder kunnen bouwen. Op dit moment bieden cellulaire telefonienetwerken diensten aan aan meer dan een miljard gebruikers wereldwijd. Deze diensten bevatten uiteraard het opzetten van telefoongesprekken maar moderne cellulaire netwerken bieden ook diensten aan die te maken hebben met het uitwisselen van boodschappen. Deze boodschappen variëren van eenvoudige tekst boodschappen (SMS) tot multimedia boodschappen (MMS) die foto’s of zelfs filmpjes bevatten. Cellulaire gebruikers kunnen tegenwoordig ook surfen op het internet en hun mail checken. Toch zijn deze diensten niet de reden van de populariteit van deze cellulaire netwerken. Hun belangrijkste troef is het feit dat we overal bereikbaar zijn. Niet enkel in de stad maar ook op het platteland en zelfs in het buitenland, gebruik makend van roaming3 diensten.

2. Waarom IMS Het idee van IMS is om internetdiensten overal en op elk tijdstip aan te kunnen bieden, gebruik makende van de cellulaire technologieën. We hebben echter net vermeld dat cellulaire netwerken reeds een brede waaier van diensten aanbieden. Een cellulaire gebruiker kan toegang tot het internet verkrijgen aan de hand van een dataverbinding en op die manier gebruik maken van bijna alle internetdiensten. Waarom hebben we dan IMS nog nodig? Om dit duidelijk te maken, leggen we eerst de twee verschillende domeinen uit in 3G-netwerken, namelijk het circuit-switched en packet-switched domein. Het circuit-switched domein is afkomstig 3

Roaming is een algemene term in draadloze telecommunicatie waarbij een bepaalde dienst wordt voorgezet hoewel de gebruiker zich niet in het netwerk bevindt waarin deze geregistreerd staat. Voor verdere informatie over roaming zie (ETSI, 2004)

4 | Hoofdstuk 2 - Het 3G IP Multimedia Subsystem uit de technologie van 2G-netwerken. De circuits in dit domein worden geoptimaliseerd voor het transport van spraak en video maar kunnen ook gebruikt worden voor het versturen van boodschappen. Circuit-switched netwerken worden reeds gebruikt sinds de geboorte van de telefonie maar worden steeds meer vervangen door de meer efficiënte packet-switched technologie. Het packet-switched domein biedt IP-toegang aan tot het internet. Terwijl 2G terminals als een modem acteren om IP-pakketten over een circuit te sturen, gebruiken 3G terminals “native” packetswitched technologie voor hun datacommunicatie. Dit heeft tot gevolg dat datatransmissies veel sneller zijn en dat de gebruikte bandbreedte voor internet toegang drastisch vergroot. Zo kan elke gebruiker een VoIP client installeren op zijn 3G-terminal en VoIP-gesprekken (die een aanzienlijke hoeveelheid bandbreedte vereisen) opzetten over het packet-switched domein. Zo’n gebruiker kan bovendien gebruik maken van alle diensten die dienstverleners op het internet aanbieden zoals voicemail en videoconferencing. Opnieuw stelt zich de vraag: waarom hebben we IMS nodig wanneer al deze internetdiensten reeds beschikbaar zijn voor 3G-gebruikers via het packet-switched domein? Het antwoord is drieledig: QoS (Quality Of Service), charging en integratie van verschillende diensten. Een belangrijke eigenschap van het packet-switched netwerk is dat het een best-effort service aanbiedt zonder QoS. Dat betekent dat er geen garantie wordt geboden op de hoeveelheid bandbreedte die de gebruiker ter beschikking krijgt en op de vertraging die de pakketten zullen oplopen. Op die manier kan een VoIP-gesprek drastisch in kwaliteit schommelen tijdens de duur van het gesprek. Een van de bestaandsredenen van MS is het aanbieden van QoS die noodzakelijk is voor real-time multimediasessies. Een tweede bestaansreden van IMS is het in staat zijn om multimediasessies op een gepaste manier aan te rekenen. Bij gewone 3G netwerken betalen gebruikers vaak per byte omdat de operator zich niet bewust is van de inhoud van de data die wordt verstuurd. Wanneer de operator zich echter wel bewust is van deze inhoud kan hij datatransmissie op verschillende manieren aanrekenen. VoIP gesprekken kunnen bijvoorbeeld op basis van tijdsduur aangerekend worden, ongeacht het aantal bytes dat verstuurd wordt. IMS verplicht geen specifiek business model maar laat de operatoren vrij om de manier waarop ze verschillende diensten aanrekenen zelf in te vullen. Het aanbieden van geïntegreerde diensten aan gebruikers is een derde grote bestaansreden voor IMS. Hoewel grote contentaanbieders en operatoren sommige multimediadiensten volledig zelf ontwikkelen, willen operatoren zichzelf niet beperkten tot deze diensten. Ze willen de mogelijkheid hebben om diensten te gebruiken die ontwikkeld zijn door derde partijen. Stel dat een operator een voicemail service heeft ontwikkeld die spraakboodschappen kan opslaan en een derde partij ontwikkelde een service om tekst om te zetten in spraak. Als de operator de tekst-naar-spraak service koopt van de derde partij kan hij spraakversies van binnenkomende tekst boodschappen aanbieden aan blinde gebruikers. IMS definieert standaard interfaces die gebruikt moeten worden door service ontwikkelaars. Op die manier wordt de samenwerking tussen verschillende services vergemakkelijkt en kunnen operatoren voordeel halen uit het feit dat ze niet gebonden zullen zijn aan één verkoper om nieuwe services te kunnen ontwikkelen.


3. Algemene principes van de IMS-architectuur In dit onderdeel zullen we een beeld geven van de design principes die achter de IMS-architectuur en zijn protocols liggen. Bovendien zullen we kort het IMS-netwerk bekijken en de verschillende netwerk elementen bespreken.

3.1 Van circuit-switched naar packet-switched Laten we eerst even bekijken hoe cellulaire netwerken geëvolueerd zijn van circuit-switched naar packet-switched netwerken en hoe IMS de volgende stap in deze evolutie is. Het derde generatie partnership project (3GPP) (3GPP, 1998) gebruikt de GSM (GSM Association, 1987)specificaties als een design basis voor een 3G mobiel systeem. GSM heeft twee manieren van opereren: circuitswitched en packet-switched. De twee 3G domeinen zijn op deze GSM-modes van opereren gebaseerd. Circuit-switched netwerken hebben twee verschillende “planes”: het signaling plane en het media plane. Het signaling plane omvat de protocollen die gebruikt worden om een circuit op te zetten tussen terminals. Ook het oproepen van services gebeurt in het signaling plane. Het media plane bevat de data die verstuurd wordt over het circuit-switched pad tussen de terminals. Signaling en media planes volgden hetzelfde pad in de eerste circuit-switched netwerken. Op een gegeven moment is men in PSTN (ITU-T, 1992) gestart met het definiëren van verschillende paden voor het signaling en media plane. In IMS worden signaling en media paden ook volledig gescheiden gehouden. De enige gebruikers die zowel signaling als media moeten behandelen zijn IMS-terminals. Geen enkele netwerkknoop hoeft beiden te behandelen. Het GSM packet-switched netwerk, ook wel gekend als GPRS (Bates, 2001)was de basis voor het packet-switched domein van 3GPP. Ondanks verschillende programma’s (WAP) die ontwikkeld werden voor het verhogen van het gebruik van dit domein, heeft men toch niet de interesse van het grote publiek kunnen wekken. Zo kon men de enorme kosten voor het opstellen van packet-switched mobiele netwerken niet rechtvaardigen.

3.2 Vereisten voor IMS Net voor de geboorte van IMS was de situatie die de operatoren onder ogen zagen dus niet bemoedigend. Spraak over circuit-switched netwerken was een gewoonte geworden en operatoren konden moeilijk extra winst halen uit het aanbieden en aanrekenen van telefoongesprekken. Bovendien waren packet-switched diensten nog niet echt ingeburgerd en hier konden operatoren dus ook niet veel geld aan verdienen. Operatoren hadden bijgevolg nieuwe attractieve diensten nodig om gebruikers aan te trekken tot het packet-switched domein. Het mobiele internet moest dus aantrekkelijker worden gemaakt voor zijn gebruikers. Op deze manier ontstond IMS en met de visie uit het eerste deel van dit hoofdstuk in gedachten begonnen materiaalverkopers en operatoren het IP Multimedia Subsystem te ontwerpen. IMS mikt dus op: • • •

Het combineren van de laatste trends in technologie Het waarmaken van het mobiele internet paradigma Het creëren van een gemeenschappelijk platform voor het ontwikkelen van diverse multimediadiensten


•

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

Laten we nu de vereisten bekijken die geleid hebben tot het ontwikkelen van IMS. In deze requirements wordt IMS gedefinieerd als een architecturaal raamwerk dat gecreëerd werd voor het leveren van IP multimediadiensten aan eindgebruikers. Dit raamwerk moet voldoen aan de volgende vereisten: • • • • • •

Ondersteuning voor het opzetten van IP-multimediasessies Ondersteuning voor een mechanisme om te onderhandelen over Quality of Service(QoS) Ondersteuning voor samenwerking tussen het Internet en circuit-switched netwerken Ondersteuning voor roaming Ondersteuning voor strenge controle, opgelegd door de operator met betrekking tot de diensten die aan de eindgebruiker worden geleverd. Ondersteuning voor snelle ontwikkeling van nieuwe diensten zonder voorafgaande standaardisatie

3.3 Protocols in IMS IMS maakt gebruik van verschillende reeds bestaande protocols om de communicatie in het signaling en media plane te verzorgen. Het belangrijkste protocol in het signaling plane is het SIP (Session Initiation Protocol). Het feit dat SIP een end-to-end protocol is en vele eigenschappen erft van de meest succesvolle internet protocols (SMTP (Postel, 1982) en http (Berners-Lee, Fielding, & Frystyk, 1996)) heeft ervoor gezorgd dat SIP als signaling protocol werd verkozen boven H323 en andere signalling protocols. In het volgende hoofdstuk geven we een uitgebreid overzicht van SIP. Een ander protocol dat gebruikt wordt in het signaling plane is het Diameter protocol (Calhoun, Loughney, Guttman, Zorn, & Arkko, 2003). Dit protocol wordt gebruikt voor authenticatie, autorisatie en accounting, wat erop neerkomt dat de communicatie tussen netwerk knopen en de HSS aan de hand van dit protocol zal gebeuren. In het media plane worden verschillende protocols gebruikt voor het overbrengen van data. Welk protocol er gebruikt wordt hangt af van de applicatie. Voor real-time toepassingen zoals Voice over IP wordt vaak het RTP (Schulzrinne, Casner, Frederick, & Jacobson, 1996) protocol gebruikt.

7 | Hoofdstuk 3 - Het Session Initiation Protocol

Hoofdstuk 3: Het Session Initiation Protocol (SIP) In dit hoofdstuk zullen we een overzicht geven dan het Session Initiation Protocol. SIP wordt in het IMS gebruikt voor de communicatie in het signaling plane. Meer specifiek gebruiken we SIP voor het opzetten en afbreken van Voice over IP gesprekken. We baseren ons in dit hoofdstuk op informatie uit (Demeester & Pickavet, 2006), (Rosenberg, et al., 2002) en (Banerjee K. , 2005).

1. Situering Het doel van VoIP is het verzenden van een spraaksignaal over het internet met een acceptabele kwaliteit. In tegenstelling tot het vaste telefonie netwerk zullen we hier geen gebruik maken van gereserveerde ciruits die een vaste brandbreedte ter beschikking hebben. We groeperen de spraakdata in pakketten die we afzonderlijk van bron naar bestemming sturen. Om een gesprek van acceptabele kwaliteit te bekomen moeten we rekening houden met de specifieke problemen die we tegenkomen bij het versturen van pakketten over het internet: delay, jitter, pakketverlies, connection less4 netwerk,… . Voor het opzetten, afbreken en wijzigen van de call hebben we controlefuncties nodig. De pakketten die verzonden worden om deze controlefuncties uit te oefenen maken deel uit van het “control plane”. Control

Voice

SDP SIP TCP/UDP

RTP/RTCP UDP IP Data-Link Fysische Laag

Bovenaan de protocol stack van het control plane zien we het SDP (Session Description Protocol) protocol. Dit protocol wordt gebruikt om de sessie te beschrijven. In het geval van VoIP hebben we het dus over een audio-sessie. Eventueel kan hier ook de beschrijving van een video-sessie aan toegevoegd worden. In deze beschrijvingen worden onder andere het IP-adres en de poort gedefinieerd waar pakketten moeten naartoe gestuurd worden. Ook het protocol waarmee de data zullen worden verstuurd, wordt vermeld in deze SDP-boodschap. Vaak gebruiken we hiervoor het RTP (Real-time Transfer Protocol) protocol.

4

In tegenstelling tot de klassieke telefonie: connection oriented. Hierbij gaan we op voorhand een verbinding opzetten en bandbreedte reserveren voor ons telefoongesprek.

8 | Hoofdstuk 3 - Het Session Initiation Protocol Eenvoudig voorbeeld SDP-boodschap v=0 o=- 1073055600 1073055600 IN IP4 10.10.5.50 s=c=IN IP4 10.10.5.50 t= 23456 23456 m=audio 5000 RTP/AVP 112 113 a =rtpmap:112 L16/48000/2 a=rtmap:113 DAT12/32000/4 a=fmtp:113 contents:DV L/R/C/WO

We zien in dit voorbeeld dat we audio kunnen verzenden. Naar het IP-adres 10.10.5.50 op poort 5000. Deze audio wordt verzonden aan de hand van RTP-payload type 112 en 113. Payload type 112 zendt L16 audio, payload type 113 zendt DAT12 audio. DAT12 audio bevat 4 kanalen audio: links, rechts, centraal en woofer. Meteen onder SDP hebben we het Session Initiation Protocol. SIP is een application-layer protocol waarmee men multimedia sessies (zoals een VoIP gesprek) kan opzetten, wijzigen en beëindigen. SIP maakt hierbij gebruik van SDP om de parameters van het gesprek te specificeren. Een SIP-boodschap bestaat enerzijds uit een verzameling van headers die gedefinieerd worden door het SIP-protocol en anderzijds uit de inhoud van de boodschap: de SDP-sessie beschrijving.

2. Algemeen Zoals eerder gezegd is het doel van het SIP-protocol het creëren en onderhouden van een sessie. Met een sessie bedoelen we uitwisseling van data tussen twee of meerdere deelnemers. Deelnemers aan een sessie kunnen zich verplaatsen tussen verschillende eindstations, geadresseerd worden door meerdere namen en bovendien communiceren gebruik makend van verschillende media (soms zelfs tegelijkertijd zoals in het geval van een videogesprek). SIP ondersteunt de volgende facetten van het opzetten en beëindigen van multimediasessies: • User location: het bepalen van waar de eindgebruiker zich op het huidige moment bevindt • User availability: het bepalen of de gebelde partij deel wil/kan nemen aan de communicatie • User capabilities: vaststellen welke media en media parameters5 er gebruikt kunnen worden • Session setup: het instellen van session parameters bij de gebelde en bellende partij • Session management: omvat de transfer en het beëindigen van sessies, wijzigen van parameters van de sessie en het uitvoeren van services

3. Terminologie Voor we uitleggen hoe het SIP-protocol in zijn werk gaat, geven we een korte beschrijving van enkele vaak gebruikte termen. Uniform Resource Identifiers bieden een eenvoudige en uitbreidbare manier om resources zoals gebruikers of servers te identificeren. Een URI kan verder nog geklasseerd worden als een locator, een naam of beide. Een Uniform Resource Locator refereert naar het deel van de URI dat resources 5

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

9 | Hoofdstuk 3 - Het Session Initiation Protocol identificeert aan de hand van een representatie van hun primair toegangsmechanisme (vb: netwerk locatie). De Uniform Resource Name wijst naar het deel van de URI dat ervoor moet zorgen dat hij globaal uniek en persistent blijft. Een address-of-record is een SIP-URI die naar een domein met een location service wijst die een URI kan mappen op een andere URI waar de gebruiker beschikbaar kan zijn. Vaak is deze AOR het publieke adres van de gebruiker en de URI waarop hij gemapt wordt het huidige IP-adres van deze gebruiker. We beschouwen als voorbeeld de SIP-URI “sip:[email protected]” . Het is duidelijk dat atlanta.com het domein is waar de location service zich bevindt en de URI kan omvormen naar “sip:[email protected]” waarbij 192.168.1.100 het IP-adres is waar Alice zich op dit moment heeft aangemeld. Een server is een netwerkelement dat aanvragen ontvangt om ze te processen en een passend antwoord terug te sturen. Een User Agent is een logische entiteit die zowel als client als server acteert. De client creëert en verstuurt nieuwe aanvragen. De rol van client is geldig voor de duur van die transactie. Een User Agent Server genereert een antwoord op een ontvangen aanvraag. Hij kan deze aanvraag accepteren, afwijzen of doorverwijzen. Een proxy server is een tussenliggende entiteit die zowel server als client taken op zich neemt met als doel aanvragen te sturen in naam van andere clients. Een proxy server vervult voornamelijk de rol van router. Hierbij zal hij aanvragen proberen door te sturen naar entiteiten die zich dichter bij de bestemming bevinden. Bovendien kunnen proxies ingezet worden om een bepaald beleid door te voeren. Zo kunnen we een proxy zo instellen dat hij bepaalde gebruikers verhindert om een gesprek op te zetten. Een proxy interpreteert aanvragen en herschrijft indien nodig specifieke delen ervan voordat hij ze doorstuurt. Bovendien kan een proxy zowel in statefull- als stateless-mode werken. Wanneer hij in stateless-mode acteert, zal hij alle informatie die hij heeft gebruikt voor het doorsturen van een boodschap meteen verwijderen nadat de boodschap verzonden is. In statefullmode zal hij deze informatie onthouden engebruiken om latere boodschappen die met deze boodschap te maken hebben te interpreteren. Een redirect server is een user agent server die 3XX-antwoorden genereert als antwoord op aanvragen die hij ontvangt. Een 3XX-antwoord vertelt de client dat hij zich moet richten tot een andere URI. De registrar server accepteert REGISTER aanvragen en plaatst de informatie die hij hierbij ontvangt (vb: het IP-adres van de computer waar de gebruiker zich op heeft aangemeld) in de location service van het domein dat hij behandelt. De location service wordt door een SIP redirect- of proxyserver gebruikt om informatie op te vragen over de huidige locatie van de gebelde partijen. Het bevat een lijst van address-of-record-sleutels die verbonden zijn met nul of meerdere contact adressen. Een REGISTER aanvraag zorgt voor een update van een element uit deze lijst. Merk wel op dat het protocol gebruikt voor de uitwisseling van informatie tussen proxy/redirect/registrar en de location service niet gespecificeerd is door SIP. We zullen verder dus ook dummy-boodschappen gebruiken indien deze communicatie verder nog aan bod komt.


4. SIP-Boodschappen 4.1 SIP-Aanvraag De layout van een SIP-aanvraag is gestandaardiseerd aan de hand van enkele velden. Men heeft hierbij hetzelfde formaat gekozen als boodschappen van het http-protocol. De onderstaande figuur illustreert de samenstelling van de velden. method SP Header field name

URI :

Header field name CR/LF Message Body

:

SP Value

Version

CR/LF CR/LF

… Value

CR/LF

De aanvraag lijn bevat de methode (REGISTER, INVITE, ACK,…), de Uniform Resource Identifier die de bestemming van de boodschap specificeert (vb: de SIP-URI van de gebruiker die je wil bellen) en de versie van het SIP-protocol (in ons geval steeds SIP/2.0). De velden onder de aanvraaglijn noemen we de headerlijnen. De aanwezigheid van specifieke headervelden varieert van aanvraag tot aanvraag. Enkele voorbeelden van headers zijn: • • • • •

• •

To: de logische identiteit van de ontvanger van de aanvraag From: de logische identiteit van de verzender van de aanvraag Call-ID: unieke identifier om een reeks boodschappen te groeperen CSeq: wordt gebruikt om transacties te identificeren en te ordenen Via: definitie van het transportprotocol dat we gebruiken voor deze aanvraag (UDP, TCP,…) en identificatie van het IP-adres en de poort waar het antwoord naartoe moet gezonden worden. Contact: contact SIP-adres van de verstuurder van de aanvraag …

De message body is optioneel en bevat vaak de SDP beschrijving maar kan vaak ook om het even welke MIME header bevatten zoals een foto, betalingsinfo,… .

4.2 SIP-Antwoord Een SIP-antwoord is zeer gelijkend aan een SIP-aanvraag maar er worden andere velden gebruikt. De antwoordlijn start met de versie van het SIP-protocol en geeft vervolgens statusinformatie weer via een status code en een uitdrukking die de code uitlegt. Hier volgt een lijst met mogelijke statuscodes • • • • • •

1xx: 2xx: 3xx: 4xx: 5xx: 6xx:

Informative (vb: 100 trying, 181 Ringing,…) Success (vb: 200 OK) Redirection (vb: 301 Moved Permanently) Client error (vb: 401 Unauthorized) Server error (vb: 500 internal server error) Global Failure (vb: 600 busy everywhere)

11 | Hoofdstuk 3 - Het Session Initiation Protocol Daarna zijn er net zoals bij een SIP-aanvraag verschillende headerlijnen mogelijk. Het laatste deel van het SIP-antwoord bevat de gevraagde informatie (vb: SDP van de ontvanger). De onderstaande figuur illustreert de samenstelling van een SIP-antwoord. Version SP Header field name

Status Code :

Header field name CR/LF Entity Body

:

SP Value

phrase

CR/LF CR/LF

… Value

CR/LF

5. Registratie Om het opzetten, afbreken of wijzigen van een gesprek te ondersteunen gebruikt SIP verschillende types SIP-aanvragen en SIP-antwoorden. Enkele voorbeelden van SIP-aanvraag types zijn INVITE, ACK, STATUS en REGISTER. De combinatie van een SIP-aanvraag en het daarop volgende SIP-antwoord noemen we een SIPtransactie. De opeenvolging van verschillende SIP-transacties die samen één geheel vormen, zoals het opzetten van een VoIP sessie, noemen we een SIP-dialoog. De registratieprocedure is slechts een SIP-transactie vermits ze slechts uit een SIP-aanvraag en het daaropvolgende SIP-antwoord bestaat. Om user location te ondersteunen moet elke SIP-gebruiker zich, telkens hij van locatie verandert, registreren bij een registrar server. Hiervoor maakt hij gebruik van een REGISTER-aanvraag. In een eenvoudig voorbeeld tonen we hoe deze registratie procedure in zijn werk gaat. Stel dat Alice met Bob wil communiceren. Alice bevindt zich in het atlanta.com-netwerk en Bob in het biloxi.com-netwerk. Alice en Bob zullen zich eerst registreren en doen dit door een REGISTERaanvraag te sturen naar hun respectievelijke SIP-registrar server. Voor de eenvoud bekijken we enkel de uitwisseling van boodschappen voor de registratie van Alice. De registratie van Bob gebeurt analoog.

Figure 6: Registratie Alice

12 | Hoofdstuk 3 - Het Session Initiation Protocol Alice stuurt dus een REGISTER-aanvraag naar de registrar-server van atlanta.com (1). Deze REGISTERaanvraag bevat verschillende velden die alle informatie bevatten die nodig is om ervoor te zorgen dat andere gebruikers Alice kunnen vinden. De registar-server zal deze informatie opslaan in de Location service databank (2) en dit bevestigen aan Alice aan de hand van een OK-antwoord(3). 1. REGISTER 2. Opslaan data REGISTER sip:atlanta.com SIP/2.0 [email protected] From: sip:[email protected] To: sip:[email protected] Contact:<sip:[email protected]>

3. OK SIP/2.0 200 OK

We zien dat zowel het From- als het To-veld de SIP-URI bevatten van Alice. Bovendien zien we in het Contact-veld de huidige locatie van Alice. Merk op dat we voor de eenvoud de boodschappen niet volledig hebben weergegeven.

Figure 7: Versturen Invite

Wanneer Bob nu een gesprek wil opzetten met Alice. Zal hij een INVITE (4) naar zijn proxy-server sturen. Het adres van deze proxy vindt hij via DNS of een configuratiebestand. De proxy zal op zijn beurt via DNS de location service van atlanta.com opzoeken en deze vragen waar [email protected] zich momenteel bevindt (5). De location service geeft het huidige IP-adres van [email protected] aan de proxy (6) en deze kan uiteindelijk de INVITE naar Alice doorsturen (7).6 4. INVITE INVITE [email protected] SIP/2.0 To: sip:[email protected] From: sip:[email protected] Call-ID:call1 Contact: sip:[email protected]

6

5. Waar is Alice 6. Antwoord [email protected]? 192.168.1.100

7. INVITE Idem boodschap 4

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 antwoorden aanvraagboodschappen zal de communicatie tussen Bob en Alice starten. Hierbij zullen de user agents van Alice en Bob rechtstreeks informatie uitwisselen en niet meer via hun respectievelijke SIP-servers werken7. Zo zal het mogelijk zijn voor Bob en Alice om hun VoIP gesprek op te zetten. Merk wel op dat het de registrar, location service database en de proxy logische functies zijn. In praktijk worden ze vaak op een zelfde server geimplementeerd. Het is nu duidelijk dat de REGISTER-aanvraag voor user mobilitity zorgt. Wanneer een gebruiker een SIP-applicatie opstart op een computer zal deze applicatie meteen een REGISTER-aanvraag versturen met de gebruikersnaam van de gebruiker en het IP-adres van de computer. Zo wordt de informatie over de huidige locatie van de gebruiker voortdurend geupdate en is hij overal bereikbaar.

6. Call Setup In wat volgt geven we een voorbeeld hoe een gesprek wordt opgezet aan de hand van SIPboodschappen. Eerst geven we een schets van de situatie: Alice (sip:[email protected]) bevindt zich in het atlanta.com domein. Bob (sip:[email protected]) in het biloxi.com domein. De toewijzing van de IP-adressen is weergegeven in Figure 8. Merk op dat we in een testopstelling private adressen gebruiken. In een reële situatie hoeven de proxy servers ook niet in hetzelfde domein als Alice of Bob te liggen.

Figure 8: Call Setup netwerk

We onderstellen nu dat Alice naar Bob wil bellen. Opdat Bob gevonden zou kunnen worden door andere SIP-gebruikers moet hij zich eerst registreren bij de registrar van biloxi.com. Deze registrar is onderdeel van de biloxi.com server.

7

Dit is echter niet altijd zo. Indien we het Record-Route veld gebruiken kunnen we ervoor zorgen dat een bepaalde SIP server alle pakketten van de communicatie kan inspecteren en eventueel wijzigen. We zullen in ons project gebruik maken van deze Record-route. Meer info volgt verder in de tekst.

14 | Hoofdstuk 3 - Het Session Initiation Protocol REGISTER REGISTER sip:registrar.biloxi.com SIP/2.0 Via: SIP/2.0/UDP 192.168.2.100:5060 To: sip:[email protected] From: sip:[email protected];tag=001 Call-ID: [email protected] CSeq: 1 REGISTER Contact: <sip:[email protected]> Expires: 7200 Content-Length: 0

Alice zal de call-setup starten door een uitnodiging tot gesprek voor Bob (INVITE) naar haar proxy server te sturen in atlanta.com. De atlanta.com server zal deze aanvraag doorsturen naar de proxy server van Bob8. Tegelijkertijd zal hij aan Alice laten weten dat de INVITE-boodschap wordt verwerkt door een SIP-antwoord terug te sturen. De biloxi.com server zal een gelijkaardige actie ondernemen. Hij stuurt de INVITE door naar Bob en stuurt een trying-antwoord naar atlanta.com. We merken hierbij wel op dat de proxy servers de INVITE-boodschap wel zullen aanpassen. Ze voegen steeds een Via- veld toe. Op die manier kan men op een hop-by-hop basis de weg terug naar Alice vinden. INVITE INVITE [email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060 To: sip:[email protected] From: sip:[email protected];tag=001 Call-ID:call1 Cseq: 1 INVITE Contact: sip:[email protected] Content-Type: application/sdp Content-Length: 142

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

(hier komt SDP van Alice)

Wanneer de INVITE uiteindelijk aankomt bij Bob zal de telefoon van Bob beginnen rinkelen. Op dat moment wordt er een 180 Ringing antwoord gestuurd naar Alice (via de twee SIP-servers). Wanneer Bob zijn telefoon opneemt wordt er een 200 OK antwoord gestuurd naar Alice (wederom via de twee SIP-servers). Deze OK-boodschap bevat ondermeer de SDP informatie van Bob die nodig is om een akkoord te sluiten over welk audio-codec en dergelijke er gebruikt zal worden tijdens het gesprek. Alice zal bevestigen aan Bob dat zij deze boodschap heeft ontvangen door een ACK rechtstreeks naar Bob te sturen. Vanaf dit moment worden de SIP-servers dus niet meer in de communicatie betrokken9.

8 9

Merk op dat we in dit voorbeeld niet volgens de redirect-methode werken. Tenzij we met het Record-route veld werken. Maar in dit voorbeeld laten we dit achterwege.

15 | Hoofdstuk 3 - Het Session Initiation Protocol Ringing SIP/2.0 180 Ringing Via: SIP/2.0/UDP 192.168.2.1:3040;branch=002; Via: SIP/2.0/UDP;192.168.1.1:2030;branch=001 Via: SIP/2.0/UDP 192.168.1.100:5060 To: Bob <sip:[email protected]>;tag=002 From: Alice <sip:[email protected]>;tag=001 Call-ID: call1 Contact: <sip:[email protected]> CSeq: 1 INVITE Content-Length: 0

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

ACK ACK [email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060 To: sip:[email protected];tag=002 From: sip:[email protected];tag=001 Call-ID:call1 Cseq: 1 ACK Contact: sip:[email protected]

Zodra de ACK door Bob is ontvangen, kan de communicatie starten. Deze communicatie bestaat uit één of meerdere RTP-mediasessies. Wanneer Bob de sessie wil stoppen verstuurt hij een BYE aanvraag naar Alice. Deze aanvraag wordt rechtstreeks verstuurd en Alice zal het einde van de sessie bevestigen met een 200 OK antwoord. BYE BYE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060 From: Bob <sip:[email protected]>;tag=002 To: Alice <sip:[email protected]>;tag=001 Call-ID: call1 CSeq: 1 BYE Content-Length: 0

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

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


Figure 9: Sequentie Diagram Call Setup


7. Record-Route Zoals reeds eerder vermeld communiceren de twee user agents Bob en Alice rechtstreeks met elkaar vanaf het moment dat Bob het gesprek accepteert (200 OK). Er is echter een mogelijkheid om ervoor te zorgen dat één of meerdere tussenliggende servers alle SIP-aanvragen en antwoorden die tussen Alice en Bob verzonden worden, kunnen zien en inspecteren. Wanneer de twee proxy servers in bovenstaand voorbeeld de SIP-boodschappen die tussen Alice en Bob verstuurd worden willen zien gedurende de hele sessie moeten ze een veld toevoegen aan de initiële INVITE. Dit veld, Record-Route genaamd, bevat de URI die wijst naar de hostname of het IPadres van de proxy die zich in het pad van de SIP-boodschappen wil plaatsen. Wanneer Bob de INVITE ontvangt met het Record-Route-veld zal hij de informatie opslaan voor de duur van de sessie. Ook Alice zal deze informatie ontvangen omdat het Record-Route-veld ook in de 200 OK-boodschap wordt gekopieerd. Bob en Alice zullen dus op die manier te weten komen dat ze hun pakketten naar de proxy servers moeten sturen in plaats van rechtstreeks naar elkaar. INVITE INVITE [email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060 To: sip:[email protected] From: sip:[email protected];tag=001 Call-ID:call1 Cseq: 1 INVITE Contact: sip:[email protected] RecordRoute:<sip:atlanta.com;1r>,<sip:biloxi.com;1r> Content-Type: application/sdp Content-Length: 142 (hier komt SDP van Alice)

OK SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.2.1:3040;branch=002 Via: SIP/2.0/UDP 192.168.1.1:2030;branch=001 Via: SIP/2.0/UDP 192.168.1.100:5060 To: sip:[email protected];tag=002 From: sip:[email protected];tag=001 Call-ID:call1 Cseq: 1 INVITE Contact: sip:[email protected] RecordRoute:<sip:atlanta.com;1r>,<sip:biloxi.com;1r> Content-Type: application/sdp Content-Length: 142 (hier komt SDP van Bob)

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


Figure 10: Sequentie Diagram Record Route

19 | Hoofdstuk 4 - Voice over IP

Hoofdstuk 4: Voice over IP (VoIP) Na een algemeen overzicht van IMS en een bespreking van SIP, het signaling protocol van IMS, kijken we nu naar het media plane van IMS. Voice over IP (VoIP) is een mogelijke toepassing die door IMS ondersteund wordt en waar we in deze thesis gebruik van zullen maken. In dit hoofdstuk lichten we VoIP kort toe en daarbij vermelden we de eisen aan welke een netwerk moet voldoen om VoIP te kunnen ondersteunen. Vervolgens zullen we een overzicht geven van het Real-time Transport Protocol dat gebruikt wordt om de data van een VoIP-gesprek doorheen het media plane van IMS te sturen. We baseren ons op gegevens uit (Schulzrinne, Casner, Frederick, & Jacobson, 1996), (Demeester & Pickavet, 2006), (NeoNova bv, 2006), (OzVoIP.com, 2004)

1. Inleiding In tegenstelling tot de klassieke manier van telefoneren maken we bij VoIP gebruik van een connectionless verbinding in een packet-switched netwerk: het internet. Dit betekent dat we op voorhand geen bandbreedte zullen reserveren in het pad tussen de twee gebruikers. Bovendien splitsen we het spraaksignaal op en versturen we het in IP-pakketten over het internet. Door het feit dat we op een pakketgebaseerde manier te werk gaan, zullen we veel efficiënter gebruik maken van de beschikbare bandbreedte. Bij een connection-oriented verbinding (zoals in het circuit-switched domein van de klassieke telefonie) zullen we een vaste hoeveelheid bandbreedte voor een gesprek reserveren. Deze hoeveelheid kan niet meer gebruikt worden door andere toepassingen. De hoeveelheid data die voor een gesprek moet verzonden worden is echter niet constant (vb: stiltes in een gespek). Bijgevolg wordt de gereserveerde bandbreedte voor het grootste deel van de tijd niet volledig benut. Bij VoIP zullen we geen bandbreedte reserveren en dus enkel de hoeveelheid bandbreedte innemen die effectief nodig is om de pakketten met spraakdata te verzenden. Bij klassieke telefonie is het bovendien noodzakelijk dat ieder telefoontoestel een fysieke eigen aansluiting bezit op een telefooncentrale. Dit maakt het moeilijk om een toestel te verplaatsen, de lijn moet namelijk mee verplaatst worden. Bij VoIP maakt het in principe niet uit waar het toestel of de softphone10 aangesloten is op het netwerk. Dit maakt dat VoIP een stuk flexibeler is dan de klassieke variant. Net zoals IMS houdt VoIP het signalling en media plane gescheiden. Binnen IMS zullen we SIP gebruiken voor het opzetten, wijzigen en afbreken van VoIP-gesprekken (signalling plane).

2. Eisen voor het netwerk Om de kwaliteit van een VoIP gesprek te kunnen garanderen moet het netwerk aan enkele vereisten voldoen. De belangrijkste vereiste is dat het netwerk voldoende bandbreedte kan voorzien om een VoIP-gesprek te ondersteunen. De bandbreedte die men nodig heeft voor het voeren van een VoIPgesprek 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.


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 jitterbuffer voor hun dataverkeer. Een voorbeeld van een toepassing om de invloed van pakketverlies te verminderen is Forward Error Correction (FEC).

Signaling plane

Media plane

SDP SIP TCP/UDP

RTP/RTCP UDP IP Data-Link Fysische Laag

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.

V

P X

CC

M

payload type timestamp SSRC CSRC

sequence number

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

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)


Figure 11: Voorbeeld timestamp

Het SSRC-veld identificeert de synchronisation source. De identifier moet random gekozen zijn om te voorkomen dat twee synchronisation sources binnen dezelfde RTP sessie dezelfde SSRC identifier zouden hebben. De CSRC lijst kan 0 tot 15 elementen bevatten (bepaald door het CC-veld). Een Contributing SouRCe draagt bij tot de creatie van de payload van dit RTP-pakket. Bijvoorbeeld wanneer bij een audio pakket het geluid van verschillende gebruikers werd gemixt (vb: groepsgesprek).

24 | Hoofdstuk 5 - De IMS-architectuur

Hoofdstuk 5: De IMS-architectuur Nadat we in hoofdstuk 2 de situering en algemene principes van het IP Multimedia Subsystem aanraakten, zullen we in dit hoofdstuk dieper ingaan op de architectuur. Daarbij geven we eerste en algemene architectuur die we vervolgens zullen vereenvoudigen tot een architectuur die we in dit onderzoek zullen gebruiken. Om dit hoofdstuk te besluiten beschrijven de rol van enkele belangrijke netwerkcomponenten bij het opzetten van een VoIP-sessie. Voor de samenstelling van dit hoofdstuk baseerden we ons op de volgende referenties: (Camerillo & Garcia-Martin, 2006), (Repiquet, 2005)

1. Algemene IMS-architectuur Voordat we dieper ingaan op de algemene architectuur van IMS moeten we in gedachten houden dat 3GPP geen knopen maar functies standaardiseert. Dit betekent dat de IMS-architectuur een verzameling is van functies die onderling verbonden zijn via gestandaardiseerde interfaces. De netwerkontwerpers zijn vrij om verschillende functies te combineren in één knoop, of één functie te verdelen over verschillende knopen. Figure 12 geeft een overzicht van de IMS-architectuur zoals ze is gestandaardiseerd door 3GPP. Ze bevat niet alle maar enkel de meest relevante interfaces die gedefinieerd zijn volgens IMS.

Figure 12: Overzicht IMS-architectuur

Op de figuur zien we de netwerkelementen die deel uitmaken van het zogehete IP Multimedia Core Network Subsystem. • • • •

Één of meerdere gebruikersdatabanken, HSSen genaamd (Home Subscriber Servers) en SLFs (Subscriber Location Functions) Één of meerdere SIP-servers die we gezamenlijk CSCFs noemen (Call/Session Control Functions) Één of meerdere ASs (Application Servers) Één of meerdere MRFs (Media Resource Functions), elk van hen verder onderverdeeld in een MRFC (Media Resource Function Controllers) en MRFP(Media Resource Function Processors)


• •

Één of meerdere BGCFs (Breakout Gateway Control Functions); Één of meerdere PSTN-gateways, elk van hen verder onderverdeeld in een SGW (Signaling Gateway), een MGCF (Media Gateway Controller Function) en een MGW (Media Gateway)

Merk op dat deze figuur geen referentie bevat naar betalingsfuncties. Deze laten we achterwege omdat ze van minder belang zijn voor ons onderzoek.

1.1 De databanken: HSS en SLF De Home Subscriber Server is een centrale bewaarplaats voor gebruikersgerelateerde informatie. Technisch gezien is de HSS een evolutie van de HLR (Home Location Register) uit het GSM netwerk. De HSS bevat alle gebruikersgerelateerde inschrijvingsdata die nodig zijn voor het behandelen van multimediasessies. Deze data bevatten ondermeer informatie over de locatie van de gebruiker, beveiligingsinformatie (zowel authenticatie- als authorisatieinformatie), informatie over het profiel van de gebruiker (voor welke diensten hij zich heeft ingeschreven,…) en de S-CSCF (Serving-CSCF) die aan deze gebruiker werd toegewezen. Een netwerk kan meer dan één HSS bevatten indien het aantal abonnees te groot is om door 1 enkele HSS behandeld te worden. In elk geval wordt alle data over één specifieke gebruiker binnen éénzelfde HSS bewaard. Netwerken met slechts één HSS hebben geen SLF nodig. Netwerken met meer dan één HSS vereisen er een. De SLF is een eenvoudige databank die gebruikersadressen mapt op een HSS. Een knoop die de SLF bevraagt met een gebruikersadres als input, krijgt als antwoord de HSS die alle informatie bevat over deze gebruiker. Zowel de HSS als de SLF gebruikt het Diameter-protocol om te communiceren met andere netwerk elementen. 1.2 De CSCF De CSCF (Call/Session Control Function), een SIP-server, is een essentiële knoop in het IMS-netwerk. De CSCF verwerkt de SIP-signalisatie in IMS. Er zijn drie verschillende types CSCF’s, afhankelijk van de functionaliteit die ze bieden. Samen worden zijn ze gekend als CSCF’s maar elk van hen behoort tot een van de volgende categorieën. • • •

P-CSCF (proxy - CSCF) S-CSCF (Serving - CSCF) I-CSCF (Interrogating - CSCF)

De P-CSCF De P-CSCF is het eerste contactpunt13 tussen de IMS-terminal en het IMS-netwerk. Vanuit een SIPstandpunt 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 PCSCF. Bovendien controleert de P-CSCF de correctheid van de SIP-aanvragen die door de IMSterminal worden verstuurd. Deze verificatie zorgt ervoor dat de IMS-terminal geen SIPboodschappen 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). SIPboodschappen 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 PCSCFs. Elke P-CSCF dient een aantal IMS-terminals, afhankelijk van de capaciteit van de knoop. De PCSCF 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 SIPregistrar. 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 SCSCF 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 IMSSSF 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 IMSterminal 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 circuitswitched 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: • •

•

16 17

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.

Public Land Mobile Network Pulse Code Modulation


Figure 13: PSTN/CS Gateway

2. IMS in ons project Het is de lezer ondertussen wel duidelijk dat IMS een zeer uitgebreide architectuur heeft die voor vele verschillende diensten een oplossing biedt. Zoals we echter in de inleiding verteld hebben zullen wij ons enkel bezig houden met VoIP. Dit heeft als gevolg dat vele netwerkfuncties niet van toepassing zijn op ons project. In wat volgt zullen we IMS herleiden tot een eenvoudig beeld van wat wij nodig hebben. Vooreerst werken we met slechts enkele gebruikers in een klein test netwerk. We zullen dus slechts één HSS instantie nodig hebben en bijgevolg geen SLF. Bovendien zetten we geen gesprekken op tussen een VoIP gebruiker en een klassieke telefonie gebruiker. Dit brengt met zich mee dat de PSTN/CS-gateway en de BGCF overbodig zijn voor ons project. We beperken ons strikt tot het packetswitched netwerk. Op gebied van Application Servers zullen we enkel de gewone SIP Application Server gebruiken. Later zal de taak van deze SIP AS duidelijk worden. Ook de MRF laten we achterwege vermits we geen codec transformaties of het mixen van verschillende media nodig zullen hebben. Dat laat ons nog de verschillende Call/Session Control Functions over. Deze behouden we vanzelfsprekend in ons netwerk wegens hun belang als SIP-servers. Wanneer we al deze vereenvoudigingen doorvoeren krijgen we de volgende architectuur.


Figure 14: Vereenvoudigde IMS-architectuur

Merk op dat Figure 14 de netwerkarchitectuur van het signaling plane weergeeft. In het media plane zullen we ook gebruik maken van een pakketreplicator. Een verdere uitleg volgt in de hoofstukken over de handover.

3. Basic Session Setup Om beter te begrijpen wat deze netwerkelementen van ons vereenvoudigd IMS-model in praktijk doen, zullen we een deel van de setup van een VoIP gesprek bespreken. Hierbij staan we stil bij de rollen die de verschillende netwerkelementen vervullen. We veronderstellen Alice en Bob, beide aangemeld op een IMS-terminal. Alice wil Bob bellen en verstuurt een SIP INVITE-boodschap. We zullen het pad van deze boodschap doorheen het IMS-netwerk volgen en uitleg geven bij de acties die genomen worden door de verschillende netwerkelementen wanneer de INVITE voorbij komt. We nemen aan dat zowel Alice als Bob zich niet in hun thuisnetwerk bevinden. Ze roamen met andere woorden vanuit hun bezocht netwerk. Bovendien hebben Alice en Bob ook een verschillend thuisnetwerk. Deze veronderstellingen nemen we omdat we zo het meest complete en complexe scenario hebben. Alle andere scenario’s zijn slechts vereenvoudigingen van dit scenario. We merken op dat de P-CSCF’s van beide gebruikers zich in het bezochte netwerk bevinden. De S-CSCF’s bevinden zich zoals eerder reeds vermeld steeds in het thuisnetwerk. Dit om de diensten steeds beschikbaar te houden voor de gebruiker, waar hij zich ook bevindt. De I-CSCF is de enige netwerk knoop18 die tijdens de session setup in contact staat met de HSS. Hij zal met de HSS communiceren aan de hand van het Diameter-protocol. Op deze manier wordt de HSS niet bij het verwerken van alle extra boodschappen betrokken. Dit is een groot voordeel, rekening houdend met het feit dat een HSS meestal informatie over honderdduizenden gebruikers bevat.

18

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

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 PCSCF 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 PCSCF 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 20

In het signaling plane 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 IMSterminal en de initiërende P-CSCF. De initiërende P-CSCF zal voor de compressie/decompressie van de boodschappen moeten zorgen.

3.3 De initiërende S-CSCF verwerkt de INVITE aanvraag Bij het ontvangen van de INVITE aanvraag zal de initiërende S-CSCF de gebruiker, Alice, identificeren en het gebruikersprofiel gebruiken dat bij de registratie reeds werd gedownload. Dit gebruikersprofiel bevat buiten informatie ook zogenoemde filtercriteria. Deze filtercriteria bevatten een verzameling triggers die bepalen of een aanvraag één of meerdere Application Servers moet passeren die diensten aan de gebruiker leveren. Merk op dat de initiërende S-CSCF de diensten niet zelf uitvoert, maar de diensten laat uitvoeren door de Application Servers. Ook de initiërende S-CSCF zal de SDP-inhoud controleren. Net zoals de initiërende P-CSCF controleert hij of de SDP media parameters voldoen aan het lokale netwerkbeleid. De initiërende S-CSCF zal hierbij echter ook gebruikersgerelateerde informatie gebruiken uit de HSS (het gebruikers profiel). Zo kan men zich bijvoorbeeld op een goedkoper tarief abonneren dat het gebruik van codecs met een hoge bandbreedte verbiedt. De initiërende S-CSCF is het eerste netwerkelement dat rekening houdt met de aanvraag-URI van de INVITE aanvraag. De IMS-terminal en initiërende P-CSCF sturen de INVITE automatisch door naar de next hop21 zonder rekening te houden met de uiteindelijke bestemmeling. De initiërende S-CSCF zal uit de aanvraag-URI de naam van het domein van de bestemmeling extraheren. Aan de hand van deze domeinnaam zal hij enkele DNS-opvragingen uitvoeren om zo het adres van de I-CSCF van Bob’s domein te verkrijgen. De S-CSCF zal tenslotte nog zijn SIP-URI aan het Record-route-veld toevoegen voordat hij de INVITE doorstuurt naar de I-CSCF van het thuis netwerk van Bob.

3.4 De terminerende I-CSCF verwerkt de INVITE aanvraag De terminerende22 I-CSCF zal nu de INVITE aanvraag moeten doorsturen naar de juiste S-CSCF. Dat wil zeggen, de S-CSCF die op dit moment aan Bob is toegewezen. Tijdens de registratie van Bob werd deze informatie in de HSS weggeschreven. De terminerende I-CSCF zal de HSS voor deze informatie bevragen aan de hand van een Diameter Location-Information-Request (LIR)boodschap. Wanneer hij een Location-Information-Answer (LIA) boodschap terug krijgt met het adres van de S-CSCF zal hij de INVITE naar dit adres doorsturen. Merk op dat de I-CSCF in normale omstandigheden niet meer in het pad van de volgende boodschappen moet betrokken worden. Hij zal bijgevolg het Record-route-veld niet wijzigen.

21

Deze next hop wordt gedefinieerd aan de hand van de route-header van de SIP aanvraag. Hier gaan we echter niet verder op in. + verwijzing naar SIP uitleg voer route header 22 De I-CSCF uit het thuisnetwerk van de gebelde gebruiker


3.5 De terminerende S-CSCF verwerkt de INVITE aanvraag De terminerende S-CSCF zal eerst de gebelde gebruiker identificeren aan de hand van de aanvraagURI. 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

Figure 16: IP-router

Output buffers

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.


IP-Netwerk

Verzend tijd

Ontvang tijd

Afspeeltijd

Vaste algemene vertraging

Pakketten juist geordend

Pakket gaat verloren

DeJitter Buffer

Figure 17: Dejitter Buffer

We willen nu de daling van de kwaliteit van ons gesprek uitdrukken in functie van het pakketverlies. De kwaliteit van een spraaksignaal wordt vaak uitgedrukt gebruik makend van de MOS-score23. Wanneer we naar verschillende codecs kijken, zien we dat bij een pakketverlies van meer dan 1% de MOS-scores van de verschillende codecs steeds dichter bij elkaar komen te liggen. Hierbij hebben we het wel over uniform pakketverlies. In dit project zullen we echter meer te maken hebben met bursty pakketverlies. Indien we een voice sample van 2000 pakketten beschouwen zal de MOS-score pas bij een burst verlies van 100 pakketten sterk dalen. De kwaliteit van het gesprek is dan nagenoeg perfect op uitzondering van het punt waar de pakketten zijn verloren, daar is er stilte. Dit willen we natuurlijk vermijden want aan die stilte kan de gebruiker merken dat hij van netwerk verandert en dat is niet de bedoeling. Bij videoconferencing heeft pakketverlies nog een grotere invloed op de kwaliteit. Een pakketverlies van 1% resulteert al in een zichtbaar mindere beeldkwaliteit. Bovendien kunnen we bij pakketverlies van beeldframes een propagatie van fouten krijgen. Om het dataverkeer te beperken worden frames vaak voorspeld op basis van vorige of verdere frames. Wanneer we een frame verliezen waarop andere frames hun voorspelling hebben gebaseerd, zullen we die frames dus niet kunnen reconstrueren. Zo verliezen we niet enkel het huidige frame, maar ook deze waarvan de voorspelling van het huidige frame afhangt . Meer uitleg vindt u hierover in een MPEG-4 tutorial (Moving Picture Experts Group (MPEG), 1998).

23

Mean Opinion Score: schaal van 1 tot 5 om de kwaliteit van een spraaksignaal uit te drukken


2. Seamless handover: hoe gerealiseerd In deze sectie zullen we twee voorstellen bespreken om een handover te realiseren. We zullen deze verschillende voorstellen evalueren op basis van hun mogelijkheid om aan de bovenstaande vereisten voor seamless handover te voldoen.

2.1 Standaard SIP: ReINVITE In het standaard SIP-protocol is er reeds ondersteuning aanwezig om over te schakelen tussen twee interfaces van een client. Voor deze handover maken we gebruik van een specifieke boodschap: ReINVITE. In de volgende uitleg veronderstellen we twee gebruikers die met elkaar in gesprek zijn: Alice en Bob. Alice heeft twee interfaces ter beschikking. Nadat de RTP-sessie tussen Bob en Alice is opgezet waarbij Alice gebruik maakt van interface 1, wil Alice overschakelen naar interface 2. Ze zal de verbinding op interface 1 afsluiten en een ReINVITEboodschap sturen naar Bob van op interface 2. Deze ReINVITE is identiek aan de oorspronkelijke INVITE-boodschap24 met dit verschil dat het Contact- en het Via-veld aangepast zijn met de gegevens van de nieuwe interface. Originele INVITE INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 10.10.5.50:5060 To: From: ;tag=001 Call-Id: call1 CSeq 1 INVITE Contact: <sip:[email protected]>

reINVITE INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.32.4:5060 To: < [email protected] >;tag=002 From: ;tag=001 Call-Id: call1 CSeq 2 INVITE Contact: <sip:[email protected]>

Figure 18: Standaard SIP: Versturen ReINVITE

Wanneer Bob dit bericht ontvangt zal hij al zijn RTP-pakketten vanaf dat moment naar de nieuwe locatie (interface) sturen.

24

In de veronderstelling dat de mobiele host het gesprek heeft opgezet en de oorspronkelijke INVITE dus gestuurd heeft.


Figure 19: Standaard SIP: Nieuwe RTP Sessie

De totale vertraging van deze zogenaamde mid-call handoff is de tijd die nodig is voor het doorzenden van de reINVITE-boodschap van Alice naar Bob. Alle pakketten die Bob stuurt tijdens deze vertraging gaan dus verloren omdat Alice enkel nog luistert op Interface 2. Bij een vertraging van 1s verliezen we 4 tot 5 pakketten bij een 16kb/s stream met voice pakketten van 64 bytes. Indien we echter met een 1,5Mb/s MPEG-4 stream werken, verliezen we zelfs 2x105 pakketten van 1050 bytes. Zo’n pakketverlies heeft vanzelfsprekend een nefaste invloed op de kwaliteit van het gesprek. Bij een MPEG-4 stream kan er bovendien een propagatie van fouten optreden indien het gaat om het verlies van I- of P-frames (Moving Picture Experts Group (MPEG), 1998). Bovendien zal het detecteren van het netwerk voor de nieuwe interface en de toewijzing van een geldig IP-adres bijdragen tot deze vertraging. Het is dus duidelijk dat deze manier van handover niet in aanmerking komt voor het realiseren van een seamless handover. Door de grote hoeveelheid pakketten die tijdens het overgangsproces verloren gaan zal de kwaliteit van het gesprek een duidelijke daling vertonen. Bijgevolg zal Alice duidelijk merken dat ze van interface is overgeschakeld.

2.2 Onze oplossing: INVITE met join-header De oplossing die wij voorstellen voor het realiseren van een seamless handover maakt gebruik van het soft-handoff principe. We baseren ons hierbij op het onderzoek van (Banerjee, Acharya, & Das, 2006). We zetten de nieuwe datastroom op voordat we de originele datastroom hebben afgesloten. We zullen er dus rekening mee moeten houden dat RTP-pakketten dubbel ontvangen worden. De IMS-server25 zal bij deze procedure een belangrijke rol spelen. Hij zal naast zijn taken in het signaling plane ook de taak van mediagateway vervullen. Als media-gateway zal de IMS-server tijdens het handover proces pakketten repliceren en naar beide actieve interfaces sturen. Om alle RTPpakketten te kunnen verdubbelen zal de IMS-server deze pakketten wel moeten ontvangen. In een normaal VoIP gesprek is dit echter niet het geval. Door gebruik te maken van het Record-route-veld kunnen we er wel voor zorgen dat alle signaling boodschappen de IMS-server passeren. Daarbij blijft echter het probleem dat de datapakketten van de RTP-sessie rechtstreeks tussen de gebruikers verstuurd worden. Om dit probleem te omzeilen zullen we gebruik maken van het Back to Back User Agent principe (B2BUA). Hierbij zal de IMS-server zich tegenover beide gebruikers gedragen als een User Agent. Hij zal SIP- en SDP-boodschappen zo aanpassen dat beide gebruikers al hun informatie 25

Die de rol van P-CSCF, S-CSCF, I-CSCF, HSS, Application Server en mediagateway uitoefent

40 | Hoofdstuk 6 - Seamless Handover via de IMS-server zullen sturen. Bij de bespreking van de IMS-server zullen we dieper ingaan op de details van deze procedure. Om te beginnen zetten we het originele VoIP gesprek op. Alice stuurt een INVITE-boodschap naar Bob vanaf interface 1. INVITE INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 10.10.5.50:5060 To: From: ;tag=001 Call-Id: call1 CSeq 1 INVITE Contact: <sip:[email protected]>

Wanneer dit gesprek is opgezet en we willen overschakelen naar de nieuwe interface, sturen we een INVITE met join-header naar de IMS-server uit het domein van de 1e interface. Deze boodschap bevat alle relevante informatie van het huidige gesprek. Merk op dat de CSeq-nummer volgt op die van de oorspronkelijke INVITE. INVITE met join-header INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.32.4:5060 To: [email protected] From: ;tag=003 Call-Id: call1 CSeq: 2 INVITE Contact: <sip:[email protected]> Join: call1;to-tag=002;from-tag=001

Figure 20: Versturen INVITE met Join

Zodra deze IMS-server de INVITE met join-header heeft ontvangen, zal hij het gesprek identificeren aan de hand van zijn call-ID. Vervolgens dupliceert hij alle RTP-pakketten van dit gesprek en stuurt hij ze naar beide interfaces. Tijdens deze overgangsperiode zal de mobiele host alle RTP-pakketten dus


RT PSe ss ie

via zijn beide interfaces ontvangen. Er is dus een pakket filter nodig om de dubbele RTP-pakketten te verwerpen. Op de IMS-server is er een gelijkaardige filter nodig vermits de client nu ook zijn RTPpakketten twee maal verstuurt. Eén maal van op elke interface.

Figure 21: Replicatie RTP pakketten

Wanneer het eerste RTP-pakket op de nieuwe interface wordt ontvangen, stuurt Alice via deze interface een reINVITE-boodschap naar Bob naar analogie met het standaard SIP-protocol. Deze ReINVITE bevat een SDP-boodschap als payload net als het OK-antwoord dat we van Bob krijgen. Deze SDP-boodschappen worden opnieuw gebruikt om de parameters van de RTP-sessie te definiëren.

RT P-

Se ss

ie

ReINVITE INVITE sip: [email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.32.5:5060 To: < [email protected] >;tag=002 From: ;tag=001 Call-Id: call1 CSeq 2 INVITE Contact: <sip:[email protected]>

Figure 22: Versturen ReINVITE

42 | Hoofdstuk 6 - Seamless Handover Bob zal na het versturen van zijn OK-boodschap naar de nieuwe interface van Alice al zijn RTPpakketten die richting uit sturen. Vervolgens stuurt Alice een BYE-boodschap via de oude interface naar de P-CSCF uit het domein van interface 1 om het gesprek over deze lijn af te sluiten.

Figure 23: Nieuwe RTP-sessie

Tenslotte registreert Alice zich met haar nieuwe locatie (nieuwe interface) bij de registrar service in het domein van de nieuwe interface met de REGISTER-boodschap. We kunnen besluiten dat we met de soft-handoff een elegante manier hebben gevonden om het probleem van pakketverlies ten gevolge van vertraging bij hard handoff op te lossen. Zo kunnen we de kwaliteit van onze voice- en videostreams hoog houden. Door het feit dat we de oude RTP-sessie pas afbreken op het moment dat we onze nieuwe sessie hebben opgezet, kunnen we pakketverlies en bijhorend kwaliteitsverlies vermijden.

43 | Hoofdstuk 7 - Ekiga

Hoofdstuk 7: Ekiga Ekiga is een open source VoIP en videoconferencing client voor Gnome (Sandras, 2003). Het maakt gebruik van zowel het SIP als het H323 protocol. Dit heeft als gevolg dat het programma veel meer kan (en dus ook ingewikkelder is) dan nodig. Bij de keuze van de client die we zouden gebruiken voor de implementatie van onze aanpassingen kwam Ekiga echter als beste optie naar voren. In dit hoofdstuk geven we eerst een beschrijving van de structuur van Ekiga zelf. Vervolgens zullen we dieper ingaan op de aanpassingen die we aan de code hebben gemaakt om de seamless handover te implementeren.

1. Structuur Ekiga maakt gebruik van 2 onderliggende bibliotheken: Opal en Pwlib. In de Opal-bibliotheek zit de volledige implementatie van het SIP- en H323-protocol. Aan de hand van klassen zoals “SIPEndPoint” en “SIPConnection” worden er gegevens over huidige SIP-gesprekken bijgehouden. Deze Opal-bibliotheek maakt dan weer gebruik van de Pwlib-bibliotheek. In Pwlib zijn zaken zoals sockets geïmplementeerd. Bovendien gebruiken Ekiga en Opal weinig standaard types. Een gewone string komt bijvoorbeeld niet voor in de code. In de plaats daarvan werken Ekiga en Opal met een PString. Deze speciale klassen zijn ook allemaal in de Pwlib-bibliotheek geïmplementeerd.

Figure 24: Structuur bibliotheken

Het is duidelijk dat, vermits wij een uitbreiding op het SIP-protocol willen implementeren, de meeste van onze aanpassingen zich in de Opal-bibliotheek zullen bevinden.


1.1 Ekiga De code van Ekiga is opgesplitst in 5 verschillende modules: gui, endpoints, devices, clients en components. De gui-module bevat alle klassen en functionaliteit die te maken hebben met de grafische gebruikersinterface van Ekiga. Eén van de belangrijkste bestanden in deze module is het callbacks-bestand. Hierin zitten alle functies die worden opgeroepen wanneer er bijvoorbeeld een knop is ingedrukt, een instelling is gewijzigd, … . Via deze functies zal de verbinding naar de rest van het programma gemaakt worden. In de Endpoints-module staan bestanden die de motor van het programma vormen. Zo is er het Ekiga-bestand dat algemene functionaliteit bevat door middel van functies zoals connect, disconnect en detect_interfaces. In het SIP-bestand wordt de klasse: GMSIPEndPoint geïmplementeerd. Deze klasse erft van SIPEndPoint en EndPoint in de Opal bibliotheek. De high level functionaliteit van het SIP-protocol wordt dus wel in deze klasse gedefinieerd, maar zodra we concreter naar de implementatie van het SIP-protocol gaan, worden we automatisch doorverwezen naar de code van de Opal-bibliotheek. Zo zijn er gelijkaardige klassen voor het H323 protocol en voor de algemene manager. In de clients en components module staan implementaties van componenten die onder meer met het omzeilen van netwerkproblemen te maken hebben. De STUN-klasse bijvoorbeeld biedt een oplossing voor de NAT-problemen die kunnen voorkomen bij het gebruik van het SIP-protocol26. Tenslotte hebben we nog de devices-module. Hierin wordt de samenwerking van Ekiga met audio- en video-drivers geïmplementeerd aan de hand van klassen zoals GMAudioEvent en VideoInput.

Figure 25: Structuur Ekiga

26

Voor meer informatie zie: hier een link naar website of naar bibliografie


1.2 Opal De verschillende VoIP-protocols worden geïmplementeerd in de Opal-bibliotheek. We zullen ons in de bespreking van Opal beperken tot de implementatie van het SIP-protocol en de klassen die van belang zijn voor onze aanpassingen. Opal is net zoals Ekiga opgedeeld in verschillende modules. De opal-module zorgt voor algemene functionaliteit en kan beschouwd worden als een toegangspunt voor de bibliotheek van waaruit de functionaliteit van de andere modules wordt opgeroepen. Andere modules zijn h323, sip, rtp,… . In wat volgt zullen we ons enkel concentreren op het bespreken van de opal-, sip- en rtp-module.

Figure 26: Structuur Opal

Opal De Opal-module kunnen we ruwweg onderverdelen in 4 soorten klassen. De klassen uit de eerste groep vormen de implementatie van alles wat te maken heeft met het opzetten van een gesprek. Ze worden voor de verschillende protocollen verder geïmplementeerd in andere modules en hebben dus enkel basisfunctionaliteit. Een OpalConnection bijvoorbeeld, bevat functies die te maken hebben met het opzetten van een verbinding. De SIPConnection klasse (uit de sip-module) is een kindklasse van deze OpalConnection die de functionaliteit ervan projecteert op het SIP-protocol. Een analoge uitleg kunnen we geven voor de H323Connection klasse.

Figure 27: OpalConnection

Naast deze eerste groep onderscheiden we een 2e groep van klassen die geen kindklassen hebben in andere protocolspecifieke modules maar wel worden gebruikt door de verschillende protocols. Zowel op hoger als op lager niveau. Een OpalCall bevat bijvoorbeeld informatie over een gesprek, SIP of H323, zoals de identificatie van de gesprekspartners (aan de hand van een SIP-URI), de starttijd en

46 | Hoofdstuk 7 - Ekiga een verzameling van verbindingen die voor dit gesprek zijn opgezet. Wanneer we met het SIPprotocol werken wordt zo’n verbinding geïmplementeerd door een SIPConnection-object. Omdat groepsgesprekken met meerdere partners mogelijk zijn, kan één OpalCall meerdere verbindingen bevatten. In Figure 28 zien we drie Connections die deel uitmaken van dezelfde OpalCall tussen Alice en Bob. Interface 1 10.10.5.50

1

PCSCF 1 10.10.5.30 1

[email protected]

[email protected] 2 3 Interface 2 192.168.32.4

3

PCSCF 2 192.168.32.5

Figure 28: OpalCall en OpalConnection

Naast deze OpalCall kunnen we ook de Transport klassen in deze groep indelen. De transport klassen zijn een implementatie van de verschillende transport protocollen zoals TCP en UDP. Ze voorzien functionaliteit waar de Connections gebruik van maken om pakketten te versturen. Enkele voorbeelden van klassen en functies zijn: OpalTransportAddress (samenstelling van een IP-adres, poort en een definitie van het tranportprotocol), OpalListenerUDP en OpalTransportUDP waarin functies als ConnectTo() zijn geïmplementeerd.

Figure 29: OpalCall en OpalTransportUDP

Een derde soort klassen uit de opal-module verzorgen de implementatie van mediastreams. Ze maken met andere woorden de verbinding tussen het ontvangen van een UDP-pakket met spraakdata en het afspelen van geluid door een audio-device dat geïmplementeerd is in de Ekigabibliotheek. Tenslotte hebben we nog enkele klassen die minder belangrijk zijn voor ons onderzoek. Het betreft hier klassen om een unieke identifier te genereren, een antwoordapparaat te implementeren, etc. Hier zullen we bijgevolg ook niet dieper op ingaan.

47 | Hoofdstuk 7 - Ekiga SIP In de sip-module staan, zoals de naam het zelf zegt, de klassen die de implementatie van het SIPprotocol verzorgen. We onderscheiden 4 bestanden in deze module: sipep, sipcon, sippdu en sdp. In het SDP-bestand staan alle klassen en functies die te maken hebben met het Session Description Protocol, een protocol dat door het SIP-protocol gebruikt wordt om over parameters van een mediasessie te negotiëren27. Bij het opstarten van Ekiga wordt er automatisch een instantie van de SIPEndPoint aangemaakt. Dit object moet alle zaken die met het SIP-protocol te maken hebben delegeren. Bij het opzetten van een gesprek zal hij een nieuwe SIPConnection aanmaken die alle zaken voor één bepaald SIP-gesprek zal regelen. Om een SIP-gesprek op te zetten moeten er, zoals in het protocol beschreven staat, controleboodschappen28 verstuurd worden. Al deze boodschappen zijn geïmplementeerd als kindklasse van een SIPPDU (SIP protocol data unit).

Figure 30: Structuur SIP module

RTP Wanneer een SIP-gesprek is opgezet zullen de spraakdata aan de hand van RTP-pakketten uitgewisseld worden tussen de twee eindgebruikers. In de RTP-module wordt de functionaliteit voorzien die deze RTP-pakketten in een juiste context kan plaatsen en afleveren aan een mediastream die de informatie verder zal verwerken. Bovendien is de anti-jitter buffer29 ook in deze module geïmplementeerd.

1.3 Pwlib Zoals eerder vermeld bestaat de Pwlib-bibliotheek voornamelijk uit definities en implementaties van PString en andere eigen gebruikte basisklassen. Aangezien we hier geen wijzigingen in zullen aanbrengen is het ook een beetje zinloos om hier lang bij stil te staan. Het enige wat we van Pwlib hoeven te weten is welke klassen we kunnen gebruiken en hoe deze klassen zijn opgebouwd om ze te kunnen onderzoeken tijdens het debuggen.

27

cfr hoofdstuk 3 INVITE, BYE, OK, … 29 Zie hoofdstuk over pakketverlies en vertraging. 28


2. Opzetten van een Call Om een betere kijk op de werking van Ekiga (het programma, niet de bibliotheek) te krijgen zullen we nu het geval beschrijven waarbij we een gesprek willen opzetten met een andere gebruiker. We beschrijven hierbij het pad dat we door de code volgen. Alsof we stap voor stap het programma uitvoeren met behulp van een debugger. Hierbij proberen we niet te veel stil te staan bij de details om zo een overkill aan informatie te vermijden en een duidelijk beeld te scheppen van de werking van het programma.

Figure 31: Call knop met SIP-url

We veronderstellen dat we aangemeld zijn onder de account van [email protected] en willen bellen met [email protected]. Vooreerst vullen we [email protected] in als SIP-URL die we willen contacteren. Wanneer we vervolgens op de call-knop klikken komen we in de callback-functie van deze knop terecht. In deze functie zullen we eerst de SIP-URL die we willen bellen uit het tekstvak lezen. Vervolgens checken we of we al een gesprek aan het voeren zijn.

Figure 32: Callback functie van "call"-knop

In dat geval zou een klik op de call-knop betekenen dat we het gesprek willen beëindigen. Dit is niet het geval en dus zullen we een nieuw gesprek trachten op te zetten. We roepen de functie connect() van de Ekiga-klasse op en geven de SIP-URL van Bob als parameter mee. CallBacks connect_cb () Druk op call-knop

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.


Figure 35: SetupCall() en MakeConnection()-functie

In de MakeConnection()-method zullen we aan de hand van de url van Bob uitmaken met welk soort protocol we te maken hebben. Het endpoint van het desbetreffende protocol zal de setup van het gesprek verder regelen. Merk hierbij op dat het OpalManager-object verschillende endpoints bevat. Eén voor elk beschikbaar protocol. In ons geval zullen we verder gaan met de MakeConnection()method van de SIPEndPoint-klasse.

Figure 36: MakeConnection in OpalManager

Vanaf nu zijn we specifiek met het SIP-protocol bezig en bevinden we ons in de sip-module van de Opal-bibliotheek. Het eerste wat we doen in de MakeConnection()-method van het SIPEndPoint is een nieuwe call-ID aanmaken. Dit is een unieke identifier waarmee we ons gesprek lokaal en op het netwerk zullen identificeren. We maken bovendien een SIPConnection aan en slaan deze op in een tabel met zijn call-ID als index. Ook dit is belangrijk vermits we later de gegevens van deze SIPConnection moeten opvragen om de handover te realiseren. Wanneer de SIPConnection is aangemaakt en opgeslagen, roepen we de SetUpConnection()-method op.


Figure 37: MakeConnection()-functie van SIPEndpoint

In deze methode zullen we concreet de INVITE-boodschap van het SIP-protocol trachten te versturen. Zoals eerder vermeld hebben we hier een Transport-object voor nodig. Er zijn verschillende Transport klassen naar analogie met de verschillende transportprotocols. Ze bevatten sockets waarover we pakketten zullen sturen. Wij zullen uiteraard gebruik maken van een UDPTransport. Deze bevat een WriteConnect()-method. Hierin worden twee acties gecombineerd. Vooreerst worden de sockets opgezet en de tweede actie wordt gedefinieerd door een functionpointer 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

UDPTransport

SetUpConnection()

WriteConnect()

1. Creer UDPTransport 2. Roep WriteConnect()-functie op

1. Activeer Sockets 2. Roep WriteINVITE()-functie op

WriteINVITE() 1. Creeer SIPTransaction-object 3. Roep Start()-functie op

SIPTransaction Start() 1. Verstuur INVITE over Transport

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 handoverprocedure die we hebben vooropgesteld. De eerste fase is het versturen van een INVITE met joinheader naar de IMS-server31 van het oorspronkelijke gesprek. Vervolgens sturen we bij het ontvangen van het eerste RTP-pakket op de nieuwe interface een ReINVITE-boodschap naar de gebruiker waar we een gesprek mee voeren. Tenslotte zullen we nog een BYE-boodschap sturen naar de IMS-server van het oorspronkelijke domein om die verbinding af te sluiten.

31

Die op dat moment als back to back user agent fungeert


3.1 INVITE met join-header We hebben ons tot nu toe enkel geconcentreerd op het beschrijven van de handover-procedure op zich en niet op het triggeren ervan. Een trigger voor het uitvoeren van de handover-procedure zou bijvoorbeeld kunnen zijn dat de sterkte van het draadloze netwerk verzwakt en we moeten overschakelen naar een GPRS-verbinding. Voor de eenvoud gebruiken we in ons project een extra knop in de menubalk van Ekiga. We zullen bij de implementatie de overgang van de reeds aanwezige verbinding (GPRS of in onze testopstelling LAN) naar het draadloze netwerk realiseren.

Figure 40: Join knop

Het eerste wat we toegevoegd hebben aan de code van Ekiga is een knop waarmee we de handoverprocedure 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 handoverprocedure zich in de Opal-bibliotheek bevindt.


Figure 43: Overgang van Ekiga- naar Opal-bibliotheek

In de HandOver()-functie van de OpalManager zoeken we eerst de OpalCall van het huidige gesprek op. Dit object gebruiken we om gegevens van het huidige gesprek op te vragen. Bovendien zullen we wijzigingen aan deze OpalCall aanbrengen omdat we nieuwe verbindingen zullen gebruiken voor het sturen van SIP-boodschappen. We geven de OpalCall mee als parameter van de SwitchConnection()functie die zich in dezelfde OpalManager bevindt.

Figure 44: HandOver functie

De SwitchConnection()-functie heeft een gelijkaardige taak voor de handover-procedure als de MakeConnection()-functie voor het opzetten van een gesprek. Eerst schrijven we het IP-adres van de nieuwe interface weg naar een plaatselijke variabele zodat we het later nog kunnen gebruiken. Bij het opzetten van een gesprek onderzoeken we in de MakeConnection()-functie welk protocol we moeten gebruiken en roepen we de MakeConnection()-functie op van het gepaste endpoint. In de handover-procedure weten we echter dat we met het SIP-protocol te maken hebben. We kunnen meteen de MakeConnection()-functie van het SIPEndpoint oproepen. Hierbij geven we de OpalCall en het IP-adres van de nieuwe interface als parameters mee.

Figure 45: SwitchConnection, van OpalManager naar SIPEndpoint

De eigenlijke functionaliteit van de handover-procedure is volledig gelokaliseerd in het SIPEndpoint. Aan de hand van een drietal functies wordt ervoor gezorgd dat nieuwe verbindingen worden opgezet, oude verbindingen worden verbroken en de nodige boodschappen worden verstuurd. De eerste van deze functies is de SwitchConnection()-functie. In deze functie zullen we ervoor zorgen dat er een SIP INVITE-aanvraag met join-header wordt verstuurd naar de IMS-aanvraag van het huidige gesprek. Deze aanvraag sturen we van uit onze nieuwe interface. Bovendien zorgen we ervoor dat de RTP-pakketten die de P-CSCF zal sturen goed opgevangen worden.

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 handoverprocedure: 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 RTPmediastreams voorbereid. Wanneer we de SDP-beschrijving van de gesprekspartner in de OKboodschap 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 fakeSDP 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 sequencenummer33 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 sequencenummer 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 RTPpakket 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?

Ja

Nee

In welke fase bevinden we ons?

join 1.Verstuur ReINVITE 2.Verander naar reinvite-fase 3.pas filter toe op pakket

reinvite

1.pas filter toe op pakket

done

1.Vervolledig handover 2.Verander naar done-fase 3.pas filter toe op pakket

1.pas filter toe op pakket

Figure 50: Beslissings diagram trigger

3.3 ReINVITE Zoals we in hoofdstuk 6 reeds aanhaalden is een ReINVITE-boodschap eigenlijk een gewone INVITEaanvraag 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 ReINVITEboodschap 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 BYEboodschap 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 SIPfunctionaliteit 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 handoverprocedure 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 IMSnetwerk. 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 (IPadres 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 IMSserver. 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 [email protected] SIP/2.0 Via: SIP/2.0/UDP 10.10.5.50:5060 To: sip:bob@ jan-ims.test From: sip:alice@ jan-ims.test Contact: sip:[email protected]

INVITE van IMS-server Bob INVITE [email protected] SIP/2.0 Via: SIP/2.0/UDP 10.10.5.30:5060 To: sip:bob@ jan-ims.test From: sip:alice@ jan-ims.test Contact: sip:[email protected]

De IMS Server zal echter wel een tabel moeten bijhouden met de werkelijke IP-adressen van Alice en Bob. Wanneer hij het antwoord van Bob krijgt zal hij in de tabel opzoeken wat het IP-adres is van Alice zodat hij de boodschap kan doorsturen. Het wijzigen van de SIP-headers is echter niet voldoende om ervoor te zorgen dat alle dataverkeer tussen Alice en Bob via de IMS-server gaat. Zoals vermeld in 5.2.2 worden de RTP-pakketten op dit moment nog steeds rechtstreeks verstuurd tussen Alice en Bob. De afspraken die gemaakt worden betreffende het dataverkeer tussen beide gesprekspartners worden verwoord in de SDPboodschappen die als inhoud van de SIP-boodschappen worden uitgewisseld. In de SDP-boodschap vermeldt de gebruiker niet enkel de codecs die hij ondersteunt maar ook de IP-adressen en poorten

62 | Hoofdstuk 8 - De IMS-Server waarop hij luistert naar inkomende datapakketten. Net als bij de wijziging van de SIP-boodschappen zal de IMS-server deze IP-adressen en poorten in de SDP-boodschap aanpassen. Op deze manier zullen ook de RTP-pakketten niet rechtstreeks maar via de IMS-server uitgewisseld worden. SDP van Alice naar IMS-server o= 1073055600 1073055600 IN IP4 10.10.5.50 c=IN IP4 10.10.5.50 t= 23456 23456 m=audio 5000 RTP/AVP 112 113 a =rtpmap:112 L16/48000/2 a=rtmap:113 DAT12/32000/4 a=fmtp:113 contents:DV L/R/C/WO

SDP van IMS-server Bob o= 1073055600 1073055600 IN IP4 10.10.5.30 c=IN IP4 10.10.5.30 t= 23456 23456 m=audio 7001 RTP/AVP 112 113 a =rtpmap:112 L16/48000/2 a=rtmap:113 DAT12/32000/4 a=fmtp:113 contents:DV L/R/C/WO

SDP van Bob naar IMS-server o= 1073055600 1073055600 IN IP4 10.10.5.51 c=IN IP4 10.10.5.51 t= 23456 23456 m=audio 6000 RTP/AVP 112 113 a =rtpmap:112 L16/48000/2 a=rtmap:113 DAT12/32000/4 a=fmtp:113 contents:DV L/R/C/WO

SDP van IMS-server Alice o= 1073055600 1073055600 IN IP4 10.10.5.30 c=IN IP4 10.10.5.30 t= 23456 23456 m=audio 7000 RTP/AVP 112 113 a =rtpmap:112 L16/48000/2 a=rtmap:113 DAT12/32000/4 a=fmtp:113 contents:DV L/R/C/WO

Het feit dat de IMS-server acteert als b2bua heeft natuurlijk alles te maken met onze handoverprocedure. Op het moment dat de IMS-server de INVITE met join-header van Alice ontvangt zal hij alle RTP-pakketten van Bob moeten verdubbelen en naar beide interfaces van Alice sturen. Hiervoor gebruiken we het Application Server gedeelte van de IMS-server. De poorten die we invullen in plaats van de locale poorten van Alice en Bob in de SDP-boodschappen zijn dus de poorten waarop de Application Server luistert. De Application Server zal zelf de juiste poorten van de gesprekspartners in een tabel bijhouden om de binnenkomende pakketten juist door te sturen.

Figure 55: Back to Back user agent: data

2.2 INVITE met join-header Op dit moment heeft de IMS-server zich volledig als back to back user agent gemanifesteerd in het netwerk. Alle SIP-setupboodschappen en alle RTP-datapakketten die tussen twee gebruikers worden uitgewisseld, komen voorbij de IMS-server. Nu hebben we echter nog niets extra geïmplementeerd dat rechtstreeks met de handover te maken heeft. De belangrijkste taak van de server tijdens de handover-procedure is het verdubbelen van pakketten die van Bob komen en deze naar de verschillende interfaces sturen van Alice sturen. Dit zal de server doen zodra hij de INVITE met join-

63 | Hoofdstuk 8 - De IMS-Server header van Alice heeft ontvangen. In deze SIP-boodschap staat alle informatie die de server nodig heeft om het verdubbelen van de pakketten te starten. INVITE met join-header INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 192.168.32.5:5060 To: [email protected] From: ;tag=003 Call-Id: call1 CSeq 1 INVITE Contact: <sip:[email protected]> Join: call1;to-tag=002;from-tag=001

Uit het Via-veld van de INVITE kan de server het IP-adres en de poort halen waar hij de verdubbelde pakketten naartoe moet sturen. De join-header levert informatie over welk gesprek het gaat. De IMSserver 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 GPRSverbinding 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 39

In onze testopstelling: LAN-verbinding 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 SIPboodschappen 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/htmlinfo/22078.htm Banerjee, K. (2005). Opgehaald van http://www.geocities.com/intro_to_multimedia/SIP/registration.html

SIP

Introduction:

Banerjee, N., Acharya, A., & Das, S. K. (2006). Seamless SIP-Based Mobility for Multimedia Applications. IEEE Network , 6-13. Bates, R. ". (2001). GPRS: General Packet Radio Service. McGraw-Hill Professional. Berners-Lee, T., Fielding, R., & Frystyk, H. (1996). Hypertext Transfer Protocol -- HTTP/1.0. RFC 1945. Opgehaald van http://www.w3.org/Protocols/rfc1945/rfc1945 Calhoun, P., Loughney, J., Guttman, E., Zorn, G., & Arkko, J. (2003). Diameter Base Protocol. RFC 3588. Internet Engineering Task Force. Camerillo, G., & Garcia-Martin, M. A. (2006). The 3G IP Multimedia Subsystem (IMS). John Wiley & Sons,Ltd. Demeester, P., & Pickavet, M. (2006). Multimedia Networks. ETSI. (2004). European Telecommunications Standards Institute. Opgehaald van http://www.etsi.org/ GSM Association. (1987). GSM World - the website of the GSM Association. Opgehaald van http://www.gsmworld.com/index.shtml Internet Engineering Task Force. (2002). ISUP to SIP mapping. RFC 3398. Opgehaald van http://www.ietf.org/rfc/rfc3398.txt ITU. (1992). International http://www.itu.int/net/home/index.aspx ITU-T. (2002). Gateway control http://www.itu.int/ITU-T/index.phtml

Communications

Protocol.

ITU-T. (1992). The ITU Telecommunication http://www.itu.int/ITU-T/index.phtml

Union.

Opgehaald

van

Recommendation

H.248.

Opgehaald

van

Standardization

Sector.

Opgehaald

van

Mockapetris, P. (1983). Domain Names - Concepts and Facilities. RFC 882. Internet Engineering Task Force. Moving Picture Experts Group http://www.chiariglione.org/mpeg/

(MPEG).

(1998).

MPEG

home

page.

Opgehaald

van

69 | Referenties NeoNova bv. (2006). Wat is www.astium.nl/nl/download/wat_is_voip.pdf

VoIP.

Opgehaald

van

www.Astium.nl:

NIST. (2001). jain-sip: JAVA API for SIP Signaling. Opgehaald van java.net: https://jainsip.dev.java.net/ OzVoIP.com. (2004). VoIP Codecs Clients Compare Codecs. Opgehaald van www.ozvoip.com: http://www.ozvoip.com/codecs.php Postel, J. B. (1982). Simple http://www.ietf.org/rfc/rfc0821.txt

Mail

Transfer

Protocol.

RFC

821.

Opgehaald

van

Repiquet, J. (2005). IMS Call Flows. Opgehaald van Tech-Invite: http://www.tech-invite.com/Ti-imsregflow-2.html Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., et al. (2002). SIP: Session Initiation Protocol. RFC 3261. Opgehaald van http://www.ietf.org/rfc/rfc3261.txt Sandras, D. (2003). Ekiga: Free your speech. Opgehaald van http://www.gnomemeeting.org/ Schulzrinne, H., Casner, S. L., Frederick, R., & Jacobson, V. (1996). RTP: A Transport Protocol for RealTime Applications. RFC 1889. Internet Engineering Task Force. The Parlay Group. (2001). Parlay :: Parlay/OSA http://www.parlay.org/en/specifications/apis_archives.asp

Specifications.

Opgehaald

van

Seamless Handover in het IP Multimedia Subsystem

Recommend Documents