MOTIware IMS MediaGateway megvalósítása. Új generációs multimédiás szolgáltatások IMS alapokon



Hasonló dokumentumok
INFOKOMMUNIKÁCIÓS SZOLGÁLTATÁSOK ÉS ALKALMAZÁSOK

AGSMHÁLÓZATA TOVÁBBFEJLESZTÉSE A NAGYOBB

IP alapú távközlés. Voice over IP (VoIP)

Kommunikáció. 3. előadás

Internetbank-EFER csatlakozás bemutatása. Bali János, Lomniczi Rudolf

NETinv. Új generációs informatikai és kommunikációs megoldások

Kommunikációs rendszerek programozása. Voice over IP (VoIP)

Építsünk IP telefont!

INFOKOMMUNIKÁCIÓS SZOLGÁLTATÁSOK ÉS ALKALMAZÁSOK

Adatátviteli rendszerek Mobil IP. Dr. habil Wührl Tibor Óbudai Egyetem, KVK Híradástechnika Intézet

Városi tömegközlekedés és utastájékoztatás szoftver támogatása

Számítógépes Hálózatok. 7. gyakorlat

Számítógépes Hálózatok. 5. gyakorlat

Autóipari beágyazott rendszerek. Komponens és rendszer integráció

Bevezető. PoC kit felépítése. NX appliance. SPAN-Proxy

ColourSMS Protokol definíció. Version 1.2

GoWebeye Monitor Release Üzenetküldés

Két típusú összeköttetés PVC Permanent Virtual Circuits Szolgáltató hozza létre Operátor manuálisan hozza létre a végpontok között (PVI,PCI)

Multiprotocol encapsulation (RFC1483) - IETF Classical IP over ATM (RFC1577) - IETF LAN Emulation (LANE) - ATM Forum Multiprotocol over ATM (MPOA) -

3G UMTS, IMS, SIP. Kanizsai Zoltán

Megfelelés a PSD2 szabályozásnak, RTS ajánlásokkal Electra openapi

Programozó- készülék Kezelőkozol RT óra (pl. PC) Digitális bemenetek ROM memória Digitális kimenetek RAM memória Analóg bemenet Analóg kimenet

Szolgáltatási szint megállapodás

- Kurt.exe a windows-os felület, amelyen keresztül a lejátszás konfigurálható.

Új generációs informatikai és kommunikációs megoldások ANMS. távközlési hálózatok informatikai hálózatok kutatás és fejlesztés gazdaságos üzemeltetés

Számítógépes Hálózatok GY 7.hét

Szolgáltatás mérés/riportolás magas fokon Egy valós megoldás Pepsi berkekben

Komplex terheléses tesztmegoldások a Mobil PS és CS gerinchálózaton

Számítógépes Hálózatok GY 6.hét

IP alapú távközlés. Virtuális magánhálózatok (VPN)

2. fejezet Hálózati szoftver

vbar (Vemsoft banki BAR rendszer)

ELEKTRONIKUS DOKUMENTUMTÁROLÁSI SZOLGÁLTATÁS (EDT)

Flash és PHP kommunikáció. Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft

Megoldás. Feladat 1. Statikus teszt Specifikáció felülvizsgálat

SIP. Jelzés a telefóniában. Session Initiation Protocol

Address Resolution Protocol (ARP)

Hálózati architektúrák és rendszerek. Nyilvános kapcsolt mobil hálózatok (celluláris hálózatok) 2. rész

Tájékoztató az 1.10-es labor használatához

4. Hivatkozási modellek

1/13. RL osztály Hálózati alapismeretek I. gyakorlat c. tantárgy Osztályozóvizsga tematika

Webes alkalmazások fejlesztése 1. előadás. Webes alkalmazások és biztonságuk

TRBOnet Térinformatikai terminál és diszpécseri konzol

Grid menedzsment megoldás az ARC köztesrétegben

ivms-4200 kliensszoftver

UNIX: folyamatok kommunikációja

Elektronikus levelek. Az informatikai biztonság alapjai II.

Hálózati operációs rendszerek II. Novell Netware 5.1 Hálózati nyomtatás

A Java EE 5 plattform

G Data MasterAdmin 9 0 _ 09 _ _ # r_ e p a P ch e T 1

Szoftverarchitektúrák 3. előadás (második fele) Fornai Viktor

