{"id":30842,"date":"2019-10-31T21:37:44","date_gmt":"2019-10-31T18:37:44","guid":{"rendered":"https:\/\/prohoster.info\/blog\/ot-skype-do-webrtc-kak-my-organizovali-videosvyaz-cherez-veb\/"},"modified":"2021-02-01T11:37:06","modified_gmt":"2021-02-01T09:37:06","slug":"ot-skype-do-webrtc-kak-my-organizovali-videosvyaz-cherez-veb","status":"publish","type":"post","link":"https:\/\/prohoster.info\/sk\/blog\/administrirovanie\/ot-skype-do-webrtc-kak-my-organizovali-videosvyaz-cherez-veb","title":{"rendered":"Od Skype po WebRTC: ako sme zorganizovali videohovor cez web","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Od<\/p>\n

Videohovory s\u00fa hlavn\u00fdm sp\u00f4sobom komunik\u00e1cie u\u010dite\u013ea a \u0161tudenta na platforme Vimbox. U\u017e d\u00e1vno sme sa vzdali Skypu, vysk\u00fa\u0161ali sme nieko\u013eko extern\u00fdch rie\u0161en\u00ed a nakoniec sme sa rozhodli pre kombin\u00e1ciu WebRTC \u2013 Janus-gateway. Po ur\u010dit\u00fd \u010das sme boli so v\u0161etk\u00fdm spokojn\u00ed, ale aj napriek tomu sa st\u00e1le objavovali niektor\u00e9 negat\u00edvne momenty. Nakoniec sme vytvorili samostatn\u00fd smer pre video.<\/p>\n

Po\u017eiadal som Kirilla Rogovogo, ved\u00faceho nov\u00e9ho smeru, aby n\u00e1m prerozpr\u00e1val evol\u00faciu videohovoru v Skyeng, objaven\u00e9 probl\u00e9my, rie\u0161enia a obmedzenia, ktor\u00e9 sme nakoniec pou\u017eili. D\u00fafame, \u017ee \u010dl\u00e1nok bude u\u017eito\u010dn\u00fd aj pre firmy, ktor\u00e9 takisto implementuj\u00fa video cez webov\u00fa aplik\u00e1ciu.<\/p>\n

<\/a><\/noindex><\/p>\n

Trochu hist\u00f3rie<\/h2>\n

V lete 2017 predstavil ved\u00faci v\u00fdvoja Skyeng Sergej Safonov na Backend Conf t\u00e9mu, ako sme \u201es Skypom skon\u010dili a implementovali WebRTC\u201c. Z\u00e1ujemcovia si m\u00f4\u017eu pozrie\u0165 z\u00e1znam jeho vyst\u00fapenia na odkaze<\/a><\/noindex> (~45 min), a tu zhrniem jeho z\u00e1kladn\u00e9 my\u0161lienky.<\/p>\n

Pre \u0161kolu Skyeng boli videohovory v\u017edy prioritn\u00fdm sp\u00f4sobom komunik\u00e1cie u\u010dite\u013e-\u017eiak. Na za\u010diatku sme pou\u017e\u00edvali \u201eSkype\u201c, ale ten n\u00e1s z viacer\u00fdch d\u00f4vodov absol\u00fatne neuspokojoval, predov\u0161etk\u00fdm kv\u00f4li nedostatku logov a nemo\u017enosti integr\u00e1cie priamo do webovej aplik\u00e1cie. Preto sme realizovali r\u00f4zne experimenty.<\/p>\n

Po\u017eiadavky na videohovor boli pribli\u017ene tak\u00e9to:
\n\u2014 stabilita;
\n\u2014 n\u00edzka cena za hodinu;
\n\u2014 nahr\u00e1vanie hod\u00edn;
\n\u2014 sledovanie, kto ko\u013eko hovor\u00ed (je pre n\u00e1s d\u00f4le\u017eit\u00e9, aby \u017eiaci hovorili na hodin\u00e1ch viac ako u\u010ditelia);
\n\u2014 line\u00e1rne \u0161k\u00e1lovanie;
\n\u2014 mo\u017enos\u0165 pou\u017e\u00edva\u0165 ako UDP, tak aj TCP.<\/p>\n

Prv\u00fdm, ktor\u00fd sme v roku 2013 vysk\u00fa\u0161ali implementova\u0165, bol Tokbox. V\u0161etko bolo v poriadku, ale bolo to ve\u013emi drah\u00e9 \u2013 113 rub\u013eov za hodinu \u2013 a konzumovalo to zisk.<\/p>\n

Potom sme v roku 2015 integrovali Voximplant. Tu bola potrebn\u00e1 funkcia sledovania, kto ko\u013eko hovor\u00ed, a z\u00e1rove\u0148 bolo toto rie\u0161enie v\u00fdrazne lacnej\u0161ie: za podmienky nahr\u00e1vania iba zvuku to vy\u0161lo na 20 rub\u013eov za hodinu. Av\u0161ak fungovalo to iba cez UDP, prepn\u00fa\u0165 sa na TCP to nevedelo. Napriek tomu to nakoniec pou\u017e\u00edvalo asi 40% \u017eiakov.<\/p>\n

Po roku sme za\u010dali z\u00edskava\u0165 firemn\u00fdch klientov s ich \u0161pecifick\u00fdmi po\u017eiadavkami. Napr\u00edklad, v\u0161etko mus\u00ed fungova\u0165 cez prehliada\u010d, v spolo\u010dnosti s\u00fa povolen\u00e9 iba http a https; teda \u017eiadne \u201eSkypy\u201c a UDP. Firemn\u00ed klienti = peniaze, preto sme sa vr\u00e1tili k Tokboxu, ale probl\u00e9m s cenou nezmizol.<\/p>\n

Rie\u0161enie \u2014 WebRTC a Janus<\/h2>\n

Rozhodli sme sa pou\u017ei\u0165 prehliada\u010dov\u00fa platformu pre peer-to-peer videohovor WebRTC<\/a><\/noindex>. Zabezpe\u010duje nadv\u00e4zovanie spojenia, k\u00f3dovanie a dek\u00f3dovanie pr\u00fadov, synchroniz\u00e1ciu st\u00f4p a kontrolu kvality s riaden\u00edm sie\u0165ov\u00fdch probl\u00e9mov. Z na\u0161ej strany mus\u00edme zabezpe\u010di\u0165 \u010d\u00edtanie pr\u00fadov z kamery a mikrof\u00f3nu, vykreslovanie videa, spr\u00e1vu spojenia, nastavenie WebRTC pripojenia a prenos pr\u00fadov na\u0148, ako aj prenos sign\u00e1lnych spr\u00e1v medzi klientmi na nadviazanie spojenia (s\u00e1m WebRTC opisuje iba form\u00e1t d\u00e1t, ale nie mechanizmus ich prenosu). V pr\u00edpade, \u017ee s\u00fa klienti za NAT, WebRTC sa pripojuje k STUN serverom, ak to nepom\u00e1ha, TURN serverom.<\/p>\n

Zvy\u010dajn\u00e9ho p2p spojenia n\u00e1m nesta\u010d\u00ed, preto\u017ee chceme nahr\u00e1va\u0165 lekcie pre \u010fal\u0161iu anal\u00fdzu v pr\u00edpade reklam\u00e1ci\u00ed. Preto pren\u00e1\u0161ame pr\u00fady WebRTC cez retransl\u00e1tor Janus Gateway od Meetecho<\/a><\/noindex>. V d\u00f4sledku toho klienti nepoznaj\u00fa adresy jeden druh\u00e9ho a vidia iba adresu servera Janus; ten tie\u017e pln\u00ed funkciu sign\u00e1lneho servera. Janus m\u00e1 mno\u017estvo potrebn\u00fdch funkci\u00ed: automaticky prech\u00e1dza na TCP, ak m\u00e1 klient zablokovan\u00e9 UDP; dok\u00e1\u017ee nahr\u00e1va\u0165 pr\u00fady cez UDP aj TCP; \u0161k\u00e1luje; a m\u00e1 dokonca zabudovan\u00fd plugin na echo testy. V pr\u00edpade potreby sa automaticky prip\u00e1jaj\u00fa STUN a TURN servery od Twilio.<\/p>\n

V lete 2017 sme mali v prev\u00e1dzke dva servery Janus plus \u010fal\u0161\u00ed server na spracovanie nahrat\u00fdch surov\u00fdch s\u00faborov zvuku a videa, aby sme nezaberali procesory hlavn\u00fdch. Pri pripojen\u00ed sa servery Janus vyberali pod\u013ea princ\u00edpu p\u00e1r-nep\u00e1r (\u010d\u00edslo spojenia). V tom \u010dase to sta\u010dilo, pod\u013ea na\u0161ich pocitov to d\u00e1valo pribli\u017ene \u0161tvorn\u00e1sobn\u00fd rezerva\u010dn\u00fd faktor, miera zavedenia bola pribli\u017ene 80. Pri tom cena klesla na ~2 ruble za lekciu, plus v\u00fdvoj a podpora.<\/p>\n

\"Od<\/p>\n

N\u00e1vrat k t\u00e9me videohovorov<\/h2>\n

St\u00e1le sledujeme sp\u00e4tn\u00fa v\u00e4zbu od \u017eiakov a u\u010dite\u013eov, aby sme v\u010das odhalili a zastavili probl\u00e9my. Do l\u00e9ta 2018 sa na prvom mieste medzi s\u0165a\u017enos\u0165ami pevne usadila kvalita spojenia. Na jednej strane to znamenalo, \u017ee sme \u00faspe\u0161ne zvl\u00e1dli in\u00e9 nedostatky. Na druhej strane bolo nutn\u00e9 r\u00fdchlo nie\u010do urobi\u0165: pri preru\u0161en\u00fdch lekci\u00e1ch riskujeme stratu ich hodnoty, niekedy spolu s hodnotou n\u00e1kupu \u010fal\u0161ieho bal\u00edka, a pri preru\u0161eniach \u00favodnej hodiny dokonca riskujeme stratu potenci\u00e1lneho klienta.<\/p>\n

V tom \u010dase bola na\u0161a videokomunik\u00e1cia st\u00e1le v re\u017eime MVP. Jednoducho povedan\u00e9, spustili sme to, fungovalo to, raz sme to \u0161k\u00e1lovali, pochopili sme, ako na to \u2013 a to bola par\u00e1da. If it works, don\u2019t fix it. Nikto sa cielene nezaoberal ot\u00e1zkou kvality spojenia. Do augusta sa uk\u00e1zalo, \u017ee takto to nem\u00f4\u017ee pokra\u010dova\u0165, a spustili sme samostatn\u00fd smer, aby sme sa vysporiadali s probl\u00e9mom s WebRTC a Janus.<\/p>\n

Na vstupe tento smer dostal: rie\u0161enie MVP, \u017eiadne metriky, \u017eiadne ciele, \u017eiadne procesy na zlep\u0161ovanie, pri\u010dom 7% u\u010dite\u013eov si s\u0165a\u017eovalo na kvalitu spojenia (\u00fadaje o \u017eiakoch tie\u017e neexistovali).<\/p>\n

\"Od<\/p>\n

Nov\u00fd smer sa pustil do pr\u00e1ce<\/h2>\n

Pr\u00edkaz vyzer\u00e1 asi takto:<\/p>\n