WebRTC | |
---|---|
Jatorria | |
Ezaugarriak | |
Egile-eskubideak | copyrightduna |
Lizentzia | BSD lizentziak |
w3c.github.io… | |
Iturri-kodea | https://github.com/w3c/webrtc-pc |
WebRTC (Denbora errealeko Web Komunikazioa, edo Web Real-Time Communication ingelesez) kode-iriki proiektu bat da, denbora errealeko multimedia aplikazioak zuzenean web arakatzaileetan garatzea ahalbidetzen duena, inongo pluginen beharrik gabe; Horretarako hainbat API (Application Programming Interface) eskaintzen ditu. Kideen arteko komunikazio zuzena (P2P) ahalbidetzen du arakatzailean bertan, inongo plugin-ik instalatu behar gabe [1]. Google, Microsoft, Mozilla eta Operak babesten dute, eta World Wide Web Consortium (W3C) eta Internet Engineering Task Force (IETF) erakundeak WebRTC estandarizatzen ari dira[2].
WebRTC-ren helburua “Kalitate handiko RTP aplikazioak arakatzaile, gailu mugikor eta IoT gailuetarako garatzea ahalbidetzea, eta aplikazio hauek guztiak protokolo multzo estandar baten bidez komunikatzeko bidea ematea” da [2]. Erreferentziako inplementazio bat software aske moduan publikatu da, BSD lizentziapean. OpenWebRTC-k beste inplementazio aske bat da, GStreamer multimedia framework-ean oinarritua. Brendan Eich-ek, JavaScript-en sortzailea, esan zuen proiektua “web aske eta garbi baten aldeko gudu luzean fronte berri bat” dela [3].
2010eko maiatzean, Google-ek Global IP Solutions edo GIPS enpresa, VoIP teknologietan aritzen zena, erosi zuen. Enpresa honek RTC egiteko behar diren hainbat osagai garatuak zituen, besteak beste codec-ak eta oihartzun kanzelazio (echo cancellation) teknikak. Google-ek teknologia hau open-source bihurtu zuen eta harremanetan jarri zen W3C eta IETF erakundeekin industrian estandarizazioa ziurtatzeko [4]. 2011-ko maiatzean Google-ek arakatzaileetan denbora errealeko komunikazioa egiteko kode-irikiko proiektu bat publikatu zuen, WebRTC izenekoa [5]. Honen ondoren lan gehiago egon da IETF-ren partez beharrezko protokoloak estandarizatzeko, eta W3C-ren partez arakatzaile API-ak estandarizatzeko. W3C-k espezifikazioa garatzen du [6], eta IETF-k batera denbora errealeko komunikazioa ahalbidetuko duten protokolo multzoa zehazten du [7].
2011ko maiatzean, Ericcson Labs enpresak WebRTC-ren lehen inplementazioa garatu zuen eraldatutako WebKIT liburutegi bat erabiliz [8]. 2011ko urrian, espezifikazioaren lehen zirriborroa publikatu zuen W3C-k. 2013ko otsailean arakatzaile desberdinen arteko lehen deia egin zen WebRTC bitartez, 2014ko otsailean lehen arakatzaile desberdinen arteko datu transferentzia, eta urte bereko uztaila iristean Google Hangouts-ek “gutxi gorabehera” WebRTC erabiltzen zuen.
W3Ck egindako zirriborroa aribidean dago [9], eta Chrome eta Firefox arakatzaileek inplementazio aurreratuak eskaintzen dituzte. API-a WHATWG-ak egindako aurretiko lanean oinarritzen da. WebRTC Working Group-ak espezifikazioak bilakaera nabarmenak jasango dituela espero du, hurrengo faktoreen ondorioz:
WebRTC API-ak multimedia aplikazio bat garatzeko behar diren teknologia guztiak biltzen ditu: multimedia kaptura, kodetze/deskodetzea, garraioa, saio kontrola, etab. API-aren osagai nagusiak hurrengoak dira:
Hauez gain API-ak estadistika funtzio bat ere eskaintzen du:
RFC 7874-k inplementazioek gutxienez PCMA/PCMU (RFC 3551), DTMF (RFC 4733) eta Opus (RFC 6716) audio codec-a eskaini behar dituztela ezartzen du. PeerConnection, data channel eta media kapturarako API-ak W3C-k zehazten ditu.
W3C ORTC (Objektuen denbora errealeko komunikazioa edo Object Real-Time Communications ingelesez) garatzen ari da WebRTC-rako [11]. Honi normalean WebRTC 1.1 deritzo. Bideo codec-ei dagokionez, une honetan WebRTC-k VP8, VP9 eta AVC onartzen ditu.
Aplikazioak garatzeko erabiltzen den maila altuko Web API-az gain, WebRTC-ren sortzaileek baila baxuagoko C++ API bat eskaintzen dute, arakatzaileen garatzaileek erabiltzeko pentsatua.
Murriztapen honekin, bideratzaileak, aldez aurretik konektatuta izan zaren tokietatik bakarrik onartuko ditu konexioak.Traversal Using Relays around NAT (TURN), -en helburua, murriztapen hauek ekiditean datza. Horretarako, bitartekari bat ezartzen da bikoteen artean. Bitartekari honek, erabiltzaile bakoitzeko konexio bat ezartzen du. Konexio hauek behin ezarrita, baten trafikoa bigarrenera bideratzen du eta alderantziz. Horrela, NAT-entzako egindako konexioa, jasotzekoaren berdina denez, trafikoa onartu egiten du.
Network Address Translation (NAT), sare pribatu bateko gailuei ip publiko bat esleitzeko erabiltzen da. Bideratzaileak, ip publiko bat izango du eta sareko ekipo bakoitzak, ip pribatu bat. Gailu hauek egindako eskaerak, bere ip pribatutik, bideratzailearen ip publikora bihurtuko ditu, honen portu bat esleituz. Hau da, gailu guztiek kanpoko sarea (Internet) atzitzeko aukera izango dute ip publiko bera erabiliz, eta bakoitza, portu batekin identifikatuta dago.
Interactive Connectivity Establment (ICE) zure web orria pareekin konektatzen uzteko esparru bat da. Arrazoi asko daude Peer A-tik Peer B-ra zuzenean konektatzeak ez funtzionatzeko. Fire-hormak pasarazi behar dira konexioak irekitzea eragotziko luketenak, helbide paregabea emango lizukete egoera gehienetan bezala zure gailuak ez badu IPren helbide publikorik, eta datuak zerbitzariaren bidez bidali, zure laguntzaileak pareekin zuzenean konektatzen uzten ez badizu. ICE-k STUN eta/edo TURN zerbitzariak erabiltzen ditu hau egiteko, behean deskribatu dugun bezala.
Session Traversal Utilities for NAT (STUN), zure helbide publikoa zein den jakin eta bideratzailearen mugak ezagutzeko protokoloa da. Funtzionamendua ondorengoa da. Bezeroak, STUN zerbitzariari kontsulta egin eta honek bere ip publikoarekin erantzungo dio.
Sm Description Protocol (SDP) konfigurazioa, formatuak, kodeketak, enkriptazioa, etab. bezalako loturen multimedia edukiak deskribatzeko estandar bat da, bi pareek elkar uler dezaten behin datuak transferituz gero. Hori, funtsean, edukia deskribatzen duen metadata da, eta ez hedabideak berak.Orduan, teknikoki, SDP ez da benetan protokolo bat, baizik eta datuak deskribatzeko erabiltzen den formatua, komunikabideak gailu artean partekatzen dituena.
Audioa/bideoa hobeto mantentzeko, WebRTC euskarriak DTMF bidaltzen du urruneko parera RTCPeerConnection batean. DTMF sistema, askotan, ‘Ukitu tonua’ bezala aipatzen da, sistemaren antzinako izen komertzial baten ondoren.
WebRTCk ez ditu DTMF kodeak bidaltzen audio-datu gisa. Horren ordez, bandatik kanpo bidaltzen dituzte, RTPk ordainduta. Kontuan izan, hala ere, WebRTC erabiliz DTMF bidaltzea posible den arren, orain ez dagoela modurik DTMF detektatzeko edo jasotzeko. WebRTCk ez die jaramonik egiten ordainketei; hau da, WebRTCren DTMF euskarria DTMF tonuetan oinarritzen diren legezko telefono-zerbitzuekin erabiltzea da lehentasuna, honako eginkizunak betetzeko: Telekomunikazio sistemak, kreditu-txartelaren edo beste ordainketa-informazio baten sarrera,etab.
DTMF urruneko parera audio bezala bidaltzen ez den bitartean, nabigatzaileek aukeratu ahal izango dute tokiko erabiltzaileari dagokion doinua jotzea bere erabiltzaile-esperientziaren parte gisa, erabiltzaileak ohitu egiten baitira bere telefonoaren doinuak entzunez entzuten.
DTMF seinalea bidali nahi dituzunean, zein pistatan bidali erabaki behar duzu lehenik. Hau aukeratutakoan, RTCRtpSender (beste pareari bidaliko dizkio tonuak pistaren audio-datuen ondoan dauden pakete gisa) bide lortuko duzu DTMF bidaltzeko erabiliko duzun RTCDTMFSender objektua. Tonu bat bidaltzen den bakoitzean, RTCPeerConnectith-ek tonalitate-gertaera bat jasotzen du, tonu-propietate batekin, zein tonu-tonu amaitzen den zehazten duena, elementu interferentziak eguneratzeko aukera ematen duena, adibidez. Buffer doinua hutsik dagoenean, tonu guztiak bidali direla adierazten duena, tonuko gertaera bat, tonu-propietatea jarrita duena (soka huts bat) lotura-objektuari ematen zaio.
Multimedia-gailuetara sartzean, jardunbide egokia da ahalik eta murrizketa zehatzenak eskaintzea. Aurrez zehaztutako kamera eta mikrofonoa murrizketa soil batekin ireki badaitezke ere, baliteke aplikaziorako egokiena izatetik urrun dagoen bitartekoen fluxua ematea.
MediaTrackConstraint objektu batean definitzen diren muga espezifikoak, bata audiorako eta bestea bideorako. Objektu honen ezaugarriak ConstraintLong, ConstraintBoolean, ConstraintDouble edo ConstraintDOMString motakoak dira. Horiek balio espezifiko bat (adibidez, zenbaki bat, boolean edo kate-zenbaki bat), maila bat (LongRange edo DoubleRange balio minimo eta maximo batekin) edo objektu bat izan daitezke, ideal edo exact definizio batekin. Balio espezifiko baterako, nabigatzailea ahalik eta antzekoena den zerbait aukeratzen saiatuko da. Maila baterako, maila horretako baliorik onena erabiliko da. Exact zehazten denean, murrizketa horrekin zehazki bat datozen bitartekoen fluxuak bakarrik itzuliko dira.
Komunikabideen fluxu baten pista jakin baten egungo konfigurazioa zehazteko, MediaStreamTrack.getSettings () dei dezakegu, gaur egun aplikatzen diren MediaTrackSetting-ak itzultzen dituena.
Era berean, medioen gailu baten pista baten mugak eguneratu daitezke, pistan applyConstraints () deituz. Horri esker, aplikazio batek multimedia-gailu bat konfiguratu dezake, aurretik dagoen transmisioa itxi behar izan gabe.
WebRTC egokitzailea Javascript altxagarri bat da. WebRTC espezifikazioari kodea idazten uzten diona eta WebRTC euskarria diten webgune guztietan ‘besterik gabe’ lan egiten uzten duena.
Hau baliagarria da WebRTC espezifikazioa erlatiboki egonkorra den bitartean, bezero guztiek ez dituztelako bere ezaugarri guztiak erabat inplementatu. Horrez gain, zenbait saltzailek WebRTC sistema bat edo batzuk dituzte. WebRTC egokitzailea erabiliz gero, ez dago baldintzarik API-ak aurretik erabiltzeko edo beste lan batzuk gauzatzeko.
Izan ere, WebRTC euskarri duen nabigatzaile bakoitzaren bertsio bakoitzak, JS konfigurazioak, beharrezko polinomioak inplementatzen ditu, APIren izen ez-finkoak ezartzen ditu, eta beste edozein aldaketa aplikatzen du WebRTC espezifikazioari idatzitako kodea egiteko.Adibidez, Firefox-bertsioetan, egokitzaileak RTCPeerConectionen jabetza gehitzen du.
Hasiera batean WebRTC web arakatzaileetan erabiltzeko garatu arren, erabilia izan da ere beste hainbat gailutan, adibidez plataforma mugikorretan eta IoT (Gauzen Internet edo Internet of Things, ingelesez) gailuetan. WebRTC-ren aplikazioetako bat web-arakatzaileetan funtzionatzen duten VoIP telefonia sistemak dira. Aplikazio hauek gai dira zuzenean arakatzailetik deiak egin eta jasotzeko, inongo software extrarik (adibidez softphone bat) instalatu behar gabe[12].
Aukerak ezin dira zenbatu. Batez ere, BYODen garaian, guztiek dute telefonoa beti prest eta hortik haratago, ordenagailu eramangarri eta ordenagailu guztiek WebRTCn parte har dezakete. Hona hemen burura nitzakeen adibide batzuk:
Hurrengo arakatzaileek WebRTC inplementazioak eskaintzen dituzte:
Internet Explorer arakatzaileari WebRTC gaitasuna gehitzeko pluginak ere existitzen dira.
2015eko urtarrilean WebRTC gaitasuna zuten arakatzaileen segurtasun akats larry bat salatu zuen TorrentFreak-ek, esanez VPN tunnel-en segurtasuna arriskuan jartzen zuela, erabiltzailearen benetako IPa erakustearen ondorioz [18]. IP helbidea irakurtzeko eskaerak ez dira arakatzaileko garatzaile kontsolan agertzen, eta iragarki blokeatzaile eta segurtasun/pribatutasun plugin gehienek ez dituzte eskaera hauek blokeatzen [19]. Honen ondorioz posible da erabiltzailearen jarraipena egitea. Hala ere, uBlock Origin plugin-ak arazo hau ekidin dezake[20].