Web service fenyegetések e- közigazgatási. IT biztonsági tanácsadó

HBONE VoIP szolgáltatás, az elmúlt egy év eredményei

IV.4. FELHŐ ALAPÚ BIZTONSÁGOS ADATTÁROLÁSI MÓDSZER ÉS TESZTKÖRNYEZET KIDOLGOZÁSA

Erőforrás gazdálkodás a bevetésirányításban

Oracle Containers for Java - j2ee alkalmazás szerver funkciók. Molnár Balázs Oracle Hungary

VoIP Megoldások. Készítette: Lipcsei János

Hálózati architektúrák laborgyakorlat

Autóipari beágyazott rendszerek. Local Interconnection Network

KAMIONIRÁNYÍTÓ RENDSZER

Azonnali fizetési rendszer megvalósítása

10. EGYSZERŰ HÁLÓZATOK TERVEZÉSE A FEJLESZTŐLAPON Ennél a tervezésnél egy olyan hardvert hozunk létre, amely a Basys2 fejlesztőlap két bemeneti

Szoftver fő funkciói. Diszpécser rádió GPS nyomkövetés Adatátvitel és tárolás Telefonhívások kezelése 1 / 7

Rubin SMART COUNTER. Műszaki adatlap 1.1. Státusz: Jóváhagyva Készítette: Forrai Attila Jóváhagyta: Parádi Csaba. Rubin Informatikai Zrt.

SSL elemei. Az SSL illeszkedése az internet protokoll-architektúrájába

Everything Over Ethernet

Norway Grants. Az akkumulátor mikromenedzsment szabályozás - BMMR - fejlesztés technológiai és műszaki újdonságai. Kakuk Zoltán, Vision 95 Kft.

A rendszer célja. Funkciók

VoIP biztonság. BME - TMIT Médiabiztonság feher.gabor@tmit.bme.hu

Hálózati rendszerek adminisztrációja JunOS OS alapokon

Diákhitel igénylés folyamata

Rőczei Gábor Szeged, Networkshop

Tisztelt Telepítő! 2. Ellenőrizze, hogy a modul engedélyezve van-e: Szekció [382] Opció 5 (alternatív kommunikátor) BE.

A számítástechnika gyakorlata WIN 2000 I. Szerver, ügyfél Protokoll NT domain, Peer to Peer Internet o WWW oftp opop3, SMTP. Webmail (levelező)

III. Felzárkóztató mérés SZÉCHENYI ISTVÁN EGYETEM GYŐR TÁVKÖZLÉSI TANSZÉK

BEÁGYAZOTT RENDSZEREK TERVEZÉSE UDP csomag küldése és fogadása beágyazott rendszerrel példa

Példa webáruház kialakítás rendszerdokumentáció

Felhő alapú hálózatok Konténerek orkesztrálása Simon Csaba. Budapesti Műszaki és Gazdaságtudományi Egyetem

az MTA SZTAKI elearning osztályának adaptív tartalom megoldása Fazekas László Dr. Simonics István Wagner Balázs

Tananyagok adaptív kiszolgálása különböző platformok felé. Fazekas László Dr. Simonics István Wagner Balázs

III. előadás. Kovács Róbert

Számítógépes hálózatok

3Sz-s Kft. Tisztelt Felhasználó!

1. Soroljon fel 3 jellemző tulajdonságát a beszédkódolóknak! Egyet fejtsen ki bővebben!

Ficsor Lajos Általános Informatikai Tanszék Miskolci Egyetem

Bodó / Csató / Gaskó / Sulyok / Simon október 9. Matematika és Informatika Tanszék Babeş Bolyai Tudományegyetem, Kolozsvár

InCa NMS jelen és jövő HFC Technics szakmai napok


Magyar Nemzeti Bank - Elektronikus Rendszer Hitelesített Adatok Fogadásához ERA. Elektronikus aláírás - felhasználói dokumentáció

10: Peer-To-Peer Hálózatok I. HálózatokII, 2007

Újdonságok Nexus Platformon

Prolan Zrt. fejlesztéseiben. Petri Dániel

Hálózati réteg. WSN topológia. Útvonalválasztás.

Az alábbi állítások közül melyek a forgalomirányító feladatai és előnyei?

Felhasználói kézikönyv

Az IEC PRP & HSR protokollok használata IEC61850 kommunikációjú védelmi automatika hálózatokban

