pretoČni video v okolju moilne telefonijesistem pretočnega videa v okolju mobilne telefonije....

UNIVERZA V MARIBORU

FAKULTETA ZA ELEKTROTEHNIKO,

RAČUNALNIŠTVO IN INFORMATIKO

Kristjan Kostrevc

PRETOČNI VIDEO V OKOLJU MOBILNE TELEFONIJE

Projektna naloga

Maribor, september 2017

I

PRETOČNI VIDEO V OKOLJU MOBILNE TELEFONIJE

Projektna naloga

Študent: Kristjan Kostrevc

Študijski program: Univerzitetni študijski program 1. stopnje

Telekomunikacije

Mentor: Red. prof. dr. Zdravko Kačič, univ. dipl. inž. el.

Somentor: Asistent Danilo Zimšek, univ. dipl. inž. tel.

II

ZAHVALA

Zahvaljujem se mentorju in somentorju za vso pomoč pri izdelavi projektne naloge. Zahvaljujem se tudi družini za vso podporo v času študija.

III

Pretočni video v okolju mobilne telefonije

Ključne besede: pretočni video, IMS, digitalna ločnica, mobilna aplikacija, IPTV

UDK:

Povzetek

Namen projektne naloge je razviti storitev, ki bo zmanjšala digitalno ločnico tako, da bo

poenostavila uporabo tehnologije pretočnega videa. V projektni nalogi so opisane osnovne

tehnologije za prenos podatkov med dvema stranema in tehnologije za prenos video vsebin.

Nato je določena zasnova sistema prenosa video vsebin, ki ji sledijo gradniki sistema

uporabljeni pri zasnovi. V zaključnem delu je opisana še implementacija sistema z android

aplikacijo in pretakanjem videa na IPTV.

IV

Streaming video in a mobile phone environment

Key words: streaming video, IMS, digital divide, mobile application, IPTV

UDK:

Abstract

The purpose of the project work is to develop a service that will reduce the digital divide by simplifying the use of streaming video technology. The project work describes the basic technologies for data transfer between two ends and the technology for the transmission of video content. Next, the design of the video content transmission system is determined, followed by the building blocks of the system, used in the design. In the final part, the implementation of the system with android application and streaming video to IPTV is described.

V

KAZALO

1 UVOD ................................................................................................... 1

2 SPLOŠEN OPIS TEHNOLOGIJ ................................................................. 2

2.1 Internetni multimedijski podsistem (IMS) ........................................................... 2

2.2 Protokol za vzpostavitev seje (SIP) ...................................................................... 3

2.3 Protokol za opis seje (SDP) ................................................................................. 3

3 OPIS TEHNOLOGIJE PRENOSA VIDEO VSEBIN ....................................... 4

3.1 Protokol za prenos v realnem času (RTP) ............................................................ 4

3.2 Realno-časovni strujani protokol (RTSP) ............................................................. 4

4 ZASNOVA SISTEMA PRENOSA VIDEO VSEBIN ....................................... 5

4.1 Scenariji uporabe ............................................................................................... 5

5 GRADNIKI SISTEMA ............................................................................. 10

5.1 Programska knjižnica ZeroMQ .......................................................................... 10

5.1.1 Vzorec objava/naročilo .................................................................................. 11

5.1.2 Vzorec zahteva/odgovor................................................................................ 12

5.2 Multimedijska komunikacijska knjižnica pjsip ................................................... 14

5.3 Medijski predvajalnik Kodi ............................................................................... 16

5.4 Aplikacijski strežnik .......................................................................................... 16

5.5 Začetni kriterij filtriranja (iFC) ........................................................................... 17

VI

6 IZVEDBA MOBILNE APLIKACIJE VIDEO TOKA ....................................... 18

6.1 Namestitev razvojnega okolja .......................................................................... 18

6.2 Nastavitev začetnega kriterija filtriranja (iFC) ................................................... 20

6.3 Komunikacija med pošiljateljem in strežnikom ................................................. 21

6.4 Opis delovanja Android aplikacije ..................................................................... 22

7 SKLEP .................................................................................................. 24

UPORABLJENI VIRI IN LITERATURA ............................................................ 25

VII

KAZALO SLIK

SLIKA 4.1: POTEK KOMUNIKACIJE PRI PRENOSU VIDEO SIGNALA ............................................................ 7

SLIKA 4.2:GRAF GRADNIKOV SISTEMA S POTEKOM KOMUNIKACIJE PRI PRENOSU VIDEO SIGNALA ................. 9

SLIKA 5.1: GRADNIKI SISTEMA ..................................................................................................... 10

SLIKA 5.2: UPORABA VZORCA OBJAVA/NAROČILO ZEROMQ ............................................................. 12

SLIKA 5.3: UPORABA VZORCA ZAHTEVA/ODGOVOR ZEROMQ ........................................................... 13

SLIKA 5.4: ARHITEKTURA MEDIJSKE KNJIŽNICE PJSIP ......................................................................... 14

SLIKA 6.1: ZASLONSKI SLIKI APLIKACIJE .......................................................................................... 23

KAZALO TABEL

TABELA 6.1: KORAKI NAMESTITVE USTREZNE PROGRAMSKE OPREME ................................................... 18

TABELA 6.2: NASTAVITEV ZAČETNEGA KRITERIJA FILTRIRANJA ............................................................ 21

1

1 UVOD

Zaradi hitrega razvoja tehnologije digitalnih komunikacij, starejše generacije ne morejo več

slediti tehnološkemu napredku in tako govorimo o digitalni ločnici. Digitalna ločnica ali

digitalni razkorak ponazarja razliko v dostopnosti in znanju uporabe tehnologij med

