Magisterski Trud - Nikola Ilievski 98 11 v3 · Abstract This master thesis has a goal to define a model that will confirm communication practically, in other words this model should

УНИВЕРЗИТЕТ„СВ.КЛИМЕНТОХРИДСКИ“

Факултетзаинформатичкиикомуникацискитехнологии-Битола

-Информатикаикомпјутерскатехника-

МАГИСТЕРСКИТРУД

тема: МоделзаP2PразменанаMPEG-DASH

мултимедијалнисодржинипрекудиректниклиентски

конекции

Изработил:

НиколаИлиевски

Индекс98/11

_________________________

Ментор

Проф.Д-р.ИлијаЈолевски

_________________________

Битола2016

Изјава

Јас,НиколаИлиевски,студентнавторциклуснастудиинаФакултетотзаинформатичкиикомуникацискитехнологии-Универзитетсв.КлиментОхридски-Битола,настудискатапрограма“Информатикаикомпјутерскатехника”,собројнаиндекс98/11,изјавувамдекаизработкатанамагистерскиоттрудподнаслов“МоделзаP2PразменанаMPEG-DASHмултимедијалнисодржинипрекудиректниклиентскиконекции”претставувасамостојноизработентрудодменеиистиотерезултатнасамостојнанаучнаработа.

Сесогласувамдагисносамситеобврскииодговорностикоипроизлегуваатодплагијаторствоинеовластенотокористењенатуѓтекст,согласносоважечкитезаконскииподзаконскиакти.

Ментор:Ред.Профд-рИлијаЈолевски

Комисијазаоценканамагистерскиоттруд:

1. Ред.Профд-рИлијаЈолевски2. Доц.Д-рЗоранКотевскии3. Доц.Д-рЕленаВлаху–Ѓоргиевска

Апстракт

Овајмагистерскитрудимазацелдадефинирамоделкојштоќепотврдипрекупрактиченпримеркомуникација,односнопреноснамултимедијалнасодржинапомеѓудваклиентиилипоконкретновебпрелистувачи.КонцептотсетемелинаупотребанадверелативноновитехнологиMSE-MediaSourceExtensionsиWebRTC-WebReal-TimeCommunication.Задвететехнологиидаденедеталенописзафункционалноститекоигиимаатинудат.Крајноеобјаснетаисаматаимплементацијанаовојмоделпрекупрактиченпример.

Клучнизборови:MediaSourceExtensions(MSE),WebReal-TimeCommunication(WebRTC),Striming,PeertoPeer.

Abstract

Thismasterthesishasagoaltodefineamodelthatwillconfirmcommunicationpractically,inotherwordsthismodelshouldtransferdata(audioandvideo)betweentwobrowsersorpeertopeer.TheconceptisbasedonMSE-MediaSourceExtensionsandWebRTC-WebReal-TimeCommunicationtechnologies.Thereisdetaileddescriptionaboutthefunctionalitiesinthesetechnologies.Attheendofthedocument,thereisaexplanationaboutthismodelusingrealprojectsample.

Keywords:MediaSourceExtensions(MSE),WebReal-TimeCommunication(WebRTC),Striming,PeertoPeer.

Содржина Апстракт......................................................................................................................................................4

Abstract.......................................................................................................................................................5

Листанаслики............................................................................................................................................9

Листанатабели..........................................................................................................................................9

1 Вовед.................................................................................................................................................10

2 DynamicAdaptiveStreamingoverHTTP...........................................................................................10

2.1 Вовед.........................................................................................................................................10

2.2 Карактеристики........................................................................................................................11

2.3 GPAC(ProjectonAdvancedContent).........................................................................................11

2.3.1 Вовед.................................................................................................................................12

2.3.2 GPACandstandards..........................................................................................................12

2.3.3 Features.............................................................................................................................13

2.3.4 Introduction.......................................................................................................................14

2.3.5 Generaloperations............................................................................................................14

2.3.6 ExportedMPDfile..............................................................................................................15

2.3.7 DASHSupportinMP4Box..................................................................................................17

2.4 MediaSourceExtensions(MSE)................................................................................................21

2.4.1 Вовед.................................................................................................................................21

2.4.2 Goals..................................................................................................................................22

2.4.3 Browsersupport................................................................................................................22

3 WebRTC.............................................................................................................................................24

3.1 History........................................................................................................................................24

3.2 Design........................................................................................................................................26

3.3 Benefits......................................................................................................................................26

3.4 Support......................................................................................................................................27

3.5 Concerns....................................................................................................................................28

3.6 Architecture...............................................................................................................................28

3.7 Real-timecommunicationwithoutplugins................................................................................31

3.8 Wherearewenow?...................................................................................................................31

3.9 Awordofwarning.....................................................................................................................32

3.10 MyfirstWebRTC........................................................................................................................32

3.11 MediaStream(akagetUserMedia).............................................................................................33

3.11.1 Constraints.........................................................................................................................36

3.11.2 Screenandtabcapture......................................................................................................36

3.12 Signaling:sessioncontrol,networkandmediainformation.....................................................36

3.13 RTCPeerConnection...................................................................................................................40

3.14 Whatissignaling?......................................................................................................................42

3.14.1 WhyissignalingnotdefinedbyWebRTC?.........................................................................42

3.14.2 RTCPeerConnection+signaling:offer,answerandcandidate..........................................44

3.14.3 CodingWebRTCforsignaling.............................................................................................45

3.14.4 Peerdiscovery....................................................................................................................47

3.14.5 HowcanIbuildasignalingservice?...................................................................................47

3.14.6 Pushingmessagesfromtheservertotheclient................................................................48

3.14.7 Scalingsignaling.................................................................................................................50

3.14.8 BuildingasignalingservicewithSocket.ioonNode..........................................................51

3.14.9 UsingRTCDataChannelforsignaling..................................................................................54

3.14.10 Signalinggotchas...........................................................................................................54

3.14.11 Readymadesignalingservers.........................................................................................54

3.14.12 Signalingsecurity...........................................................................................................55

3.14.13 Aftersignaling:usingICEtocopewithNATsandfirewalls............................................55

3.14.14 STUN..............................................................................................................................58

3.14.15 TURN..............................................................................................................................59

3.14.16 DeployingSTUNandTURNservers................................................................................60

3.14.17 Beyondone-to-one:multi-partyWebRTC.....................................................................61

3.14.18 MultipointControlUnit.................................................................................................61

3.14.19 Beyondbrowsers:VoIP,telephonesandmessaging.....................................................62

3.14.20 RTCPeerConnectionwithoutservers.............................................................................63

3.14.21 Caller..............................................................................................................................63

3.14.22 Callee.............................................................................................................................64

3.14.23 RTCPeerConnectionplusservers...................................................................................64

3.14.24 Asimplevideochatclient..............................................................................................66

3.14.25 What'sgoingon?...........................................................................................................67

3.15 Networktopologies...................................................................................................................74

3.16 RTCDataChannel........................................................................................................................76

3.17 Security......................................................................................................................................78

3.18 Inconclusion..............................................................................................................................78

3.19 Developertools..........................................................................................................................78

4 Моделнареаленпроект.................................................................................................................80

4.1 Функционалности.....................................................................................................................80

4.2 MSE–MediaSourceExtension.................................................................................................81

4.3 Сигнализацискисервер...........................................................................................................81

4.4 HTMLИмплементација............................................................................................................84

4.5 Потребниресурсизапоставувањенаоколина.....................................................................86

4.6 Сценарија..................................................................................................................................86

4.6.1 Сценарио1........................................................................................................................87

4.6.2 Сценарио2........................................................................................................................88

4.6.3 Сценарио3........................................................................................................................89

4.7 Споредбенастатистика............................................................................................................91

Заклучок....................................................................................................................................................92

КористенаЛитература.............................................................................................................................93

Листа на слики Слика1GPACлого....................................................................................................................................11Слика2MSEмодел..................................................................................................................................21Слика3WebRTCлого...............................................................................................................................24Слика4WebRTCархитектура..................................................................................................................29Слика5JSEPАрхитектура........................................................................................................................40Слика6WebRTCАрхитектура..................................................................................................................41Слика7JSEPАрхитектура........................................................................................................................43Слика8apprtcinaction............................................................................................................................50Слика9СветбезNATиFirewall...............................................................................................................55Слика10Реаленсветзакомуникацијапомеѓудваpeer-ови...............................................................56Слика11КористењенаSTUNсерверзадобивањенајавнаIP/portадреса.......................................59Слика12STUN,TURNandsignaling..........................................................................................................60Слика13Fullmeshтопологија.................................................................................................................61Слика14CISCOMCUуред........................................................................................................................62Слика15наогањенакандидатизаконекција.......................................................................................65Слика16WebRTCпатекинаконекција..................................................................................................66Слика17Архитектуранаapprtcвидеочетапликацијата.....................................................................68Слика18GooglechannelAPI–поставувањенаканал...........................................................................69Слика19GooglechannelAPI–праќањенапорака................................................................................70Слика20Multipointcontrolunit–примернатопологија......................................................................75Слика21Tethr/Tropo:disastercommunicationsinbriefcase..................................................................76Слика22WebRTCinChrome....................................................................................................................79Слика23Архитектуранареаленпроект................................................................................................80Слика24Визуелникомпонентинамоделот.........................................................................................81Слика25mode-Serveronly.....................................................................................................................88Слика26modeonePeer..........................................................................................................................89Слика27modeMultiplePeers.................................................................................................................90

Листа на табели Табела1ИменувањанаWebRTCкомпонентите...................................................................................32Табела2ВебпрелистувачикоикористатWebSocket...........................................................................49Табела3СтатистикабезкористењенаP2P...........................................................................................91Табела4СтатистикасокористењенаP2P.............................................................................................91

1 Вовед Со брзиот развој на софтверот и хардверот, а воедно и со збогатувањето на содржините

достапни на интернет, се јавува потреба од поорганизиран начин за пренос на податоци докрајнитеклиенти,односнокорисници.Еднаодсодржинитекоисевопостојанраствоквалитетавоедено и во Мегабајти е и пренесувањето на аудиовизуелна содржина. Поради ова, наместодосегашнатанајчестокористенатехнологијанапреноснасодржинатасервер-клиент,целтаедасе оформи модел со имплементација каде што главна улога ќе имаат самите клиенти. Тие бипренесувалесегментинааудиовизуелнасодржинамеѓусебноодносноклиент-клиент.Соовабисенамалилдиректниотсообраќајотодсервердоклиентите,штобибилоодогромнакористприследење на аудиовизуелни содржини во живо, или при први проекциии на некоја серија илифилм.

Засаматаимплементацијаакцентеставеннадвеклучнитехнологиикоисерелативноновиисесеуште во експериментална фаза MSE-Media Source Extensions и WebRTC- Web Real-TimeCommunication.

2 Dynamic Adaptive Streaming over HTTP 2.1 Вовед

DynamicAdaptiveStreamingoverHTTP(DASH),илипопознатсонеговотоскратеноимеMPEG-DASH,претставуватехникакојавршиадаптибилностримањенамултимедијалнасодржина.МожедагикористипостоечкитеHTTPвебсервери,патакастриминготсевршиодстрананасервердоклиент.СличнонаAppleHTTPLiveStreaming(HLS)решението,истотакаиMPEG-DASHработинапринципнасеквенцијалносегментирањенасодржината.Односно,содржинатаседелинамалиHTTP-basedсегменти,вокоисесодржикратокаудиовизуеленинтервалкојштодоколкусеспоисоостанатитесегментиможедаформирасодржинакојабитраелаоднеклолкусекундидонеколкучаса.Напримергледањенафилм,илипакпреноснанекојспортскинатпреварвоживо.Содржинатапрактичноможедабидедостапнавоповеќеваријанти,односноистатадаимаразличенbitrate.ЗавременаприкажувањетонасодржинатанаMPEG-DASHплеерот,клиентотавтоматскиизбираеднаодалтернативитезапреземањенанареденсегмент,базиранонамоменталнитеусловивокоисенаоѓамрежата.Сеизбирасегментотсонајголемbitrateкојштоможедабидепреземенвовременскиотинтервал,додекасеемитувапретходниотсегмент.Притоаеземеновопредвидданесејаватпрекиниилибаферирањенавидеосодржината.Соова,MPEG-DASHклиентотможедостадобродасеприлагодиилиадаптиравозависностодпроменатанаусловитевомрежата,асотоаидаобезбедиемитувањенасодржинасовисокквалитетвокојамоментотнабаферирањенасодржинаилипрекиниќесесведенинаминимум.

MPEG-DASHвопринципепрвиотадаптибиленплеерзастримањенамултимедијалнасодржинакојаегенерализирнасоинтернационаленстандард.MPEG-DASHистотаканетребадасемешасосотранспортниотпротоколбидејкикористиTCP.

MPEG-DASHјакористивеќепостоечкатаинфраструктуранаHTTPвебсервери,односноинфраструктуратакојаштосекористизакојаидабилосодржинанаWorldWideWeb.Соовасеовозможувадостапностнамногукорисничкиуреди,какоштосетелевизори,десктопкомпјутери,паметнителефони,таблетиисл.Стандардизирањетонаадаптибилнотостримањенамултимедијалнасодржинаимазацелдаобезбедидовербанапазарот,соштооварешениебисеприлагодилозауниверзалнаупотреба.

2.2 Карактеристики

DASHтехнологијатаобезбедуваадаптибилностримањенамултимедијалнасодржинакадештосодржинатаеподеленанапомалисегменти,коиштоможатдасепренесуваатдоклиентотпрекуHTTP.Мediapresentationdescription(MPD)датотекатасодржидеталниинформации(времетраењенавидеото,URL,детализавидеоформатот,видеорезолуција,какоиbitrate-от),коиможатдабидаторганизиранинаразличниначиникакоSegmentList,SegmentTemplate,SegmentBaseилиSegmentTimeline,возависностодпотребите.

DASHимплементацијатаеaudio/video“codecagnostic”,односносесправувасоразличнивидеоформатиииститеможедагиемитуванаразличниуреди.Еденилиповеќетипови(различнирезолуциииbitrates)намултимедијалнидатотекиможатдабидатдостапни.Сотоаиселекцијатанаконкретнадатотекаможедабидеизвршенаврзбазанаусловитевомрежата,можноститенауредотнакојштосегледасодржината,подесувањатанакорисникот,овозможувањетонаадабтибилностзастримањекакоиQoE(QualityofExperience).

2.3 GPAC(Project on Advanced Content)

Слика1GPACлого

2.3.1 Вовед

GPACProjectonAdvancedContentпретставуваимплементацијанаMPEG-4стандардотнапишанвоANSIC.GPACпакетотсодржиалаткизаемитувањенааудиовизуелнасодржина(mediaplayback),векторскаграфикаи3Дмоделирање.

GPACнудитрисетовинаалаткивоосновнатаверзија(libgpac):

• Мултимедијален(cross-platform)плеер,којможедасекористипрекуконзола(MP4Client)иливизуелниотинтерфејсOsmo4.

• Пакувачнамултимедијалнасодржина,MP4Box

• Серверскиалаткизамултиплексирањеистримање–коисесеуштевофазанадевелопмент.

GPACпреставува(cross-platform)алатка,односноедостапназаповеќеплатформинаоперативнисистеми.Напишанаево(речиси100%ANSI)Cзаполеснапреносливост,какоисоцелдакористиштоеможнопомалкумеморија.ВомоментовдостапенезаWindows,Linux,Solaris,WindowsCE(SmartPhone,PocketPC2002/2003),iOS,Android,EmbeddedLinux(familiar8,GPE)какоиSymbianOSсистем.

Овајпроектенаменетзаширокаупотреба,почнувајкиодкрајникорисницидоразвивачитенасофтверимултимедијалнисодржини.Даваможностдасеекспериментирасокористењенановистандарди,претварањенамултимедијалнасодржинавооптимизиранасодржинакојаможедабидекористенанамобилниуреди.Достапнисеиплееризастримањенамултимедијалнасодржина.

GPACframeworkеразвиванодÉcolenationalesupérieuredestélécommunications(ENST)воделотзаистражувањенадигиталнамултимедијалнасодржина.

2.3.2 GPAC and standards

GPACнајпрвозапочнадасеразвивавостартапвоNewYorkcity1999година.КакософтверсоотворенкодGPACофицијалнозапочнадасенадградуваво2003годинасоосновнацелдасеразвиеоднула(fromscratch),воANSIC,апокрајтоадабидеигенерализиранкакоMPEG-4стандардот,флексибиленаалтернативанаMPEG-4.ЛиценциранеподLGPLлиценцата.

Соразвојотсофтверот,истиотполекаевалуирашеисегаподдржувамногудругимултимедијалнистандарди,какоштосеX3D,W3CSVGTiny1.2,OMA/3GPP/ISMAMPEGDynamicAdaptiveStreamingпрекуHTTP(MPEG-DASH)штоеодпосебенинтересвоовојмагистерскитруд.Истотакаподдржуваи3DнаembeddedplatformsсопомошнаOpenGL.

2.3.3 Features

2.3.3.1 Packaging Multimedia Content

GPACнудиенкодериимултиплексери,какоиалаткизаобработканавидеосодржинаособеноMP4датотеки,какоинеколкуалаткизаscenedescriptions(BIFS/VRML/X3Dконвертери,SWF/BIFS,SVG/BIFS,и.т.н).MP4Boxгинудиситеовиеалаткивоапликацијапрекукомандналинија.Моменталнодостапнисеследнивеоперацииифункции:

• MP4/3GPконверзијаодMP3,AVI,MPEG-2TS,MPEG-PS,AAC,H263,H264,AMR,имногудруги,

• 3GPPDIMSпакувањеодSVGtiny1.2датотеки

• Filelayout:фрагментација,пополнувањенапразнини(interleaving),ичистење

• Сегментирањенадатотекиспоредголеминаиливреметрање,извлекувањенасегментиоддатотекакакоидодавањенановасодржина

• XMLинформацијазаMP4иRTPтраки,

• MediaTrackекстракции,

• ISMAE&Aенкрипцијаидекрипција,

• 3GPPпреводи(SUB/SRT/TTXT/TeXML),VobSubimport/export,

• BIFSконверзијанасцениикодеципомеѓуMP4,BTиXMT-A,

• LASeRконверзијанасцениикодеципомеѓуMP4,SAF,SVGandXSR(XMLLASeR),

• XMLстатистиказаBIFSсцени(BT,XMT-AиMP4),

• КонверзијавоиодBT,XMT-A,WRL,X3DиX3DVсоподдршказаgzip.

2.3.3.2 Playing Multimedia Content

GPACподдржуваголембројнапротоколиистандарди,меѓукои:

• BIFSсцени(2D,3Dкакоикомбинацијана2D/3Dсцени),

• VRML2.0(VRML97)сцени(исклучувајќиGEOилиNURBSекстензии),

• X3Dсцени(нецелосни)воX3D(XML)какоиX3DV(VRML)формати,

• SVGTiny1.2сцени(вклучувајќиипаковани3GPDIMSдатотеки),

• LASeRиSAF(нецелосна)поддршка,

• Прогресивновчитување/рендерирањенаSVG,X3DиXMTдатотеки,

• HTTPчитањенаситесценскидетали,

• GZIPподдршказаситеформатинаMPEG4/X3D/VRML/SVG,

• MP4и3GPPчитањенадатотеки(local&http),

• MP3иAACдатотеки(local&http)какоиHTTPстриминг(ShoutCast/ICEcastradios),

• Најчестокористенитемедијакодецизаслики,аудиоивидео,

• Најчестокористенитемедиаконтејнери,

• 3GPPTimedText/MPEG-4StreamingText,

• MPEG-2TSдемултиплексер(local/UDP/RTP)какоиDVBподдршка(самозаLinuxоперативенсистем),

• ПоддршказастримањепрекуRTP/RTCP(unicastиmulticast)какоиRTSP/SDP,

• ПлагинизаMozilla(osmozilla,Win32иLinux)какоизаInternetExplorer(GPAX,Win32иPPC2003).

2.3.3.3 Streaming Multimedia Content

Воверзијата0.4.5,GPACимаексперименталенserver-sideкакоиалаткизастриминг

• MP4/3GPиRTPстример(unicastиmulticast),

• RTPстримерсосервисенtimeslicing(DVB-H)симулација,

• MPEG-2TSбродкастсокористењенаMP4/3GPдатотекиилиRTPстримовикаковлез,

• BIFSRTPброадкасталаткизаовозможувањестримингвоживокакоиRandomAccessPointsгенерирање.

2.3.4 Introduction

MP4Boxпретставувакомпонентакојаштослужизапакувањенамултимедијалнасодржина,

богатасоголембројнафункционалности:конверзија,разделување,порамнување,

извлекувањекакоимногудруги.Секористиедноставнопрекуупотребанакомандналинија.

2.3.5 General operations

ВопродолжениеследувапримеркакоможепрекуGPACдасенаправиекспортнаMPDфајл.СопрватакомандасегенерираMPDдатотекакојасодржисамоеденRepresentationтаг,односноможедасекористисамоеденbitrate.ДодекапаквовториотслучајвоMPDдатотекатасесодржатдверепрезентациинаbitrateзавидеоиаудио.

• mp4box-dash10000-frag1000-rapC:\Users\nikola\Desktop\videoToMPD\GOPR5969.MP4 • MP4Box-dash10000-outm.mpd1.mp4#audio2.mp4#audio1.mp4#video2.mp4#video

2.3.6 Exported MPD file Сокористењенагоренаведенитекомандивоmp4Boxконзолата,возависностодвидеофајловитештогиимамеседобиваатследнивеxmlсттруктури:

• Еденbitrate

<?xml version="1.0"?>  <MPD xmlns="urn:mpeg:dash:schema:mpd:2011" minBufferTime="PT1.500S" type="static" mediaPresentationDuration="PT0H0M41.795S" maxSegmentDuration="PT0H0M9.009S" profiles="urn:mpeg:dash:profile:full:2011"> <ProgramInformation moreInformationURL="http://gpac.sourceforge.net"> <Title>1_dash.mpd generated by GPAC</Title> </ProgramInformation> <Period duration="PT0H0M41.795S"> <AdaptationSet segmentAlignment="true" maxWidth="1280" maxHeight="720" maxFrameRate="30000/1001" par="16:9" lang="und"> <ContentComponent id="1" contentType="video" /> <ContentComponent id="2" contentType="audio" /> <Representation id="1" mimeType="video/mp4" codecs="avc1.64001f,mp4a.40.2" width="1280" height="720" frameRate="30000/1001" sar="1:1" audioSamplingRate="44100" startWithSAP="1" bandwidth="2895992"> <AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"/> <BaseURL>1_dashinit.mp4</BaseURL> <SegmentList timescale="1000" duration="8508"> <Initialization range="0-2099"/> <SegmentURL mediaRange="2100-1978539" indexRange="2100-2227"/> <SegmentURL mediaRange="1978540-5164668" indexRange="1978540-1978679"/> <SegmentURL mediaRange="5164669-8568222" indexRange="5164669-5164796"/> <SegmentURL mediaRange="8568223-12162069" indexRange="8568223-8568362"/> <SegmentURL mediaRange="12162070-15130084" indexRange="12162070-12162197"/> </SegmentList> </Representation> </AdaptationSet> </Period> </MPD>

• Дваbitrate-изавидеоиаудио

<?xml version="1.0"?>  <MPD xmlns="urn:mpeg:dash:schema:mpd:2011" minBufferTime="PT1.500S" type="static" mediaPresentationDuration="PT0H0M41.795S" maxSegmentDuration="PT0H0M10.010S" profiles="urn:mpeg:dash:profile:full:2011"> <ProgramInformation moreInformationURL="http://gpac.sourceforge.net"> <Title>m.mpd generated by GPAC</Title> </ProgramInformation> <Period duration="PT0H0M41.795S"> <AdaptationSet segmentAlignment="true" bitstreamSwitching="true" lang="und"> <AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"/> <SegmentList>

<Initialization sourceURL="m_set1_init.mp4"/> </SegmentList> <Representation id="1" mimeType="audio/mp4" codecs="mp4a.40.2" audioSamplingRate="44100" startWithSAP="1" bandwidth="193824"> <BaseURL>1_track2_dash.mp4</BaseURL> <SegmentList timescale="44100" duration="440294"> <SegmentURL mediaRange="1597-243194" indexRange="1597-1640"/> <SegmentURL mediaRange="243195-484725" indexRange="243195-243238"/> <SegmentURL mediaRange="484726-726053" indexRange="484726-484769"/> <SegmentURL mediaRange="726054-968024" indexRange="726054-726097"/> <SegmentURL mediaRange="968025-1012634" indexRange="968025-968068"/> </SegmentList> </Representation> <Representation id="2" mimeType="audio/mp4" codecs="mp4a.40.2" audioSamplingRate="48000" startWithSAP="1" bandwidth="194237"> <BaseURL>2_track2_dash.mp4</BaseURL> <SegmentList timescale="48000" duration="479232"> <SegmentURL mediaRange="936-246011" indexRange="936-979"/> <SegmentURL mediaRange="246012-488106" indexRange="246012-246055"/> <SegmentURL mediaRange="488107-730397" indexRange="488107-488150"/> <SegmentURL mediaRange="730398-972699" indexRange="730398-730441"/> <SegmentURL mediaRange="972700-1014697" indexRange="972700-972743"/> </SegmentList> </Representation> </AdaptationSet> <AdaptationSet segmentAlignment="true" bitstreamSwitching="true" maxWidth="1280" maxHeight="720" maxFrameRate="30000/1001" par="16:9" lang="und"> <SegmentList> <Initialization sourceURL="m_set2_init.mp4"/> </SegmentList> <Representation id="3" mimeType="video/mp4" codecs="avc3.64001f" width="1280" height="720" frameRate="30000/1001" sar="1:1" startWithSAP="0" bandwidth="2703539"> <BaseURL>1_track1_dash.mp4</BaseURL> <SegmentList timescale="30000" duration="300300"> <SegmentURL mediaRange="1595-2421647" indexRange="1595-1638"/> <SegmentURL mediaRange="2421648-6049530" indexRange="2421648-2421691"/> <SegmentURL mediaRange="6049531-9734320" indexRange="6049531-6049574"/> <SegmentURL mediaRange="9734321-13561002" indexRange="9734321-9734364"/> <SegmentURL mediaRange="13561003-14117569" indexRange="13561003-13561046"/> </SegmentList> </Representation> <Representation id="4" mimeType="video/mp4" codecs="avc3.42c029" width="1280" height="720" frameRate="30000/1001" sar="1:1" startWithSAP="1" bandwidth="11600862"> <BaseURL>2_track1_dash.mp4</BaseURL> <SegmentList timescale="30000" duration="300300"> <SegmentURL mediaRange="907-15814327" indexRange="907-950"/> <SegmentURL mediaRange="15814328-31354701" indexRange="15814328-15814371"/> <SegmentURL mediaRange="31354702-44785112" indexRange="31354702-31354745"/> <SegmentURL mediaRange="44785113-58403737" indexRange="44785113-44785156"/> <SegmentURL mediaRange="58403738-60578352" indexRange="58403738-58403781"/> </SegmentList> </Representation> </AdaptationSet> </Period> </MPD>

2.3.7 DASH Support in MP4Box

ВопродолжениеследуваатдетализапочестокористенитефункциикоиседостапнивоMP4BoX:

-dashDuration:овозможувадасенаправиDASHсегментирањеодвлезнитефајлови,возависност

одспецифиранатадолжина,односновреметраењенаспецифичниотсегмент.

-outfilenameдефинирањенаимезагенериранатадатотеказаMPD.Можедасекористии

релативнапатека.Ситегенериранифајловиќебидатдодаденивоистиотдиректориумкадештое

иMPD.

-tmpdirnameспецифицирањенапривремендиректориумкадештоќесегенерираатпривремени

фајловикоидодекатраепроцесотнагенерирањенаMPDдатотекаата(стандардната“default”

привреманалокацијаепоставенавозависностодоперативниотсистем).

-profileNAMEгоспецифицираDASHпрофилот:onDemand,live,main,simple,full,покрајова

достапнисеидвапрофилиодDASH-IF:dashavc264:live,dashavc264:onDemand.

-rapпригенерирањетоприсилувасегментитедазапочнуваатодслучајноизбранивременски

интервали.Должинатанасекојсегментнемадабидедефиниранакакоштоедефинираново-

dashswitch-от.

-frag-rapСитефрагментизапочнуваатсослучајнистартниточки.Должинатанафрагментотнема

дабидедефиниранакаково-fragседодекавидеосодржинатанеемодификувана

повторно.(ISOBMFonly)

-segment-namenameсетираименасегментотзагенериранитесегменти.Аконеесетиран

(default),сегментитеседодаваатеденпоследругвоизлезниотдиректориум,исклучокедоколку

сеработизаliveпрофил,кадештоdefault-ниоттемплејтdash_%sекористен.Имињатана

сегментитеможатдасеконфигурираатсокористењенаподножествоодидентификаторитево

SegmentTemplate:$RepresentationID$,$Number$,$Bandwidth$какои$Time.

-segment-extnameјасетираекстензијатанасегментот.Стандарднаеm4s,додекапакnullе

идентификаторкојсекористикогаекстензијанеепотребна.

-base-urlstringсесетираглавнотоurlнаMPDлевел.Можедасекористиинаповеќеместакогае

потребнодасекористатповеќеURL-а.

-mpd-titlestringгосетираимето(MPDtitle).

-mpd-sourcestringпоставувањенаMPDsourceпараметарот

-mpd-info-urlstringпоставувањенаMPDinfourlпараметарот.

-cprtstringдодаваcopyrightпараметарвоMPDдатотеката.

-dash-ctxFILEзапишуваичитаDASHтајмингоддатотека(аконепостоидатотекатасекреира

нова).ОвааопцијагозачувувамоменталниоттајмингнаDASHпрезентацијата,какоидетализа

ситесегментиосвенпрвиотиницијализацискиот.

-dyamicдоколкусакамедакосристимединамичкиMPDтип,наместостатичен(најчестокогасе

користи-dash-live)

-mpd-refreshгоспецифициравреметраењетонакреирањенаMPDдатотеката

-subdurDURспецифицирањенамаксималнадолжинанавлезнатадатотека,соцелдабиде

обработенавоLIVEилиcontextмод.Ованеправипроменанадолжинатанасекојсегмент,туку

прекинувасообработкаведнашштомвреметраењетосумираногонадминеспецифираното.

-min-bufferTIMEсеспецифицираминималнотовременабаферирањеMPDminbuffertimeво

милисекунди.

-dash-scaleSCALEспецифицирањенавреметоза-dashи-fragизразенивоединициво

секунда(SCALEunitsperseconds).

-mem-fragsфрагментитенајпрвоќебидатпродуциранивомеморијапапослетоазапишаниво

фајл.

-sample-groups-trafзачувуваописзагрупите(traf).Доколкунееизбрананекојапосебнаопција,

стандардносеизбираизачувуваописзагрупитевоmoviebox.

-subsegs-per-sidxNслужизасетирањенасуб-сегменти,исекојгозапишувавоSIDXbox.Акое

избрана0,SIDXboxсекористизасекојсегментпоединечно.Акопакеизбран-1,SIDXboxнесе

користи.Воостанатитеслучаи,сегментеротќепакуваNсуб-сегментивоSIDX.

-single-segmentсекористикогаепотребенсамоеденсегментвосекојтагзарепрезентација.Кога

секористиonDemandпрофилот,овафукнцијаеавтоматскиизбрана.

-single-fileкогасакамедасегенерирапосебенфајлзасекојрепрезентацискитаг.

-bs-switchingMODEпретставуварежимнаbitstreamкојштоможедаедефиниранодследниве

типови:

§ inband(default):генерираиницилизацискисегментикомпатибилнисосекојрепрезентацискитаг

којсенаоѓавотаготзаадаптацискосетирањесокористењенанекојодследнивевидео

параметри(avc3,hev1)

§ merge:генерирањенасегментикомпатибилнисосекојрепрезентацискитагкојсенаоѓавотагот

заадаптацискосетирање,соспојувањенавидеопараметривоеденконфигурацискифајл.

§ multi:генерирањенаединеченсегментсоповеќеописи,односнозаписзасекојатрака(cfHbbTV

specification).

§ no:вослучајкоганесекористиbitstreamswitchingмодот.Модотавтоматскиевклученкогабарем

еденфајлеобработен

-no-frags-defaultгиисклучуваситезнаменца(flags)вофрагментите.

ВозможноедаседодадатвоMP4BoxнизаодISOBMFфајловикоисодржатразлична

мултимедијалнасодржина:MP4BoxќегенерираповеќеразличниадаптибилнисетовизаISOBMF.

Различнитевлезнифајловисефилтрираатвозависностоднивниотмултимедијалентип,јазики

кодек,сотоаседеталитесесобраниворазличниадаптацискисетови.

Датотекитеможедасодржатидополнителниаргументисопомошна:[OPT]наставка.Одредени

тракиможатдабидатадресираникакоединствениворепрезентацискиоттагсопомошна

фрагментите.Следнитефрагментииопцииседефинирани:

#trackID=NсекористиID-тонатраката

#videoсекористисамопрватавидеотракаодвлезнатадатотека

#audioсекористисамопрватааудиотракаодвлезнатадатотека

:id=NAMEгосетирарепрезентацискотоIDвоNAMEпараметарот.

:period=NAMEгосетирарепрезентацискиотпериодвоNAME.Повеќепериодиможатдасе

користат.ПериодитеќесепојавуваатвоMPDдатотекатавоистредоследкакоштосе

специфициранисооваафункција.

:BaseURL=NAMEгосетираBaseURLпараметарот.ЗаповеќеBaseURL-aепотребнодасеизврши

операцијатаповеќекратно.

:bandwidth=VALUEгосетирарепрезентацискиотbandwidthвоконкретнатавредност.

:xlink=VALUEсетиравредностзаxlinkзапериодкојштогосодржиовојелемент.

:duration=VALUEЈазголемувавредностанапериодотзапериоддаденвосекунди.Секористи

самокоганееспецифициранвлезнамултимедијалнадатотека.

:role=VALUEсетираулогаворепрезентацискиоттаг(cfDASHspec).Мултимедијалнатадатотекасо

различнаулогаприпаѓаворазличенадаптацискисет.

:desc_p=VALUEдодаваописнанивонапериодот.Вредностаморадабидесоодветно

форматиранакакоXMLелемент.

:desc_as=VALUEдодаваописнаAdaptationSetниво.Вредностаморадабидесоодветно

форматиранакакоXMLелемент.Двавлезнифајловисоразличнивредностиќебидат

експортираниворазличниAdaptationSetелементи.

:desc_as_c=VALUEдодаваописнанивонаAdaptationSet.Вредностаморадабидесоодветно

форматиранакакоXMLелемент.ВредностаеигнориранадодекасекреираатAdaptationSet

елементите.

:desc_rep=VALUEдодаваописвоRepresentationнивото.Вредностаморадабидесоодветно

форматиранакакоXMLелемент.ВредностаеигнориранадодекасекреираатAdaptationSet

елементите.

2.4 Media Source Extensions (MSE)

Слика2MSEмодел

2.4.1 Вовед

MediaSourceExtensions(MSE)еW3CспецификацијакојаштоовозможувапрекуJavaScriptдасепраќаатbytestreamsдомедијакодецитекоиседелодвебпрелистувачитевокоиеподдржанHTML5видеостандардот.Меѓудругитепозитивникарактеристики,овозможенаеиклиентскаимплементацијанабаферирањенамултимедијалнасодржина,односностримањесопомошсамонаJavaScriptбезкористењенадополнителнибиблиотеки.MSEекомпатибиленсоEncryptedMediaExtensions,нонетребадасемешаатовиедвепосебниспецификации,меѓудруготокајнитуеднаодовиеимплементациинеенеопходнокористењетонадругата.

NetflixобајвиексперименталнаподдршкавоЈуни2014закористењенаMSEопцијататазаемитувањенавидеосодржинавоSafariпрелистувачнаOSXYosemitebetarelease.

YouTubeзапочнасокористењенаMSEзаедносоHTML5плееротвоСептември2013година.

2.4.2 Goals

Овааспецификацијабешедизајнираназадагидостигнеследнивецели:

• ДаовозможиJavaScriptдаконструирамедијастримовинезависниодтоакакомултимедијалнатасодржинаепреземана.

• Даседефинирамеханизамкојќеобезбедимоделнаспојување,баферирање,какоитоадабидатопфатенисценаријазаадаптивностримање,додавањереклами,едитирањенавидеотои.т.н.

• МинимизирањенапотребатаодобработканамултимедијалнатасодржинасокористењенаJavaScript.

• Искористувањенакешмеморијатанапрелистувачотколкуштоеможноповеќе.

• Дефинирањенаусловизаформатотнаbytestreamспецификацијата.

• Небараподдршказакористењенаспецифиченмедијаформатилипакнекојкодек.

Спецификацијатадефинира:

• Пропишанооднесувањенакорисничкитеагенти,соцелдасеобезбедиинтероперабилностпомеѓукорисничкитеагентиивебапликациитеприпроцесирањенамултимедијалнасодржина.

• Пропишанооднесувањесоцелдасеовозможидругиспецификациидадефинираатмултимедијалниформатикоиможатдасекористатсоовааспецификација.

2.4.3 Browser support

MSEеподдржанодследнивеверзиинавебпрелистувачи:

• InternetExplorerодversion11наWindows8.1.(2013October)

• GoogleChromeодпочетокотна2013,какоинаAndroid.• Safari8наOSX.• Operaод9June2015.• Firefox42соподдршказаситесајтовиседо3Ноември2015,кадештоедостапнасамо

подгрупанафункционалностидостапнисамозаYouTube.FirefoxјадодадеистатаподгрупанафункционалностинаMSEзаYouTubeнаMacOSXзапочнувајкисоверзијаFirefox38.ИстатаподдршкаедодаденаизаFirefoxнаGNU+Linuxод6Ноември2015.

3 WebRTC

Слика3WebRTCлого

WebRTC(WebReal-TimeCommunication)претставуваAPIпочетнодефинираноодWorldWideWebConsortium(W3C),којштодефинираbrowser-to-browserкомуникација.Служизапреноснаподатоципрекукоиможидасеостваригласовениливидеоповиксокористењетонакамераимикрофон(voicecalling,videochat),какоиP2Pfilesharingбезупотребанаинтерниилиекстерниплагини.

3.1 History

Еднаодпоследнитенајголемипредизвициприградењетонаwebапликацииедасеовозможи

комуникацијапрекугласивидео:RealTimeCommunication(RTC).RTCсестремидабиде

едноставенприупотребавовебапликацијаистокаковнесувањенатекствоtextinput.Безова,

ниесмеограниченидавоведувменовииновативнирешенијавокоиштолуѓетоќебидатво

интеракција.

Историскигледано,RTCедостакомплексен,барапознавањавоаудиоивидеотехнологии.

ИнтегрирањетонаRTCтехнологијатасопостоечкасодржина,податоцикакоисервисиедоста

тешкаибарадоставреме,особенокогаепотребнодасеприлагодизадаработинаВеб.

Gmailвидеочатотстанапопуларенво2008,иво2011GoogleгововедеHangouts,којштого

користиGoogleTalkсервисот.GoogleгокупиGIPS,компанијакојашторазвимногукомпонентикои

сенеопходнизаRTC,какоштосекодецииисфрлувачинаехотовоаудиосигналот.Googleго

отворикодотразвиенодGIPSиговрзасостандардиверификуванивоIETFиW3Cсоцелдасе

обезбедииндустрискиконсензус.ВоМај2011,Ериксонјапоставипрватаимплементацијана

WebRTC.

WebRTCденесгиимплементираситеотворенистандардизаreal-time,plugin-freeвидео,аудиои

разменанаподатоци.Потребатаереална:

• МногуwebсервисивеќекористатRTC,носепотребнипреземањаинсталацијана

дополнителниапликациииплагини.ТоасеSkype,Facebook(којштокористиSkype)какои

GoogleHangouts(којштокористиGoogleTalkплагин).

• Преземањето,инсталирањетиажурирањетонаплагиниможедаиспаднекомплексно,склоно

енагрешкиисамиотпроцеседостанепопуларенизаморен.

• Плагинитеможатдабидатделикатнизаинсталација,дебагирење,тестирањеиодржување,

можеидабараиповрзувањесокомплекснаискапатехнологија.Секогашетешкодасе

убедатлугетодаинсталираатплагиниприупотребананекојсофтверзапрвпат!

ГлавнитепринципинаWebRTCпроектотетоаштоAPI-тотребадаимаотворенкод,даеслбодно

закористење(бесплатно),стандардизирано,вграденовоситевебпрелистувачикакоитоадае

поефикасноодситедосегакористетехнологииодовааобласт.

API-тосебазиранаработатанаWHATWG(WebHypertextApplicationTechnologyWorkingGroup).БешезамисленаимплементацијапрекуConnectionPeerAPI,инацртитезаоваапочетназамислабеакреираниодEricssonLabs.РаботнатагрупазаWebReal-TimeCommunicationsочекуваовааспецификацијадаевалуираидагидодефинираследниветочки:

• РезултатотодтековнитеизменивоRTCWEBгрупатанаIETFдадефинирасетнапротоколикои,штоќедефинираатдетализаreal-timecommunicationsнанивонапрелистувачи,водоумент.Бидејќинитуеденпротоколзасигнализацијанеенеопходен,најчестосекористиSIPпрекуWebsockets(RFC7118).

• Проблемизаприватносткоиќесејаваткогаќесеизложатлокалнитестримови.

• Техничкидискусиивогрупата,заимплементацијанаподаточнитеканали(datachannels)вопракса.

• Искустводобиенопрекуранатаимплементација.

• Повратнаинформацијаодостанатигрупиииндивидуи.

3.2 Design

ГлавнитекомпонентинаWebRTCвклучуваат:

• getUserMedia ,овозможувапрелистувачотдаимадостапностдокамера,микрофон,какоидаснима

содржинапрекунив

• RTCPeerConnection ,кадештосесетираатaudio/videoповиците,односносепоставувакомуникацијата

помеѓудваилиповеќеклиенти.

• RTCDataChannel ,кадештосеовозможувапрелистувачитедаразменуваатподатоцимеѓусебно(peer-to-

peer)

WebRTCAPI-тоистотакавклучувафункцијазастатистика:

• getStats ,овозможувавебапликациајтадапрепратилистаодстатистикивоврскасосесиитена

WebRTC.ОвиестатистичкиподатоцисеопишанивопосебенW3Cдокумент.

3.3 Benefits

WebRTCовозможуваповеќевидовинаrealtimeкомуникацијакакоаудио,видеоитекстпомеѓукорисниците.КористењетонаWebRTCносиразличнипридобивкизаразличнимаркетингаспекти.Закрајнитекориснициимадвеглавнипридобивки:

• Леснаиедноставнаупотреба:Real-timeкомуникацијатавозможноедафункционирабезпотребаодинсталацијанадодатниапликацииилиплагини.

• Безбедност:WebRTCприсилувакористењенаенкрипцијазадвататипанакомуникација,мултимедијалнаикомуникацијатазасигнаизирање.Сотоа,WebRTCобезбедувависоконивонабезбедносткакоивоситеостанатинајчестокористеникомерцијалнителефонскисистеми.

ЗакомпаниитеWebRTCможедаобезбедиуштеповќепридобивки

• Намалувањенатрошоци:Зачувувањенатрошоцизаtoll-freetelephonenumberвоcallцентрите

• Богатакомуникација:Овозможувањенакомуникацијатапомеѓукорисницитесовидеоитекстпоракибезпотребаодинсталацијанапосебниапликацииисервери.

• Непрекинатакомуникација:Гичувакорисницитенавебстранатаивоистовремевклучувагласовениливидеокомуникацискиканалсодругикорисници.

• Безбедност:Комуникацијатаебезбеднапомеѓукорисниците,бидејќиприпреноснаподатоцитесекористатстандардитезаенкрипција/декрипција.

Заоператорите,WebRTCможедополнителнодагипровајдираследнивеновиможности:

• Мобилнателефонија:ПотпирајќисенаWebRTCтехнологијата,сервиснитепровајдериможатдаимовозможатнакорисницитедапристапатдоVoIPсервисбезкористењенапосебниидодатниапликации.

• Хостиранисервиси:СопоставувањенаWebRTCgatewayкрајнитекориснициќебидатвоможностдапристапатдоSIP(SessionInitiationPrtocol)хостираннаPBX(PrivateBranchExchange)какоиcallцентритебезпотребаодпроменанаовиесервиси.

• WebRTCкакоуслуга:СличнокакоPBXсервисите,сервиснитепровајдериможатдахостираатWebRTCGatewaysвоименакомпанијата.WebRTCповицитенаменетидонекојакомпанијасепроцесираниодWebRTCGatewayнасервиспровајдерот.ДојдовнитеWebRTCповициможатдабидаттрансвериранивоSIPповициирутираникрајнодокомпаниите.Компанијатанемадаимапотребадапромениништовоинфраструктурата,бедијќиќеоперирасамосоSIPповици

3.4 Support

WebRTC е поддржан во следниве прелистувачи.

• DesktopPC

• MicrosoftEdge21

• GoogleChrome23

• MozillaFirefox22

• Opera18

• Android

• GoogleChrome28

• MozillaFirefox24

• OperaMobile12

• ChromeOS

• FirefoxOS

• iOS

• Bowser

• Blackberry10

• Browser

ОдСептември2015,InternetExplorerиSafariсеуштенемаатnativeподдршказаWebRTCноистатаевклученавоновиотпрелистувачнаMicrosoft,Edge.НеколкуплагиниседостапнизадајапокријатработатанаWebRTCвоовиепрелистувачи.

3.5 Concerns

ВоЈануари2015,TorrentFreakрепортирадекапрелистувачитекоиподдржуваатWebRTCстрадаатодсериознибезбедноснипроблемикоиштојадоведувавопрашањеибезбедностанаVPN-tunnels,содозволувањетоначитањенавистинскатаIPaddress.IPадреситенесевизуелноприкажанивоконзолатанаbrowser-от,итиенесеблокираатсопомошначестокористенитеплагиниadblocking/privacyplugins(онлајнследењеодмаркетингкомпании).

WebRTCможедабидевклучениисклученкакокомпонентавоFirefoxсопомошнаконфигурацискиотпараметар"media.peerconnection.enabled"во about:config ,адодекадеталнитепараметризаWebRTCсетинзитесенаоѓаатпод about:webrtc .WebRTCнеможедабидеисклучен

водесктопверзијатанаGoogleChrome,ноистотоможедасенаправисокористењенаплагин.

3.6 Architecture

WebRTCимовозможуванаразвивачитенавебапликациидаразвиваатмултимедијалниапликациикоикомуницираатвореалновреме,(видеочат)навебпрелистувач,безкористењенапосебниплагини,инсталацијанадополнителниапликации.Главнатацеледасеовозможиизградбанаеднаплатформакојаштоќеработинаголембројнапрелистувачинаразличниоперативнисистеми.

Генералноархитектуратаизгледакаконаследнаваслика:

Слика4WebRTCархитектура

Целатаархитектураеподеленагенералнонадваслоеви:

1.РазвивачитенапрелистувачисезаинтересиранизазаWebRTCC++слојоткакоидеталитезаснимањеипродуцирањеаудиовизуелниподатоци.

2.РазвивачитенаВебАпликацииќесезаинтересиранизаWebAPIслојот.

• YourWebAppВеббазиранаапликацијасовидеоиаудио,какоиможностзаразменанапоракиовозможениодВебAPIзакомуникацијавореалновреме.

• WebAPIAPIкоештоќебидекористеноодстрананаразвивачитенасофтвернаапликацииодтипотнавебвидеочатапликации.

• WebRTCNativeC++APIAPIслојкојовозможувалеснаимплементацијананаWebAPIфункциите.

• Transport/SessionСесискитекомпонентисеизградениврзбазанареискористувањенакомпонентитеодlibjingle,

безкористењенаилиобврзувањезакористењенаxmpp/jingleпротоколот.

• RTPStackМреженстекзаRTP,theRealTimeProtocol.

• STUN/ICEКомпонентакојадозволуваповицитедакористатSTUNиICEмеханизмисоцелдасевоспоставиконекцијапрекуразличнитиповинамрежи.

• SessionManagementАбстракцијанасесискислој.Овдесеоставаимплементацијатадабиденаправенаодапликацискиотразвивачнаапликациајта.

• VoiceEngineVoiceEngineпретставуваframeworkзаработасоаудиосодржината,односнопреносназвукодзвучнатакартичканамрежа.

• iSAC/iLBC/OpusiSAC:ШирокопојасенисуперширокопојасенаудиокодекзаVoIPистримањенааудиоподатоци.iSACкористи16kHzили32kHzфрекфенцијанасемплирањесоадаптибиленипроменливbitrateод12до52kbps.

iLBC:теснопојасенкодекзаговорзаVoIPистримањенааудиоподатоци.Користи8kHzфрекфенцијанасемплирањесоbitrateод15.2kbpsза20msрамкикаки13.33kbpsза30msрамки.ДефинниранисеодIETFRFCs3951о3952.

Opus:Поддржуваконстантнииваријабилниbitrateод6kbit/sдо510kbit/s,големинанарамкитеод2.5msдо60ms,какоиваријабилнисемплирањаод8kHz(со4kHzbandwidth)до48kHz(со20kHzbandwidth,кадештоцелиотопсегначовековиотгласовенсистемможедабидерепродуциран).ДефинирансоIETFRFC6176.

• NetEQforVoiceДинамиченjitterbufferкојсодржиимеханизамнаприкривањенагрешкикоинастаналекаконапримергубењенапакетиисл.Држилатентностнанајнискоможнониво,додекапакгоодржуваквалитетотназвукнанајвисокоможнониво.

• AcousticEchoCanceler(AEC)

TheAcousticEchoCancelerесофтверкојштовореалновремеготргаехотовоаудиосигналот,односносигналоткојштоепродуциранназвучникотданесепрефрлинамикрофоноткојсекористиистовремено.

• NoiseReduction(NR)TheNoiseReductionпретставувасофтверскакомпонентазапроцесирањенасигналодкојштосетргаатдополнителнизвуцикоидоаѓаатвопозадинаодмикрофонот,напримеркакозвукод

вентилаторсвирањеисл.

• VideoEngineVideoEngineпретставуваframeworkзапреноснавидеосигнал,продуциранодкамератадомрежата,какоиодмрежатадасенаправиприказнаекран.

• VP8ВидеокодекодWebMProject.ДоброприлагодензаRTCкомуникација,какоиштоеидизајниранзапомалалатентност.

• VideoJitterBufferДинамиченJitterBufferзавидео.Помагапригубењенапакитедагипополнинедостатоцитеодсигналотсоцелштоеможнопомалкудасеодразинаквалитетотнавидеото.

• ImageenhancementsНапример,гитрганечистотиитенасликатапродуцираниодвебкамерата.

3.7 Real-time communication without plugins

Замислетекогавашиотсмартфон,телевизорикомпјутерможатдакомуницираатпрекузаедничка

платформа.Замислетедекаелеснодаседодадевидеокомуникацијакакоиpeer-to-peer

споделувањенаподатоцивовашатавебапликација.ТоаевизијатанаWebRTC.

3.8 Where are we now?

WebRTCмоменталносекористивоповеќеапликациикакоWhatsApp,FacebookMessenger,

appear.inкакоиплатформикакоTokBox.Истотакапостоииексперименталнадостапностна

WebRTCвоiOSBrowser.WebRTCистотакаеинтегрирансоWebKitGTK+какоиQtnative

апликациите.

MicrosoftгидодадеMediaCaptureиStreamAPI-јатавоEdgeпрелистувачот.

WebRTCесоставенодтриапија:

• MediaStream(akagetUserMedia)

• RTCPeerConnection

• RTCDataChannel

getUserMediaедостапенвоChrome,Opera,FirefoxиEdge.

RTCPeerConnectionедостапенвоChrome(наdesktopкакоизаAndroid),Opera(десктопкакоина

последниотAndroidBeta)истотакаинаFirefox.Збор-двазаименувањата:посленеколку

итерации,RTCPeerConnectionеимплементиранодChromeиOperaкако

webkitRTCPeerConnectionаодFirefoxкакоasmozRTCPeerConnection.Останатитеименувањаи

имплементациисепрогласенизазаостанати(depricated).Когастандардитеипроцеситеќесе

стабилизираат,префикситеќебидатскратени.

W3CStandard Chrome Firefox

getUserMedia webkitGetUserMedia mozGetUserMedia

RTCPeerConnection webkitRTCPeerConnection mozRTCPeerConnection

RTCSessionDescription RTCSessionDescription mozRTCSessionDescription

RTCIceCandidate RTCIceCandidate mozRTCIceCandidate

Табела1ИменувањанаWebRTCкомпонентите

RTCDataChannelеподдржанвоChrome,OperaиFirefox.

3.9 A word of warning

Требадасебидедонекојамераскептичендоколкусенаиденатерминот'supportsWebRTC'.

ЧестопрекуоваможедасеалудирадекаgetUserMediaеподдржан,нонеиситедругиRTC

компоненти.

3.10 My first WebRTC

КомплетнаWebRTCапликацијаепотребнодагисодржиследнивефункционалности:

• Дапреземастримодaudio,videoилидругвиднаподатоци.

• ДаземемрежниинформациикакоштосеIPадресаипорти,идагиразменисо

останатитеWebRTCклиенти(попознатикакоpeers)давоспоставиконекција,дурии

прекуNATsиfirewalls.

• Дакоординиракомуникација(signaling)соцелдасерепортираатгрешкикакоидасе

иницираилизатворисесија.

• Разменанаинформациивоврскасомултимедијалнитеподатоцикакоидеталитеза

клиентите,какоштоерезолуцијаикодеци.

• Комуницирањепрекустримањенааудио,видеоилидругвиднаподатоци.

• Задасеостварикомуникацијаистримањенаподатоци,WebRTCгиимплементира

следнивеAPI-ја:

• MediaStream:добивапристапдоподатоцизастримање,какоштосекорисничка

камераимикрофон.

• RTCPeerConnection:аудиоивидеоповици,сообјектизаенкрипцијаименаџментна

проток.

• RTCDataChannel:peer-to-peerкомуникацијазаразменанаподатоци.

3.11 MediaStream (aka getUserMedia)

MediaStreamAPI-тогисинхронизирастримовитезавидеоиаудио,напримерстримотпреземан

одкамераистримотпреземанодмикрофонимаатсинхронизираниаудиоивидеотраки.(Може

дасенапоменеидекаMediaStreamтракитенесеедноисносо<track>елементот,којшто

претставуванештососемаразлично)

НајлесниотначинзадасеразбереMediaStreamедасепогледененекојапостоечка

имплементација:

1. ДоколкувоChromeилиOpera,гоотворимеследноводемо:

https://webrtc.github.io/samples/src/content/getusermedia/gum

2. ЈаотворимеВебконзолата.

3. Јаследимеstreamпроменливата,којаевоглобаленопсег.

СекојMediaStreamимаinput,којштоможедабидеMediaStreamгенериранод

navigator.getUserMedia(),какоиoutput,којштоможедабидепроследендоvideoelementили

RTCPeerConnection.

getUserMedia()можедапреземетрипараметри:

• constraintsobject.

• successcallbackкојштодоколкуеповикануспешноекреиранMediaStream.

• failurecallbackкојштодоколкуеповикансеслучиланекаквагрешка.

СекојMediaStreamималабела,напримеркако'Xk7EuLhsuHKbnjLWkW4yYGNJJ8ONsgwHBvLQ'.Низа

одMediaStreamTracksсевраќаприповикнафункциитезааудиоgetAudioTracks()какои

getVideoTracks()завидео.

Запретходноспоменатиотпример(бидејќинеедостапноаудио)иземајќивопредвиддекавеб

камератаеконектирана,stream.getVideoTracks()битребалодавратинизаодедна

MediaStreamTrackтракакојаштогопретставувастримотодкамерата.СекојMediaStreamTrackима

тип('video'или'audio'),илабела(напр.'FaceTimeHDCamera(Built-in)'),ипретставуваеденили

повеќеканали,билозааудиоиливидео.Воовојслучај,имасамоеднавидеотракаинемааудио

трака,нолесноедасевизуелизираисценариосоповеќетраки,например,четапликација

којаштоземастримодпреднакамера,заднакамераимикрофон.

ВоChromeиOpera,URL.createObjectURL()методотгоконвертираMediaStreamвоBlobURLкојшто

можедабидесетиранкакоsrcатрибутвоvideoelement.(ВоFirefoxиOpera,srcатрибутотнаvideo

елементотможедабидесетирансамостојноодстримот.)СедоверзијаM25,Chromium-

базиранитепрелистувачи(ChromeиOpera)овозможуваатаудиоподатоцитеодgetUserMediaда

бидатпроследенидоaudioилиvideoелемнти(нодасеземевопредвиддекамедијаелементот

ќебидепригушенвоовојслучај).

getUserMediaможедабидекористенкаковлезенјазолзаWebAudioAPI-то:

function gotStream(stream) { window.AudioContext = window.AudioContext || window.webkitAudioContext; var audioContext = new AudioContext(); // Креирање на AudioNode од стримот var mediaStreamSource = audioContext.createMediaStreamSource(stream);

// Конектирање до дестинацијата mediaStreamSource.connect(audioContext.destination); }

navigator.getUserMedia({audio:true}, gotStream);

Chromium-basedапликациитеиекстензиитеможатистотакадагоинтеркорпорираат

getUserMedia.ДодавањетонаaudioCaptureи/илиvideoCaptureпривилегиитевоманифестот

овозможувадозволатазабарањенаовозможувањетонапермисситедасепојавиидабиде

одобреносамоеднаш,завременаинсталацијата.Понатамукорисникотнемадабидепрашан

повторнозадаодобрикористењенакамераилимикрофонодапликацијата.

ДодекапакзастранитекоикористатHTTPS:одобрувањетозакористењенакамера/микрофоне

потребносамоеднаш.Потоавоинфонапрелистувачотќееприкажанаiсостојбаза“Always

Allow”.

Истотака,ChromeсеочекувадагоисфрлиодупотребаHTTPпристапотзаgetUserMedia()накрајот

на2015.ВеќеможедасезабележипредупредувањеприкористењенаgetUserMediaнаHTTP

странанаChromeM44.

ТуканамератаедасеовозможиMediaStreamдастримабилокаквасодржина,несамосодржина

одкамераилимикрофон.Оватребадаовозможиистримањенаподатоциоддиск,илипак

податоциоддругиизворикаконапримерсензориилидругивлезниуреди.

БитноедасезабележидекаgetUserMedia()морадасекористинасервер,нонеилокалноодфајл

системот,бидејќиPERMISSION_DENIED:1грешкаќебидеприкажана.

getUserMedia()делувадостапомоќновокомбинацијасоJavaScriptAPIsибиблиотеки:

• WebcamToyеphotoboothапликацијакојакористиWebGLсоцелдададеефектинасликикои

можатдабидатсподелуваниилизачуванилокално.

• FaceKatе'facetracking'играизграденаврзheadtrackr.js.

• ASCIICameraкористиCanvasAPIзадагенерираASCIIслики.

3.11.1 Constraints

ConstraintsсеимплементиранивоChrome,FirefoxиOpera.Прекунивможедасесетираат

најразличнипараметри,каконапримервидеорезолуцаијазаgetUserMedia()и

RTCPeerConnectionaddStream()повиците.Туканамератаедаседадеподдршкаизадруги

параметрикакоштосеaspectratio,facingmode(преднаилизаднакамера),бројнафрејмови,

ширинависинаисл..

Примерзареференцаhttps://webrtc.github.io/samples/src/content/getusermedia/resolution/.

Дополнително:getUserMediaconstraintsсесетираатгенералнонанивонапрелистувач,патака

пременитесеафектуираатнаситетабови.Доколкусесетиранеочекуванавредност,заистатасе

појавувадескриптивнагрешкаодтипот:

navigator.getUserMedia error:

NavigatorUserMediaError {code: 1, PERMISSION_DENIED: 1}

3.11.2 Screen and tab capture

Chromeапликациитеистотакаовозможуваатсподелувањена'video'одедентабилинанивона

целиотдесктопсопомошнаchrome.tabCaptureиchrome.desktopCaptureAPI-ја.

ИстотакавозможноеидасекористискриноткаковлеззаMediaStreamвоChromeсокористење

назасегаекперименталнотоchromeMediaSourceconstraint.Битноедасезаблежидека

снимањетонаскринотбараHTTPSиможедабидекористеноводевелопментфазаилидасе

активирасопременанафлегнанивонапрелистувач.

3.12 Signaling: session control, network and media information

WebRTCкористиRTCPeerConnectionзакомуникацијаодноснопренесувањенасодржинатаза

стримањепомеѓупрелистувачите(peers),ноистотакаепотребенмеханизамкојштоќеја

координиракомуникацијатаиќепраќаконтролнипораки,процесотепознаткакосигнализирање

(signaling).МетодитенасигнализирањенеседефенираниодWebRTC:сигнализирањетонеедел

одRTCPeerConnectionAPI-то.

Развивачитенаапликацииможедаизбератсвојпротоколзакомуникацијасоконтролнитепораки

,какоштосеSIPилиXMPP,какоисекојатехнологијакојаштонудидвонасочнакомуникацијa.

Придефинирањетонамеханизамзасигнализирање,постојаттритипанаинформациикоишто

можедасепраќаат:

• Контролнипоракизаодржувањенасесијата-даиницијализираатилизатвораткомуникација

илидарепортираатгрешки.

• Мрежнакомуникација-нанадворешниотсветдасеприкажеIPадресатаипортот.

• Мултимедијалниможности-коикодециирезолуцииможатдабидаткористениво

прелистувачот,исокоипараметрипрелистувачотможедакомуницира?

Разменатанаподатоцисопомошнасигнализирањетоморапретходнодазавршиуспешнопред

дасеоствариврскатазаостварувањенаpeer-to-peerстриминг.

Например,дазамислимедекаAliceсакадакомуницирасоBob.Вопродолжениееприкажан

примерпреземенодWebRTCW3CWorkingDraftдокументот,којштоимазацелдагоотслика

процесотнасигнализирање.Вокодотсесметадекапостоимеханизамзасигнализирање,

поставенвоcreateSignalingChannel()методот.ИстотакатребадасезабележидекавоChromeи

Opera,RTCPeerConnectionседефинирасопоставувањенапрефикси.

var signalingChannel = createSignalingChannel(); var pc; var configuration = ...; // start(true) вредност за да се иницира повик function start(isCaller) { pc = new RTCPeerConnection(configuration); // праќање на ice candidates до друг клиент pc.onicecandidate = function (evt) { signalingChannel.send(JSON.stringify({ "candidate": evt.candidate })); }; // еднаш штом некој стрим пристигне, постави remote video element pc.onaddstream = function (evt) {

remoteView.src = URL.createObjectURL(evt.stream); }; // земи локален стрим, прикажи го во локалниот видео елемент navigator.getUserMedia({ "audio": true, "video": true }, function (stream) { selfView.src = URL.createObjectURL(stream); pc.addStream(stream); if (isCaller) pc.createOffer(gotDescription); else pc.createAnswer(pc.remoteDescription, gotDescription); function gotDescription(desc) { pc.setLocalDescription(desc); signalingChannel.send(JSON.stringify({ "sdp": desc })); } }); } signalingChannel.onmessage = function (evt) { if (!pc) start(false); var signal = JSON.parse(evt.data); if (signal.sdp) pc.setRemoteDescription(new RTCSessionDescription(signal.sdp)); else pc.addIceCandidate(new RTCIceCandidate(signal.candidate));

};

Најпрво,AliceиBobразменуваатмрежниинформации.(изразот'findingcandidates'референцира

допроцесотнанаоѓањеинтерфејсипортсопомошнакористењенаICEframework-от.

1. AliceкреираRTCPeerConnectionобјектсопомошнаonicecandidatehandler.

2. Овојметодсеповикуваведнашштомнекојкандидатедостапен.

3. AliceпраќасериализиранакандидатпоракадоBob,сопомошнадефинираниот

сигнализацискиканал,којштогокористатдветестрани,WebSocketилинекојдругмеханизам.

4. КогаBobдобивакандидатпоракаодAlice,сеизвршуваaddIceCandidate,соцелдаседодаде

новкандидатподметодотза“remotepeerdescription”.

WebRTCклиентите(попознатикакоpeers,AliceиBob)истотакаепотребноидагиразменат

деталитеза“localandremoteaudioandvideomedia”,какоштосерезолуцијаикодеци.

Сигназилизирањетозаразменанаконфигурацискиинформациисеобавувасоofferи

answerфункциитесопомошнаSessionDescriptionProtocol(SDP):

1. AliceгоизвршуваcreateOffer()методот.Callbackаргументотепоставенво

RTCSessionDescription:(localsessiondescription)

2. Воcallback-от,Aliceсамостојногосетирасвојотlocaldescriptionсокористењена

setLocalDescription()методотапотоаистиотsessiondescriptionсепрепраќадоBobсопомошна

сигнализацискиотканал.БитноедасезабележидекаRTCPeerConnectionнеовозможува

праќањенадетализакандидатиседодеканесесетираатsetLocalDescription():овае

верифицирановиJSEPIETFdraftдокументот.

3. Bobгосетираdescription-отпратенодAliceигосетиракајсебеподremotedescriptionсо

користењенаusingsetRemoteDescription()методот.

4. ПотоаBobгоактивираRTCPeerConnectioncreateAnswer()методот,прекукојгопоставива

remotedescription-отдобиенодAlice,приштоlocalsession-отќебидегенерираниќеодговара

сонејзиниот.ОткакоповикотзаcreateAnswer()еизвршеннаредносепроследувалокалнниот

RTCSessionDescription:BobгосетираlocaldescriptionиигопрепраќанаAlice.

5. КогаAliceќегодобиеBob'ssessiondescription-от,истиотгопоставувакајсебекакоremote

descriptionсопомошнаsetRemoteDescription.

6. Ping!

RTCSessionDescriptionобјектитевопринципсеblobsкоиштосериализираниизгледааатвака:

v=0 no=mozilla...THIS_IS_SDPARTA-42.0a1 2745272417442659269 0 IN IP4 0.0.0.0 ns=- nt=0 0 na=fingerprint:sha-256 5B:9D:40:50:2E:E0:F2:58:87:E8:02:F3:96:8B:67:76:9A:8F:C4:AB:E3:42:7A:4D:74:C4:09:24:96:05:F7:EA na=ice-options:trickle na=msid-semantic:WMS * nm=application 9 DTLS/SCTP 5000 nc=IN IP4 0.0.0.0 na=sendrecv na=ice-pwd:8695d2002a8cdf9f79112e146590328d na=ice-ufrag:8ef2934b na=mid:sdparta_0 na=sctpmap:5000 webrtc-datachannel 256 na=setup:actpass na=ssrc:2630960550 cname:{e2aaa485-48ba-4e31-beb4-6db0857ec0c0}n\

Разменатанамрежниимултимедијалниинформацииможедабидекомплетиранасимултано,но

дватапроцесиморадазавршатпреддазапочнеаудиоивидеостриминготпомеѓуpeer-овите.

offer/answerархитектуратаопишанапретходнонакраткосеименувасоJSEP,JavaScriptSession

EstablishmentProtocol.

Слика5JSEPАрхитектура

Веднашштомпроцесотзасигнализирањезавршиуспешно,податоцитеможатдабидатстримани

директноpeertopeer,помеѓуповикувачотиповикуваниот—илипакдоколкуовајпроцесе

прекинатодгрешка,започнувапроцесотнастримање.

3.13 RTCPeerConnection

RTCPeerConnectionпретставуваWebRTCкомпонентакојаштообезбедуваефикаснаистабилна

комуникацијазастримањепомеѓуповеќеpeer-ови.

ВопродолжениеепретставенаWebRTCархитектуратаприкажаноодулоганаRTCPeerConnection.

Какоштоможедасезабележи,зеленитекомпонентисепокомплексинте

Слика6WebRTCАрхитектура

ОдJavaScriptперспектива,главнонештоштотребадасерасчистиетоадекаRTCPeerConnectionги

покриваситекомплексниделовиприкажанинадијаграмот.Кодецитеипротоколитекористениод

WebRTCвршатобемнаработасоцелдајанаправатreal-timeкомуникацијатавозможна,дурии

прекупонеквалитетнитеконекции:

• Прикривањенаизгубенипакети

• Пригушувањенаехото

• Прилагодувањеспоредбрзинатанамрежата

• Динамичнобаферирање

• Автоматскаконтролаирегулација

• Пригушувањенашумипречки

• Чистењенаслики

Претхосниотпримеримазацелдајаприкажиедноставностанакомуникацијатаприкористење

наWebRTCкојагопокриваделотзасигнализирање.Следуваатпримеривокоисеопишанидве

различниWebRTCапликации:

• прватаимазацелдаопишеедноставнокористењенаRTCPeerConnection;

• додекавторатадапрезентиракомплетнавидеочетапликација.

3.14 What is signaling?

WebRTCовозможуваpeertopeerкомуникација,нонаWebRTCсепакмуепотребенисервер:

• Заклиентитедаразменатметаподатоцисоцелдасекоординиратвокомуникацијата–овасенарекува(signaling)–илипроцеснасигнализирање.

• Дасесправатсомрежнитеадреснипреведувачи(NATs)иfirewalls.

Сигназилирањетоепроцеснакоординацијаприкомуникацијата.КоганекојаWebRTCапликација

епотребнодавоспоставиповик('call'),обетестраниповикувачотиповикуваниотепотребнода

разменатинформации:

• Сесискиконролнипоракикоисекористатзаотпочнувањеилизатварањенакомуникација.

• Поракизагрешка.

• Мултимедијалнаметадата,какоштосекодеци,пропусенопсегкакоитиповинамултимедија.

• Податоцисоклучови,потребнизавоспоставувањенабезбеднаконекција.

• Мрежниподатоци,каконапримерIPадресаипорткојаќебидеприкажанананадворешниот

свет.

Овајпроцеснасигнализирањетребадаобезбедипраќањенапоракикакоипримањенапораки

досекојклиент.ОвајмеханизамнееимплементиранвоWebRTCAPI-јата,потребноесамостојно

дасеизградиодстрананаонојкојјаразвивапликацијата.Вопродолжениеќебидатобјаснети

некоинасокизаградењенасервисзасигнализирање.

3.14.1 Why is signaling not defined by WebRTC?

Задасемаксимизиракомпатибилностсовеќепостоечкитетехнолобии,методитеипротоколите

засигнализирањенесеспецифицираниодстрананаWebRTCстандардите.Истиотеотфрленод

странанаJSEP(JavaScriptSessionEstablishmentProtocol):

Целтасигнализирањетодасеоставинастрананаапликацијатасетемеливрзтоадекаразличен

типнаапликакцииможатдаработатсоразличнипротоколинапримерSIPилиJingleпротоколиза

сигнализирање,илиимапотребадасенаправинештоспецифишчнонанивонаапликација.

JSEP'sархитектуратаистотакаотфрласостојбатиназачувувањеприсигнализирање,односноне

постоиstate-machine.Доколкубиималоstate-machineтоабибилопроблематчно,напримеркога

странатабисепрелоадиралабисеизгубилеситеподатоцизасигнализирање.Затоа,состојбатана

сигнализирањесечуванапосебенсервер.

Слика7JSEPАрхитектура

JSEPгиобврзуваклиентитедаразменатподатоципрекуofferиanswer.Овааразменанаподатоци

сеодвивапрекуSessionDescriptionProtocol(SDP),иизгледавака:

v=0 o=- 7614219274584779017 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio video

a=msid-semantic: WMS m=audio 1 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:W2TGCZw2NZHuwlnf a=ice-pwd:xdQEccP40E+P0L5qTyzDgfmW a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=mid:audio a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9c1AHz27dZ9xPI91YNfSlI67/EMkjHHIHORiClQe a=rtpmap:111 opus/48000/2

…

WebRTCедизајнирантакаштоможедабидеедитиранпреддабидефиналнопосавенкакоlocal

илиremotedescription.Например,preferAudioCodec()функцијатавоapprtc.appspot.comсекористи

засетирањенаdefault-кодекотиbitrate-от.

3.14.2 RTCPeerConnection + signaling: offer, answer and candidate

RTCPeerConnectionпретставуваделодWebRTCкојштосекористизакреирањенаконекција

помеѓуpeer-овитезапонатамошнаразменанааудиивидеоподатоци.

ЗаиницијалзирањенаовојпроцесRTCPeerConnectionимадвезадачи:

• Дагииспитамоменталнитесостојбинаpeer-от,какоштосерезолуцијаиможникодеци.Ова

семетаподатоципратенипрекуofferиanswerмеханизмот.

• Земањенапотенцијалнамрежнаадресазавоапликацискатамашина,попознатакако

кандидат(candidate).

Веднашштомоваалокалнакомуникацијаќебидекомплетирана,морадабидеразменетасо

помошнамеханизмотзасигнализацијасоостанатиотpeer.

ДоколкупретпоставимедекаAliceсеобидувадагоповикаEve.Вакабиизгледаланивната

комуникација:

• AliceкреираRTCPeerConnectionобјект.

• Aliceкреираoffer(anSDPsessiondescription)сопомошна

RTCPeerConnectioncreateOffer()методот.

• AliceпоставуваsetLocalDescription()сосоодветниотoffer.

• Aliceгоспремаoffer-отипрекумеханизмотзасигнаизацијаигопрќанаEve.

• EveповикуваsetRemoteDescription()соoffer-отдобиенодAlice,соованејзиниот

RTCPeerConnectionесвесензаконфигурацијатанаAlice's.

• EveповикуваcreateAnswer(),ипрекууспешниотcallbackдеталитесепраќаатдоlocalsession

description:Eve'sanswer.

• Eveгосетираовојanswerкакосвојсопствен-localdescriptionсопомошна

setLocalDescription()методот.

• EveпотоагокористимеханизмотзасигнализирањеиигопраќаодговоротназатнаAlice.

• AliceгосетираEve'sanswer-откакоremotesessiondescriptionсопомошна

usingsetRemoteDescription()методот.

AliceиEveистотакаепотребнодаразменатинформациивоврскасомрежата.Терминот'finding

candidates'референцирадопроцесвокојштоепотребнодасепронајдатмрежниинтерфејсии

портовипрекукористењенаICEframework-от.

• AliceкреираRTCPeerConnectionобјектсопомошнаonicecandidateфункцијата.

• Функцијатаеповиканакогаимадостапникандидати.

• Прекуфункцијата,AliceпраќаподатоцисокандидатидоEve,прекумеханизмотза

сигнализирање.

• КогаEveдобивакандидатскапоракаодAlice,сеправиповикaddIceCandidate(),соцелдасе

додадекандидатпрекуremotepeerdescription.

JSEPподдржуваICECandidateTrickling,којштоовозможуваинкрементаторнокреирањена

кандидатиодповикувачотдоповиканиотpeerпослекреирањетонаиницијалниотoffer,сошто

процесотнасетирањенаконекцијатаќезапочнеипредпристигнувањенаситекандидати.

3.14.3 CodingWebRTCforsignaling

ВопродолжениееприкажанпримеродW3Ccodeкојштосумарногоопишувапроцесотна

сигнализација.Вокодотепретпоставеннекојмеханизамнасигнализација,SignalingChannel.

var signalingChannel = new SignalingChannel(); var configuration = { 'iceServers': [{

'url': 'stun:stun.example.org' }] }; var pc; // повикување на start()методот за иницијализација function start() { pc = new RTCPeerConnection(configuration); // праќање на ice candidates до останатите клиенти pc.onicecandidate = function (evt) { if (evt.candidate) signalingChannel.send(JSON.stringify({ 'candidate': evt.candidate })); }; // тригер за започнување на комуникацијата – креирање на offer pc.onnegotiationneeded = function () { pc.createOffer(localDescCreated, logError); } // веднаш штом стримот пристигне, прикажи го на remote video елементот. pc.onaddstream = function (evt) { remoteView.src = URL.createObjectURL(evt.stream); }; // земи локален стрим, прикажи го во локално и спреми истиот да биде препратен navigator.getUserMedia({ 'audio': true, 'video': true }, function (stream) { selfView.src = URL.createObjectURL(stream); pc.addStream(stream); }, logError); } function localDescCreated(desc) { pc.setLocalDescription(desc, function () { signalingChannel.send(JSON.stringify({ 'sdp': pc.localDescription })); }, logError); } signalingChannel.onmessage = function (evt) { if (!pc) start(); var message = JSON.parse(evt.data); if (message.sdp) pc.setRemoteDescription(new RTCSessionDescription(message.sdp), function () { // доколку се добие некој offer, потребен ни е answer да биде генериран if (pc.remoteDescription.type == 'offer')

pc.createAnswer(localDescCreated, logError); }, logError); else pc.addIceCandidate(new RTCIceCandidate(message.candidate)); }; function logError(error) { log(error.name + ': ' + error.message);

}

3.14.4 Peer discovery

Зателефонскитеразговириимаметелефонскиброевиипрефикси.Заonlineвидеочети

праќањетонапораки,потрбенниеидентитетврзкојможемедадефинирамесесија-конекција.

НаWebRTCапликациитеимепотребенначинпрекукојклиентитеќекомуницираатиќебидат

известенидекаепотребнозапочнувањенаразговор.

PeerdiscoveryмеханизмитенеседефинираниодстрананаWebRTC.Процесотепотребнодабиде

едноставенистокакопраќањенаемаилилипраќањенаURL,завидеочетапликацииподдржани

одtalky.io,tawk.comиbrowsermeeting.com,одвасдоволноесамодапоканитепријателипреку

споделувањеналинк.ИстотакапостоииексперименталнаимплементцијанаправенаодChrisBall

serverless-webrtcкојаовозможувавоспоставуањенаWebRTCповикиразменанаметаподатоци

прекукојидабилоmessagingserviceкаконапримерIM.

3.14.5 How can I build a signaling service?

Протоколитеимеханизмитезасигнализирањекакоштовеќенапомнавмепретходнонесе

дефинираниодстрананаWebRTC.Какоидаезасекојапосериознаапликациниепотребени

додатенсерверзаразменанапоракитезасигнализацијапомеѓуклиентите.Зажал,веб

апликацијатанеможедирекнодаоствариконекцијасосоговорникотсокојсакамедастапимево

контакт.

Среќнаоколностетоаштопоракитезасигнализацијаседостамали,инајчестосепренесуваат

предпочетокотнаразговорот.Притестирањесоapprtc.appspot.comиsamdutton-nodertc.jit.suпри

конекцијазавидеочет,просечносепраќаатоколу30–45поракипрекусерверотзасигнализирање

коиненадминуваатвкупнаголеминанад10kB.

Покрајтоаштоимамалипобарувањазапропусниотопсег,WebRTCприпраќањена

сигнализирачкипоракинекористимногумеморијаприпроцесирање,бидејќитиесамосе

препраќааткакопоракисомаласодржинавоврскасосесискитеподатоци(напримеркакотоа

коиклиентисеконектирани).

Механизмотзасигнализацијакојсекористизаразменанаподатоцизасесијата,можеистотака

дасекористиинаапликацисконивобидејќиистиотпретставувасамосервисзапраќањена

пораки.

3.14.6 Pushing messages from the server to the client

Сервисотзасигнализацијаморадабидедвонасочен,односнодаобезбедикомуникацијаклиент

досерверисервердоклиент.Двонасочнатакомуникаицјанеможедасеодвивапрекукласичната

комуникацијапрекуHTTPклиент/серверrequest/responseмоделот,носепакимаинекоинемногу

популарнирешенијакакоштоеlongpolling.Истотаканизгодинитеразвиенисеимногусервиси

одтипотна(pushdata)коиработатнаwebserverкакоинавебапликациивовебпрелистувач.

Истотака,вопоследновремеимамногуимплементациинаEventSourceAPI.Тоаовозможува

праќањеидетектирањена'server-sentevents',односноподатоцитеодвебсервердабидат

пратенидовебпрелистувачсопомошнаHTTP.EventSourceедизнајнирансамозаеднострана

комуникација,новокомбинацијасоXHRможедагипокриепотребитезаразменана

сигнализирачкипораки.Сигнализирачкиотсервиспраќапоракиодповикувачот,сопоможнаXHR

повик,исопомошнаEventSourceпраќапоракидоповикуваниотклиент.

WebSocketееднооднајприроднитерешенија,дизајниранзацелоснадвостранакомуникација

клиент-серверисерверклиент(поракитеможатдабидатпраќанииводветенасокивоисто

време).ЕднаодпредноститенасигнализирачкиотсерверграденсопомошнаWebSocketили

Server-SentEvents(EventSource)етоаштоback-end-отзаовиеAPI-јаможедабидеизграденод

различниwebframework-ци,прилагодливесонајчестокористенитејазици,какоштосеPHP,

PythonиRuby.

Над¾одвебпрелистувачитекористатWebSocket,илиштоедостаповажно,ситевеб

прелистувачикоиобезбедуваатподдршказаWebRTCистотакаподдржуваатWebSocket,какона

десктоптакаинамобилниуреди.TLSепотребнодасекористиприситеконекции,заданесе

појаватнекриптиранипоракивооптек,какоидасередуцираатпроблемитесоproxytraversal.

Табела2ВебпрелистувачикоикористатWebSocket

Механизмотзасигнализирањевоapprtc.appspot.comWebRTCвидеочетапликацијатаенаправен

сопомошнаGoogleAppEngineChannelAPI,којштокористиCometтехники(longpolling)зада

овозможисигнализирањепомеѓуаплиакцијатаиклиентот.

Слика8apprtcinaction

Истотакаевозможнодасенаправимеханизамзасигнализирањесокористењенаajaxповикод

странанаклиентот,ноовасосебеносииголембројнанепотребниповицидосерверот,којштосе

особенопроблематичнидоколкусепраќаатодмобиленуред.Дурииповоспоставувањетона

сесијата,клиентитеепотребнодаправатповторноповицидосерверотзадапровератдали

сесијатабилапреќинатаоднекојдругклиент.

3.14.7 Scaling signaling

ИакосервисотзасигнализирањекористирелативномалbandwidthкакоиCPUпоклиент,

серверитекоигоовозможуватсигнализирањетозапопуларниапликацииморадабидатспремни

даопслужатголембројнакандидати,односнодаобработатголембројнапоракидобиениод

различнилокации,совисокстепеннаконкурентност.WebRTCапликациитекоидобиваатвисок

trafficимсепотребнисерверизасигнализацијакоиштоможатдасесправатсовисокload.

Постојатголембројнаопциикоиштоовозможуваатвисокобемнаработакакоивисоки

перформансидоколкуговклучатследново:

• eXtensibleMessagingandPresenceProtocol(XMPP),попознатподиметоJabber:протоколизграден

врзбазанаинстантпоракикоиштоможатдабидатискористенизасигнализирање.

ИмплементацијатанасерверотвклучуваejabberdиOpenfire.JavaScriptклиенти

какоStrophe.jsкористатBOSHдаовозможатдвонасочнакомуникацијаg,нопорадиразлични

причиниBOSHнееефикасенвоистамеракакоиWebSocket,ипорадиповеќепричининеможе

добродасесправидоколкуимаповеќекорисници

• БиблиотекитесоотворенкодкакоZeroMQ,OpenMQ.NullMQгокористиZeroMQконцептотзавеб

платформите,користатSTOMPprotocolпрекуWebSocket.

• КомерцијалнитеcloudmessagingплатформикоикористстWebSocketкакоштосе

Pusher,KaazingиPubNub.(PubNubистотакаимаAPIforWebRTC.)

• КомерцијалнитеWebRTCплатформикакоvLine.

3.14.8 Building a signaling service with Socket.io on Node

Вопродолжениееприкажанпримеркадештовебапликацијакористисигналингмеханизам

изграденсопомошнаSocket.ioнаNodeJS.ДизајнотнаSocket.ioовозможуваедноставноградење

насервисизаразменанапораки,апокрајтоаSocket.ioпрактичноедостадобарзакористењесо

WebRTCбидејќиимавграденконцептна'rooms'.Овајпримернеедизајнирандасекористи

некадеивопродукција,ноработидостадоброапликациисорелативномалбројнакорисници.

Socket.ioкористиWebSocketанудииподдршказаAdobeFlashSocket,AJAXlongpolling,AJAX

multipartstreaming,IframeиJSONPpolling.Можедасепортиранаразличнисервери,носечини

декаенајдоброприлагодензаNodeJSверзијата,којаштоеопишанаивопримеротво

продолжение.

ВопримеротнемаописзаделотнаWebRTC.Примеротсодржисамоелементисокојопишува

какодасекористимеханизамнасигнализацијавоеднавебаплиакција.Прекуследењена

конзолатаможеидасевидатидеталикоганекојсеприклучвананекојroomиразменувапораки.

Описзаклиентот,index.html:

<!DOCTYPE html> <html> <head> <title>WebRTC client</title> </head> <body> <script src='/socket.io/socket.io.js'></script> <script src='js/main.js'></script> </body>

</html>

JavaScriptдатотекатаmain.jsреференциранавоклиентот:

var isInitiator; room = prompt('Enter room name:'); var socket = io.connect(); if (room !== '') { console.log('Joining room ' + room); socket.emit('create or join', room); } socket.on('full', function (room){ console.log('Room ' + room + ' is full'); }); socket.on('empty', function (room){ isInitiator = true; console.log('Room ' + room + ' is empty'); }); socket.on('join', function (room){ console.log('Making request to join room ' + room); console.log('You are the initiator!'); }); socket.on('log', function (array){ console.log.apply(console, array);

});

Комплетнатасерверскаапликација:

var static = require('node-static'); var http = require('http'); var file = new(static.Server)(); var app = http.createServer(function (req, res) { file.serve(req, res); }).listen(2013); var io = require('socket.io').listen(app); io.sockets.on('connection', function (socket){ // функција за логирање на пораки пратени до клиент function log(){ var array = ['>>> Message from server: ']; for (var i = 0; i < arguments.length; i++) { array.push(arguments[i]); } socket.emit('log', array); }

socket.on('message', function (message) { log('Got message:', message); socket.broadcast.emit('message', message); }); socket.on('create or join', function (room) { var numClients = io.sockets.clients(room).length; log('Room ' + room + ' has ' + numClients + ' client(s)'); log('Request to create or join room ' + room); if (numClients === 0){ socket.join(room); socket.emit('created', room); } else if (numClients === 1) { io.sockets.in(room).emit('join', room); socket.join(room); socket.emit('joined', room); } else { // максимум два клиенти socket.emit('full', room); } socket.emit('emit(): client ' + socket.id + ' joined room ' + room); socket.broadcast.emit('broadcast(): client ' + socket.id + ' joined room ' + room); });

});

(Несепотребнипосебнипознавањазаnode-staticзастартувањенаовојпример,едноставносамо

гоправисерверотпоедноставен)

Застартувањенаовааапликацијалокално,потребенниеинсталиранNodeJS,socket.ioиnode-

static.NodeJSпотребноесамодабидепреземениинсталиранодофицијалнатастраница,достае

брзоиедноставно.Додеказаинсталацијанаsocket.ioиnode-static,потребноесамодасе

стартуваNodePackageManagerвотерминалидасеизвршатследниведвекоманди:

npm install socket.io

npm install node-static

Додекапакзастартувањенасерверот,потребноедассеизвршиследнавакоманда:

node server.js

Наредноепотребнодасеотворивебпрелистувачсолокацијанаlocalhost:2013.Потоапотребное

дасеотвориуштеедентабсоистатаадреса,изадаседетектиратоаштосеслучувавопозадина

можедасеотвориконзола.

Каковидабилопристапдакористимезасигнализирањепотребноедасеизградисервиссличен

нагоренаведениот.

3.14.9 Using RTCDataChannel for signaling

СервисотзасигнализирањеенеопходензаиницирањенаWebRTCсесија.Какоидае,кога

конекцијаќеевоспоставенапомеѓудваpeer-ови,RTCDataChannelможе,теоретски,дасекористи

какосигнализацискиканал.Оваможедајаредуциралатентностазасигнализацијабидејќи

поракитесепроследуваатдиректноипомагаприредуцирањенатрансверотнаподатоципреку

сигналингсерверот.

3.14.10 Signaling gotchas

• RTCPeerConnectionнемадастартувадаприбиракандидатиседодекаsetLocalDescription()не

сеповика.ОваезапишаноивоJSEPIETFdraftдокумантот.

• ТребадасекористиможностаTrickleICE,дасеповикаaddIceCandidate()колкуштоеможно

побрзно,односнокогаќепристигнепрвиоткандидат.

3.14.11 Readymade signaling servers

Доколкунемапотребадасекреирасопствениспецифиченсерверзасигнализација,воовој

мементнарасполагањесеследнивесервери,коиштокористатимплементацијакакоштое

прикажанавопретхосниотпримерзаSocket.io,ииститесеинтегриранисоWebRTCклиентски

библиотеки:

• webRTC.io–еденодпрвитебиблиотекизаWebRTC.

• easyRTC-full-stackWebRTCпакет.

• Signalmaster-сигнализацискисерверкреиранзадакористиSimpleWebRTCJavaScript

клиентскабиблиотека.

Истотакадоколкунесакамедапишеменикаковкод,достапнисекомплетникомерцијални

WebRTCплатформикакоvLine,OpenTokиAsterisk.

3.14.12 Signaling security

ЕнкриптирањетоезадолжителнозаситеWebRTCкомпоненти.Какоидае,механизмитеза

сигнализирањенеседефинираникакостандардвоWebRTC,паоставеноенакорисникотштоќе

одлучитука.Аконекојпреземесигнализцискипораки,можедајазапресесијата,прерутира

конекции,илипакдапромениилиинјектирадругасодржина.

Најбитенфакторзабезбедностприсигнализирањеекористењенабезбеднипротоколи,HTTPSи

WSS(i.eTLS),којштогарантирадекапоракитенеможедабидатпресретнатиидекриптирани.Исто

такапотребноеидасеводисметкаданесенаправиbroadcastдоситеклиентикоганекојапорака

енаменетасамозадоеденклиент.

3.14.13 After signaling: using ICE to cope with NATs and firewalls

Заразменанаподатоци,односносигнализирањевоWebRTCапликациитекористатисерверза

посредство,додеказаразменанамултимедијалнитеподатоциоткакосесијатаќеевоспоставена,

RTCPeerConnectionовозможувадиректнаконекцијапомеѓуклиентите,peertopeer.

Вопоедноставенсвет,секојWebRTCклиентбиималуникатнаадресакојаштоможедабиде

разменетасодругиклиентиидасеодвивакомуникацијадиректно.

Слика9СветбезNATиFirewall

НовореалностаречисиситеуредисенаоѓаатпозадиеднаилиповеќеслоевинаNAT,некоиимаат

антивируснипрограмикоиштоблокираатспецифичнипортовиипротоколи,додекапакимногусе

позадипроксиикорпоративниfirewall-и.Firewall-отиNATможатдабидатимплементираниод

еденуред,каконапримерwifirouter.

Слика10Реаленсветзакомуникацијапомеѓудваpeer-ови

WebRTCапликациитеможатдакористатICEframeworkсоцелдапреминатпрекукомплексноста

штојасодржимрежнатаимплементацијавореалниотсвет.Соцелдасеовозможиова,

апликацијатаморадапратиICEserverURL-адоRTCPeerConnection,какоштоеобјаснатово

продолжение.

ICEсеобидувадагопронајденајдобриотпатзадасеконектираатповеќеpeer-ови.Гипробува

ситеможнисценаријапаралелноигоизбиранајефикаснотокоефункционира.ICEнајпрвосе

обидувадавоспоставиконекцијасокористењенаадресатанауредотhostaddressдобиенаод

уредотзакомуникацијанаоперативниотсистем(networkcard).Акоовојобиденеуспешен(штое

случајзауредикоисепозадиNAT)ICEобезбедуванадворешнаадресасопомошнакористењена

сопомошнаSTUNсервер,доколкуиовајобидебезуспешен,собраќајотсерутирапрекуTURN

server.

Содругизборови:

• STUNсерверотсекористизадобивањенаекстернимрежниадреси.

• TURNсерверотсекористизадапрерутирасообраќајакодиректниот(peertopeer)несе

комплетира.

СекојTURNсерверподдржуваиSTUN:TURNсерверотеиSTUNсерверсододадена

функционалностзапримањеипрепраќањеподатоци.ICEистотакаправикопијана

комплексностанаNATпоставките.Вореалноста,NATможедапобаранештоповеќеодсамојавни

адресаипорт.

URL-атазаSTUNи/илиTURNсерверитесеспецифициранивоWebRTCапликацијатаво

конфигурацијатазаiceServers,којштосеипрваргументприсетирањенаRTCPeerConnection

конструкторот.Напримерзаapprtc.appspot.comвредноститеизгледаатвака:

{ 'iceServers': [ { 'url': 'stun:stun.l.google.com:19302' }, { 'url': 'turn:192.158.29.39:3478?transport=udp', 'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=', 'username': '28224511:1379330808' }, { 'url': 'turn:192.158.29.39:3478?transport=tcp', 'credential': 'JZEOEt2V3Qb0y27GRntt2u2PAYA=', 'username': '28224511:1379330808' } ]

}

ШтомRTCPeerConnectionгиимаовиеинформации,ICE“магијата”сеслучуваавтоматски.

RTCPeerConnectionгокористиICEframework-отзаодредувањенанајдобритепатекипомеќу

колиентите,игикористииSTUNиTURNсерверитекогаепотребно.

3.14.14 STUN

NATпровајдираIPадресакојаштосекористивоприватналокалнамрежа,ноовааистаадресане

можедасекористиијавно.БезјавнаадресанемаможностWebRTCpeer-овитедакомуницираат.

ЗадасенадминеовојпроблемсекористиSTUNсерверот.

STUNсерверотживеенастранатанајавнодостапнитеинтернетадреси,соедноставназадача,да

провериIP:portзасекојповиккојдоаѓа(заапликацијанакојаповикотепратенпозадиNAT)ија

враќатааадресаназадпрекуодговорот(response).Содругизборови,аплиакцијатакористиSTUN

серверзадаоткриеIP:portодперспективанајавнокористењенаадресите.Овојпроцес

овозможуваWebRTCpeer-отдадобиејавнаадресакојаќејакористизасебе,ипотоаќејапрати

истатадодругpeerсопомошнакористењенамеханизамзасиганлизирање,соцелдаобезбеди

директенлинк.(Вопракса,различниNATработатнаразличниначини,аможедапостојати

поовеќеNATслоја,новопринциптоаеедноисто)

STUNсерверитенемаатзазадачадаработатанекојакомплексназадачаилипакдазачувуваат

некоиподатоци,порадитоаSTUNсерверсонемногуголемиперформансиможедаопслужи

голембројнаклиентииповици.

МногуWebRTCповициуспешносевоспоставенисопомошнаSTUN:86%,базирајќисена

webrtcstats.com.

Слика11КористењенаSTUNсерверзадобивањенајавнаIP/portадреса

3.14.15 TURN

RTCPeerConnectionсеобидувадавоспоставидиректнакомуникацијапомеѓуpeer-овитепреку

UDP.Акооваенеуспешно,RTCPeerConnectionсепрефрланаTCP.Акоиоваенеуспешно,TURN

серверможедасекористикакокрајнаопција.

TURNсерверитеимаатјавнаадреса,порадитоаиститеможатдабидатпристапениодклиентии

коисенаоѓаатпозадиfirewall-иилиproxies-ја.TURNсерверитеимаатралативноедноставена

задача,дапрепрататстрим,нозаразликаодSTUNсерверите,тиеработатсотрансверирањена

големаколичинанаподатоци.

Слика12STUN,TURNandsignaling

НапретходнатасликаможедасезабележидекаакоSTUNкомуникацијатаенеуспешна,

комуникацијатасепренасучувапрекукористењенаTURNсервер.

3.14.16 Deploying STUN and TURN servers

Затестирање,GoogleкористијавенSTUNсервер,stun.l.google.com:19302,којштоекористеиод

apprtc.appspot.com.ЗапродукцискиSTUN/TURNсервис,сепрепорачувакористењенаrfc5766-

turn-server;кодоткојсекористизаSTUNиTURNсерверитеедостапенна

code.google.com/p/rfc5766-turn-server,којштоистотакаводиидонеколкуартикливокоисе

објасноваатидетализаинсталацијатаиподесувањенасерверот.Истотакадостапнаеи

виртуелнасликазакористењенаамазонсервиситеVMimageforAmazonWebServices.

АлтернативанаTURNсерверотеиrestund,достапенеистотакаиsourcecodeкојможидасе

поставинаAWS.ВопродолжениесенаоѓаатиинструкциизасетирањенаrestundнаGoogle

ComputeEngine.

3.14.17 Beyond one-to-one: multi-party WebRTC

Лесноедасезамислисценариокадестримингбисеодвивалдвонасочноone-to-one.Например

видеоконференцијапомеѓугрупинаколеги,илијавеннастанкадештоимаеденпрезентери

неколкумилиониклиентикоигопрататпрезентирањето.

WebRTCапликацијатаможедакористиповеќеRTCPeerConnectionsприштосекојendpointсе

конектирадодругиотendpointодносносекористиmeshконфигурација.Овајпристапсекористи

кајtalky.io,иработизачудувачкидоброзамалбројнакорисници.

Слика13Fullmeshтопологија

Алтернативно,WebRTCаплиакцијатаможедаизберееденendpointкојштоќебидедистрибуиран

доситедруги,прекусвезда(star)конфигурација.Истотакаевозможнодасенаправииспоствен

механизамзаредистрибуирањенастримингот

ОдChrome31иOpera18,MediaStreamодеднаRTCPeerConnectionконекцијаможедабиде

користенакаковлеззадруга.Оваовозможувапофлексибилнаархитектура,бидејќиовозможува

вебапликацијадасесправисорутирањеидаодлучикојpeerдасеконектира.

3.14.18 Multipoint Control Unit

ПодобраопцијазаапликациикадештиимаголембројнакориснициекористењенаMultipoint

ControlUnit(MCU).Оваесерверкојштоработикакомостпрекукојможедасепренесува

мултимедијалнасодржинадоголембројнакорисници.MCUsможедасесправисоголембројна

различнирезолуции,кодецикакоивременскирамкипривебконференции,даовозможи

transcoding,даовозможипрепраќањенастрим,даспоиаудиоивидеосигнал.Заповицисо

повеќекорисницисејавуваатповеќетиповинапроблемиодтипоткакодасеприкажатповеќе

видеосигнали,какодасеспојатситеаудиосигналиодкорисниците.ДалиCloudplatform-итекако

штосеvLineистотакасестрематдагооптимизираатсообраќајотзарутирање.

ЕднорешениеедасенабавиMCUхардверскипакет,илипакдасенаправисопствен.

Слика14CISCOMCUуред

НеколкусофтверскирешенијасоотворенкодседостапникакоMCUваријанта.На

пример,Licode(претходнопопознаткакоLynckia)провајдираотворенкодзаMCUзаWebRTC;

OpenTokгоимаMantis.

3.14.19 Beyond browsers: VoIP, telephones and messaging

СтандардизираниосновинаWebRTCовозможуваатдасевоспоставикомуникацијапомеѓу

WebRTCапликациитевовебпрелистувачиосонекојадругаплатформа,напримеркакотелефон

илисистемзавидеоконференција.

SIPпретставувапротоколзасигнализацијакојштосекористиодстрананаVoIPивидео

конференцискитесистеми.ЗадасеовозможикомуникацијапомеѓуWebRTCвебаплиакцијатаи

SIPклиентоткаковидеоконференцискисистем,наWebRTCмуепотрбенпроксисерверза

медијаторствоприсигнализирањето.Сигнализирањетоморадаминувапрекуgateway,ноеднаш

штомистотоевоспоставено,SRTPсообраќај(видеоиаудио)можедасенасочидиректноодносно

peertopeer.

PSTN,односноPublicSwitchedTelephoneNetwork,гопретставувапреминотоданалогниво

дигиталнисигналикогавопрашањеекомуникацијатасотелефони.ЗаразговорипомеѓуWebRTC

вебапликацииителефони,сообраќајотморадапоминуванизPSTNgateway.

Голембројнаапликации,библиотекииплатформигокористатWebRTCзакомуникацијасо

останатиотсвет:

• sipML5:JavaScriptSIPclientсоотворенкод

• jsSIP:JavaScriptSIPбиблиотека

• Phono:opensourceJavaScriptплагинphoneAPI

• Zingayaphonewidget

• Twilio:гласовниитекстуалнипораки

• Uberconference:конференции

ИстотакаsipML5девелоперитеизградијаиwebrtc2sipgateway.TethrиTropoдемонстрирааa

frameworkfordisastercommunicationsкојштосеносивокуфер,сокористењенаOpenBTScellда

овозможикомуникацијапомеѓумодернитетелефонииWebRTC.Телефонскакомуникацијабез

користењенамобиленоператор!

3.14.20 RTCPeerConnection without servers

КодоткојследувапретставуваимплементацијанаедентабWebRTCdemoat

https://webrtc.github.io/samples/src/content/peerconnection/pc1,којштосимулиралокаленаи

далечинскаRTCPeerConnectionконекција,какоисподелувањеналокалнаидалечинскавидео

конекцијаприкажананаеднастрана.Вопринциповааимплементацијанеможеданајдепримена

вореалноста(повикувачотиповиканиотдасенаеднастрана)новоголемамерајаобјаснува

можнатаупотребанаRTCPeerConnectionAPI-то,бидејќиRTCPeerConnectionможедаразменува

податоциидиректнобезупотребанаметодизасигнализирањеинаразменанапораки.

Воовојпример,pc1претставувалокаленpeer(повикувач)иpc2претставувадалечинскиpeer

(повиканиот).

3.14.21 Caller

1. КреирањенановаRTCPeerConnectionконекцијаидодавањенастримотодgetUserMedia():

// servers is an optional config file (see TURN and STUN discussion below) pc1 = new webkitRTCPeerConnection(servers); // ...

pc1.addStream(localStream);

2. Креирањенаofferисетирањенаlocaldescriptionзаpc1какоизаremotedescriptionнаpc2.Ова

можедаекомплетиранодиректновокодотбезупотребанаметодзасигнализација,бидејќии

дватаповикувачотиповикуваниотсенаистастрана.

pc1.createOffer(gotDescription1); //... function gotDescription1(desc){ pc1.setLocalDescription(desc); trace("Offer from pc1 \n" + desc.sdp); pc2.setRemoteDescription(desc); pc2.createAnswer(gotDescription2);

}

3.14.22 Callee

1. Креирањенаpc2,иприкажувањенастримотодpc1иприкажувањеподвидеоелементот:

pc2 = new webkitRTCPeerConnection(servers); pc2.onaddstream = gotRemoteStream; //... function gotRemoteStream(e){ vid2.src = URL.createObjectURL(e.stream);

}

3.14.23 RTCPeerConnection plus servers

Вореалниотсвет,наWebRTCмусепотребниисервери,употребатаедостаедноставна,возможни

сеследнивесценарија:

• Корисницитесесамооткриваатнамрежатаиразменуваатреалниподатоцикаконапример

имиња.

• WebRTCклиентскитеапликации(peers)разменуваатмрежниинформации.

• Peer-овитеразменуваатиподатоцизамултимедијалнатасодржинакаковидеоформати

резолуцијанавидеото.

• WebRTCклиентскитеапликациипотребноедагипреминатситеNATgatewaysиfirewalls.

Вопревод,наWebRTCмусепотребничетиритипанаserver-sideфункционалност:

• Откривањенакориснициимегусебнакомуникација.

• Сигнализирање.

• NAT/firewallпробивање.

• Сервери(Relay)вослучајpeer-to-peerкомуникацијатаданеуспее.

NATtraversal,peer-to-peernetworking,какоиситепотребниусловизакреирањенасерверска

апликацијакојакористиоткривањеналокациииовозможувамеханизамзасигнализирањесево

склопнаовааточка.ДоволноеSTUNпротоколот,какоинеговатаекстензијаTURNсекористатод

ICEframework-отсоцелдасеовозможинепреченакомуникацијапомеѓуконекциите

RTCPeerConnection,какоидасеизбегнатситемрежниспецифичностикоигиносатсосебе

мрежнитеимплементации.

ICEеframeworkзаконектирањенаpeer-ови,напримеркакодвавидеоклиенти.Иницијално,ICE

сеобидувадагиповрзеpeer-овитедиректно,сонајмаламожналатентност,сопомошнаUDP.Во

овојпроцес,STUNсерверитеимаатсамоедназадача:даовозможатpeer-откојсенаоѓапозади

NATданајдејавнаадресаипорт.(GoogleдаванарасполагањенеколкуSTUNсервери)

Слика15наогањенакандидатизаконекција

AkoUDPенеуспешен,ICEпробувадавоспоставиконекцијапрекуTCP:најпрвоHTTP,потоаHTTPS.

Акодиректнатаконекцијаенеуспешна,порадиNATtraversalиfirewalls,ICEвопогонвпуштаи

посредник(relay)TURNсервер.Содругизборови,ICEнајпрвоќекористиSTUNсоUDPсоцелда

остваридиректнаконекцијапомеѓуpeer-овите,акоовајобиденеуспешен,ќесенаправинов

обидзавоспоставувањенаконекцијапрекуTURN(relay)сервер.Терминот'findingcandidates'

алудиранапроцесотнапронаоѓањемреженинтерфејсипорт.

Слика16WebRTCпатекинаконекција

3.14.24 A simple video chat client

Примероткојследувагоопишувамеханизмотзасигнализирањеупотребенприимплемнтацијата

наapprtc.appspot.com.

Тукаобјаснатоечекорпочекоркакобиизгледалоградењетонаеднавидеочетапликација,вклучувајќиедноставенсерверзасигнализацијапровајдиранодSocket.ioкојеактивираннаNodeserver.

МестозапроверканаработатанаWebRTC,комплетносовклучувањенасигнализирањекакои

NAT/firewalltraversalсокористењенаSTUNсервер,епримеротнаapprtc.appspot.com,којвосебе

вклучувавидеочетапликација.Воапликацијатавграденаеиadapter.jsкомпонентакојатребада

сесправисоразличнитеименувањанаRTCPeerConnectionиgetUserMedia()имплементацијатана

различнитевебпрелистувачи.

Кодотедоброопишан,азаредоследотнанастанитеможедасеследилогирањетонаконзола.Во

продолжениесеопишанидеталите.

3.14.25 What's going on?

Примеротзапочнувасоактивирањенаinitialize()функцијата:

function initialize() { console.log("Initializing; room=99688636."); card = document.getElementById("card"); localVideo = document.getElementById("localVideo"); miniVideo = document.getElementById("miniVideo"); remoteVideo = document.getElementById("remoteVideo"); resetStatus(); openChannel('AHRlWrqvgCpvbd9B-Gl5vZ2F1BlpwFv0xBUwRgLF/* ...*/'); doGetUserMedia();

}

Вредноститезаroomпроменливвата,какоивредностанатокеноткористенаприopenChannel(),се

провајдираниодстрананасаматаапликација.

СледниовкодгииницијализирапроменливитезаHTMLвидеоелементитекоиштоприкажуваат

видеостримовиодлокалнатакамера(localVideo)какоивидеоодстримотнадалечинскиот

клиент(remoteVideo).resetStatus()едноставносамосетирастатуснапорака.

ФункцијатаopenChannel()госетирасигнализирањетопомеѓуWebRTCклиентите:

function openChannel(channelToken) { console.log("Opening channel."); var channel = new goog.appengine.Channel(channelToken); var handler = { 'onopen': onChannelOpened, 'onmessage': onChannelMessage, 'onerror': onChannelError, 'onclose': onChannelClosed }; socket = channel.open(handler);

}

Засигнализирање,овојпримеркористиGoogleAppEngineChannelAPI,којштоовозможува

праќањенапоракипомеѓуJavaScriptклиентите.

Слика17Архитектуранаapprtcвидеочетапликацијата

Воспоставувањетонаканалотфункциониранаследниовначин:

1. КлиентотAгенерирауникатноID.

2. КлиентотAбаратокенодAppEngine,игопраќасвоетоID.

3. AppEngineотвораканаликреиратокенпобарањетоприменоодклиентскотоID.

4. AppEngine-отгопраќатокенотдоклиентотA.

5. КлиентотAотвараsocketислушанаотворениотканал.

Слика18GooglechannelAPI–поставувањенаканал

Праќањетонапоракафункциониранаследниовначин:

1. КлиентотBправиповикдоAppEngine.

2. AppEngineappгопрепуштабарањетодоканалот.

3. КаналотјарутирапоракатадоClientA.

4. Активиранеonmessagecallback-отнаКлиентотА.

Слика19GooglechannelAPI–праќањенапорака

Одгоренаведенотоможедасезаклучиследново:сигналнитепоракисепраќаатвозависностод

механизмоткојштогоизбираонајкојјасоздаваапликацијата:Механизмотзасигнализирањенее

специфициранодWebRTC.ChannelAPIекористенвопоследниотпример,носекакодексе

достапниидругиметодинапримерWebSocket.

ПослеповикотназаopenChannel(),getUserMedia()функцијатаеповиканавоinitialize(),истата

проверувадалипрелистувачотподдржуваgetUserMediaAPI.Акосееворед,onUserMediaSuccess

повикотекомплетиран:

function onUserMediaSuccess(stream) { console.log("User has granted access to local media."); // Call the polyfill wrapper to attach the media stream to this element. attachMediaStream(localVideo, stream); localVideo.style.opacity = 1; localStream = stream; // Caller creates PeerConnection. if (initiator) maybeStart();

}

Овојсегментодкодотовозможувавидеосодржинатаодлокалнатакамерадабидеприкажанаво

localVideoелементот,сокреирањенаobject(Blob)URLипоставувањенаистотовоsrcатрибутот.

СтримотеистотакасетиранкаковредностзаlocalStream,којштонаредноедостапенина

далечинскиоткорисник.

Воовојмомент,initiatorфлеготесетиранна1(иостануватакасетирандодеканесепрекине

сесија)порадитоаmaybeStart()еповикана:

function maybeStart() { if (!started && localStream && channelReady) { // ... createPeerConnection(); // ... pc.addStream(localStream); started = true; // Caller initiates offer to peer. if (initiator) doCall(); }

}

Оваафункцијакористимеханизамзасправувањесоповеќеасинхрониповици

(callbacks)maybeStart()функцијатаможедаеповиканаоднеколкуразличнифункции,нокодотќе

сеизвршисамокогаlocalStreamќеедефинираниchannelReadyфлеготќеесетираннаtrueикога

комуникацијатанемадаевеќестартувана.Порадитоа,акоконекцијатасеуштенеевоспоставена,

акостримотедостапен,иакоканалотеспремензапраќањенасигналнипораки,конекцијатае

креиранаипратенадолокалниотвидеострим.Веднашштомовојчекорсе

комплетира,startedфлеготесетираннаtrue,папорадиоваконекцијатанемадабиде

прекреиранаповторно.

3.14.25.1 RTCPeerConnection: making a call

createPeerConnection(),повиканаодmaybeStart(),еместотокадештозапочнувавистинската

употребанаWebRTC:

function createPeerConnection() { var pc_config = {"iceServers": [{"url": "stun:stun.l.google.com:19302"}]}; try { // Create an RTCPeerConnection via the polyfill (adapter.js). pc = new RTCPeerConnection(pc_config); pc.onicecandidate = onIceCandidate;

console.log("Created RTCPeerConnnection with config:\n" + " \"" + JSON.stringify(pc_config) + "\"."); } catch (e) { console.log("Failed to create PeerConnection, exception: " + e.message); alert("Cannot create RTCPeerConnection object; WebRTC is not supported by this browser."); return; } pc.onconnecting = onSessionConnecting; pc.onopen = onSessionOpened; pc.onaddstream = onRemoteStreamAdded; pc.onremovestream = onRemoteStreamRemoved;

}

Најосновноедасесетираконекција,сокористењенаSTUNсервер,преку

onIceCandidate()callbackфункцијата.Сотоасесетираниситепотребнинастани:когасесијатае

отворенаилиевопроцеснаконекција,икоганадворешенстримедодаденилиотфрлен.Во

принцип,ситегоренаведениметодилогираатсамопораки—исклучувајќиго

onRemoteStreamAdded(),кадештосесетираатдеталитезаremoteVideoелементот:

function onRemoteStreamAdded(event) { // ... miniVideo.src = localVideo.src; attachMediaStream(remoteVideo, event.stream); remoteStream = event.stream; waitForRemoteVideo();

}

КогаcreatePeerConnection()еповиканаодстрананаmaybeStart(),инициранеповикзакреирање

наofferиистиотеиспратендоповиканиотpeerодстрананаповикувачот:

function doCall() { console.log("Sending offer to peer."); pc.createOffer(setLocalAndSendMessage, null, mediaConstraints);

}

Процесотнакреирањенаofferесличенкаковоонојкадештонебешекористенсигналингсервер,

новопродолжение,испратенаепоракадодалечинскиотpeer,сосериализиранaсодржинаод

локалниотSessionDescription.ОвојпроцесеовозможенодsetLocalAndSendMessage():

function setLocalAndSendMessage(sessionDescription) { // Set Opus as the preferred codec in SDP if Opus is present. sessionDescription.sdp = preferOpus(sessionDescription.sdp); pc.setLocalDescription(sessionDescription); sendMessage(sessionDescription);

}

3.14.25.2 Signaling with the Channel API

onIceCandidate()callbackфункцијатаеизвршенаоткакоRTCPeerConnectionеуспешнокреирансо

createPeerConnection(),носиинформациизакандидатитекакоштотиедоаѓаат:

function onIceCandidate(event) { if (event.candidate) { sendMessage({type: 'candidate', label: event.candidate.sdpMLineIndex, id: event.candidate.sdpMid, candidate: event.candidate.candidate}); } else { console.log("End of candidates."); }

}

Излезнитепораки,пратениодклиентдосервер,сепреќаатпрекуsendMessage()функцијатасо

помошнаXHRбарање:

function sendMessage(message) { var msgString = JSON.stringify(message); console.log('C->S: ' + msgString); path = '/message?r=99688636' + '&u=92246248'; var xhr = new XMLHttpRequest(); xhr.open('POST', path, true); xhr.send(msgString);

}

XHRработидоброприпраќањенапоракиодклиентдосервер,нопокрајоваепотребени

механизамзапраќањенапоракитеодсервердоклиент.Овааапликацијатоагоправисопомош

наGoogleAppEngineChannelAPI.Поракитепримениодсерверотсепроцесираатво

методотprocessSignalingMessage():

function processSignalingMessage(message) { var msg = JSON.parse(message); if (msg.type === 'offer') { // Callee creates PeerConnection if (!initiator && !started) maybeStart(); pc.setRemoteDescription(new RTCSessionDescription(msg)); doAnswer(); } else if (msg.type === 'answer' && started) { pc.setRemoteDescription(new RTCSessionDescription(msg)); } else if (msg.type === 'candidate' && started) {

var candidate = new RTCIceCandidate({sdpMLineIndex:msg.label, candidate:msg.candidate}); pc.addIceCandidate(candidate); } else if (msg.type === 'bye' && started) { onRemoteHangup(); }

}

Акопоракатаеодговородносноanswerоднекојpeer(резултатнанекојoffer),RTCPeerConnection

госетираremoteSessionDescriptionапослетоаможедазапочнекомуникацијата.Акопоракатае

offer(i.e.поракаодповикуваниотpeer)RTCPeerConnectionгосетираremoteSessionDescription,

праќаповратенодговордоповикувачот,изапочнуваконекцијасоповикувањена

RTCPeerConnectionstartIce()методот:

function doAnswer() { console.log("Sending answer to peer."); pc.createAnswer(setLocalAndSendMessage, null, mediaConstraints);

}

Крајнопослеоваповикувачкиотиповикуваниотpeerмеѓусебносеповрзани,имаатразменето

податоци,сесијатаеиницијализиранаиreal-timeкомуникацијатаможедазапочне.

3.15 Network topologies

WebRTCкакоштоемоменталноимплементиранподдржуваone-to-oneкомуникација,номожеда

бидекористенивопокомплекснимрежнисценарија:например,конектирањенаповеќеpeer-ови

коиќеимаатмеѓусебнадиректнакомуникација,илипаксокористењенаMultipointControl

Unit(MCU),односносерверкојќеможедаработисоголембројнакорисници,кадештоќесе

прависелективнопренесувањенастримилинекојакомбинацијанаснимањеирепродуцирање

намултимедијаленстрим:

Слика20Multipointcontrolunit–примернатопологија

МногупостоечкиWebRTCапликациидемонстрирааткомуникацијапомеѓупрелистувачи,но

покрајоваgatewayсерверитеможатдаовозможатWebRTCапликацијадастапивоинтеракцијасо

другиуредикаконапримертелефони(akaPSTN)какоисоVOIPсистеми.ВоМај2012,Doubango

Telecomпостависофтверсоотворенкодsipml5SIPclient,изграденврзбазанаWebRTCи

WebSocketкојштоовозможувавидеоповиципомеѓупрелистувачидругиапликациинаiOSилина

Android.AtGoogleI/O,TethrиTropoдемонстрирааaframeworkfordisastercommunications',

односно,сокористењенаOpenBTScellдасеовозможикомуникацијапомеѓуиднитетелефонии

компјутерисопомошнаWebRTC.

Слика21Tethr/Tropo:disastercommunicationsinbriefcase

3.16 RTCDataChannel

Какоштоеподдржанаудиоивидеотрансвер,WebRTCподдржуваreal-timeкомуникацијаиза

другитиповинаподатоци.

RTCDataChannelAPIовозможуваpeer-to-peerразменанаподатоципоизбор,сомногумала

латентностивисокпротокнаподатоци.ПостојатмногупотенцијалниприменинаоваAPI,на

пример:

• Индустријатазаизработканаигри

• Далечинскоуправувањенадесктопапликации

• Real-timeтекстчет

• Трансвернадатотеки

ОваAPIиманеколкукарактеристикипрекукоигоправиRTCPeerConnectionпомоќенипо

флексибиленприpeer-to-peerкомуникацијата:

• Повеќесимултаниканали,соприоритет.

• Reliableиunreliableиспораканаподатоци.

• Вграденабезбедност(DTLS).

• Можностдасекористисоилибезаудиоивидеосодржина.

СинтаксатаедостасличнанаWebSocket,соsend()методиmessageeventаргумент:

var pc = new webkitRTCPeerConnection(servers, {optional: [{RtpDataChannels: true}]}); pc.ondatachannel = function(event) { receiveChannel = event.channel; receiveChannel.onmessage = function(event){ document.querySelector("div#receive").innerHTML = event.data; }; }; sendChannel = pc.createDataChannel("sendDataChannel", {reliable: false}); document.querySelector("button#send").onclick = function (){ var data = document.querySelector("textarea#send").value; sendChannel.send(data);

};

Комуникацијатасеодвивадиректнопомеѓупрелистувачите,соRTCDataChannelпренесувањето

можедабидедостапобрзоодWebSocketдурииакоrelay(TURN)серверотевофункцијапри

трансверотнапораки.

RTCDataChannelедостапенвоChrome,OperaиFirefox.Веќесекористивонеколкувебапликации

• CubeSlamеигракојаштогокористиапи-тозакомуникацијавоиграта,односнокогасе

играпротивдругиграчпроменитесепраќаадиректнопрекуоваапи.

• SharefestкористиRTCDataChannelзаразменанафајлови

3.17 Security

Постојатнеколкуначиниreal-timeкомуникацијатадабиденесигурнаодстрананабезбедност.На

пример:

• Некриптираниподатоцидабидатпресретнатипомеѓукомуникацијатапомеѓу

прелистувачите,илиприкомуникацијапрелиствач-сервер.

• Апликацијатадаснимаидистрибуиравидеоилиаудиобезкорисникотдазнаезатоа.

• Можностадасеинсталиравирусприинсталирањенанекојплагинилиапликација.

WebRTCиманеколкукарактеристикизадапридонеседоизбегнувањенапретходно

наведенитепроблеми:

• WebRTCимплементацијатакористипротоколзабезбедносткакоштоеDTLSиSRTP.

• ЕнкрипцијатаезадолжителназаситеWebRTCкомпоненти,вклучувајќигиимеханизмите

засигнализирање.

• WebRTCнееплагин:неговитекомпонентисеизвршуваатподпроцесотнапрелистувачоти

непретставуваатпосебенпроцес,компонентитенебараатпосебнаинсталација,исе

ажурираатсамоприажурирањенасофтверот.

• Камератаимикрофонотдоколкусекористат,мораексплицитнодаимаседадедозвола,

покрајтоаикогаиститесеактивни,визуелноимаприказдекаиститесевофункцијаи

пренесуваатаудиоиливидеосодржина.

3.18 In conclusion

API-јатакакоистандардитенаWebRTCможатдапридонесатзаразвојотнаапликациитеодтипот

нателефонија,видеопродукција,изработканаигри,изработканамузика,прибирањенавестии

многудругитипвинаапликации.

3.19 Developer tools

• WebRTCстатистикавоврскасосесијатаможедабиденајденана:

• chrome://webrtc-internalsстранавоChrome

• opera://webrtc-internalsстранавоOpera

• about:webrtcстранавоFirefox

o Пример:

Слика22WebRTCinChrome

o chrome://webrtc-internalsscreenshot

4 Модел на реален проект

Слика23Архитектуранареаленпроект

4.1 Функционалности Моделот,односнопрактичниотделодоваамагистерскагиопфаќаследнивафункционалности:

• ПреземањенамултимедијалничанковиодсервервозависностодMPDдефиницијата,сопомошнаMSE.

• ПренесувањенамултимедијалнитечанковиодедендодругWebRTCклиент• Пренесувањенамултимедијалнитечанковиодповќеклиентидоеденклиент(повеќе

WebRTCконекциинаедентаб)• Контрола(конфигурација)затоаколкучанковисекојклиентбитребалодакешира• МеханизамкојдоколкунеможедапреземеконкретенчанкодWebRTCклиентитеда

правидиректенповикдоСерверсоштибијапрезелсодржинатаодтаму.

Слика24Визуелникомпонентинамоделот

4.2 MSE – Media Source Extension

СопомошнаMSE,сегментиодаудиовизуелнасодржинасеприкажуваатнавидеоплеерот.Засегментитедабидатприкажанинавидеоплееротпретходноепотребнодасекомплетираатследниведвачекори:

• НајпрвосепреземаMPDфајлот,истиотсепарсираисеизвлекуваатподатоцивоврскасолокацијанавидеото,какоидетализаситесегменти(одкојдокојбајтедефиниран).

• ПрекуJavascriptмеханизамсепреземаатчанковитередоследно,иседодавааатнаMSEбаферот.Следновидеосодржинатасеприкажуванаплеерот.

4.3 Сигнализациски сервер

ПретставуваJavaWebSocketимплементација,прекукојасеодвивакомуникацијатапомеѓуклиентитесоцелдасевоспоставиWebRTCконекцијата.

/*ВоспоставувањенаWebsocketконекција(клиент<->signalingserver)*/ @Override publicvoidonOpen(WebSocketconn,ClientHandshakehandshake){ System.out.println("Newclientconnected:" +conn.getRemoteSocketAddress()+"hash" +conn.getRemoteSocketAddress().hashCode()); MyPeermyPeer=newMyPeer(conn); myPeerList.put(String.valueOf(conn.getRemoteSocketAddress().hashCode()),myPeer); }

/*СекористизадобивањенаJSONbasedпоракаодстрананаклиентите(webbrowser).ВозависностодакцијатавопоракатасезачувуваатдетализаклиентотилисепрепраќаатдеталидодругклиентзадасевоспоставиWebRTCконекција*/ @Override publicvoidonMessage(WebSocketconn,Stringmessage){ System.out.println("onMessage"+message); SignalingMessagesignalingMessageReceived=gson.fromJson(message, SignalingMessage.class); switch(signalingMessageReceived.getAction()){ case"startConnection": startConnection(conn,signalingMessageReceived); break; case"setLocalSDP": myPeerList.get(signalingMessageReceived.getHash()).setLocalSDP(signalingMessageReceived.getLocalSDP()); break; case"setRemoteSDP": MyPeermyPeer=myPeerList.get(signalingMessageReceived.getHash()); SignalingMessagesignalingMessage=newSignalingMessage(); signalingMessage.setRemoteSDP(signalingMessageReceived.getRemoteSDP()); signalingMessage.setRemoteHash(signalingMessageReceived.getRemoteHash()); signalingMessage.setHash(signalingMessageReceived.getHash()); signalingMessage.setAction("setRemoteSDP"); myPeer.setRemoteSDP(signalingMessageReceived.getRemoteSDP()); myPeer.getWebsocket().send(gson.toJson(signalingMessage)); break; case"localICE": System.out.println("localICE"); MyPeermyPeerLocalIce=myPeerList.get(signalingMessageReceived.getHash()); List<String>l=myPeerLocalIce.getLocalICEList(); l.add(signalingMessageReceived.getLocalICE()); break;

case"remoteICE": try{ Thread.sleep(4000); }catch(InterruptedExceptione){ e.printStackTrace(); } System.out.println("remoteICE"); MyPeermyPeer1=myPeerList.get(signalingMessageReceived.getHash()); MyPeermyPeer2=myPeerList.get(signalingMessageReceived.getRemoteHash()); for(StringremoteICE:myPeer2.getLocalICEList()){ SignalingMessagesignalingMessageIce2=newSignalingMessage(); signalingMessageIce2.setAction("setRemoteICE"); signalingMessageIce2.setRemoteICE(remoteICE); myPeer1.getWebsocket().send(gson.toJson(signalingMessageIce2)); } for(StringremoteICE:myPeer1.getLocalICEList()){ SignalingMessagesignalingMessageIce1=newSignalingMessage(); signalingMessageIce1.setAction("setRemoteICE"); signalingMessageIce1.setRemoteICE(remoteICE); myPeer2.getWebsocket().send(gson.toJson(signalingMessageIce1)); } break; case"chunkRequest": try{ Thread.sleep(4000); }catch(InterruptedExceptione){ e.printStackTrace(); } System.out.println("chunkRequest"); MyPeerchunkRequest=myPeerList.get(signalingMessageReceived.getRemoteHash()); SignalingMessagesignalingMessageIce=newSignalingMessage(); signalingMessageIce.setAction("chunkRequest"); signalingMessageIce.setActionParam(signalingMessageReceived.getActionParam()); chunkRequest.getWebsocket().send(gson.toJson(signalingMessageIce)); break; default: thrownewIllegalArgumentException("invalidaction:" +signalingMessageReceived.getAction()); } }

/*ЕкстенцијазаonMessageметодот.Овдеспоредизбраниотрежимнаработа(server,onePeer,multiPeer)седефиниратипотнаклиентот.*/ privatevoidstartConnection(WebSocketconn, SignalingMessagesignalingMessageReceived){ SignalingMessagesignalingMessage=newSignalingMessage(); Stringhash=String.valueOf(conn.getRemoteSocketAddress().hashCode()); signalingMessage.setHash(hash); MyPeermyPeer=myPeerList.get(hash); myPeer.setClientType(signalingMessageReceived.getClientType()); System.out.println("***"+signalingMessageReceived.getOutgoing().equals("true"));

if(myPeer.getClientType().equals("server")||signalingMessageReceived.getOutgoing().equals("true")){ signalingMessage.setAction("createOffer"); signalingMessage.setIsAdmin(true); }elseif(myPeer.getClientType().equals("onePeer")){ signalingMessage.setAction("createAnswer"); MyPeerremoteCandidatePeer=getRemoteCandidatePeer(); signalingMessage.setRemoteSDP(remoteCandidatePeer.getLocalSDP()); signalingMessage.setHash(String.valueOf(conn.getRemoteSocketAddress().hashCode())); signalingMessage.setRemoteHash(String.valueOf(remoteCandidatePeer .getWebsocket().getRemoteSocketAddress().hashCode())); }elseif(myPeer.getClientType().equals("multiPeer")){ signalingMessage.setAction("createAnswer"); MyPeerremoteCandidatePeer=getRemoteCandidatePeer(); signalingMessage.setRemoteSDP(remoteCandidatePeer.getLocalSDP()); signalingMessage.setHash(String.valueOf(conn.getRemoteSocketAddress().hashCode())); signalingMessage.setRemoteHash(String.valueOf(remoteCandidatePeer .getWebsocket().getRemoteSocketAddress().hashCode())); } myPeerList.put(hash,myPeer); conn.send(gson.toJson(signalingMessage)); }

/*МетодпрекукојсебараслободенWebRTCклиент*/ privateMyPeergetRemoteCandidatePeer(){ for(Map.Entry<String,MyPeer>entry:myPeerList.entrySet()){ if(entry.getValue().getLocalSDP()!=null &&entry.getValue().getRemoteSDP()==null){ System.out.println("getRemoteCandidatePeer"); System.out.println(entry.getValue().getWebsocket().getRemoteSocketAddress().hashCode()); returnentry.getValue(); } } returnnull; }

4.4 HTML Имплементација

Визуелноапликацијатаимаедноставенинтерфејс.Таасесостоиодтрикомпоненти:

• Видеоплеер–задолжензаприкажувањенамултимедијалнатасодржина,репрудуциравидеоизвук.

• Секцијазапоставувањенаконфугурација–конфигурабилниседвапараметривоапликацијата.Бројотначанковикојштоконкретниотклиентбиможелдагичува,какоитипотнарежимнаработанаклиентот,коештоепојаснатоподеталновопродолжениепрекусценарија.

• Секцијазаприкажувањенастатистичкиподатоци

<html> <head> <title>MSE & WEBrtc</title> </head> <body> <div id="root"> <div id="left">  <video id="myVideo" controls>No video available</video> </div> <div id="right">  <div id="configuration"> <label class="title">Configuration :</label> </br> <label>receve chunks from :</label> <select id="connection-type"> <option value="server">server only</option> <option value="onePeer">one Peer</option> <option value="multiPeer">multiple Peers</option> </select> </br> <div id="cache-content"> <label>cache</label> <select id="cache-size"> <option value="6">6</option> <option value="5">5</option> <option value="4">4</option> <option value="3">3</option> <option value="2">2</option> <option value="1">1</option> <option value="0">0</option> </select> <label>chunks</label> </div> </br> <button id="save-config">Save Configuration</button> <button id="startStream" style="visibility:hidden;">Play</button> </div>  <div id="statistics"> <label class="title">Statistic :</label> </br> <label>receved data from :</label> </br> <div class="separator"></div>

<label class="obj">server:</label> <label id="chunk-size-from-server" data-bytes="0">0</label> <label>MB</label> </br> <div class="separator"></div> <label class="obj">peer 1:</label> <label id="chunk-size-from-peer1" data-bytes="0">0</label> <label>MB</label> </br> <div class="separator"></div> <label class="obj">peer 2:</label> <label id="chunk-size-from-peer2" data-bytes="0">0</label> <label>MB</label> </br> </div> </div> </div>  <script src="main_v1.js"></script>  <script src="webrtc.js"></script>  <script src="adapter.js"></script> <script src="ga.js"></script> <link rel="stylesheet" type="text/css" href="theme.css"> </body> </html>

4.5 Потребни ресурси за поставување на околина

Конкретнозапоставувањенаработнаоколиназаовајпроект(моделнаапликакција)несепотребниобемниподготовкиипоставувања.АплиакцијатабиможеладабидеоперативнанаплатформанакојаможедасеинсталираЈаваиTomcatСервер.

TomcatСерверотјаобезбедувастранатазапристаппрекувебпрелистувач,.MPDфајлот(којсодржидетализавидеосодржината),какоивидеофајлотодкојштосепреземаатчанковизавидеосоджината.

4.6 Сценарија

Возависностодизбранатаконфигурација,возможнисетрисценарија,односнотриразличнирежиминаработакоиможедагиимаеденклиент.Конфигурабилниседвефункционалностивоапликација:

• Подесувањезабројначанковикоиштоможедагичувавомеморијаактивниотклиентнааплиакацијата.

• Режимнаработа1. Serveronly–режимвокојшточанковитесепреземаатдиректноодсерверво

зависностодтоаштоедефинирановоmpdфајлот(несекористиWebRTC).2. OnePeer–режимвокојштосеправиконкцијасодругWebRTCклиент.Преку

комуникацијатаостваренасосигнализицискиотсерверсеодредувадаличанкотќебидепреземеноддругиотWebRTCклиентилиќеенеопходнодасепреземичанкотдиректноодглавниотсервер.

3. MultiplePeers–режимвокојштосеправиконекцијасоповеќедругиWebRTCклиенти.ОдноснобарателотначанковиправиWebRTCконекциисоповеќеклиенти,соцелдаимапоголемишансидапреземасодржинаодWebRTCклиентинаместодаземачанковиодглавниотсервер.

4.6.1 Сценарио 1

Serveronly–режимнаработа.Сеправатповицидосерверзапреземањена.MPDконтентот,какоишестповицизапреземањенавидеосодржината(сегменти).Воконзолатаможедасезабележиитоадекапрвопреземенитесегментисебришатодмеморија.Патакадостапниодмеморијазапонатамушнопрепуштањенавидеосодржинатаконостанатитеклиентисепоследнопримените4сегменти.Какоштоедефинирановоконфигурацијата.ВоделотзастатистикаможедасезабележидекацелатасодржинаепреземенасамоодСервер.

Слика25mode-Serveronly


Доколкуотворименовтабвовебпрелистувачотиизберимережимнаработа“onepeer”ќезабележимедекаовојклиентправисамодвадиректниповицидосервер,односногиземаодсерверсамоониеподатоцикоиWebRTCклиентотнеевоможностдагипредаде.ОстанатитечетирисегментисепреземаатпрекуDataChannel-отнаWebRTCконекцијата.Статистикатапотврдувадекаодсерверенаправентрансверод2MBапрекуWebRTCсепренесени13MB.

Слика26modeonePeer


Воовасценариоопфатенепоследниотрежимнаработа.ТукасеправатдвеWebRTCконекциивокоииницијатореактивниотклиент.Патака,воделотзастатискикаможедасезабележидекасодржинатаепреземенаод3локации,Сервер,Peer1иPeer2(WebRTC).

Слика27modeMultiplePeers

4.7 Споредбена статистика

БезкористењенаP2PСценарио Сервер Клиент1 Клиент2 Клиент3

1 15 0 02 15 0 03 15 0 0

Вкупно 45 0 0 0Табела3СтатистикабезкористењенаP2P

СомаксималнокористењенаP2PСценарио Сервер Клиент1 Клиент2 Клиент3

1 15 0 02 0 15 03 0 7,50 7,50

Вкупно 15 22,5 7,5 0Табела4СтатистикасокористењенаP2P

Заклучок

WebRTCедостаинтереснатехнологијавокојасевклучуваоркестрацијанамногутехнологииипротоколи.Даваможностконкретнаапликацијадаработинадесктопкакоимобилнибазираниуредисопреноснамултимедијалнасодржина.ПостојатголембројнабиблиотекиисервисикоиштосенарасполагањезаработасоWebRTCJavaScriptAPI-токакоипроцесотнасигнализирање.Постојативеќеготовисервисизасигнализирање.Ситеовиеопциипомаггатдоколкусакамедаизградименекоерешениекоигикористиметодитенастримингнавидеоиаудиосодржина.

Користена Литература

[1] Salvatore Loreto, Simon Pietro Romano, “Real-Time Communication with WebRTC”

[2] Rob Manson, “Getting Started with WebRTC”

[3] Matthew Wolenetz, Google Inc., Jerry Smith, Microsoft Corporation Mark Watson, Netflix Inc., Aaron Colwell (until April 2015), Google Inc., Adrian Bateman (until April 2015), Microsoft Corporation, “W3C Media Source Extensions”

https://w3c.github.io/media-source/

[4] Adam Bergkvist, Ericsson; Daniel C. Burnett, Voxeo; Cullen Jennings, Cisco; Anant Narayanan, Mozilla (until November 2012)

http://www.w3.org/TR/webrtc/

[5] Sam Dutton, “Getting Started with WebRTC”

http://www.html5rocks.com/en/tutorials/webrtc/basics/

http://www.html5rocks.com/en/tutorials/webrtc/basics/#signaling

[6] Muaz Khan, “WebRTC for Beginners”,

www.webrtc-experiment.com

[7] https://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP

[8] https://gpac.wp.mines-telecom.fr/home/

[9] https://en.wikipedia.org/wiki/GPAC_Project_on_Advanced_Content

[10] http://www.w3.org/TR/media-source/

[11] https://en.wikipedia.org/wiki/Media_Source_Extensions

[12] http://www.streamingmedia.com/Articles/Editorial/What-Is-.../What-is-MPEG-DASH-79041.aspx

Documents

Magisterski Trud - Nikola Ilievski 98 11 v3 · Abstract This master thesis has a goal to define a model that will confirm communication practically, in other words this model should