Linux kiszolgáló felügyelet: SUSE Manager

RIEL Elektronikai Kft v1.0

ALKALMAZÁS KERETRENDSZER

Osztott Objektumarchitektúrák

Átírás:

MOTIware IMS MediaGateway megvalósítása Új generációs multimédiás szolgáltatások IMS alapokon

Tartalom Media Gateway a MOTIware IMSben... 3 Media Resource Function (MRF)... 3 Media Gateway... 3 Technikai megvalósítási javaslat a Motiware szolgáltatás MRF moduljára... 5 Adatstruktúrák... 10

Media Gateway a MOTIware IMSben A MOTIware, az ITware mobiletelevíziós megoldása 2012 elejére egészült ki az IMS integráció lehetőségével. Az integráció technikai részletei leginkább az MOTIware architektúra ismeretében bírnak jelentőséggel, viszont a médiaszolgáltatást nyújtó Media Gateway komponens más IMS rendszerekben önállóan is helyt állhat. Az itt következő leírás ennek a részletes specifikációja. Media Resource Function (MRF) Az IMS szabvány a szolgáltatások nyújtásához definiál bizonyos alap funkciókat, amiket implementálva egységes felületet lehet biztosítani az alkalmazás szeverek felé. Ilyen funkció-halmaz a médiakezelést megvalósító MRF, ami a különböző média tartalmak keverését, a médiaformátumok közötti átkódolást és a médiafolyamok statisztikáinak összegyűjtését végzi. Az implementálásához két alegységet kell megvalósítani: MRFC (Media Resource Function Control): a médiafolyamok vezérlését végzi, SIP végpontként működik (SIP segítségével kommunikál az S-CSCF-ekkel) MRFP (Media Resource Function Processor): a médiafolyamon végzett műveletekért és annak kiszolgálásáért felelős alegység Media Gateway A Media Gateway szerepe a rendszerben egy médiaforrás implementálása, ami az IMS hálózatában MRF (Media Redource Function) feladatokat lát el. Megvalósítja a SIP User Agent-ként működő MRFC vezérlési modult, valamint a media átkódolását és kiszolgálását végző MRFP-t. Mivel a teszt-ims rendszer jelenleg video kiszolgálására alkalmas média szerverrel nem rendelkezik, ennek szimulálása is a feladat részét képezi. A Media Gateway-nek valamilyen analóg vagy digitális forrásból érkező jelet kell tudnia kiszolgálnia a SIP jelzésprotokollon és RTP transzporton keresztül, egy, a Wowza Média Szerver által is értelmezhető médiakódolás segítségével. A kiszolgálás megvalósításához a Media Gateway-nek szabványos SIP kliensként kell működnie, mely a hozzá érkező hívásokat megválaszolja, és a képességek egyeztetése után a hozzá SDP-ben továbbított csatorna információk alapján a megfelelő médiafolyam kapcsolatot felépíti.

A tervezett implementációban a Motiware szolgáltatás által biztosított csatornák a Media GW bemeneti forrását képezik. A csatornákon belül igényelhető különböző minőségű és felbontású médiafolyamok definíciója konfigurációs fájlban adható meg: minden egyes médiafolyamhoz külön portot kell foglalni a média szerver hálózati interfészén. A beérkező médiakéréseket ezen bemeneti folyamok tetszőleges számban előállított továbbításával szolgálja ki. A Media GW a kiszolgálás során átkódolást már nem végez, a Wowza szerver által értelmezhető videojel előállítása a média útvonalának egy korábbi szakaszán történik. A média továbbításához a Media GW a SIP kapcsolatoknál alkalmazott RTP csomagformátumot használja. A továbbítás során az adott porton beérkező médiafolyamot 160 bájtos csomagokra darabolva, RTP fejléccel ellátva az adott csatornához nyilvántartott összes kliens végpontnak elküldi. Ezek a végpontok a Motiware GW-en futó SIP kliensekhez tartozó médiavégpontok, melyek a Wowza szerver bemeneteként vannak konfigurálva. A Media GW a végpontokra vonatkozó adatokat a médiakérés INVITE üzenetében lévő SDP leíróban kapja. A média gateway RTP-továbbítást végző modulját, bár átkódolást nem végez, a szolgáltatást igénybe vevő felhasználók és a számukra biztosított csatornák számának függvényében véges kapacitású erőforrásként kell kezelni. A tervezés szempontjából ez azt jelenti, hogy skálázhatónak és fizikai szinten modularizálhatónak, elosztottnak kell lennie a médiakiszolgálásnak. A média GW-en belül az MRFC funkciót ellátó SIP kliens nem végez erőforrás-igényes feladatokat, így a skálázhatósági igények csak az MRFP modulnál jelentkeznek. A média GW architektiurális felépítése ennek megfelelően a következőképpen alakul: MRFC: egy példányban futó SIP kliens, ami a médiakiszolgálás vezérlését végzi MRFP: tetszőleges számú RTP továbbító almodulból álló felhő, amely konfigurációs szinten bővíthető újabb elemekkel A fenti architektúra a modulok logikai felosztását írja le, fizikai szinten lehetőség van arra is, hogy egy hardveren fusson a teljes media GW. Az MRFP és MRFC elemek között a médiavezérlési funkciók biztosításához szükség protokoll megvalósítása a Kommunikációs protokollok fejezet MRFC- MRFP kapcsolat protokoll -ban leírtaknak megfelelően történik. az RTP továbbító modul beregisztrál a vezérlő modulba a vezérlő modul egy adott porton lévő csatorna adott célcímre történő kijátszására utasítja az RTP továbbító modult a vezérlő modul egy adott célcímre történő csatorna kijátszásának a leállítására utasítja az RTP továbbító modult