različnimi generacijami uporabnikov. Namen tega projekta je definirati storitev, s katero bi

prispevati k zmanjšanju digitalne ločnice za uporabnike, ki so trenutno nevešči uporabe

določenih tehnologij oz. aplikacij. Ta storitev bo s pomočjo mobilne aplikacije skrbela za

realno časovni pretok videa. Tehnologijo bomo tem uporabnikom približali tako, da se bo

video pretakal na IPTV, saj menimo, da uporabniki, ki niso vešči rokovanja s pametnimi

telefoni obvladajo rokovanje z IPTV oz. televizorji, ki so že desetletja prisotni v svetu in so

množično uporabljani skozi več generacij uporabnikov.

Za dosego cilja bomo teoretično raziskali osnovne tehnologije, ki omogočajo komunikacijo

in pretakanje podatkov med dvema stranema, nato bomo raziskali tehnologije prenosa

video vsebin. Iz vseh znanih informacij bomo nato zasnovali sistem prenosa video vsebin,

ki bo primeren za implementacijo storitve realno časovne video razglednice. Pri zasnovi

bodo uporabljeni gradniki sistema, ki bodo prav tako opisani. V zaključni fazi bo sledila še

implementacija sistema z android aplikacijo in pretakanjem videa na IPTV.

2

2 SPLOŠEN OPIS TEHNOLOGIJ

Poglavje opisuje osnovne tehnologije na katerih temelji storitev realno časovne video

razglednice. Te so Internetni multimedijski podsistem (IMS), protokol za vzpostavitev seje

(SIP) in protokol za opis seje (SDP). V nadaljevanju opisane tehnologije predstavljajo osnovo

pri načrtovanju komunikacijskega sistema.

2.1 Internetni multimedijski podsistem (IMS)

Internetni multimedijski podsistem (ang. IP Multimedia Subsystem oz. IP Multimedia Core

Network Subsystem), kratko IMS je arhitektura, ki skrbi za prenos multimedijskih storitev

preko protokola IP. Je ena izmed arhitekturnih platform omrežij novih generacij (ang. Next

Generation Network), kratko NGN in oblikuje strategijo prihodnosti, kjer bodo številni

operaterji ponujali svoje storitve preko IP tehnologij. Je alternativa klasični (PSTN/ISDN)

telefoniji in ponuja standardizacijo multimedijskih storitev, ki se prenašajo preko protokola

IP. Ena od prednosti te tehnologije je konvergenca naprav in dostopovnih tehnologij. S tem

omogočimo delovanje storitve tako na mobilnih telefonih, kot na IP televizorjih in tudi

ustrezno opremljenih fiksnih telefonih.

Pomembno vlogo kot gradnik IMS ima tudi funkcija krmiljenja klicne seje (ang. Call Session

Control Function), kratko CSCF. CSCF je namreč odgovoren za nadzor signalizacije

komunikacije med omrežjem IMS in uporabniško opremo (ang. User Equipment UE).

Kontrolira začetek seje, njen konec, avtentifikacijo uporabnika, varnost omrežja in kvaliteto

storitve (QoS). Imamo štiri tipe CSCF glede na funkcionalnosti, ki jih ponujajo. Ti tipi so: P-

CSCF (Proxy-CSCF), I-CSCF (Interrogating-CSCF), S-CSCF (Serving-CSCF) in E-CSCF

(Emergency-CSCF).

3

2.2 Protokol za vzpostavitev seje (SIP)

Protokol za vzpostavitev seje (Session Initiation Protocol (SIP)) je komunikacijski tekstovni

protokol v IMS, ki skrbi za signalizacijo in komunikacijo med oddajno in sprejemno stranjo.

Kot tak vzpostavlja, ureja in končuje seje. Nahaja pa se v aplikacijskem sloju v referenčnega

protokolnega sklada ISO/OSI.

2.3 Protokol za opis seje (SDP)

Protokol za opis seje (Session Description Protocol (SDP)) deluje znotraj SIP protokola. Za

razliko od SIP-a, ki skrbi za signalizacijo in komunikacijo v sejah, SDP skrbi za medijske

vsebine v teh sejah. Za medijske vsebine skrbi na tak način, da z določenimi parametri opiše

vsebino. Tako ti parametri vsebujejo različne podatke kot so naslov izvora in ponora

medijske vsebine, parameter, ki pove, če medij vsebuje avdio in video zapis, pomemben je

tudi parameter, ki pove, kako je zakodirana medijska vsebina. Vsi ti parametri so

pomembni, da na naslovni strani lahko uspešno prejmemo medijsko vsebino.

4

3 OPIS TEHNOLOGIJE PRENOSA VIDEO VSEBIN

V tem poglavju bomo opisali tehnologije, ki jih bomo uporabili za prenos video vsebin.

Izrednega pomena je, da vse te tehnologije spoznamo saj jih bomo združili v neko celoto in

tako morali poskrbeti, da bodo med seboj pravilno delovale, saj bo le tako lahko pravilno

deloval tudi celotni sistem. Tako bomo pri zasnovi storitve za potrebe realno časnega

prenosa video vsebin uporabili protokol RTP, za možnost kasnejšega ogleda videa pa

protokol RTSP.

3.1 Protokol za prenos v realnem času (RTP)

Protokol za prenos v realnem času (Real-time Transport Protocol (RTP)) je omrežni

protokol, ki je namenjen prenašanju avdio in video vsebin preko IP omrežij. Večinoma se

uporablja pri komunikaciji sistemov, ki prenašajo medijske vsebine. Spada pod aplikacijski

sloj protokolnega sklada ISO/OSI.

3.2 Realno-časovni strujani protokol (RTSP)

