Mérési útmutató a Mobil kommunikációs laboratórium méréseihez
SIP mérés SIP alapú VoIP hívások vizsgálata, és az IP Multimedia Subsystem (IMS) szerepének bemutatása
Mérés helye: Mobil Kommunikáció és Kvantumtechnológiák Laboratórium IB. 113 A mérést összeállította: Faigl Zoltán Utolsó módosítás: 2013. szeptember 18.
Tartalomjegyzék 1 MÉRÉS LEÍRÁSA
3
1.1 MI AZ IMS HÁLÓZAT? 1.1.1 AZ IMS MEGJELENÉSE AZ UMTS FEJLŐDÉSE SORÁN 1.1.2 AZ IMS ELŐNYEI 1.1.3 AZ IMS HÁTRÁNYAI 1.1.4 AZ IMS ALRENDSZER FUNKCIONÁLIS FELÉPÍTÉSE 1.1.5 JELZÉS ÉS ADATFORGALOM SZÉTVÁLASZTÁSA 1.2 IMS PROTOKOLLOK 1.2.1 SIP PROTOKOLL 1.2.2 SDP PROTOKOLL 1.2.3 RTP ÉS RTCP PROTOKOLL 1.3 AZ IMS KÉT LEGFONTOSABB SIP METÓDUSA 1.3.1 IMS REGISZTRÁCIÓ 1.3.2 IMS KAPCSOLATFELÉPÍTÉS 1.4 IRODALMI HIVATKOZÁS 1.5 ELLENŐRZŐ KÉRDÉSEK
3 3 4 5 5 7 8 8 10 11 11 11 12 15 16
2 MÉRÉSI KÖRNYEZET
17
2.1 MÉRÉSHEZ HASZNÁLT SZOFTVEREK 2.1.1 WIRESHARK 2.1.2 X-LITE
18 18 19
3 MÉRÉSI UTASÍTÁS
20
3.1 I. FELADAT: HÍVÁSFELÉPÍTÉS SIP KLIENSEK KÖZÖTT 3.2 II. FELADAT: HÍVÁSFELÉPÍTÉS KÉT SIP KLIENS KÖZÖTT AZ IMS HÁLÓZAT BEVONÁSÁVAL 3.3 III. FELADAT: SZORGALMI FELADATOK
20 20 21
1 Mérés leírása A mérés során a hallgatók a gyakorlatban is megismerik a SIP alapú VoIP hívások logikáját, illetve képet alkothatnak az IMS hálózat működéséről.
1.1 Mi az IMS hálózat? Röviden az IP Multimedia Subsystem (IMS) egy globális, hozzáférési hálózattól független, IP feletti kapcsolatokat és szolgáltatásokat vezérlő architektúra, amely a mára igen elterjedt internet-alapú protokollokkal felvértezett végkészülékek számára nyújt multimédiás kapcsolódási lehetőséget [1].
1.1.1 Az IMS megjelenése az UMTS fejlődése során Az IMS bevezetése az UMTS hálózatok evolúciójához köthető. A 3GPP szabványosítási szervezet Release-ek (ún. „Kiadások”) formájában jelenteti meg az egyre újabb 3G hálózatspecifikációkat [2]. Az UMTS Release 5 (2002) legfontosabb újdonságai közé tartozik az IMS (IP Multimedia Subsystem) megjelenése, és a SIP (Session Initiation Protocol) alapú multimédia szolgáltatások és a csomagkapcsolt hordozószolgáltatások kezelése (szolgáltatás fejlődés). Ehhez a Release-hez köthető a HSDPA (High-Speed Downlink Packet Access), az IPv6 gerinchálózat, valamint a végpontok közötti QoS támogatás megjelenése is. A Release 6 (2004) legfontosabb újdonságai: IMS Phase 2, Presence, Instant Messaging, hozzáférési hálózat-függetlenség, DRM (Digital Rights Management), és a WLAN–3G együttműködés megjelenése. Az UMTS Release 5 utáni fejlesztések elsődleges célja a felhasználói élmény növelése. A fenti elvnek megfelelően a Release 6 elsősorban a kapacitás növelésére, QoS támogatásra és valósidejű multimédiás csomagkapcsolt alapú szolgáltatások fejlesztésére és nyújtására, valamint a teljes IP (all-IP) hálózat irányába való továbblépésre helyezi a fő hangsúlyt. A Release 6 egyik fontos célja a különböző technológiák integrációja (2G, 3G, WLAN stb.), és az UMTS rendszerrel történő együttműködés (például számlázás, biztonság, felhasználó azonosítása) kidolgozása. Azonos session control layert (IMS) használ minden szolgáltatás számára (multimédia, streaming, játékok stb.) Az IMS fejlesztései közül kiemelkedik az üzenetküldés és konferenciahívások támogatása, az áramkörkapcsolt és csomagkapcsolt hálózatokkal történő együttműködés fejlesztése. A szolgáltatások területén újdonság a vészhívások támogatása, Push-to-Talk over Cellular (PoC; cellás hálózatokban Push-to-Talk szolgáltatás), jelenlét, helyzet információ (location information), azonnali üzenetküldés, és a csomagkapcsolt streaming szolgáltatások támogatása. A 3GPP UMTS Release 6 egyik kulcseleme a Multimedia Broadcast Multicast Service (MBMS) szolgáltatás, melynek segítségével ugyanaz a tartalom egyszerre több felhasználóhoz juttatható el ugyanabban a rádiós cellában. Az IMS alapvető szerepe a további Release-ekben (Release 7, 8, 9) nem változott, fix és mobil hálózatok közös, egységes szolgáltatásvezérlő platformjaként van jelen.
1.1.2 Az IMS előnyei A telekommunikációs hálózat különböző szintjein zajló konvergencia-folyamatok a szolgáltatókat rádöbbentették, hogy a hatékony feladatvégzés érdekében az eltérő hálózati platformok közötti kommunikáció vezérlési és menedzselési módszereit egységesíteni kell. Ezen fő motiváció által vezérelve a különböző ipari résztvevők a 3GPP (3rd Generation Partnership Project), az ETSI és a Parlay Forum szorgalmazásával és vezetésével lefektették az IP Multimédia Alrendszer (IMS – IP Multimedia Subsystem) alapjait [2]. Az IMS architektúrát egy olyan, csomagkapcsolt hálózatok fölé kialakított fedőhálózatként (overlay network) hozták létre, mely a különböző IP alapú (mobil és vezetékes) kommunikációs rendszerekben egységes felületként képes a szolgáltatások integrálására és valós idejű multimédia alkalmazások nyújtására. Fontos tervezési szempont volt, hogy az IMS egységes szolgáltatási és menedzsment platformja felett harmadik fél által fejlesztett szolgáltatások is gond nélkül működhessenek, így nagyszámú és változatos alkalmazások legyenek elérhetők az előfizetők számára. Négy különböző kulcsfunkcionalitás teszi az IMS-t a jövő szolgáltatás- és alkalmazásorientált konvergens hálózatainak alapvető technológiájává: • Könnyű és hatékony szolgáltatás-integráció, akár harmadik fél számára is. A hozzáadott értékkel bíró szolgáltatások közötti interakció támogatott. • A hagyományos szolgáltatások gond nélkül működhetnek az új architektúrán, az áramkörkapcsolt hálózatrészekkel is zökkenőmentes az együttműködés. • Az IMS a szolgáltatás minőségének biztosítására is fejlett mechanizmusokat nyújt. Kapcsolatonként igényelhető a QoS paraméterek beállítása. Ehhez a szükséges hálózati intelligenciát a PDF (Policy Decision Function) biztosítja. • A szolgáltatók által kiemelkedő fontossággal bíró összetett és akár személyre szabható számlázási funkciók is integráltan vannak jelen az IMS rendszerben. Lehetőség van különböző szolgáltatási üzleti modellek megvalósítására, esemény- és QoS alapú számlázásra is. A felsorolt funkciók egyike sem tekinthető külön-külön forradalmi újításnak, ám az IMS az első olyan rendszer, mely ezen kulcsfunkciók integrálását és interakcióját a hálózat minden dimenziójában lehetővé teszi. Az IMS rendszerét eredetileg mobil környezetbe tervezték, ám minden gond nélkül alkalmazható vezetékes hálózatokban, és megfelel az NGN hálózatok heterogenitása által keltett kívánalmaknak is. A szolgáltatások szinte bármilyen összetétele létrehozható, mégpedig a végfelhasználók számára tökéletesen transzparens módon. Az 1. ábra az IMS szerepét szemlélteti. A vezetékes és vezetéknélküli hozzáférési hálózatok az IP végpontok bekötésére szolgálnak. Az IMS az IP feletti multimédiás kapcsolatok kiépítését menedzseli, és szabványos Quality of Service (QoS), biztonsági, és számlázási szolgáltatásokat nyújt. Az IMS szolgáltatásait távközlési, üzleti, és játék alkalmazások veszik igénybe.
1. ábra – Az IMS szerepe.
1.1.3 Az IMS hátrányai A 3GPP IMS architektúra rejt magában problémákat, amely kockázatossá teszi a nagy sávszélesség igényű, valós idejű, IP-alapú szolgáltatások széleskörű elterjedését. A központosított funkciók, illetve az egy felhasználó által okozott nagy volumenű jelzésforgalom skálázhatósági problémához vezethet. Több millió felhasználó kiszolgálása komoly hálózatméretezési feladatot igényel. Manapság forgalomszűréssel próbálják levenni a terhet a szűk keresztmetszetekről. 3GPP hozzáférési hálózatok esetén a PDN GW (illetve korábbi 3GPP releasekben a GGSN) lát el központi szerepet. Szolgáltatónként kb. 2-3 PDN GW / GGSN tart fenn IP kontextust minden Internethez csatlakozó 3G felhasználónak. Release 8, 9 esetén a PDN GW alagutaz minden IP forgalmat az eUTRAN és az Internet, illetve IMS között. IMS-nél skálázhatósági problémát okozhat a P-CSCF, amely központi proxy funkciót lát el. Minden SIP jelzés áthalad rajta. IPsec biztonsági kapcsolatot kell fenntartania a beregisztrált IMS felhasználókkal. Az S-CSCF is központosított, a regisztrált felhasználók összes meglévő SIP kapcsolatát kezeli. Egy lehetséges megoldást jelent ezekre a problémákra a központi funkciók decentralizálása, lokális döntéshozás támogatása. Ez a törekvés az IMS egyes funkcióinak elosztásához, esetenként újfajta közös vezérlőplatform koncepció kialakításához vezet. Például a peer-topeer SIP (P2PSIP) hálózatoknál [11] egy elosztott overlay hálózat biztosítja a korábbi központosított funkciókat (mint pl. location update, regisztrálás, címzés). Fontos kritérium, hogy a jövőbeli hálózatok is kézben tarthatóak legyenek a szolgáltatók szempontjából, az egységes szolgáltatás vezérlőplatform, számlázás, QoS támogatás, biztonsági szolgáltatások megmaradjanak.
1.1.4 Az IMS alrendszer funkcionális felépítése Az IMS hálózati tartomány a szolgáltatók maghálózatában található. A 2. ábra az IMS főbb funkcionális elemeit szemlélteti. A bal ábra az alapvető IMS funkciókat tartalmazza, és azok kapcsolódását más 3GPP Release 8 hálózati funkciókhoz, a jobb ábra részletesebb.
2. ábra – Az IMS alrendszer funkcionális felépítése.
Az IMS lényegében az a vezérlő rendszer, amely segítségével megtalálják egymást és az alkalmazás szervereket a beregisztrált felhasználók, és az IMS jelzésprotokolljai segítségével multimédiás kapcsolatot építenek ki. Az IMS hálózat a következő fő funkcionális entitásokból áll: P-CSCF (Proxy Call/Session Control Function): adott IMS tartományhoz (pl. mik.bme.hu) csatlakozó felhasználók jelzésforgalma egy proxy szerveren megy keresztül. A proxy biztosítja a felhasználók és az IMS tartomány közötti biztonságos kommunikációt. Az IMS regisztráció során kölcsönös hitelesítés zajlik le az IMS hálózat (pontosabban az S-CSCF) és a felhasználói készülék között, amely során létrejönnek a kapcsolatkulcsok. A sikeres regisztrációs fázist követően IPsec kapcsolatot tart fenn a P-CSCF minden aktív terminállal. S-CSCF (Serving CSCF): Az IMS fő jelzés protokollja a Session Initialization Protocol (SIP). Ez kliens-szerver oldali megközelítést használ. Az S-CSCF valósítja meg a kiszolgáló oldalt. Alapvető feladata a SIP kapcsolatok kiépítése, a kapcsolatok menedzselése, állapotainak fenntartása. Az S-CSCF felel a felhasználók hitelesítéséért és az IMS és a felhasználó közötti kulcsegyeztetésért. A felhasználók hitelesítéséhez és kulcsegyeztetéshez szükséges adatokat a Home Subscriber Server-től (HSS) kéri le. Az S-CSCF a felhasználó otthoni hálózatában helyezkedik el. I-CSCF (Interrogating CSCF): idegen adminisztratív IMS tartományból érkező SIP jelzésüzenetek nem a P-CSCF-en, hanem az I-CSCF-en keresztül érkeznek be. Az I-CSCF feladata megkeresni, hogy adott felhasználót melyik S-CSCF szolgálja ki. Az I-CSCF a HSStől kérdezi le ezt az információt. AS (Alkalmazás szerverek): SIP user agent-eket valósítanak meg különböző multimédiás alkalmazások nyújtására (pl. hangmenü szolgáltatás). BGCF (Brekout Gateway Control Function): eldönti, hogy adott esetben egy multimédiás kapcsolatot ki kell irányítani az áramkörkapcsolt tartományba. MGCF (Media Gateway Control Function), Media GW: különböző jelzés és média transzport protokollok között fordít : pl. IMS és PSTN (Public Switched Telecommunication Network) között SIP / ISUP, RTP / PCM fordítást végez. MRF (Multimedia Resource Function): médiával kapcsolatos feladatokat hajt végre, pl. konferenciahívásnál összekeveri a hangcsatornákat, hangjelzéseket generál stb.
Az alábbi entitások a 3GPP Release 8 maghálózat és rádiós hozzáférési hálózat részei. PCRF (Policy and Charging Rules Function): 3GPP maghálózat része, előfizetőkre vonatkozó engedélyezési és számlázási szabályokat mondja meg. PDN GW (Packet Data Network Gateway), Serving GW: A 3GPP Release 8 szabványban definiált EPC (Evolved Packet Core) maghálózat része. A PDN GW biztosít a termináloknak kapcsolatot az IP alapú hálózatok felé, így az IMS felé is. E-UTRAN (Evolved Universal Terrestrial Radio Access Network): 3GPP Release 8 szabványban definiált mobil hálózat rádiós hozzáférési része, amely az eNodeB-kat, azaz bázisállomásokat tartalmazza. LTE-nek (Long Term Evolution) is nevezik. Névlegesen 100 Mbps downlink és 20 Mbps uplink csúcs adatátviteli sebességet képes elérni 20 MHz spektrum szélességben.
1.1.5 Jelzés és adatforgalom szétválasztása Az 3. ábra az IMS-en keresztüli multimédiás kapcsolat-felépítést mutatja be 3GPP Release 8 hozzáférési hálózaton keresztül. Az IMS jelzésüzenetek a P-CSCF, I-CSCF, S-CSCF entitásokon keresztül haladnak, a média forgalom közvetlenül a terminálok között halad. Az IP forgalom minden esetben a PDN GW-en keresztül megy, az IP forgalom a PDN GW és a terminál között alagutazással továbbítódik. A 4. ábra a lehetséges jelzésútvonalakat szemlélteti, attól függően, hogy egy IMS felhasználó másik IMS felhasználót hív, a multimédiás szolgáltatás egy alkalmazás szervert érint (pl. hangmenü), vagy PSTN hálózatba intéz hívást.
3. ábra – Jelzés és adatforgalom útvonala IMS-alapú kapcsolatok esetén.
4. ábra – Az IMS jelzésforgalom tipikus útvonalai.
1.2 IMS protokollok Az 5. ábra az IMS-alapú kapcsolatokhoz szükséges protokollarchitektúrát mutatja be a felhasználói készülékben. A fizikai és adatátviteli réteg protokollok hozzáférési technológia függőek. A hálózati rétegben IPv4 vagy IPv6 protokollt használnak. A szállítási rétegben alapvetően UDP-ét alkalmaznak. Megjegyezzük, hogy a SIP protokoll TCP és STCP felett is mehet. Az alkalmazási réteg szintjén helyezkednek el az IMS jelzésprotokollok (SIP, SDP) és a média átviteli protokollok (RTP, RTCP).
5. ábra – Egy IMS terminál protokollarchitektúrája.
1.2.1 SIP protokoll Az IMS jelzésprotokollja a Session Initialization Protocol (SIP), amely egy nyílt, HTTP-szerű, szövegalapú protokoll. Az IETF RFC 3261 és további szabványok specifikálják. A SIP jelzésüzeneteket könnyű értelmezni és egyszerű előállítani. A SIP külső biztonsági szolgáltatások nélkül igen könnyen sebezhető (pl. elárasztásos támadásal, man-in-the-middle támadással, jelzés lehallgatással, adatmódosítással). A SIP jelzések „hop-by-hop” módon haladnak a SIP kliensek és az IMS entitások között. A SIP feladata a multimédiás kapcsolatok kiépítése, módosítása, bontása. Ez a protokoll biztosítja, hogy a végpontok beregisztrálják a helyzetüket (IP címüket), illetve ez alapján megtalálják egymást.
Alapvető SIP metódusok: REGISTER: felhasználói azonosító (sip:
[email protected]) beregisztrálása egy adott elérési címre (IP címre). Regisztráció során történik a felhasználó-hitelesítés, és az IMS-hez való hozzáférés-engedélyezés is. INVITE: e metódus segítségével tud multimédiás kapcsolatot kiépíteni egy felhasználó más felhasználóval vagy alkalmazás szerverrel. BYE: SIP kapcsolat bontására használják a kommunikáló felek CANCEL: függőben lévő kérés (pl. SIP INVITE) megszakítására alkalmazzák OPTIONS: SIP proxy vagy másik SIP User Agent képességeinek lekérésére használják ACK: Az ACK kérés igazolja, hogy egy SIP kliens végső választ kapott egy INVITE üzenetre. Csak az INVITE metódussal együtt használják. SIP metódus kiegészítések: SUBSCRIBE: más felhasználók állapotváltozásairól való értesítésre történő feliratkozásra használják. Állapot-információ pl. a jelenlét (presence) vagy regisztrációs állapot. Az RFC 3265 szabvány írja le a metódust. NOTIFY: adott felhasználót értesíti egy olyan állapotváltozásról, amely figyelésére feliratkozott. Az RFC 3265 szabvány írja le. MESSAGE: csetelés metódusa. Az RFC 3428 szabvány specifikálja. PRACK: az RFC 3262 szabvány definiálja, nem végleges válaszok megbízható célba juttatására. Az alap SIP szabvány kétféle választ definiál: végleges választ, amelynek megbízató célba juttatásáról gondoskodik, és nem végleges (provizórikus) választ, amely azt jelzi, hogy egy kérés feldolgozás alatt van. Az alap SIP szabvány a nem végleges válaszokat nem megbízható módon továbbította. A PRACK metódus gondoskodik a provizórikus üzenetek pozitív nyugtázásáról. SigComp - SIP üzenetek tömörítése A SIP jelzésüzenetek mérete nem elhanyagolható mobil hálózatok esetében, ugyanis nagyságrendileg 100-1000 bájt hosszú a szállítási réteg szintjén egy jelzésüzenet. Az RFC 3320, Signaling Compression szabvány a SIP jelzésforgalmat tömörítéssel csökkenti. SIP üzenet felépítése // metódus neve INVITE tel:+1-212-555-2222 SIP/2.0
// SIP fejléc: a metódus kötelező és opcionális mezőit tartalmazza Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7 Max-Forwards: 70 Route: <sip:pcscf1.visited1.net:7531;lr;comp=sigcomp>, <sip:scscf1.home1.net;lr> P-Preferred-Identity: "John Doe" <sip:
[email protected]> P-Access-Network-Info: 3GPP; cell-id-3gpp=234151D0FCE11 Privacy: none From: <sip:
[email protected]>;tag=171828 To:
Call-ID: cb03a0s09a2sdfglkj490333 Cseq: 127 INVITE Require: precondition, sec-agree Proxy-Require: sec-agree Supported: 100rel Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi-c=98765432; spi-s=87654321; port-c=8642; port-s=7531 Contact: <sip:[5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp> Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp Content-Length: 545
// SIP body része: jelen esetben SDP média információkat tartalmaz v=0 o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ddd s=c=IN IP6 5555::aaa:bbb:ccc:ddd t=0 0 m=audio 3456 RTP/AVP 97 96 b=AS:25.4 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos none remote sendrecv a=rtpmap:97 AMR a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2 a=rtpmap:96 telephone-event a=maxptime:20 m=video 3400 RTP/AVP 98 99 b=AS:75 a=curr:qos local none a=curr:qos remote none a=des:qos mandatory local sendrecv a=des:qos none remote sendrecv a=rtpmap:98 H263 a=fmtp:98 profile-level-id=0 a=rtpmap:99 MP4V-ES
1.2.2 SDP protokoll A Session Description Protocol (SDP) (RFC 4566) célja a média komponensek leírása és egyeztetése a kommunikáló felek között. A képességegyeztetés lehet statikus vagy dinamikus, azaz a kapcsolat élettartalma során változhat. Pl. ’m’ megnevezi a médiakomponenst, ’a’ megad egy média attribútumot, ’c’ megadja a kapcsolódási címet és portot, ’t’ a kapcsolat felépítésének és lebontásának időpontját. A médiaforgalom az IMS entitások kihagyásával, közvetlenül megy a SIP kliensek között. Általában a szolgáltatók beállítják, hogy áthaladjon a SIP proxyn. SDP egyeztetés menete
6. ábra – Média attribútumok egyeztetése SDP-vel.
A 6. ábra a média attribútumok egyeztetését mutatja be. Az INVITE üzenetben a kezdeményező fél megadja az általa támogatott média attribútumokat (pl. kodekeket). A másik fél a 183 Session progress üzenet SDP részében visszaküldi az elfogadható média attribútumok leszűkített listáját. Végül a kezdeményező által küldött PRACK üzenet tartalmazza a közös SDP paramétereket. A (3) PRACK üzenet jelzi, hogy folyamatban van az erőforrások lefoglalása Alice-nél. Ha Alice oldalán felkészült a hálózat a
multimédia forgalom átvitelére, Alice az (5) UPDATE üzenettel jelzi BoBnak. Végül Bob 200 OK-val jelzi Alice-nak, hogy hívásra kész a végső SDP paraméterekkel. Akár a SIP kliensek, akár a SIP proxy szerverek is kezdeményezhetik az SDP paraméterek dinamikus újratárgyalását, abban az esetben, ha pl. átviteli sebesség csökken valamelyik oldalon. Ehhez SIP UPDATE vagy re-INVITE üzenetet alkalmaznak.
1.2.3 RTP és RTCP protokoll A Real-time Transport Protocol (RTP) (RFC 3550) csomagkapcsolt hálózatok végpontjai közötti valósidejű adatátvitelre dolgozták ki. Tipikusan UDP protokoll felett halad. Az adatcsomagokat időbélyeggel látja el, így a fogadó oldal képes helyes idősorrendbe állítani a csomagokat, és kiszűrni a jittert. A Real-time Control Protocol (RTCP) az RTP vezérlő protokollja. Az RFC 3550 szabvány ötféle RTCP üzenetet definiál: SR (Sender Report): küldő fél riportja különböző RTP statisztikákról. Pl. küldött csomagok száma. RR (Receiver Report): fogadó fél riportja különböző RTP statisztikákról. Pl. fogadott csomagok száma, becsült jitter szórásnégyzet, stb. SDES (Source Description): az RTP folyam forrásáról tartalmaz információt. Pl. név, email cím, telefonszám. Bye: Az RTP kapcsolatot megszakító entitás küldi a másik félnek. APP (Application): alkalmazás-specifikus adatokat tartalmaz. Pl. push-to-talk szolgáltatásnál használják a talk burst üzenetek átvitelére.
1.3 Az IMS két legfontosabb SIP metódusa 1.3.1 IMS regisztráció IMS előfizetők a SIP REGISTER metódussal csatlakoznak az IMS alrendszerhez. A regisztálás során kölcsönös hitelesítés zajlik az S-CSCF és az IMS terminál között. 3GPP IMS hálózatoknál alapvetően az UMTS-nél bevezetett AKA hitelesítést használják. Az S-CSCF a 401 Unauthorized üzenetben küld kihívást (RAND), amelyre a másodszorra kiküldött REGISTER üzenetben küld választ (RES) a terminál. Ha a válasz megfelelő, akkor beregisztrálja az S-CSCF, és a felhasználó igénybe veheti a számára engedélyezett IMS szolgáltatásokat. Az IMS regisztrációt a 7. és 8. ábra szemlélteti. A Diameter üzenetek célja felhasználóra vonatkozó adatok lekérése a HSS-től. Az I-CSCF a HSS útbaigazítása alapján találja meg a felhasználó S-CSCF kiszolgálóját.
7. IMS regisztráció.
8. IMS regisztráció menete.
1.3.2 IMS kapcsolatfelépítés A 9. és 10. ábra a multimédiás kapcsolatfelépítést mutatja be, SIP INVITE metódus segítségével.
9. ábra – IMS kapcsolatfelépítés.
10. ábra – IMS kapcsolatfelépítés üzenet diagrammja.
1.4 Irodalmi hivatkozás [1] 3GPP: "3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2, (Release 9) ", 3GPP TS 23.228 v9.0.0, http://www.3gpp.org/ftp/Specs/html-info/23228.htm, June 2009. [2] Bokor László, Szabó Sándor, „Az IMS megjelenése és alkalmazása fix és vezetéknélküli mobil hálózatokban”, Híradástechnika, LXI. ÉVFOLYAM 2006/10, 11-19. oldal. [3] Miikka Poikselka, Georg Mayer, The IMS: IP Multimedia Concepts and Services, 3rd Edition, ISBN: 978-0-470-72196-4, January 2009. [4] Pierre Lescuyer, Thierry Lucidarme, Evolved Packet System (EPS): The LTE and SAE Evolution of 3G UMTS, ISBN: 978-0-470-05976-0, January 2008. [5] J. Rosenberg, et al., "SIP: Session Initiation Protocol," IETF 3261, http:// www.ietf.org/rfc/rfc3261.txt, June 2002. [6] A. Roach, "Session Initiation Protocol (SIP)--specific event notification," IETF RFC 3265, http://www.ietf.org/rfc/rfc3265.txt, June 2002. [7] B. Campbell, ed. "Session Initiation Protocol (SIP) Extension for Instant Messaging" IETF RFC 3428, http://www.rfc-editor.org/rfc/rfc3428.txt, Dec. 2002. [8] R. Price et al. “Signaling Compression,” IETF RFC 3320, http://www.rfceditor.org/rfc/rfc3320.txt, Jan. 2003. [9] M. Handley, et al., “SDP: Session Description Protocol”, RFC 4566, http://www.rfceditor.org/rfc/rfc4566.txt, July 2006. [10] H. Schulzrinne, et al., “RTP: A Transport Protocol for Real-Time Applications”, IETF standard, RFC 3550, http://www.ietf.org/rfc/rfc3550.txt, Jul. 2003. [11] P2PSIP: http://www.p2psip.org/reading.php, Sept. 2009. [12] OpenIMS: http://www.openims.com, Sept. 2009.
1.5 Ellenőrző kérdések
Rajzolja le az IMS hálózat funkcionális felépítését! Az ábra a legfontosabb IMS entitásokat kell, hogy tartalmazza! Hogyan továbbítódik az IMS szolgáltatások jelzés és adatforgalma? Rajzolja le egy SIP terminál protokollarchitektúráját! Melyik hálózatrészben helyezkednek el, és milyen funkciót látnak el a következő entitások: P-CSCF, I-CSCF, S-CSCF, HSS, AS, PDN GW, eNodeB? Milyen szerepet lát el a SIP, SDP, RTP, és RTCP protokoll? Röviden összegezze a protokollok célját, jellegzetességeit!
2 Mérési környezet A mérés során a hallgatók párokat képeznek, páronként egy jegyzőkönyv megírása szükséges. A hallgatópárok az első feladatban az IMS kliensek között közvetlen, a második feladatban az openIMS nevű IMS rendszeren keresztül építenek fel hívást. A mérési környezetet a 11. ábra szemlélteti. Mérőhelyek: IMS kliens, lehallgatás
OpenIMS
I-CSCF 192.168.130.1 P-CSCF 192.168.130.3
HSS 192.168.130.4
S-CSCF 192.168.130.2
11. ábra – Mérési környezet.
Az IMS kliens konfigurálásához az első feladatnál a hallgatónak le kell kérdeznie mérőhely IPv4 címét. Második feladatnál az IMS felhasználó nevét és jelszavát, illetve a P-CSCF címét kell megadni. Az IMS felhasználók neve és jelszava test#@open-ims.test és test#, ahol ’#’ a hallgató számára kiosztott szám (#=1..10). A 3.1 fejezetben lévő feladathoz (közvetlen hívás két kliens között az IMS kihagyásával) az X-lite klienst használjuk. X-lite konfigurációja a 3.1 fejezetben leírt feladathoz: Display name: direct# Username: direct# Password: Authorization user name: direct#@valami.hu Domain: valami.hu Register with domain and receive incoming calls: Proxy: hívott fél IP címe UDP port, amin SIP jelzésre figyel a kliens: Topology tab manually specify range: 5060-5061 Voicemail tab check for voicemails: A 3.2 fejezetben lévő feladathoz, amely bevonja az openIMS-t, használjuk a Boghe IMS client nevű alkalmazást. (Az X-lite kliens hívott fél által kezdeményezett hívásmegszakítás esetén hibásan működik. A hiba az, hogy nem küld SIP BYE üzenetet, ezért folytatódik a hívás.) Boghe IMS client konfigurációja a 3.2 fejezetben leírt feladathoz:
Options Identity Display name: test# Public Identity: sip:test#@open-ims.test Private Identity: test#@open-ims.test Password: test# Realm: open-ims.test OptionsNetwork: Proxy-CSCF Host: 192.168.130.3 Proxy-CSCF Port: 4060 Transport: UDP OptionsPresence, OptionsMessaging menüben érdemes kikapcsolni a felsorolt szolgáltatásokat, mivel ezeket nem támogatja az IMS. (X-lite konfigurációja a második feladathoz: Display name: test# Username: test# Password: test# Authorization user name: test#@open-ims.test Domain: open-ims.test Register with domain and receive incoming calls: Proxy: 192.168.130.3:4060 Voicemail tab check for voicemails: Presence tab Mode: disabled)
2.1 Méréshez használt szoftverek 2.1.1 Wireshark A Wireshark egy ingyenes adatcsomagszűrő és elemző alkalmazás. A mérés során felhasznált képességei a csomagszűrés és a statisztikák készítése. A csomagszűrés két szinten történhet: csomagok tárolása szintjén (capture filter), és csomagok megjelenítése szintjén (display filter). Display filter esetén a következő operátorokra lehet szükség a mérés során: Feltételeket „and” és „or” operátorral lehet elválasztani Feltételt „!” jellel lehet negálni Adott protokollra szűrhetünk: pl. sip, rtp, rtcp, udp Adott IP címre szűrhetünk a forrás, cél, vagy mindkét IP fejléc mezőben, azaz, például az ip.src==192.168.130.3 or ip.dst==192.168.130.3 feltétel ekvivalens az ip.addr==192.168.130.3 feltétellel. A display szűrők grafikusan, menüből is állíthatóak, illetve ha egy csomagra klikkelünk jobb egérgombbal, akkor a csomagra vonatkozó szűrőfeltétel képezhető. A statisztikai menüből a Flow graph menüt használjuk, amely a megjelenített (kiszűrt) csomagokat képes üzenetdiagrammon ábrázolni.
2.1.2 X-lite Az eyeBeam egy IMS szoftver kliens, amelynek ingyenes változata az X-lite.. http://www.counterpath.com/x-lite.html
2.1.3 Boghe IMS/RCS client A GSM Association (GSMA) Rich Communication Client (RCS) követelményeinek megfelelő Java alapú IMS kliens, amely az IMS hang és videó hívás mellett támogatja többek között az alábbi funkciókat: Enhanced Address Book (Open Mobile Alliance (OMA) specifikálta) Enhanced Messaging (OMA) Content Sharing (GSMA) File Transfer (OMA) https://code.google.com/p/boghe/
3 Mérési utasítás A mérést a hallgatók párokban végzik. Minden pár üljön le két egymással szomszédos mérési helyhez. Páronként elég egy mérési beszámolót írni!
3.1 Első feladat: hívásfelépítés SIP kliensek között Az első mérés célja megvizsgálni a SIP hívásfelépítés menetét két SIP kliens között, az IMS bevonása nélkül. 1. Építsen fel közvetlen VoIP kapcsolatot két SIP kliens között! 2. Wireshark segítségével hallgassa le a VoIP jelzés és adatforgalmat, és mentse el a lehallgatott üzeneteket (trace-t) egy .cap kiterjesztésű fájlba! 3. Elemezze a látottakat! Wireshark segítségével rajzolja ki a VoIP hívás üzenetfolyam diagramját (jelzés és adatforgalmat egyaránt), és értelmezze az egyes protokollok szerepét! Az üzenetdiagramm kirajzolásához előbb display filterrel szűrje ki a szükséges üzeneteket, és jelenítse meg a Statistics Flow graph menüpont segítségével. Összegezze, hogy milyen IP címeken és portokon halad a SIP, RTP, RTCP forgalom az egyes irányokban? Értelmezze a látottakat! Milyen hangkodekben egyeznek meg a felek, milyen sávszélességet használnak a kodekhez?
3.2 Második feladat: hívásfelépítés két SIP kliens között az IMS hálózat bevonásával A második mérés célja megvizsgálni az IMS-be történő regisztráció, és az IMS-en keresztülmenő VoIP hívásfelépítés menetét. 1. Hallgassa le Wireshark segítségével az alábbi üzenetváltásokat az egyik SIP kliensen. A lehallgatott trace-t mentse el! A SIP kliens beregisztrál IMS szolgáltatásra. A SIP kliens felhívja a másik SIP klienst (amely már korábban beregisztrált az IMS szolgáltatásra), a két fél beszélget, majd az első SIP kliens megszakítja a hívást. A másik SIP kliens felhívja az első SIP klienst, a két fél beszélget, majd a másik SIP kliens megszakítja a hívást. 2. Jelenítse meg Wireshark segítségével a két SIP kliens között zajló, illetve a SIP kliens és az IMS P-CSCF között zajló üzenetváltást! 3. Összegezze, hogy a SIP, RTP, RTCP forgalom irányonként milyen IP címet és portokat használ! Milyen entitásokat érint a kommunikáció? 4. Értelmezze a SIP REGISTER metódust! Milyen felhasználói hitelesítés történt?
5. Milyen különbségeket lát az I. feladatban látott kommunikációhoz képest a kapcsolat-felépítés során (SIP üzenetek összehasonlítása)?
3.3 III. feladat: szorgalmi feladatok 1. Próbáljon meg hívást felépíteni egy beregisztrált és egy nem beregisztrált SIP felhasználó között. Írja le, és értelmezze, hogy mit tapasztalt! 2. Határozza meg, hogy milyen capture filter-rel lehet kiszűrni az IMS-en keresztüli VoIP hívás jelzés- és adatforgalmát? (ld. tcpdump manualja) 3. Wireshark segítségével hallgasson le egy VoIP hívást!