Technikai megvalósítási javaslat a Motiware szolgáltatás MRF moduljára MRFC Az MRFC funkciót megvalósító modul egy IMS-ben regisztrált SIP végpont (SIP UAC, SIP User Agent Client), amely a médiakéréseket fogadja, feldolgozza és menedzseli a felépült média-folyamokat. Hitelesítési és authorizációs feladatokat nem kell ellátnia, mert ezeket az IMS hálózati elemei illetve a Motiware AS végzik. Ha egy médiakérés beérkezik az MRFC-hez, akkor a kiszolgálásának már csak technikai jellegű akadályai lehetnek (pl. nem áll rendelkezésre a megfelelő srteam), az adminisztratív szűréseknek már megfelelt az igény. A konkrét média-folyamatokat nem az MRFC végzi, de hozzá tartozik az összes menedzsment és vezérlési feladat. Ezek a feladatok az alábbiak: az MRFP modulok és a hozzájuk tartozó csatornák nyilvántartása a SIP kommunikáció, médiakérés kezelése az aktív médiafolyamok nyilvántartása, a SIP session-höz való kapcsolása MRFP-menedzsment A rendszertervben az MRFP modulok skálázhatósági és erőforrás-menedzsmenti szempontokat figyelembe véve önálló egységenként vannak definiálva. Az MRFC-nek képesnek kell lennie kezelnie az MRFP-halmaz változásait, új modulok bekötését és meglévők eltávolítását. Ennek érdekében az MRFC és MRFP modulok egyfajta kliens-szerver architektúrában kapcsolódnak egymáshoz. Az MRFP bejelentkezik az MRFC-hez, és jelzi, hogy mely csatornákat lehet rajta keresztül elérni. Az MRFC a megfelelő adatszerkezetben nyilvántartja a bejelentkezett MRFP-ket, illetve egy listát a streamelhető csatornákról és azok elérhetőségéről. Ha egy csatorna több MRFP-nél is elérhető, akkor az MRFC egy (a jelen dokumentációban nem definiált) algoritmus alapján kiválasztja az optimális modult (például az alapján, hogy melyiken van adott időpillanatban kevesebb aktív stream-elés). Ha egy MRFP modul kijelentkezik az MRFC-től, akkor a hozzá tartozó csatornákkal együtt törlődik a megfelelő listákból. SIP kommunikáció Az MRFC modul az IMS-nek egy érvényes SIP URI-val rendelkező eleme. A SIP azonosítója az IMS felhasználói számára elérhető, címezhető, így képes SIP session-ök felépítésére. A végpont minden esetben fogadó oldalként vesz részt egy kapcsolat felépítésében. A kapcsolatot kizárólag INVITE tranzakcióval lehet kezdeményezni. Az igényelt csatornára vonatkozó adatokat az INVITE üzenet tartalmaként elküldött SDP leíró tartalmazza: a fogadó oldal IP címe ( C mező) a fogadó oldalon használt port ( O és M mezők)

