WebRTC

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 . Google, Microsoft, Mozilla eta Operak babesten dute, eta World Wide Web Consortium (W3C) eta Internet Engineering Task Force (IETF) erakundeak WebRTC estandarizatzen ari dira.

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 . 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 .

Historia 
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 . 2011-ko maiatzean Google-ek arakatzaileetan denbora errealeko komunikazioa egiteko kode-irikiko proiektu bat publikatu zuen, WebRTC izenekoa . 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 , eta IETF-k batera denbora errealeko komunikazioa ahalbidetuko duten protokolo multzoa zehazten du .

2011ko maiatzean, Ericcson Labs enpresak WebRTC-ren lehen inplementazioa garatu zuen eraldatutako WebKIT liburutegi bat erabiliz . 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 , 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:

 IETF erakundeko RTCWEB taldean hartutako erabakiak, espezifikazioarekin batera RTC komunikazioak definituko duen protokolo multzoa definitzeko.
 Sistemen gaitasun eta stream lokalak kanpora erakustean sortutako pribatutasun arazoak.
 Taldean edukitako eztabaida teknikoak, partikularki data channel-en inplementazioari buruzkoak.
 Hasierako esperimentazioan lortutako esperientzia.
 Beste talde eta pertsonek emandako feedback-a.

Diseinua 
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:
 getUserMedia-k audio eta bideoa lortzen ditu, adibidez gailuaren kamera eta mikrofonoa atzituz. Hau aurrerapen handia da web aplikazioentzat, WebRTC garatu baino lehen normalean plugin bat instalatzea beharrezkoa izaten zelako gailuko kamera edo mikrofonoa atzitu ahal izateko.
 RTCPeerConnection-ek kideen arteko audio eta bideo komunikazioa ahalbidetzen du. Protokolo hau seinale prozesamenduaz, codec-en tratamenduaz, kideen arteko komunikazioaz (P2P), segurtasunaz eta banda zabaleraren kudeaketaz arduratzen da. Seinalizazioa, berriz, ez da RTCPeerConnection API-aren parte. Izan ere, WebRTC espezifikazioan ez da seinalizazio protokolorik zehazten, eta aplikazio garatzaileek erabaki beharko dute zein protokolo erabili.
 RTCDataChannel-ek kiden arteko edozein motako datuak komunikatzea ahalbidetzen du. WebSocket-ek erabiltzen duen api berdina erabiltzen du, eta oso latentzia txikia du.
Hauez gain API-ak estadistika funtzio bat ere eskaintzen du:
 getStats-en bidez web aplikazioak WebRTC saioari buruzko hainbat estadistika atzitu ditzake. Datu estadistiko hauek beste dokumentu batean W3C dokumentu batean deskribatuko dira.

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 . 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.

Zerbitzariak

TURN 
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.

NAT 
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.

ICE 
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.

STUN 
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.

SDP 
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.

DTMFren erabilera 
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.

Funtzionamendua 
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.

Mugak 
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.

Bateragarritasunaren hobetzea 
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.

adapter.js -ren funtzioa 
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.

Adibideak 

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.

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:

 Bezeroaren arreta bideokonferentziaren bidez 
 Dokumentuak web bidez elkarrekin lan egitea (suebakien gaineko web lankidetza).
 SmartTV-ek egiteko aukera ematen dizu bideokonferentziak azpiegiturarik edo zerbitzurik gabe atzealdean exekutatzen ari den, arakatzailea baldin badago.
 Ez zaizkizu bideo-konferentziak interesatzen? (Hodeien biltegia eta WebRTC bakarrik hartzen ditu) WebRTCk Facebook, LinkedIn eta Twitter bezalako Social Media plataformen aurpegia goitik behera alda lezake, txertatuz gero.
 Windows-eko ohiko dendan telefono zenbakiak erakutsi beharrean, eman QRcode edo NFC espazio bat, erabiltzaileek zuzenean zuregana jo dezaten beren telefonoarekin edo tabletarekin (kamera, mikrofonoa, bozgorailua, etab).

Hedapena 

Hurrengo arakatzaileek WebRTC inplementazioak eskaintzen dituzte:
 Mahaigaineko PCkoak
 Microsoft Edge 12+
 Google Chrome 28+
 Mozilla Firefox 22+
 Safari 11+
 Opera 18+
 Vivaldi 1.9+
 Androidekoak
 Google Chrome 28+ (29 bertsiotik aurrera modu lehenetsian aktibatua)
 Mozilla Firefox 24+
 Opera Mobile 12+
 Chrome OS
 Firefox OS
 Blackberry 10
 IOS 11
 MobileSafari/WebKit
 Tizen 3.0

Internet Explorer arakatzaileari WebRTC gaitasuna gehitzeko pluginak ere existitzen dira.

Segurtasun arazoak 
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 . IP helbidea irakurtzeko eskaerak ez dira arakatzaileko garatzaile kontsolan agertzen, eta iragarki blokeatzaile eta segurtasun/pribatutasun plugin gehienek ez dituzte eskaera hauek blokeatzen . Honen ondorioz posible da erabiltzailearen jarraipena egitea. Hala ere, uBlock Origin plugin-ak arazo hau ekidin dezake.

Erreferentziak

Kanpo estekak 

World Wide Web