Realno-časovni strujani protokol (Real-Time Streaming Protocol (RTSP)) je omrežni protokol

v aplikacijskem sloju. Uporabljamo ga za kontrolo medijskih strežnikov za pretakanje videa,

torej, da vzpostavi in kontrolira seje med dvema koncema. Klienti medijskih strežnikov

izdajajo ukaze za predvajanje, snemanje in ustavljanje, s čimer olajša kontrolo realno-

časovnega pretakanja medijskih vsebin.

5

4 ZASNOVA SISTEMA PRENOSA VIDEO VSEBIN

Poglavje opisuje kako smo s tehnologijami, ki smo jih opisali v prejšnjih poglavjih, zasnovali

sistem pretočnega videa v okolju mobilne telefonije. Najprej smo preučili vse možne

scenarije uporabe storitve in na podlagi le-teh ustvarili dva grafa, ki prikazujeta

komunikacijo v sistemu ter ju opisali. Sistem pretočnega videa v okolju mobilne telefonije

v osnovi omogoča prenos video signala, zajetega s kamero mobilnega telefona, na IP

televizor v realnem času.

4.1 Scenariji uporabe

Uporabnik aplikacije se bo med uporabo storitve srečal z različnimi scenariji uporabe.

• IPTV na prejemnikovi strani je izključen ali je v stanju hibernacije:

V primeru, da je IPTV na prejemnikovi strani izključen, bo imel pošiljatelj oz. uporabnik

aplikacije možnost, da vseeno začne s pretokom videa ali pa, da videa ne pretaka. V

primeru, da se bo odločil za pretok videa, se bo ta shranil in prejemniku bo ob vklopu

ponujena možnost, da uporabnik video naknadno pogleda ali pa, da ga zavrže. Če se bo

odločil za ogled, se bo video predvajal, v nasprotnem primeru pa se bo shranjen video

izbrisal.

• IPTV na prejemnikovi strani je vključen:

Če je IPTV na prejemnikovi strani vključen, bo prejemnik najprej dobil obvestilo, da mu

pošiljatelj želi posredovati video v živo. Ob tem bo imel možnost izbire, da video gleda takoj,

da ga shrani in ga pogleda kasneje, ali da videa ne želi pogledati in ga zavrže. Pošiljatelj bo

nato dobil obvestilo o prejemnikovi odločitvi. V primeru, da želi video shraniti se bo

pošiljatelj odločil ali želi nadaljevati s pretokom videa ali ne. Za slednje se bo odločil v

primeru, da shranjen video ob kasnejšem ogledu ne bo več aktualen ali zaradi kakega

drugega razloga. Prav tako bo prejemnik v vsakem trenutku imel možnost, da preneha z

gledanjem videa. V tem primeru bo spet dobil možnost izbire, da se celoten video shrani za

6

kasnejši ogled. Pošiljatelj bo prejel obvestilo o prejemnikovem prenehanju gledanja videa.

V primeru, da bo prejemnik želel shraniti video za kasnejši ogled se bo pošiljatelj lahko

odločil ali želi nadaljevati s pretakanjem videa ali ne.

7

Slika 4.1: Potek komunikacije pri prenosu video signala

Iz predvidenih scenarijev uporabe smo izdelali graf (slika 4.1), ki prikazuje komunikacijo v

sistemu med klientom mobilne naprave, IMS-om, aplikacijskim strežnikom ter IPTV-jem.

Najprej klient mobilne naprave pošlje povabilo oz. INVITE na katerega dobi odgovor »100

Trying« kar pomeni, da se zahteva izvaja in, da bo treba počakati na odgovor. To povabilo

pride vse do končnega uporabnika na IPTV-ju, kar v praksi pomeni, da ta dobi obvestilo, da

mu pošiljatelj želi pretakati video klic v živo. Od tu naprej pa sta mogoča dva scenarija. 1.

da naslovnik sprejme povabilo, kar pomeni, da IPTV pošlje signal 180 Ringing do

aplikacijskega strežnika, od tam pa dobi odgovor 200 OK. Ko pride do tega se sproži signal

RTP Media in začne se pretakanje videa od klienta mobilne naprave do IPTV-ja.

2. možnost pa je, da naslovnik zavrne pretok videa. V tem primeru gre od IPTV-ja do

aplikacijskega strežnika signal Cancel + Message, ki pomeni, da je uporabnik zavrnil

ponudbo za pretok videa, v sporočilu pa je zapisano ali želi, da se video vseeno shrani na

8

aplikacijski strežnik in se kasneje pretaka ali, da tudi kasneje ne želi gledati videa.

Aplikacijski strežnik na to odgovori s signalom Message, ki je ponudba sprejemniku, da

kasneje predvaja shranjen video. V primeru, da sprejemnik želi shraniti video za kasneje, se

vseeno sproži signal RTP Media, le, da tokrat potekla pretakanje videa le do aplikacijskega

strežnika kjer se vsebina shrani za kasnejše pretakanje do IPTV-ja, ko bo to želel naslovnik.

Po zaključku katerega koli od teh scenarijev oz. tudi v primeru, da naslovnik zavrne takojšnje

predvajanje videa in shranjevanje videa se komunikacija nadaljuje s tem, da aplikacijski

strežnik do klienta mobilne naprave pošlje signal 180 Ringing in dobi za odgovor 200 OK.

Klient mobilne naprave odgovori s ACK signalom, kar pomeni, da je bil odgovor na začetni

INVITE oz. povabilo sprejet. IPTV prejme signal ACK in odgovori s signalom BYE, ki ga pošlje

v smeri IPTV ter s tem zaključi direktno komunikacijo s klientom mobilne naprave, seveda

pa dobi tudi potrditev, da je bil signal BYE sprejet v obliki signala 200 OK. Ko je direktna

komunikacija med klientom mobilne naprave in IPTV zaključena, lahko pride še do

komunikacije med aplikacijskim strežnikom in IPTV. Ko se namreč naslovnik odloči, da si želi

ogledati shranjen video signala RTP Media in RTSP poskrbita, da se video iz aplikacijskega

strežnika predvaja na IPTV.

Celotna arhitektura sistema z vsemi signali je tudi na spodnji sliki 4.2.

9

Slika 4.2:Graf gradnikov sistema s potekom komunikacije pri prenosu video signala

10

5 GRADNIKI SISTEMA

Poglavje opisuje gradnike sistema in tehnologije, ki smo jih uporabili za njegovo gradnjo.

Sistem sestoji iz omrežja IMS, klienta na mobilni napravi, klienta za televizor in

aplikacijskega strežnika. V nadaljevanju so opisani posamezni gradniki in koncepti

uporabljeni pri implementaciji gradnikov. Protokol ZeroMQ uporabimo pri implementaciji

klienta za televizor in ima različne vzorce delovanja. Sledi pjsip, ki je pri izvedbi projekta

pomembna tehnologija in ga uporabljamo za signalizacijo in upravljanje pretoka medijskih

vsebin med klientoma, omrežjem IMS in aplikacijskim strežnikom. Kodi je medijski

predvajalnik, ki ga uporabimo kot osnova za klient, ki deluje na televizorju. Uporabljamo še

začetni kriterij filtriranja, ki zahteve s strani klientov, ki izpolnjujejo pogoje in zadevajo

storitev posreduje do aplikacijskega strežnika. Celoten sistem vidimo na spodnji sliki 5.1.

Slika 5.1: Gradniki sistema

5.1 Programska knjižnica ZeroMQ

Programska knjižnica ZeroMQ, ki je lahko imenovana tudi ØMQ, 0MQ ali ZMQ, je

programska knjižnica namenjena pošiljanju sporočil. Omogoča izdelavo kompleksnega in

visoko zmogljivega komunikacijskega sistema. ZeroMQ je v ravnovesju med tehnologijami

11

nizkega nivoja kot so Berkeley vtičnice in visokonivojskimi profesionalnimi tehnologijami za

sporočanje. Ponuja namreč fleksibilnost in izvedbo nizkonivojskih sistemov, ter

enostavnost izvajanja visokonivojskih tehnologij. Njegove glavne prednosti so zanesljiva

izvedba, preprostost in prilagodljivost.

Tok poslanih sporočil je odvisen od izbranega vzorca, med katerimi so naslednji štirje:

• vzorec objava/naročilo: uporabljen za distribucijo podatkov od enega procesa

(publisher) do več prejemnikov (subscribers)

• vzorec zahteva/odgovor: uporabljen za pošiljanje zahteve in prejetje odgovora na

vsako poslano prošnjo

• vzorec cevovod: uporabljen za distribucijo podatkov do izbranih vozlišč

• vzorec izključni par: uporabljen za povezavo dveh vrstnikov med seboj

5.1.1 Vzorec objava/naročilo

Vzorec ZeroMQ, ki uporablja vtičnice »publish« in »subscribe« uporabimo, ko želimo

objaviti tok podatkov in omogočimo poljubnemu številu klientov, da uporabljajo oziroma

pridobivajo ta tok podatkov (slika 5.2).

12

Najprej ustvarimo založnika, ki nato objavlja vsebino. Sporočila od založnika niso poslana

neposredno naročniku ampak so sporočila objavljena. Naročnik se nato naroči na vsebino

in prejema sporočila. Založnik objavi vsebino in ne ve, če je nanjo sploh naročen kateri

naročnik. Komunikacija pri vzorcu objava/naročilo je asinhrona, založnik in naročnik sta

neodvisna en od drugega. Če založnik nekaj objavi in se naročnik šele nato prijavi na

vsebino, vsebine za nazaj ne bo dobil. Prav tako se naročnik lahko poveže na več kot enega

založnika z uporabo enega klica »poveži« za vse povezave.

5.1.2 Vzorec zahteva/odgovor

Vzorec zahteva/odgovor je najbolj osnoven in vzorec. Njegovo uporabo vidimo na sliki 5.3.

Sestavljen je iz dveh vtičnikov, prvi REQ tip vtičnika deluje kot klient in pošilja zahteve in

nato prejema odgovore. Drugi tip vtičnika je REP, ki prejema zahteve in pošilja odgovore.

Slika 5.2: Uporaba vzorca objava/naročilo ZeroMQ

13

Na spodnji sliki vidimo primer, ko klient kot zahtevo pošlje »Hello«, strežnik pa na to

odgovori z »World«.

Slika 5.3: Uporaba vzorca zahteva/odgovor ZeroMQ

Kot prikazuje slika (slika 5.1) se ZeroMQ uporabi pri implementaciji klienta na televizorju.

Medijski predvajalnik Kodi podpira razvoj vtinikov preko katerih dodajamo funkcionalnosti

v programskem jeziku Python. Knjižnica pjsip pa ima podporo za video samo v

implementaciji v jeziku C++. Za medsebojno komunikacijo med grafičnim delom klienta, ki

je implementiran v programskem jeziku Python in komunikacijskim delom v jeziku C++ se

uporabi protokol ZeroMQ.

14

5.2 Multimedijska komunikacijska knjižnica pjsip

Slika 5.4: Arhitektura medijske knjižnice pjsip

V sistemu potekata signalizacija in prenos videa. Medijska knjižnica pjsip (slika 5.4)

implementira tako vso signalizacijo, kot tudi protokole za prenos vsebin. Pjsip je napisan v

jeziku C in implementira protokole, kot so: SIP, SDP, RTP, STUN, TURN, in ICE. Osnovne

komponente in funkcionalnosti, ki jih nudi knjižnica pjsip, so podpora prehajanju NAT, pjsua

za c++, podpora ipv6, pjmedia, SDL in za FFmpeg.

Omogočanje sejnega prehoda NAT (STUN) - prehod NAT s pomočjo posrednikov (TURN) in

vzpostavitvijo medsebojne povezave (ICE) so tehnologije za prehajanje NAT (prevajanje

omrežnih naslovov oz. angleško Network Address Translate). Protokol STUN (ang. Session

Traversal Utilities for NAT) je protokol, ki služi kot orodje drugim protokolom pri prehajanju

NAT. Lahko ga uporabimo kot končno točko za določitev IP naslova in vrat. Razširitev TURN

(ang. Traversal Using Relays around NAT) je razširitev STUN in protokol za pomoč pri

prehajanju NAT, za kar uporablja releje. ICE (ang. Interactive Connectivity Establishment)

in je protokol, ki uporablja STUN in njegovo razširitev TURN. Protokol ICE je uporaben pri

vseh protokolih, ki uporabljajo model ponudba/odgovor, kot npr. SIP. Ti protokoli namreč

težko delujejo skozi NAT. ICE izmenja množico IP naslovov in vrat za vsak medijski pretok.

Opisani protokoli so nujni pri implementaciji v omrežjih s protokolom IP verzije 4, saj se pri

15

teh uporablja NAT. PJSIP ponuja tudi podporo za IP verzije 6, kjer teh funkcionalnosti ni

potrebno vključevati.

Knjižnica pjsip tako podpira komunikacijo preko ipv6. V želji, da aplikacija podpira UDP

transport ipv4 in ipv6 morata biti ustvarjena dva ločena transporta po protokolu UDP, po

en za vsako verzijo internetnega protokola.

Za razvoj aplikacijskih strežnikov je primerna knjižnica pjsip za programski jezik C, ki je nizko

nivojska. Ima podporo za pjmedia in FFmpeg. Pjmedia upravlja z avdiom in videom, ter tudi

s snemanjem. Je izjemno prenosljiva po številnih namiznih sistemih in mobilnih platformah

in celo takih brez operacijskega sistema. Porablja malo pomnilnika, ob tem pa omogoča

dobro kvaliteto, dobro obvlada tresenje tudi na nižjih pasovnih širinah. Je tudi razširljiv in

podpira strojno opremo, »firmware« in je primerna tudi za implementacijo na vgrajenih

napravah.

V pjsip je prav tako že vključena razširitev za programski jezik c++ in Python (samo knjižnica

pjsua). Pjsua je visokonivojska knjižnica, ki jo uporabljamo na strani klienta in je

enostavnejša za implementacijo lastnih klientov.

Kot prikazuje shema na sliki (slika zgradbe knjižnice pjsip) knjižnica pjsip vsebuje za potrebe

razvoja aplikacij na platformi android knjižnico pjsua v programskem jeziku Java. Pri razvoju

uporabimo razvojno orodje Android studio, v projekt pa vključimo Pjsua kot zunanjo

knjižnico. Imena metod in razredov so enaka kot pri implementaciji v jeziku c++.

Knjižnica SDL ali Simple DirectMedia Layer je knjižnica napisana v jeziku C, ki na različnih

platformah nudi možnost dostopa do strojnega nivoja na katerega je nato mogoče zapisati

visoko zmogljive igre ali multimedijske aplikacije. Zaradi zapisa na strojnem nivoju lahko te

igre in aplikacije delujejo na različnih aplikacijskih sistemih. SDL upravlja s komponentami

kot so avdio, video in vhodne naprave. V primeru uporabe knjižnice pjsua, uporabimo

knjižnico SDL za prikazovanje videa.

16

FFmpeg je brezplačna programska oprema oz. projekt pri katerem razvijajo knjižnice in

programe, ki rokujejo z multimedijskimi podatki. FFmpeg je sposoben kodirati, dekodirati,

multipleksirati, demultipleksirati, prekodirati, pretakati, filtrirati in predvajati

multimedijsko vsebino. Kljižnici pjsip in pjsua lahko za potrebe kodiranja, odkodiranja in

prekodiranja videa vključujeta FFmpeg.

5.3 Medijski predvajalnik Kodi

Medijski predvajalnik Kodi je brezplačen, odprto kodni medijski predvajalnik, ki ga lahko

naložimo na različne operacijske sisteme in se lahko uporabi tudi za implementacijo

klientov za IPTV. Podprti operacijski sistemi so Windows, Linux ter Mac OS, obstajajo pa

tudi različice, ki podpirajo namestitev na majhnih poceni kartičnih računalnikih kot je

Raspberry Pi, . Teče tudi na igralni konzoli Microsoft Xbox, za katero je bil tudi razvit in se

prvotno imenoval XBMC (Xbox Media Center). Podpira vse najpogostejše avdio in video

formate, ob tem pa lahko prikazuje tudi slike, sezname predvajanja, vremensko napoved,

novice. Dodatno pa lahko namestimo tudi različne dodatke preko vtičnikov v jeziku Python

in tako s skriptami razširimo funkcionalnosti Kodi-ja. Tako lahko s skriptami v programskem

jeziku Python dodamo funkcionalnosti kot so: prikaz TV sporeda, klienti za upravljanje z e-

pošto, funkcionalnost prikaza napovednikov filmov, internetna TV, programi za spremljanje

in snemanje kanalov linearne televizije, igre ter še mnogo več. V naši implementaciji bomo

preko vtičnika dodali klient za IMS s prikazom videa.

5.4 Aplikacijski strežnik

Aplikacijski strežnik ali AS je programska oprema, ki omogoča ustvarjanje spletnih aplikacij

in strežniško okolje za njihovo izvajanje. Glede na delovanje ločimo več tipov aplikacijskih

strežnikov. Eden od tipov je uporabniški agent B2B, ki smo ga uporabili v implementaciji

storitve pretočnega videa v okolju mobilne telefonije. Uporabniški agent B2B (Back-to-back

user agent), poznan tudi pod kratico B2BUA, je element protokola SIP. Deluje med obema

komunikacijskima koncema tako, da pomaga pri vzpostavitvi in preklicu seje. B2BUA je

17

pravzaprav kombinacija dveh manjših SIP komponent. To sta UAC (User Agent Client) in

UAS (User Agent Server). UAC je komponenta, ki pošilja SIP sporočila in sprejema SIP

odgovore, UAS pa pošilja SIP odgovore in sprejema SIP sporočila. Na ta način oba elementa

SIP rokujeta s povratno signalizacijo od enega do drugega konca. IMS preusmeri SIP zahteve

do ustreznega aplikacijskega strežnika glede na IFC, ki je opisan v nadaljevanju.

5.5 Začetni kriterij filtriranja (iFC)

Začetni kriterij filtriranja (Initial Filter Criteria (iFC)) je IMS standard, ki je zapisan v obliki

XML. XML dokument vsebuje informacije o identiteti uporabnika in pravila usmerjanja.

Vsebuje prioriteto, sprožilno točko in aplikacijski strežnik. Prioriteta določi vrstni red

preverjanja točk proženja. Točka proženja mora ustrezati iskani lastnosti. Če je ta pogoj

izpolnjen iFC prepusti SIP zahteve do aplikacijskega strežnika. Poznamo dva tipa začetnih

kriterijev filtriranja: deljeni in nedeljeni. Pri deljenem je naročniku razkrita le referenčna

številka. Ob registraciji je tako CSCF-ju poslana le ta številka in ne celoten XML dokument,

saj je bil ta že predhodno shranjen v CSCF. Pri nedeljenem iFC-ju pa se v CSCF ob registraciji

pošlje celoten XML dokument.

18

6 IZVEDBA MOBILNE APLIKACIJE VIDEO TOKA

Poglavje opisuje praktično izvedbo projekta. Najprej opišemo namestitev razvojnega

okolja, nato komunikacijo med omrežjem IMS in aplikacijskim strežnikom, kar zajema

implementacijo začetnega kriterija filtriranja, sledi implementacija komunikacije med

pošiljateljem in strežnikom. Prikazana je tudi implementacija vtičnika klienta medijskega

predvajalnika Kodi. Na koncu smo zasnovali še klient mobilne aplikacije za operacijski

sistem android.

6.1 Namestitev razvojnega okolja

Za izvedbo praktičnega dela projekta je bilo najprej potrebno namestiti razvojno okolje na

katerem bomo razvili storitev. Sam razvoj bo potekal na dveh računalniških sistemih, saj

bomo morali komunikacijo testirati od začetka do konca, torej od pošiljateljeve do

naslovnikove strani. Na prvem sistemu smo imeli nameščen operacijski sistem Raspberry Pi

Raspbian GNU/Linux 8, na drugem pa operacijski sistem Ubuntu 17.04. Na oba sistema smo

namestili v prejšnjih poglavjih opisane komponente, kot so: pjsip, FFmpeg in ostale

potrebne knjižnice. Koraki namestitve razvojnega okolja so navedeni v tabeli 6.1.

Tabela 6.1: Koraki namestitve ustrezne programske opreme

mkdir -p ~/Install_development_enviroment/download_dir #ustvari mapo

cd ~/Install_development_enviroment/download_dir #premaknemo se v ustvarjeno

mapo

sudo apt install build-essential binutils libasound2-dev libv4l-dev libsdl1.2-dev git nasm

libsdl2-dev yasm qt-sdk bzip2 #tam namestimo določeno aplikacijo

wget https://github.com/cisco/openh264/archive/v1.6.0.tar.gz #wget pridobi datoteko

iz spleta

tar xvzf v1.6.0.tar.gz #razširimo pridobljen arhiv

cd openh264-1..6.0/ #dalje se premaknemo v mapo openh264-1..6.0

19

make -j4 #naredimo oz. prevedemo datoteke iz izvorne kode

sudo make install #ukaz kopira datoteke v končne lokacije oz. program se namesti

cd .. #premaknemo se iz trenutne mape

wget ftp://ftp.videolan.org/pub/x264/snapshots/last_x264.tar.bz2 #pridobimo

datoteko iz spleta

tar jxf last_x264.tar.bz2 #razširimo arhiv

cd x264-s* #se premaknemo v mapo x264-s*

wget http://ftp.br.debian.org/debian/pool/main/n/nasm/nasm_2.13.01-2_amd64.deb

#pridobimo datoteko iz spleta

sudo dpkg -i nasm_2.13.01-2_amd64.deb #namestimo enake pakete kot so bili na

izvorni strojni opremi

./configure --enable-static –extra-asflags="-fPIC" #preveri ali so vse potrebne knjižnice

za prevajanje programa


sudo make install-lib-static #ukaz kopira datoteke v končne lokacije oz. program se

namesti


wget http://ffmpeg.org/releases/ffmpeg-3.0.2.tar.bz2 #pridobimo datoteko iz spleta

tar jxf ffmpeg-3.0.2.tar.bz2 #razširimo pridobljen arhiv

cd ffmpeg-3.0.2 #dalje se premaknemo v mapo

./configure --enable-gpl --enable-libx264 --enable-nonfree –enable-version3 #preveri ali

so vse potrebne knjižnice za prevajanje programa nameščene na sistemu




wget http://www.pjsip.org/release/2.6/pjproject-2.6.tar.bz2 #pridobimo datoteko iz

spleta

tar jxf pjproject-2.6.tar.bz2 #razširimo pridobljen arhiv

cd pjproject-2.6pjlib/include/pj/ #dalje se premaknemo v mapo

cd pjlib/include/pj #dalje se premaknemo v mapo

20

mv config_site_sample.h config_site.h #premaknemo config_site_sample.h v

config_site.h

nano config_site.h #v config_site.h skopiramo spodnji vrstici #define

#define PJMEDIA_HAS_OPENH264_CODEC 1

#define PJMEDIA_HAS_VIDEO 1

cd ../../../ #premaknemo se iz trenutne mape

./configure #preveri ali so vse potrebne knjižnice za prevajanje programa nameščene

na sistemu



cd pjsip-apps/src/vidgui #dalje se premaknemo v mapo

qmake-qt4 #qmake je ukaz, ki poenostavi stvaritev makefile-a po različnih platformah


6.2 Nastavitev začetnega kriterija filtriranja (iFC)

Za pravilno komunikacijo sistema smo nastavili začetni kriterij filtriranja (tabela 6.2), tako,

da omrežje IMS prepušča do aplikacijskega strežnika samo relevantne zahteve

uporabnikov, ki imajo vključeno storitev. V dokument XML smo tako nastavili pogoje, da

filter prepušča pakete z metodo INVITE in imajo v glavi SIP okvirja pod kategorijo »To:« v

vsebini besedo »pc«. Slednja kategorija namreč pove kam je paket namenjen in v kolikor je

namenjen storitvi realno časovne video razglednice, ima v naslovu besedno zvezo »pc«.

Tako smo določili z namenom, da iFC ve, katere pakete prepušča in katerih ne.

Prav tako smo pod značko »Server Name« določili SIP naslov aplikacijskega strežnik

sip:postcard_as.ietkims.uni-mb.si, ki ga sistem uporablja za delovanje.

21

Tabela 6.2: Nastavitev začetnega kriterija filtriranja

<?xml version="1.0" encoding="UTF-8"?>

<ServiceProfile>

<InitialFilterCriteria>

<Priority>1</Priority>

<TriggerPoint>

<ConditionTypeCNF>0</ConditionTypeCNF>

<SPT>

<ConditionNegated>0</ConditionNegated>

<Group>0</Group>

<Method>INVITE</Method>

<SIPHeader>

<Header>To</Header>

<Content>"pc"</Content>

</SIPHeader>

<Extension></Extension>

</SPT>

</TriggerPoint>

<ApplicationServer>

<ServerName>sip:postcard_as.ietkims.uni-mb.si</ServerName>

<DefaultHandling>0</DefaultHandling>

</ApplicationServer>

</InitialFilterCriteria>

</ServiceProfile>

6.3 Komunikacija med pošiljateljem in strežnikom

Za vzpostavitev komunikacije med pošiljateljem in sprejemnikom oz. med klientom

mobilne aplikacije in medijskim predvajalnikom Kodi smo vzpostavili sistem z IMS-om in

22

Aplikacijskim strežnikom. V medijski predvajalnik Kodi smo dodali vtičnik imenovan »IETK

IMS client«. Za komunikacijo slednjega s sistemom IMS skrbi zaledni sistem implementiran

v C++.

Vtičnik "IETK IMS client" je napisan v programskem jeziku Python in skrbi, da se uporabnik

registrira v SIP ter prejema video tok in ga prikazuje. Implementiran je na naslednji način.

Najprej uvozimo knjižnice, med katerimi so zelo pomembne knjižnice za »xbmc« in knjižnica

»zmq«. Knjižnice xmbc poskrbijo, za povezljivost s programom Kodi in prikaz grafičnih

gradnikov. Knjižnica ZeroMQ pa poskrbi za komunikacijo do zalednega sistema klienta

implementiranega v c++ . Po uvozu naštetih knjižnic se vtičnik poveže na pravi IP naslov in

vrata kamor pošlje nastavitve zalednemu sistemu. V nastavitvah pošlje uporabniško ime in

geslo za registracijo v omrežje IMS. Nato se naroči na sporočila zalednega sistema in ob

prejetju sporočil »ONREG«, »ONCALL« in »ONREJECT prikaže primeren dialog uporabniku

in pošilja povratno informacijo zalednemu sistemu.

6.4 Opis delovanja Android aplikacije

V tem podpoglavju bomo opisali načrtovano delovanje in izgled mobilne aplikacije. Glavna

naloga Android aplikacije je prenašati video tok iz mobilne naprave preko omrežja IMS do

medijskega predvajalnika Kodi. Klient mobilne aplikacije je razvit v razvojnem orodju

Android Studio z uporabo programskega jezika Java. Pri razvoju se uporabi knjižnica pjsip z

vključeno podporo za video. Podprti načini kodiranja vsebin so odvisni od posamezne

naprave in od kodekov, ki jih ta podpira. Aplikacija je zasnovana tako, da izbere skupni

kodek med klicanima napravama. Če jima noben kodek ni skupen se storitev ne izvede.

Aplikacija vsebuje dva zaslona, ki ju vidimo na spodnji sliki (slika 6.1). Na prvem glavnem

zaslonu najprej izberemo naslovnika, kamor bomo pošiljali video. Ko izberemo prejemnika

lahko začnemo z zajemom videa in avdia ter pošiljanjem vsebin v živo. Drugi zaslon je

namenjen nastavitvam, kjer lahko nastavimo kvaliteto videa, dodamo stike v imenik,

upravljamo s standardnimi nastavitvami našega računa in dobimo več informacij o verziji in

razvijalcih aplikacije.

23

Slika 6.1: Zaslonski sliki aplikacije

24

7 SKLEP

Ob končani projektni nalogi lahko zaključimo, da je končna storitev realno časovne video

razglednice preprosta za uporabo in bi lahko pomagala zmanjšati digitalno ločnico. Ob tem

smo tehnologijo pretočnega videa predstavili na nov način in tako ustvarili novo storitev. Iz

teh razlogov predpostavljamo, da takšna rešitev pripomore k lažji uporabi storitev s strani

neveščih uporabnikov. Za potrditev te domneve bi bilo potrebno izvesti primerno

testiranje. Prav tako bi bilo dobro v prihodnosti sistem izboljšati, da bi deloval robustneje.

V sistem bi v nadaljevanju kazalo vključiti storitev omrežnega imenika, kar bi pripomoglo k

enostavnejši uporabi storitve.

25

UPORABLJENI VIRI IN LITERATURA

[1] Powell, H. A quick and dirty introduction to ZeroMQ, dostopno na

http://blog.scottlogic.com/2015/03/20/ZeroMQ-Quick-Intro.html [5. 9. 2017].

[2] About SDL, dostopno na https://www.libsdl.org/ [5. 9. 2017].

[3] Application server, dostopno na https://en.wikipedia.org/wiki/Application_server

[5. 9. 2017].

[4] Application Server Guide, dostopno na

http://clearwater.readthedocs.io/en/stable/Application_Server_Guide.html [5. 9. 2017].

[5] Macioszczyk, E. Catis Blog, dostopno na http://catis-blog.com/ [5. 9. 2017].

[6] FFmpeg, dostopno na https://www.ffmpeg.org/ [5. 9. 2017].

[7] FFmpeg Wikipedia, dostopno na https://en.wikipedia.org/wiki/FFmpeg [5. 9. 2017].

[8] How To Work with the ZeroMQ Messaging Library, dostopno na

https://www.digitalocean.com/community/tutorials/how-to-work-with-the-zeromq-

messaging-library [5. 9. 2017].

[9] Initial Filter Criteria, dostopno na

https://docs.oracle.com/cd/E23521_01/doc.60/e23532/sbors_app_ifc.htm [5. 9. 2017].

[10] IP Multimedia Subsystem, dostopno na

https://en.wikipedia.org/wiki/IP_Multimedia_Subsystem [5. 9. 2017].

[11] IP Multimedia Subsystem (IMS) Call Flows, dostopno na

http://www.eventhelix.com/ims/#.Wa5HZMgjHIU [5. 9. 2017].

[12] IPv6 support, dostopno na https://trac.pjsip.org/repos/wiki/IPv6 [5. 9. 2017].

[13] Real Time Streaming Protocol, dostopno na

https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol [5. 9. 2017].

[14] Real-time Transport Protocol, dostopno na https://en.wikipedia.org/wiki/Real-

time_Transport_Protocol [5. 9. 2017].

[15] Session Initiation Protocol, dostopno na

https://en.wikipedia.org/wiki/Session_Initiation_Protocol [5. 9. 2017].

[16] Session Traversal Utilities for (NAT), dostopno na https://tools.ietf.org/html/draft-

ietf-behave-rfc3489bis-18 [5. 9. 2017].

26

[17] Simple DirectMedia Layer, dostopno na

https://en.wikipedia.org/wiki/Simple_DirectMedia_Layer [5. 9. 2017].

[18] SIP (Session Initiation Protocol) Introduction, dostopno na

http://www.siptutorial.net/SIP/ [5. 9. 2017].

[19] Kodi, dostopno na https://sl.wikipedia.org/wiki/Kodi [5. 9. 2017]

[20] Pjmedia, dostopno na

http://www.pjsip.org/docs/latest/pjmedia/docs/html/index.htm [5. 9. 2017].

[21] Pjsip, dostopno na http://www.pjsip.org/ [5. 9. 2017].

[22] Pjsua Python Module, dostopno na

https://trac.pjsip.org/repos/wiki/Python_SIP_Tutorial [5. 9. 2017].

[23] Publish/Subscribe ZeroMQ, dostopno na http://learning-0mq-with-

pyzmq.readthedocs.io/en/latest/pyzmq/patterns/pubsub.html [5. 9. 2017].

[24] Python SIP, Build and Installation, dostopno na

https://trac.pjsip.org/repos/wiki/Python_SIP/Build_Install [5. 9. 2017].

[25] Traversal Using Relays around NAT, dostopno na

https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT [5. 9. 2017].

[26] Prokop, A. Understanding Session Description Protocol (SDP), dostopno na

https://andrewjprokop.wordpress.com/2013/09/30/understanding-session-description-

protocol-sdp/ [5. 9. 2017].

[27] Anritsu. Understanding IMS. Izdaja 2. 2013. Dostopno na http://www.hke-

auditech.cz/download/files/Understanding-IMS.pdf [5. 9. 2017].

[28] What Does CSCF (Call Session Control Function) Do in Your IMS Network?, dostopno

na http://gonorthforge.com/what-does-cscf-call-session-control-function-do-in-your-ims-

network/ [5. 9. 2017].

[29] ZeroMQ, dostopno na https://en.wikipedia.org/wiki/ZeroMQ [5. 9. 2017].

[30] Piël, N. ZeroMQ an introduction, dostopno na http://nichol.as/zeromq-an-

introduction [5. 9. 2017].

pretoČni video v okolju moilne telefonijesistem pretočnega videa v okolju mobilne telefonije....

Documents