a csatorna azonosítója, ami tartalmazza a nevét és a kívánt minőséget ( I mező) (Megjegyzés: az esetleges kereskedelmi forgalomban kapható média szerver megoldásokban felhasználási szinten nem biztos, hogy hozzá lehet férni az SDP mezőhöz. Mivel az I mező használata nem kötelező, csak kiegészítő információkat tartalmaz a médiakapcsolatról, nagy valószínűséggel egy kész média szervert használva az egyes csatornákhoz külön-külön SIP azonosítót kellene rendelni, ami az IMS menedzsment folyamatai miatt megnehezítheti új csatornák hozzáadását illetve meglévők megszűntetését.) A médiakapcsolat sikeres felépítése után a bontást normál működés esetén a kliens kezdeményezi. Ebben az esetben az MRFC fogadja a BYE üzenetet, majd felszabadítja az erőforrásokat. A lejátszás megszakadását az MRFP is jelezheti, ilyenkor az MRFC-nek kell kiküldeni a BYE üzenetet a kliensnek. Médiakapcsolatok menedzselése A beérkező médiakéréshez az MRFC kiválasztja a megfelelő MRFP-t, és a kommunikációs csatornán jelzi az MRFP-nek, hogy melyik csatornát milyen IP/port végpontra kell stream-elni. Az aktív médiafolyamokhoz nyilvántart egy adatstruktúrát, amelyben eltárolja, hogy melyik SIP session-höz melyik MRFP, melyik csatornája van hozzárendelve, annak mi az egyedi azonosítója, illetve az aktuális állapota. Ezen adatok alapján bármelyik irányból érkező eseményt le tudja kezelni és jelezni a másik végpont felé. A megfelelő azonosíthatósághoz a tárolt adatok mindegyikéhez egyedi azonosítóra van szükség: SIP CallID, MRFP azonosító, csatorna azonosító, stream azonosító (ezt az MRFP generálja). MRFP A rendszer tetszőleges számú, egymástól független MRFP modult tartalmazhat. Ezek feladata a médiaforrástól kapott bemeneti RTP folyam igény szerinti végpontokra történő továbbítása, többszörözése. A bemeneti médiafolyamok konfigurációs szinten állíthatóak, dinamikusan nem változtathatók. A modul bejelentkezik az MRFC-hez a saját azonosítójával és elküldi azon csatornák listáját, melyeket bemenetként kap. Az MRFP ezután vár, hogy az MRFC-től utasítást kapjon a stream-elésre. Az üzenetben megkapja, hogy melyik csatornát milyen IP/port végpontra kell továbbítani valamint a stream azonosítóját, amivel a későbbiekben lehet rá hivatkozni. A továbbításhoz az MRFP-nek nyilván kell tartania egy listát, hogy az adott bemenő folyamot milyen végpontokra kell küldeni. Stream-elés indításakor a modul belerakja a listába az új címet. Az MRFC felé nyugtázni kell a stream-elés megkezdésének sikerességét, hogy negatív válasz esetén másik MRFP-t tudjon keresni a médiakéréshez. Maga a továbbítás úgy történik, hogy az UDP socket-ről leveszi az RTP csomagot, majd a csatornához tartozó összes célcímre kiküldi azt. A stream-elést befejezni a célcím listából való törlésével lehet. Ha a steam-elés az MRFP oldalon megszakad, akkor ezt jelezni kell az MRFC-nek, hogy a vezérlési síkon is le lehessen zárni a kapcsolatot.

Az MRFC-MRFP kommunikáció Az IMS szabvány nem tartalmaz megkötést az MRF implementációkban megvalósított kommunikációs protokollra. Ajánlásként a H.248 valamint a SIP protokollt említi, ezek azonban a jelen rendszer céljaihoz részben nem alkalmasak részben túl komplexnek tűnnek. Ezért a saját MRF megoldásban (ami a transzkódolás és egyéb médiafunkciók hiányában az MRF funkcióknak csak egy részét tartalmazza) egy saját, egyszerű, szöveges vezérlési protokollt javaslunk, ami testre szabottan biztosítja a szükséges funkciókat. Üzenetek MRFP kapcsolódás: Médiakezelés:

Üzenet-szekvenciák MOTIware IMS MediaGateway

Adatstruktúrák MRFC: MRFP: