WebRTC. Видео конференција во прелистувачот. Мултикориснички разговор со помош на гласовен разговор WebRTC Webrtc

Преамбула. Вклучено P2P видео разговор WebRTC базае алтернатива на Skype и други средства за комуникација. Главните елементи на p2p видео разговор базиран на WebRTC се прелистувач и контакт сервер. P2P видео разговорите се peer-to-peer видео разговори во кои серверот не учествува во преносот на тековите на информации. Информациите се пренесуваат директно помеѓу прелистувачите на корисниците (врсниците) без никакви дополнителни програми. Покрај прелистувачите, видео разговорите p2p користат контакт сервери, кои се дизајнирани да регистрираат корисници, да складираат податоци за нив и да обезбедат префрлување помеѓу корисници. Прелистувачите што ги поддржуваат најновите технологии WebRTC и HTML5 обезбедуваат инстант текстуални пораки и пренос на датотеки, како и гласовна и видео комуникација преку IP мрежи.

Значи, разговори, веб-разговори, гласовни и видео разговори во веб-интерфејс, IMS, VoIP се услуги кои обезбедуваат онлајн комуникации преку композитни мрежи со префрлување на пакети. Како по правило, комуникациските услуги бараат или инсталирање на клиентски апликации на кориснички уреди (компјутери, паметни телефони, итн.) или инсталирање на приклучоци и екстензии во прелистувачите. Услугите имаат свои комуникациски мрежи, од кои повеќето се изградени на архитектура клиент-сервер.

Услугите за комуникација се апликации, освен IMS, во кои каналите за глас, видео, податоци и текст не се интегрирани. Во мрежите на секоја услуга, . Треба да се напомене дека овие апликации не можат да работат истовремено во неколку комуникациски мрежи, т.е. Апликациите обично не можат да комуницираат едни со други, што бара да се инсталира посебна апликација за секоја комуникациска мрежа.

Проблемот на интегрирање на комуникациски услуги во реално време (чет, телефонија, видео конференции), т.е. интеграцијата на гласовни, видео, податочни канали и пристапот до нив со помош на една апликација (прелистувач) може да се реши во peer-to-peer или p2p видео разговори (peer-to-peer, point-to-point) врз основа на протоколот WebRTC. Во суштина, прелистувачот што поддржува WebRTC станува единствен интерфејс за сите кориснички уреди (компјутери, паметни телефони, iPad, IP телефони, мобилни телефониитн.) кои работат со комуникациски услуги.

WebRTC е тој што обезбедува имплементација во прелистувачот на сите технологии кои обезбедуваат комуникација во реално време. Суштината на p2p видео разговорите е дека мултимедијалните и текстуалните податоци се пренесуваат директно помеѓу прелистувачите на корисниците (далечинско вртење) без учество на сервер или дополнителни програми. Така, прелистувачите не само што обезбедуваат пристап до скоро сите информациски ресурсиИнтернет, кои се складирани на сервери, но стануваат и средство за пристап до сите комуникациски услуги во реално време и услуги за пошта (говорна пошта, е-пошта, СМС, итн.)

Серверите (контактните сервери) на p2p видео разговорите се наменети само за регистрирање корисници, складирање податоци за корисниците и воспоставување врска (префрлување) помеѓу прелистувачите на корисниците. Првите p2p видео разговори беа имплементирани со користење на флеш технологии. Флеш p2p видео разговори се користат, на пример, во во социјалните мрежи. Flash p2p видео разговорите не обезбедуваат висок квалитетпренос на мултимедијални податоци. Покрај тоа, за да емитувате глас и видео пренос од микрофонот и видео камерата во видео разговорите со флеш p2p, треба да инсталирате флеш приклучокво веб-прелистувач.

Но, новата генерација на телекомуникациски услуги вклучува веб-комуникации, кои користат само прелистувачи и контакт сервери кои поддржуваат протоколи WebRTC и спецификацијата HTML5 за комуникација преку Интернет. Секој кориснички уред (компјутер, iPad, паметни телефони итн.) опремен со таков прелистувач може да обезбеди висококвалитетни гласовни и видео повици, како и пренос на инстант текстуални пораки и датотеки.

Значи, новата технологија на веб-комуникации (p2p разговори, видео разговори) е протоколот WebRTC. WebRTC заедно со HTML5, CSS3 и JavaScript ви овозможуваат да креирате различни веб-апликации. WebRT е дизајниран да организира веб-комуникации (peer-to-peer мрежи) во реално време со користење на peer-to-peer архитектура. P2P разговорите базирани на WebRTC обезбедуваат пренос на датотеки, како и текстуална, гласовна и видео комуникација помеѓу корисниците преку Интернет користејќи само веб-прелистувачи без употреба на надворешни додатоци и додатоци во прелистувачот.

Во p2p разговорите, серверот се користи само за воспоставување на p2p врска помеѓу два прелистувачи. За креирање на клиентскиот дел од разговорот p2p врз основа на протоколот WebRTC, се користат HTML5, CSS3 и JavaScript. Клиентската апликација е во интеракција со прелистувачите преку WebRTC API.

WebRTC е имплементиран од три JavaScript API:

• RTCPeerConnection;
• MediaStream (getUserMedia);
• RTCDataChannel.

Прелистувачите пренесуваат медиумски податоци користејќи го протоколот SRTP, кој работи на врвот на UDP. Бидејќи NAT создава проблеми за прелистувачите (клиентите) зад NAT рутерите кои користат p2p конекции преку Интернет, STUN се користи за заобиколување на NAT преведувачите. STUN е протокол клиент-сервер кој работи на врвот на UDP транспортниот протокол. Во разговорите на p2p, по правило, се користи јавен STUN сервер, а информациите добиени од него се користат за UDP конекција помеѓу два прелистувачи доколку се зад NAT.

Примери за имплементација на WebRTC апликации (p2p разговори, гласовни и видео веб-разговори):
1. P2P видео разговор Bistri (видео разговор со еден клик, p2p разговор), базиран на WebRTC, може да се отвори на Бистри. Бистри работи во прелистувачот без да инсталира дополнителни програми и додатоци. Суштината на работата е како што следува: отворете p2p видео разговор користејќи ја наведената врска, откако ќе се регистрирате во интерфејсот што се отвора, поканете партнери, а потоа од листата на врснички клиенти изберете го партнерот што е онлајн и кликнете на „видео повикот " копче.

Како резултат на тоа, MediaStream (getUserMedia) ќе го сними микрофонот + веб камерата, а серверот ќе разменува сигнални пораки со избраниот партнер. По размена на сигнални пораки, PeerConnection API создава канали за пренос на гласовни и видео потоци. Покрај тоа, Бистри пренесува инстант текстуални пораки и датотеки. На сл. 1 прикажува слика од екранот на интерфејсот за видео разговор Bistri p2p.

Ориз. 1. P2P видео разговор Бистри

2. Twelephone (p2p видео разговор, p2p разговор, SIP Twelephone) - оваа клиентска апликација е изградена врз основа на HTML5 и WebRTC, која ви овозможува да остварувате гласовни и видео повици, како и да испраќате инстант текстуални пораки, т.е. Twelephone вклучува тест p2p разговор, видео разговор и SIP Twelephone. Треба да се напомене дека Twelephone го поддржува протоколот SIP и сега можете да остварувате и примате гласовни и видео повици од SIP телефони користејќи ја вашата сметка на Twitter како телефонски број. Освен тоа, текстуални поракиможете да внесувате гласовно преку микрофонот, а програмата за препознавање глас го внесува текстот во линијата „Испрати порака“.

Twelephone е веб-телефонија базирана на прелистувач Гугл хром, почнувајќи од верзијата 25, без дополнителни софтвер. Twelephone беше развиен од Крис Матие. Заднината Twelephone е изградена на Node.js. Серверот (серверот за контакт) се користи само за воспоставување p2p конекција помеѓу два прелистувачи или WebRTC клиенти. Апликацијата Twelephone нема свои алатки за авторизација, туку е фокусирана на поврзување со сметка ( сметка) на Твитер.

На сл. 2 прикажува слика од екранот на интерфејсот за видео разговор на Twelephone p2p.

Ориз. 2. P2P Twelphone

3. Групниот p2p видео разговор Conversat.io е изграден на најновите WebRTC и HTML5 технологии. Видео разговорот Conversat е развиен врз основа на библиотеката SimpleWebRTC и е наменет за комуникација помеѓу до 6 врснички клиенти во една просторија (за комуникација, наведете го името на заедничката просторија за врснички клиенти во линијата „Именувај го разговорот“). P2P видео разговор Conversat обезбедува комуникациски услуги на корисниците без да се регистрира на серверот за контакт. На сл. Слика 3 покажува слика од екранот на интерфејсот за видео разговор Conversat p2p.

Ориз. 3. Групен P2P видео разговор Conversat.io

За да учествуваат во P2P видео разговори базирани на WebRTC, корисниците мора да имаат инсталиран прелистувач кој го поддржува протоколот WebRTC и спецификацијата HTML5. Во моментов, прелистувачите на Google Chrome, почнувајќи од верзијата 25, и Mozilla Firefox Nightly го поддржува протоколот WebRTC и спецификацијата HTML5. WebRTC апликациите се супериорни во однос на Flash апликациите во однос на квалитетот на пренос на слика и звук.

Поголемиот дел од материјалот на WebRTC е фокусиран на апликациското ниво на кодирање и не придонесува за разбирање на технологијата. Ајде да се обидеме да одиме подлабоко и да дознаеме како се јавува врската, што се дескрипторот на сесијата и кандидатите, зошто се потребни серверите STUN и TURN.

WebRTC Вовед

WebRTC е технологија ориентирана кон прелистувачот која ви овозможува да поврзете два клиенти за пренос на видео податоци. Главните карактеристики се внатрешна поддршка на прелистувачот (нема потреба од имплементирани технологии од трета страна како што е adobe flash) и можност за поврзување клиенти без употреба на дополнителни сервери - peer-to-peer врска (во натамошниот текст, p2p).

Воспоставувањето врска p2p е прилично тешка задача, бидејќи компјутерите не секогаш имаат јавни IP адреси, односно адреси на Интернет. Поради малиот број на IPv4 адреси (и за безбедносни цели), беше развиен механизмот NAT, кој ви овозможува да креирате приватни мрежи, на пример, за домашна употреба. Многу домашни рутери сега поддржуваат NAT и благодарение на ова, сите домашни уреди имаат пристап до Интернет, иако интернет провајдерите обично обезбедуваат една IP адреса. Јавните IP адреси се единствени на Интернет, но приватните не се единствени. Затоа, поврзувањето на p2p е тешко.

За подобро да го разберете ова, разгледајте три ситуации: двата јазли се на иста мрежа (слика 1), двата јазли се на различни мрежи (еден приватен, другиот јавно) (Слика 2) и двата јазли се во различни приватни мрежи со истите IP адреси (слика 3).

Слика 1: Двата јазли на иста мрежа

Слика 2: Јазли во различни мрежи (една во приватна, една во јавна)

Слика 3: Јазли во различни приватни мрежи, но со нумерички еднакви адреси

На сликите погоре, првата буква во ознаката со два знака го означува типот на јазол (p = peer, r = рутер). На првата слика, ситуацијата е поволна: јазлите во нивната мрежа се целосно идентификувани со мрежните IP адреси и затоа можат директно да се поврзат еден со друг. На втората слика имаме две различни мрежи со слични броеви на јазли. Тука се појавуваат рутери (рутери), кои имаат два мрежен интерфејс– внатре во вашата мрежа и надвор од вашата мрежа. Затоа имаат две IP адреси. Редовните јазли имаат само еден интерфејс преку кој можат да комуницираат само во рамките на нивната мрежа. Ако тие пренесуваат податоци на некој надвор од нивната мрежа, тогаш само користејќи NAT внатре во рутерот (рутерот) и затоа се видливи за другите под IP адресата на рутерот - тоа е нивно надворешен IP адреса. Значи јазол p1 има внатрешни работи IP = 192.168.0.200 И надворешен IP = 10.50.200.5 , а последната адреса исто така ќе биде надворешна за сите други јазли во неговата мрежа. Слична е ситуацијата и за јазолот p2. Затоа, нивната комуникација е невозможна доколку се користат само нивните внатрешни (сопствени) IP адреси. Можете да користите надворешни адреси, односно адреси на рутер, но бидејќи сите јазли во истата приватна мрежа имаат иста надворешна адреса, ова е доста тешко. Овој проблем може да се реши со помош на механизмот NAT

Што ќе се случи ако одлучиме да ги поврземе јазлите преку нивните внатрешни адреси? Податоците нема да ја напуштат мрежата. За да го подобрите ефектот, можете да ја замислите ситуацијата прикажана на последната слика - двата јазли имаат исти внатрешни адреси. Ако ги користат за да комуницираат, тогаш секој јазол ќе комуницира со себе.

WebRTC успешно се справува со ваквите проблеми користејќи го протоколот ICE, кој, сепак, бара употреба на дополнителни сервери (STUN, TURN). Повеќе за сето ова подолу.

Две фази на WebRTC

За да поврзете два јазли преку протоколот WebRTC (или едноставно RTC, ако комуницираат два iPhone), треба да извршите некои прелиминарни чекори за да ја воспоставите врската. Ова е првата фаза - воспоставување врска. Втората фаза е пренос на видео податоци.

Вреди да се каже веднаш дека иако технологијата WebRTC користи многу на различни начиникомуникации (TCP и UDP) и има флексибилно префрлување меѓу нив, оваа технологија нема протокол за пренос на податоци за поврзување. Не е изненадувачки, бидејќи поврзувањето на два p2p јазли не е толку лесно. Затоа е неопходно да се има малку дополнителниметод на пренос на податоци кој на никаков начин не е поврзан со WebRTC. Може да биде пренос на сокет, HTTP протокол, дури може да биде SMTP протоколили Руска пошта. Овој механизам за пренос почетнасе нарекува податок сигнал. Не треба да се пренесуваат многу информации. Сите податоци се пренесуваат во текстуална форма и се поделени на два вида - SDP и Ice Candidate. Првиот тип се користи за воспоставување логичка врска, а вториот за физичка врска. Повеќе за сето ова подоцна, но засега е само важно да се запамети дека WebRTC ќе ни даде некои информации што ќе треба да се пренесат на друг јазол. Штом ги пренесеме сите потребни информации, јазлите ќе можат да се поврзат и нашата помош повеќе нема да биде потребна. Значи, сигналниот механизам што треба да го имплементираме е одделно, ќе се користи само кога е поврзан, но нема да се користи при пренос на видео податоци.

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

• Иницијатор (повикувач):
• Понуда за почеток на пренос на видео податоци (креирајПонуда)
• Добивање на вашиот SDP SDP)
• Примање на вашиот кандидат за мраз Ice кандидат)
• Повик на чекање (callee):
• Примање локален (ваш) медиумски поток и негово поставување за пренос (getUserMediaStream)
• Примање понуда за почеток на пренос на видео податоци и креирање одговор (createAnswer)
• Примање на неговиот SDP објект и пренесување низ механизмот за сигнализација (SDP)
• Примање на вашите објекти-кандидат за мраз и нивно пренесување низ механизам за сигнализација (кандидат за мраз)
• Примање далечински (странски) медиумски пренос и негово прикажување на екранот (onAddStream)

Разликата е само во втората точка.

И покрај очигледната сложеност на чекорите, всушност има три од нив: испраќање сопствен медиумски пренос (точка 1), поставување параметри за поврзување (точки 2-4), примање туѓ медиумски пренос (точка 5). Најтешкиот чекор е вториот чекор, бидејќи се состои од два дела: воспоставување физичкиИ логичноврски. Првиот укажува патека, по кој мора да патуваат пакетите за да стигнат од еден мрежен јазол до друг. Вториот укажува видео/аудио параметри– каков квалитет да се користи, какви кодеци да се користат.

Ментално, фазата createOffer или createAnswer треба да се поврзе со фазите на полагање на објектите кандидати за SDP и Ice.

Основни ентитети Медиумски преноси (MediaStream)

Главниот ентитет е медиумскиот поток, односно потокот на видео и аудио податоци, слика и звук. Постојат два вида медиумски преноси - локални и далечински. Локалниот прима податоци од влезните уреди (камера, микрофон), а далечинскиот преку мрежата. Така, секој јазол има и локална и оддалечена нишка. Во WebRTC, постои интерфејс MediaStream за преноси, а исто така има и подинтерфејс LocalMediaStream специјално за локален пренос. Во JavaScript можете да го сретнете само првото, но ако користите libjingle можете да го сретнете и вториот.

WebRTC има прилично збунувачка хиерархија во нишката. Секој пренос може да се состои од неколку медиумски траки (MediaTrack), кои пак може да се состојат од неколку медиумски канали (MediaChannel). И, исто така, може да има неколку медиумски преноси.

Ајде да погледнеме сè по ред. За да го направите ова, да имаме на ум некој пример. Да речеме дека сакаме да пренесеме не само видео од нас, туку и видео од нашата маса, на кое лежи парче хартија на кое ќе напишеме нешто. Ќе ни требаат две видеа (нас + маса) и едно аудио (нас). Јасно е дека ние и табелата треба да се поделиме во различни нишки, бидејќи овие податоци веројатно слабо зависат еден од друг. Затоа, ќе имаме два MediaStream - еден за нас и еден за масата. Првиот ќе содржи и видео и аудио податоци, а вториот ќе содржи само видео (слика 4).

Слика 4: Два различни медиумски текови. Еден за нас, еден за нашата маса

Веднаш е јасно дека медиумскиот поток на минимум мора да вклучува способност да содржи податоци различни типови- видео и аудио. Ова е земено предвид во технологијата и затоа секој тип на податоци се имплементира преку медиумска песна MediaTrack. Медиумската песна има посебен вид на својство , што одредува дали е видео или аудио (Слика 5)

Слика 5: Медиумските преноси се состојат од медиумски траки

Како ќе се случи сè во програмата? Ќе создадеме два медиумски струи. Потоа ќе создадеме две видео нумери и една аудио песна. Ајде да добиеме пристап до камерите и микрофонот. Ајде да ѝ кажеме на секоја песна кој уред да го користи. Ајде да додадеме видео и аудио песна на првиот медиумски пренос и видео песна од друга камера на вториот медиумски пренос.

Но, како да ги разликуваме медиумските текови на другиот крај на врската? За да го направите ова, секој медиумски поток има својство на етикета - етикетата на потокот, неговото име (слика 6). Медиумските траки го имаат истиот имот. Иако на прв поглед се чини дека видеото може да се разликува од звукот на други начини.

Слика 6: Медиумските преноси и траки се идентификуваат со етикети

Значи, ако медиумските траки може да се идентификуваат преку ознака, тогаш зошто треба да користиме два медиумски текови за нашиот пример, наместо еден? На крајот на краиштата, можете да пренесете еден медиумски поток, но да користите различни песни во него. Стигнавме до една важна сопственост на медиумските текови - тие синхронизираатмедиумски песни. Различни медиумски преноси не се синхронизираат еден со друг, туку во секој медиумски пренос сите траки се играат истовремено.

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

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

Конечно, вреди да се размислува за стерео звук. Како што знаете, стерео звукот е два различни звуци. И тие исто така мора да се пренесат одделно. За ова се користат MediaChannels. Медиумска аудио песна може да има многу канали (на пример, 6 ако ви треба 5+1 аудио). Има и канали во медиумските траки, се разбира. синхронизиран. За видео, обично се користи само еден канал, но може да се користат неколку, на пример, за преклопување на рекламирање.

За да резимираме:Ние користиме медиумски поток за пренос на видео и аудио податоци. Во секој медиумски поток, податоците се синхронизираат. Можеме да користиме повеќе медиумски преноси ако не ни треба синхронизација. Внатре во секој медиумски пренос има два вида медиумски траки - за видео и за аудио. Обично нема повеќе од две песни, но може да има повеќе ако треба да пренесете неколку различни видеа (на соговорникот и неговата маса). Секоја песна може да се состои од неколку канали, кои обично се користат само за стерео звук.

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

Опис на сесија (SDP)

Различни компјутери секогаш ќе имаат различни камери, микрофони, видео картички и друга опрема. Има многу опции што ги имаат. Сето ова мора да се координира за медиумски пренос на податоци помеѓу два мрежни јазли. WebRTC го прави ова автоматски и создава посебен објект– Опис на сесијата на СДП. Пренесете го овој објект на друг јазол и медиумските податоци може да се пренесат. Само што сè уште нема врска со друг јазол.

За ова се користи кој било механизам за сигнализација. SDP може да се пренесе или преку приклучоци, или од лице (кажете му на друг јазол по телефон) или од Руската пошта. Сè е многу едноставно - ќе ви биде даден готов SDP и треба да го испратите. И кога ќе го добиете од другата страна, префрлете го во одделот WebRTC. Описот на сесијата е зачуван како текст и може да се менува во вашите апликации, но тоа генерално не е потребно. На пример, кога поврзувате десктоп ↔ телефон, понекогаш треба да го присилите изборот на саканиот аудио кодек.

Обично, кога воспоставувате врска, мора да наведете некој вид адреса, како што е URL-то. Ова не е неопходно овде, бидејќи преку механизмот за сигнализација вие самите ќе ги испратите податоците до нивната дестинација. За да му укажеме на WebRTC дека сакаме да воспоставиме врска p2p, треба да ја повикаме функцијата createOffer. Откако ќе ја повикате оваа функција и ќе наведете специјален повратен повик 'a, ќе се креира објект SDP и ќе биде предаден на истиот повратен повик. Сè што се бара од вас е да го пренесете овој објект преку мрежата на друг јазол (соговорник). По ова, податоците ќе пристигнат на другиот крај преку механизмот за сигнализација, имено овој SDP објект. Овој дескриптор на сесија е туѓ за овој јазол и затоа носи корисни информации. Примањето на овој објект е сигнал за започнување на врската. Затоа, мора да се согласите со ова и да ја повикате функцијата createAnswer. Тоа е целосен аналог на createOffer. Повторно, дескрипторот на локалната сесија ќе биде предаден на вашиот повратен повик и ќе треба да се пренесе назад преку механизмот за сигнализација.

Вреди да се напомене дека можете да ја повикате функцијата createAnswer само откако ќе добиете туѓ SDP објект. Зошто? Бидејќи локалниот SDP објект што ќе се генерира при повикување createAnswer мора да се потпира на далечинскиот објект SDP. Само во овој случај е можно да ги координирате вашите поставки за видео со поставките на вашиот соговорник. Исто така, не треба да ги повикувате createAnswer и createOffer пред да го примите локалниот медиумски пренос - тие нема да имаат што да напишат на објектот SDP.

Бидејќи WebRTC има можност да уредува објект SDP, по добивањето на локален дескриптор треба да се инсталира. Можеби изгледа малку чудно што треба да го пренесеме на WebRTC она што самиот ни го даде, но тоа е протоколот. Кога ќе се прими далечинска рачка, таа исто така мора да се инсталира. Затоа, мора да инсталирате два дескриптори на еден јазол - ваш и туѓ (т.е. локален и оддалечен).

По ова ракувањејазлите знаат за желбите на едни со други. На пример, ако јазолот 1 поддржува кодеци A и B, а јазолот 2 поддржува кодеци B и C, тогаш, бидејќи секој јазол ги знае своите и дескрипторите на другиот, двата јазли ќе изберат кодек B (Слика 7). Логиката за поврзување сега е воспоставена и медиумските струи може да се пренесат, но има уште еден проблем - јазлите сè уште се поврзани само со механизам за сигнализација.

Слика 7: Преговарање за кодек

Кандидат за мраз

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

Значи, врската е веќе воспоставена (логичка врска), но сè уште нема патека по која мрежните јазли можат да пренесуваат податоци. Не е сè толку едноставно, но да почнеме едноставно. Јазлите нека бидат на истата приватна мрежа. Како што веќе знаеме, тие лесно можат да се поврзат едни со други користејќи ги нивните внатрешни IP адреси (или можеби некои други, ако не се користи TCP/IP).

Преку одреден повратен повик и WebRTC нè информира за објектите кандидат за мраз. Тие исто така доаѓаат во текстуална форма и, како и дескрипторите на сесиите, тие едноставно треба да бидат испратени преку механизам за сигнализација. Ако дескрипторот на сесијата содржеше информации за нашите поставки на ниво на камера и микрофон, тогаш кандидатите содржат информации за нашата локација на мрежата. Пренесете ги на друг јазол и тој ќе може физички да се поврзе со нас, а бидејќи веќе има дескриптор за сесија, логично ќе може да се поврзе и податоците ќе „течат“. Доколку се сети да ни го испрати својот кандидатски објект, односно информации за тоа каде се наоѓа самиот на мрежата, тогаш ќе можеме да се поврземе со него. Дозволете ни да забележиме овде уште една разлика од класичната интеракција клиент-сервер. Комуникацијата со серверот HTTP се јавува според шемата за одговор-барање, клиентот испраќа податоци до серверот, кој ги обработува и ги испраќа преку адресата наведена во пакетот за барање. Во WebRTC треба да знаете две адресии поврзете ги од двете страни.

Разликата од дескрипторите на сесиите е во тоа што треба да се инсталираат само далечински кандидати. Уредувањето овде е забрането и не може да донесе никаква корист. Во некои имплементации на WebRTC, кандидатите треба да се инсталираат само откако ќе се постават дескриптори на сесии.

Зошто имаше само еден дескриптор за сесија, но може да има многу кандидати? Бидејќи локацијата на мрежата може да се одреди не само од нејзината внатрешна IP адреса, туку и од надворешната адреса на рутерот, а не нужно само една, како и адресите на серверите TURN. Остатокот од параграфот ќе биде посветен на детална дискусија за кандидатите и како да се поврзат јазлите од различни приватни мрежи.

Значи, два јазли се на иста мрежа (Слика 8). Како да ги идентификувате? Користење на IP адреси. Нема друг начин. Точно, сè уште можете да користите различни транспорти (TCP и UDP) и различни порти. Ова се информациите што се содржани во објектот кандидат - IP, PORT, TRANSPORT и некои други. Нека, на пример, користете UDP транспорт и порта 531.

Слика 8: Два јазли се на иста мрежа

Потоа, ако сме во јазол p1, тогаш WebRTC ќе ни даде таков кандидат објект - . Ова не е точен формат, само дијаграм. Ако сме на јазолот p2, тогаш кандидатот е . Преку механизмот за сигнализација, p1 ќе го прими кандидатот на p2 (односно, локацијата на јазолот p2, имено неговата IP и PORT). Тогаш p1 може директно да се поврзе со p2. Поточно, p1 ќе испрати податоци до 10.50.150.3:531 со надеж дека ќе достигне p2. Не е важно дали оваа адреса припаѓа на јазолот p2 или на некој посредник. Единствено важно е дека податоците ќе се испраќаат преку оваа адреса и ќе можат да стигнат до p2.

Сè додека јазлите се на иста мрежа, сè е едноставно и лесно - секој јазол има само еден кандидат објект (секогаш значи свој, односно неговата локација во мрежата). Но, ќе има многу повеќе кандидати кога ќе се вклучат јазлите различнимрежи.

Да преминеме на покомплексен случај. Еден јазол ќе се наоѓа зад рутерот (поточно, зад NAT), а вториот јазол ќе се наоѓа на истата мрежа со овој рутер (на пример, на Интернет) (Слика 9).

Слика 9: Еден јазол е зад NAT, а другиот не е

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

Да претпоставиме дека веб-серверот е директно поврзан на Интернет, односно има јавна IP * адреса. Ова нека биде јазол p2. Јазол p1 (веб клиент) испраќа барање на адресата 10.50.200.10. Прво, податоците одат до рутерот r1, поточно до неговиот внатрешни работиинтерфејс 192.168.0.1. После тоа, рутерот се сеќава на изворната адреса (адреса p1) и ја внесува во посебна NAT табела, а потоа ја менува изворната адреса во своја (p1 → r1). Понатаму, на мој начин надворешенинтерфејс, рутерот испраќа податоци директно до веб-серверот p2. Веб-серверот ги обработува податоците, генерира одговор и ги испраќа назад. Испраќа r1 до рутерот, бидејќи е во повратната адреса (рутерот ја замени адресата со своја). Рутерот ги прима податоците, ја гледа табелата NAT и ги препраќа податоците до јазолот p1. Рутерот овде делува како посредник.

Што ако неколку јазли од внатрешната мрежа истовремено пристапуваат до надворешната мрежа? Како рутерот ќе разбере кому да го испрати одговорот? Овој проблем е решен со користење пристаништа. Кога рутерот ја заменува адресата на домаќинот со своја, тој исто така ја заменува и портата. Ако два јазли пристапуваат на Интернет, тогаш рутерот ги заменува нивните изворни порти со различни. Потоа, кога пакетот од веб-серверот ќе се врати на рутерот, рутерот ќе разбере од пристаништето на кого е доделен пакетот. Пример подолу.

Да се ​​вратиме на технологијата WebRTC, или поточно, на делот од неа што го користи протоколот ICE (оттука и кандидатите за мраз). Јазолот p2 има еден кандидат (неговата локација во мрежата е 10.50.200.10), а јазолот p1, кој се наоѓа зад рутерот со NAT, ќе има два кандидати - локален (192.168.0.200) и кандидат за рутер (10.50.200.5). Првиот не е корисен, но сепак е генериран, бидејќи WebRTC сè уште не знае ништо за оддалечениот јазол - може или не е на истата мрежа. Вториот кандидат ќе ни се најде, а како што веќе знаеме, пристаништето (за да се помине преку NAT) ќе игра важна улога.

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

На пракса двата јазлиќе биде зад НАТ. За да се создаде запис во NAT табелата на секој рутер, домаќините мора да испратат нешто до оддалечениот домаќин, но овој пат ниту првиот не може да го достигне вториот ниту обратно. Ова се должи на фактот што јазлите не ги знаат нивните надворешни IP адреси, а испраќањето податоци на внатрешни адреси е бесмислено.

Меѓутоа, ако надворешните адреси се познати, врската лесно ќе се воспостави. Ако првиот јазол испрати податоци до рутерот на вториот јазол, рутерот ќе го игнорира, бидејќи неговата NAT табела е сè уште празна. Меѓутоа, во рутерот на првиот јазол, се појави неопходен запис во табелата NAT. Ако сега вториот јазол испраќа податоци до рутерот на првиот јазол, тогаш рутерот успешно ќе ги пренесе на првиот јазол. Сега табелата NAT на вториот рутер ги има и потребните податоци.

Проблемот е што за да ја дознаете вашата надворешна IP адреса, потребен ви е јазол лоциран во споделена мрежа. За да се реши овој проблем, се користат дополнителни сервери кои се директно поврзани на Интернет. Со нивна помош, вредните записи се креираат и во табелата NAT.

STUN и TURN сервери

При иницијализирање на WebRTC, треба да ги наведете достапните сервери STUN и TURN, кои отсега ќе ги нарекуваме ICE сервери. Ако серверите не се наведени, тогаш само јазлите на истата мрежа (поврзани со неа без NAT) ќе можат да се поврзат. Веднаш вреди да се напомене дека за 3g мрежи употребата на сервери TURN е задолжителна.

ЗАПРЕДУВАЊЕ сервере едноставно сервер на Интернет кој враќа повратна адреса, односно адреса на јазолот на испраќачот. Домаќинот зад рутерот контактира со STUN серверот за да помине NAT. Пакетот што дојде до серверот STUN ја содржи изворната адреса - адресата на рутерот, односно надворешната адреса на нашиот јазол. Ова е адресата STUN што серверот ја враќа назад. Така, јазолот ја прима својата надворешна IP адреса и портата преку која е достапен од мрежата. Следно, WebRTC ја користи оваа адреса за да создаде дополнителен кандидат (адреса на надворешен рутер и порта). Сега има запис во NAT табелата на рутерот што им овозможува на пакетите испратени до рутерот на потребната порта да стигнат до нашиот јазол.

Да го погледнеме овој процес со пример.

Пример (работа со STUN сервер)

Серверот STUN ќе биде означен со s1. Рутерот, како и досега, е преку r1, а јазолот е преку p1. Исто така, ќе треба да ја следите табелата NAT - ќе ја означиме како r1_nat. Покрај тоа, оваа табела обично содржи многу записи од различни јазли на подмрежата - тие нема да бидат дадени.

Значи, на почетокот имаме празна табела r1_nat.

Табела 2: Заглавие на пакети

Јазолот p1 го испраќа овој пакет до рутерот r1 (без разлика како, различни подмрежи можат да користат различни технологии). Рутерот треба да ја замени изворната адреса Src IP, бидејќи адресата наведена во пакетот очигледно не е погодна за надворешна подмрежа; згора на тоа, адресите од таков опсег се резервирани и ниту една адреса на Интернет нема таква адреса. Рутерот прави замена во пакетот и создава нов влезво вашата табела r1_nat. За да го направите ова, тој треба да излезе со број на порта. Потсетете се дека бидејќи неколку хостови во подмрежа можат да пристапат до надворешна мрежа, табелата NAT мора да складира дополнителни информации, така што рутерот може да одреди кој од овие неколку јазли е наменет за повратниот пакет од серверот. Нека рутерот излезе со порта 888.

Променет заглавие на пакетот:

Табела 4: Табелата NAT е ажурирана со нов запис

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

Вистинската порта на која јазолот p1 ја прифаќа врската е, се разбира, 35777, но серверот испраќа податоци до фиктивнипорта 888, која рутерот ќе ја смени во вистинската 35777.

Значи, рутерот ги замени изворната адреса и портата во заглавието на пакетот и додаде запис во табелата NAT. Сега пакетот се испраќа преку мрежата до серверот, односно јазолот s1. На влезот, s1 го има следниот пакет:

Src IP Src PORT Dest IP Destin PORT

10.50.200.5	888	12.62.100.200	6000

Табела 5: STUN сервер примен пакет

Севкупно, серверот STUN знае дека добил пакет од адресата 10.50.200.5:888. Сега серверот ја испраќа оваа адреса назад. Вреди да застанеме овде и уште еднаш да го погледнеме она што штотуку го погледнавме. Табелите погоре се фрагмент од заглавиепакет, воопшто не од него содржина. Не зборувавме за содржината, бидејќи не е толку важна - некако е опишано во протоколот STUN. Сега ќе ја разгледаме, покрај насловот, и содржината. Ќе биде едноставно и ќе ја содржи адресата на рутерот - 10.50.200.5:888, иако ја презедовме од заглавиепакет. Ова не се прави често; протоколите обично не се грижат за информациите за адресите на јазлите; важно е само пакетите да бидат доставени до нивната наменета дестинација. Овде гледаме протокол кој воспоставува патека помеѓу два јазли.

Значи, сега имаме втор пакет што оди во спротивна насока:

Табела 7: STUN серверот испраќа пакет со оваа содржина

Следно, пакетот патува низ мрежата додека не стигне до надворешниот интерфејс на рутерот r1. Рутерот разбира дека пакетот не е наменет за него. Како тој го разбира ова? Ова може да го одреди само пристаништето. Тој не ја користи портата 888 за свои лични цели, туку ја користи за NAT механизмот. Затоа, рутерот ја гледа оваа табела. Ја гледа колоната External PORT и бара линија што одговара на Dest PORT од дојдовниот пакет, односно 888.

Внатрешна IP Внатрешна порта Надворешна IP Надворешна порта

192.168.0.200	35777	10.50.200.5	888

Табела 8: Табела NAT

Имаме среќа, таква линија постои. Ако немавме среќа, пакетот едноставно ќе беше фрлен. Сега треба да разберете кој јазол на подмрежата треба да го испрати овој пакет. Нема потреба да брзате, ајде повторно да се потсетиме на важноста на пристаништата во овој механизам. Во исто време, два јазли на подмрежата може да испраќаат барања до надворешната мрежа. Потоа, ако рутерот излезе со порта 888 за првиот јазол, тогаш за вториот ќе излезе со порта 889. Да претпоставиме дека ова се случило, односно табелата r1_nat изгледа вака:

Табела 10: Рутерот ја заменува адресата на приемникот

Src IP Src PORT Dest IP Destin PORT

12.62.100.200	6000	192.168.0.200	35777

Табела 11: Рутерот ја смени адресата на приемникот

Пакетот успешно пристигнува до јазолот p1 и, гледајќи ја содржината на пакетот, јазолот дознава за неговата надворешна IP адреса, односно адресата на рутерот на надворешната мрежа. Го знае и портот што рутерот минува низ NAT.

Што е следно? Која е користа од сето ова? Придобивка е внесување во табелата r1_nat. Ако сега некој испрати пакет со порта 888 на рутерот r1, тогаш рутерот ќе го препрати овој пакет до јазолот p1. Ова создаде мал тесен премин до скриениот јазол p1.

Од примерот погоре можете да добиете одредена идеја за тоа како функционира NAT и суштината на серверот STUN. Општо земено, механизмот ICE и серверите STUN/TURN се прецизно насочени кон надминување на ограничувањата на NAT.

Помеѓу јазолот и серверот не може да има еден рутер, туку неколку. Во овој случај, јазолот ќе ја добие адресата на рутерот кој прв пристапува до истата мрежа како и серверот. Со други зборови, ќе ја добиеме адресата на рутерот поврзан со серверот STUN. За p2p комуникација, тоа е токму она што ни треба, ако не го заборавиме фактот дека секој рутер ќе ја додаде линијата што ни треба на табелата NAT. Затоа, патот назад повторно ќе биде исто толку мазен.

TURN серверот е подобрен STUN сервер. Оттука треба веднаш да одземете дека секој TURN сервер може да работи и како STUN сервер. Сепак, има и предности. Ако комуникацијата p2p е невозможна (како, на пример, во мрежите 3g), тогаш серверот се префрла во режим на реле, односно работи како посредник. Се разбира, тогаш не зборуваме за било каков p2p, но надвор од механизмот ICE, јазлите мислат дека директно комуницираат.

Во кои случаи е неопходен серверот TURN? Зошто нема доволно STUN сервер? Факт е дека постојат неколку видови NAT. Тие ги заменуваат IP адресата и портата на ист начин, но некои од нив имаат дополнителна заштита од „фалсификување“ вградена во нив. На пример, во симетричниТабелата NAT складира уште 2 параметри - IP и порта на оддалечениот јазол. Пакет од надворешната мрежа поминува низ NAT до внатрешната мрежа само ако изворната адреса и портата се совпаѓаат со оние што се запишани во табелата. Затоа, трикот со серверот STUN не успее - табелата NAT ги складира адресата и портата на серверот STUN и, кога рутерот ќе прими пакет од соговорникот WebRTC, го отфрла затоа што е „фалсификуван“. Не дојде од STUN серверот.

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

Кратко резиме

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

• Медиумски поток
  • Видео и аудио податоци се спакувани во медиумски потоци
  • Медиумските преноси ги синхронизираат медиумските записи што ги сочинуваат
  • Различни медиумски преноси не се синхронизираат едни со други
  • Медиумските преноси можат да бидат локални и далечински, локалниот обично е поврзан со камера и микрофон, далечинските добиваат податоци од мрежата во шифрирана форма
  • Постојат два вида медиумски траки - за видео и за аудио.
  • Медиумските траки имаат можност за вклучување/исклучување
  • Медиумските траки се состојат од медиумски канали
  • Медиумските траки ги синхронизираат медиумските канали што ги сочинуваат
  • Медиумските текови и медиумските записи имаат ознаки по кои можат да се разликуваат
• Рачка за сесија
  • Описот на сесијата се користи за логично поврзување на два мрежни јазли
  • Описот на сесијата складира информации за достапни начиникодирање видео и аудио податоци
  • WebRTC користи надворешен механизам за сигнализација - задачата за препраќање дескриптори на сесии (sdp) паѓа на апликацијата
  • Механизмот за логично поврзување се состои од две фази - понуда (понуда) и одговор (одговор)
  • Генерирањето на дескриптор на сесија е невозможно без користење на локален медиумски поток во случај на понуда и е невозможно без користење на далечински дескриптор на сесија во случај на одговор.
  • Добиениот дескриптор мора да биде даден на имплементацијата на WebRTC и не е важно дали овој дескриптор се прима од далечина или локално од истата имплементација WebRTC
  • Можно е малку да се уреди дескрипторот на сесијата
• Кандидатите
  • Кандидат за мраз е адресата на јазол во мрежата
  • Адресата на јазолот може да биде ваша, или може да биде адреса на рутер или сервер TURN
  • Секогаш има многу кандидати
  • Кандидатот се состои од IP адреса, порта и тип на транспорт (TCP или UDP)
  • Кандидатите се користат за воспоставување физичка врска помеѓу два јазли во мрежата
  • Кандидатите треба да бидат испратени и преку механизам за сигнализација
  • Кандидатите исто така треба да се пренесат на имплементации на WebRTC, но само на далечински
  • Во некои имплементации на WebRTC, кандидатите може да се пренесат само откако ќе се постави дескриптор за сесија
• STUN/TURN/ICE/NAT
  • NAT е механизам за обезбедување пристап до надворешна мрежа
  • Домашните рутери поддржуваат специјална NAT табела
  • Рутерот ги заменува адресите во пакетите - изворната адреса со своја, ако пакетот оди во надворешна мрежа, а адресата на примачот со адресата на домаќинот на внатрешната мрежа, ако пакетот доаѓа од надворешна мрежа.
  • За да обезбеди повеќеканален пристап до надворешна мрежа, NAT користи порти
  • ICE - NAT Траверзален мотор
  • Сервери STUN и TURN – помошни сервери за NAT траверсирање
  • STUN серверот ви овозможува да ги креирате потребните записи во табелата NAT, а исто така ја враќа надворешната адреса на домаќинот
  • Серверот TURN го генерализира STUN механизмот и го прави секогаш да работи
  • Во најлошите случаи, серверот TURN се користи како посредник (реле), односно p2p се претвора во врска клиент-сервер-клиент.

Денес, WebRTC е „жешката“ технологија за пренос на аудио и видео во прелистувачите. Конзервативните технологии, како што се HTTP Streaming и Flash, се посоодветни за дистрибуција на снимена содржина (видео на барање) и се значително инфериорни во однос на WebRTC во однос на преносите во реално време и онлајн, т.е. каде што е потребна минимална латентност на видеото за да им се овозможи на гледачите да видат што се случува „во живо“.

Можноста за висококвалитетна комуникација во реално време доаѓа од самата архитектура WebRTC, каде што протоколот UDP се користи за транспорт на видео стримови, што е стандардна основа за пренос на видео со минимални доцнења и е широко користен во комуникациските системи во реално време.

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

Друга добра причина да се обидете со WebRTC е тоа што дефинитивно е тренд. Денес секој Андроид Прелистувач Хромја поддржува оваа технологија, која гарантира дека милиони уреди се подготвени да го гледаат емитувањето без да инсталираат дополнителен софтвер или конфигурации.

Со цел да се тестира WebRTC технологијата во акција и да се изврши едноставна онлајн емитување, користевме софтвер за сервер за сервер за медиуми и радиодифузија Flashphoner WebRTC. Карактеристиките ја наведуваат можноста за емитување на WebRTC стримови во режим еден-на-многу, како и поддршка за IP камери и системи за видео надзор преку протоколот RTSP; Во овој преглед ќе се фокусираме на веб-веб преносите и нивните карактеристики.

Инсталирање на WebRTC Media & Broadcasting Server

Бидејќи за Windows системинемаше верзија на серверот и не сакав да инсталирам виртуелна машина како VMWare+Linux, за да можам да тестирам онлајн емитувања дома Виндоус компјутерНе успеа. За да заштедиме време, решивме да земеме пример за облак хостинг вака:

Тоа беше Centos x86_64 верзија 6.5 без претходно инсталиран софтвер во центарот за податоци во Амстердам. Така, сè што имаме на располагање е серверот и ssh пристапот до него. За оние кои се запознаени со команди на конзолата Linux, инсталирањето на WebRTC сервер ветува дека ќе биде едноставно и безболно. Па што направивме:

1. Преземете ја архивата:

$wget https://site/download-wcs5-server.tar.gz

2. Отпакувајте:

$tar -xzf преземање-wcs5-server.tar.gz

3. Инсталирајте:

$cd FlashphonerWebCallServer

За време на инсталацијата, внесете ја IP адресата на серверот: XXX.XXX.XXX.XXX

4. Активирајте ја лиценцата:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. Стартувајте WCS сервер:

Стартување на веб-серверот за $service

6. Проверете го дневникот:

$tail - f /usr/local/FlashphonerWebCallServer/logs/flashphoner_manager.log

7. Проверете дали двата процеса се на место:

$ps aux | grep Flashphoner

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

Тестирање на WebRTC онлајн емитувања

Тестирањето на преносите се покажа како едноставна работа. Покрај серверот, постои веб-клиент, кој се состои од десетина Javascript, HTML и CSS датотеки и беше распореден од нас во папката /var/www/html за време на фазата на инсталација. Единственото нешто што требаше да се направи е да се внесе IP адресата на серверот во конфигурацијата flashphoner.xml за да може веб-клиентот да воспостави врска со серверот преку HTML5 Websockets. Ајде да го опишеме процесот на тестирање.

1. Отворете ја страницата за тест-клиент index.html во прелистувачот Chrome:

2. За да започнете со емитување, треба да кликнете на копчето „Start“ во средината на екранот.
Пред да го направите ова, треба да бидете сигурни дека веб-камерата е поврзана и подготвена за употреба. Нема посебни барања за веб камерата, на пример, користевме стандардна камера вградена во лаптоп со резолуција од 1280x800.

Прелистувачот Chrome дефинитивно ќе побара пристап до камерата и микрофонот, така што корисникот ќе разбере дека неговото видео ќе биде испратено до серверот на Интернет и ќе го дозволи тоа.

3. Интерфејсот претставува успешно емитување на видео потокот од камерата до серверот WebRTC. Во горниот десен агол, индикаторот покажува дека преносот оди на серверот; во долниот агол има копче „Стоп“ за да престане да го испраќа видеото.

Забележете ја врската во полето подолу. Содржи единствен идентификатор за овој пренос, така што секој може да се придружи на гледањето. Само отворете ја оваа врска во вашиот прелистувач. За да го копирате на таблата со исечоци, кликнете на копчето „Копирај“.

Во реални апликации како што се вебинари, предавања, онлајн видео преноси или интерактивна телевизија, програмерите ќе треба да ја имплементираат дистрибуцијата на овој идентификатор до одредени групи гледачи за да можат да се поврзат со саканите преноси, но ова е веќе логиката на апликацијата . WebRTC Media & Broadcasting Server не влијае на него, туку само дистрибуира видео.

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

Резултати од тестирањето на WebRTC серверот за онлајн емитување

За време на тестовите, латентноста изгледаше совршена. Пингот до центарот за податоци беше околу 100 милисекунди и доцнењето беше невидливо за око. Од тука, можеме да претпоставиме дека вистинското доцнење е исто 100 плус или минус неколку десетици милисекунди за времето на баферирање. Во споредба со Flash видео: во такви тестови, Flash не се однесува толку добро како WebRTC. Значи, ако ја движите раката на слична мрежа, движењето на екранот може да се види само по една или две секунди.

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

Серверот е прилично лесен за инсталирање и конфигурирање; неговото работење не бара никакви сериозни вештини освен познавање на Linux на ниво на напреден корисник кој може да извршува команди од конзолата преку ssh и да користи уредувач на текст. Како резултат на тоа, успеавме да поставиме онлајн пренос од еден до многу помеѓу прелистувачите. Поврзувањето дополнителни гледачи со преносот исто така не претставуваше никакви проблеми.

Се покажа дека квалитетот на емитувањето е сосема прифатлив за вебинари и онлајн преноси. Единственото нешто што покрена некои прашања беше резолуцијата на видеото. Камерата поддржува 1280x800, но резолуцијата на сликата за тестирање е многу слична на 640x480. Очигледно, ова прашање треба да се разјасни со програмерите.

Видео за тестирање емитувано од веб камера
преку WebRTC сервер

Технологиите за остварување повици од прелистувачот постојат многу години: Java, ActiveX, Adobe Flash...Во последните неколку години стана јасно дека приклучоците и лево виртуелни машиниТие не светат со практичност (зошто воопшто да инсталирам нешто?) и што е најважно, со безбедност. Што да се прави? Има излез!

До неодамна, IP мрежите користеа неколку протоколи за IP телефонија или видео: SIP, најчестиот протокол, H.323 и MGCP излегуваа од сцената, Jabber/Jingle (се користи во Gtalk), полуотворен Adobe RTMP* и, се разбира , затворен Skype. Проектот WebRTC, инициран од Google, се обидува да ја промени состојбата на работите во светот на IP и веб-телефонијата, правејќи ги сите меки телефони, вклучувајќи го и Skype. WebRTC не само што ги имплементира сите комуникациски способности директно во прелистувачот, кој сега е инсталиран на речиси секој уред, туку истовремено се обидува да реши и поопшт проблем на комуникација помеѓу корисниците на прелистувачот (размена на различни податоци, емитување на екранот, соработка со документи и многу повеќе).

WebRTC од перспектива на веб-развивачот

Од гледна точка на веб-развивач, WebRTC се состои од два главни дела:

• контрола на медиумски преноси од локални ресурси (камера, микрофон или екран локален компјутер) се имплементира со методот navigator.getUserMedia, кој враќа објект MediaStream;
• peer-to-peer комуникација помеѓу уредите кои генерираат медиумски потоци, вклучувајќи дефинирање на методи на комуникација и нивно директно пренесување - објекти RTCPeerConnection (за испраќање и примање аудио и видео потоци) и RTCDataChannel (за испраќање и примање податоци од прелистувачот).

Што ќе правиме?

Ќе сфатиме како да организираме едноставен мулти-кориснички видео разговор помеѓу прелистувачите базирани на WebRTC користејќи веб-сокети. Ќе почнеме да експериментираме во Chrome/Chromium, како најнапредни прелистувачи во однос на WebRTC, иако Firefox 22, објавен на 24 јуни, речиси ги достигна. Мора да се каже дека стандардот сè уште не е усвоен, а API може да се менува од верзија до верзија. Сите примери беа тестирани во Chromium 28. За поедноставност, нема да ја следиме чистотата на кодот и компатибилноста со вкрстените прелистувачи.

MediaStream

Првата и наједноставна WebRTC компонента е MediaStream. Тоа му дава на прелистувачот пристап до медиумските преноси од камерата и микрофонот на локалниот компјутер. Во Chrome, за ова треба да ја повикате функцијата navigator.webkitGetUserMedia() (бидејќи стандардот сè уште не е финализиран, сите функции доаѓаат со префикс, а во Firefox истата функција се нарекува navigator.mozGetUserMedia()). Кога ќе го повикате, од корисникот ќе биде побарано да дозволи пристап до камерата и микрофонот. Повикот ќе може да се продолжи само откако корисникот ќе даде согласност. Параметрите на потребниот медиумски поток и две функции за повратен повик се пренесуваат како параметри на оваа функција: првата ќе биде повикана ако успешно се добие пристап до камерата/микрофонот, втората - во случај на грешка. Прво, ајде да создадеме HTML-датотека rtctest1.html со копче и елемент:

WebRTC - прво воведно видео ( висина: 240 px; ширина: 320 px; раб: 1px солидно сиво; ) getUserMedia

Microsoft CU-RTC-Web

Мајкрософт не би бил Мајкрософт доколку веднаш не одговори на иницијативата на Google со објавување на сопствената некомпатибилна нестандардна опција наречена CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web. htm). Иако уделот на IE, веќе мал, продолжува да опаѓа, бројот на корисници на Skype му дава надеж на Мајкрософт да го замени Google и може да се претпостави дека овој конкретен стандард ќе се користи во прелистувачот Верзии на Skype. Стандардот на Google е фокусиран првенствено на комуникација помеѓу прелистувачите; во исто време, најголемиот дел од гласовниот сообраќај сè уште останува на редовната телефонска мрежа, а портите помеѓу неа и IP мрежите се потребни не само за лесно користење или побрза дистрибуција, туку и како средство за монетизација што ќе им овозможи на повеќе играчи да развијте ги. Појавата на друг стандард не само што може да доведе до непријатна потреба програмерите да поддржуваат две некомпатибилни технологии одеднаш, туку и во иднина да му даде на корисникот поширок избор на можна функционалност и достапни технички решенија. Чекај и види.

Овозможување локален тек

Внатре во ознаките на нашата HTML-датотека, ајде да декларираме глобална променлива за медиумскиот поток:

Var localStream = нула;

Првиот параметар на методот getUserMedia мора да ги специфицира параметрите на бараниот медиумски поток - на пример, едноставно овозможете аудио или видео:

Var streamConstraints = („аудио“: точно, „видео“: точно); // Побарајте пристап и до аудио и до видео

Или наведете дополнителни параметри:

Var streamConstraints = ( „аудио“: точно, „видео“: ( „задолжително“: ( „maxWidth“: „320“, „maxHeight“: „240“, „maxFrameRate“: „5“), „изборно“: ) );

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

Функција getUserMedia_success(stream) ( console.log("getUserMedia_success():", stream); localVideo1.src = URL.createObjectURL(stream); // Поврзете го медиумскиот пренос со елементот HTML localStream = пренос; // и зачувајте го во глобална променлива за понатамошна употреба)

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

Функција getUserMedia_error(грешка) ( console.log("getUserMedia_error():", грешка); )

Вистинскиот повик до методот getUserMedia е барање за пристап до микрофонот и камерата кога ќе се притисне првото копче

Функција getUserMedia_click() ( console.log("getUserMedia_click()"); navigator.webkitGetUserMedia(stream Constraints, getUserMedia_success, getUserMedia_error); )

Не е возможно да се пристапи до медиумски пренос од датотека отворена локално. Ако се обидеме да го направиме ова, ќе ја добиеме грешката:

Грешка во NavigatorUserMedia (шифра: 1, PERMISSION_DENIED: 1)"

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

Може да ги изберете уредите до кои ќе има пристап Chrome во Поставки, Прикажи врска со напредни поставки, дел за приватност, копче Содржина. Во прелистувачите Firefox и Opera, уредите се избираат од паѓачката листа директно кога е дозволен пристапот.

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

Забележете го пулсирачкиот круг во иконата за обележувачи и иконата на камерата на десната страна од лентата за адреси:

RTCMediaConnection

RTCMediaConnection е објект дизајниран да воспоставува и пренесува медиумски текови преку мрежата помеѓу учесниците. Дополнително, овој објект е одговорен за генерирање опис на медиумска сесија (SDP), добивање информации за ICE кандидати за преминување NAT или заштитни ѕидови(локално и користење STUN) и интеракција со серверот TURN. Секој учесник мора да има една RTCMediaConnection по конекција. Медиумските потоци се пренесуваат со помош на шифрираниот протокол SRTP.

ВРТИ сервери

Постојат три типа на ICE кандидати: домаќин, srflx и реле. Домаќинот содржи информации добиени локално, srflx - како изгледа јазолот на надворешен сервер (STUN) и реле - информации за прокси сообраќај преку серверот TURN. Ако нашиот јазол е зад NAT, тогаш кандидатите за домаќини ќе содржат локални адресии ќе биде бескорисна, кандидатите за srflx ќе помагаат само со одредени типови на NAT и релето ќе биде последната надеж да го помине сообраќајот преку среден сервер.

Пример за ICE кандидат од типот домаќин, со адреса 192.168.1.37 и порта udp/34022:

A=candidate:337499441 2 udp 2113937151 192.168.1.37 34022 тип на домаќинска генерација 0

Општ формат за одредување STUN/TURN сервери:

Var сервери = ( "iceServers": [ ( "URL": "stun:stun.stunprotocol.org:3478" ), ( "URL": "turn:user@host:port", "акредитиви": "лозинка" ) ]);

Постојат многу јавни STUN сервери на Интернет. Постои голема листа, на пример. За жал, тие решаваат премалку проблеми. Практично нема јавни сервери TURN, за разлика од STUN. Ова се должи на фактот дека серверот TURN поминува низ медиумски потоци, што може значително да го вчита и мрежниот канал и самиот сервер. Затоа, најлесниот начин да се поврзете со серверите TURN е сами да го инсталирате (очигледно, ќе ви треба јавна IP адреса). Од сите сервери, според мене, најдобар е rfc5766-turn-server. Има дури и готова слика за Amazon EC2.

Со TURN, не е сè толку добро како што би сакале, но активен развој е во тек, и би сакал да се надевам дека по некое време WebRTC, ако не е еднаков на Skype во однос на квалитетот на премин преку превод на адреси (NAT) и заштитни ѕидови , е барем забележливо ќе се приближи.

RTCMediaConnection бара дополнителен механизам за размена на контролни информации за да се воспостави врска - иако ги генерира овие податоци, не ги пренесува, а преносот до другите учесници мора да се спроведе посебно.

Изборот на методот на пренос зависи од развивачот - барем рачно. Штом ќе се изврши размената на потребните податоци, RTCMediaConnection автоматски ќе инсталира медиумски преноси (ако е можно, се разбира).

модел понуда-одговор

За воспоставување и менување на медиумските преноси, се користат моделот понуда/одговор (опишан во RFC3264) и SDP (протокол за опис на сесија). Тие се користат и од протоколот SIP. Во овој модел, постојат два агенти: Offerer - оној кој го генерира SDP описот на сесијата за да создаде нов или модифицира постоечка (Offer SDP) и Answerer - оној кој го добива SDP описот на сесијата од друг агент и одговара со сопствен опис на сесијата (Одговор SDP). Во исто време, спецификацијата бара протокол на повисоко ниво (на пример, SIP или сопствен преку веб-сокети, како во нашиот случај), кој е одговорен за пренос на SDP помеѓу агентите.

Кои податоци треба да се пренесат помеѓу две RTCMediaConnection за да можат успешно да воспостават медиумски преноси:

• Првиот учесник што ја иницира врската формира понуда во која пренесува SDP податочна структура (истиот протокол се користи за истата цел во SIP) опишувајќи ги можните карактеристики на медиумскиот поток што треба да започне да го пренесува. Овој блок на податоци мора да се пренесе на вториот учесник. Вториот учесник формира Одговор, со својот SDP, и го испраќа до првиот.
• И првиот и вториот учесник ја вршат постапката за одредување на можни ICE кандидати со чија помош вториот учесник може да им пренесе медиумски поток. Како што се идентификуваат кандидатите, информациите за нив треба да се пренесат на друг учесник.

Понуда за формирање

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

Дополнително, потребни се два ракувачи со настани: onicecandidate при дефинирање на нов кандидат за ICE и onaddstream кога поврзувате медиумски пренос од далечната страна. Да се ​​вратиме на нашето досие. Ајде да додадеме уште еден во HTML по линиите со елементи:

креирај Понуда

И по линијата со елементот (за во иднина):

Исто така, на почетокот на кодот JavaScript ќе декларираме глобална променлива за RTCPeerConnection:

Var pc1;

Кога го повикувате конструкторот RTCPeerConnection, мора да наведете STUN/TURN сервери. За повеќе информации за нив, видете ја страничната лента; сè додека сите учесници се на иста мрежа, тие не се задолжителни.

Var сервери = нула;

Параметри за подготовка на Понуда SDP

Var offerConstraints = ();

Првиот параметар на методот createOffer() е функција за повратен повик наречена по успешното формирање на понуда

Функција pc1_createOffer_success(desc) ( console.log ("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // Поставете RTCPeerConnection генерирано користејќи го методот setLocalDescription. // Кога далечната страна ќе го испрати својот SDP одговор, ќе треба да се постави со методот setRemoteDescription // Се додека втората страна не се имплементира, не правиме ништо // pc2_receivedOffer(desc); )

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

Функција pc1_createOffer_error(грешка)(consol.log("pc1_createOffer_success_error(): грешка:", грешка); )

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

Функција pc1_onicecandidate(настан)( if (event.candidate) ( console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), настан.кандидат); // Се додека втората страна не се имплементира, не правиме ништо // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); ) )

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

Функција pc1_onaddstream(настан) ( console.log("pc_onaddstream()"); remoteVideo1.src = URL.createObjectURL(event.stream); )

Кога ќе кликнете на копчето „createOffer“, ќе создадеме RTCPeerConnection, ќе ги поставиме методите onicecandidate и onaddstream и ќе побараме формирање на Offer SDP со повикување на методот createOffer():

Функција createOffer_click() ( console.log("createOffer_click()"); pc1 = нов webkitRTCPeerConnection(сервери); // Креирај RTCPeerConnection pc1.onicecandidate = pc1_onicecandidate; //Повратен повик функција за обработка на pc1stream.d1 кандидати Функцијата за повратен повик се повикува кога медиумски поток се појавува од далечната страна. Сè уште нема pc1.addStream(localStream); // Ајде да го пренесеме преносот на локалниот медиум (претпоставувајќи дека веќе е примен) pc1.createOffer(// И всушност бараме формирање на Offer pc1_createOffer_success, pc1_createOffer_error, offerConstraints);)

Да ја зачуваме датотеката како rtctest2.html, да ја подигнеме на серверот, да ја отвориме во прелистувач и да видиме во конзолата кои податоци се генерираат за време на неговото работење. Второто видео сè уште нема да се појави, бидејќи има само еден учесник. Да потсетиме дека SDP е опис на параметрите на медиумската сесија, достапните кодеци, медиумските преноси и кандидатите за ICE се можни опции за поврзување со даден учесник.

Формирање на одговор SDP и размена на ICE кандидати

И SDP на понудата и секој од кандидатите за ICE мора да се префрлат на другата страна и таму, по нивното примање, RTCPeerConnection ги повикува методите setRemoteDescription за SDP на понудата и addIceCandidate за секој кандидат за ICE добиен од далечната страна; слично во задната страназа Одговор SDP и далечински ICE кандидати. Самиот одговор SDP е формиран слично на Понудата; Разликата е во тоа што не се повикува методот createOffer, туку методот createAnswer, а пред тоа методот RTCPeerConnection setRemoteDescription се пренесува до Offer SDP добиен од повикувачот.

Ајде да додадеме уште еден видео елемент во HTML:

И глобална променлива за втората RTCPeerConnection под декларацијата на првата:

Var pc2;

Обработка на понуда и одговор SDP

Формирањето на Answer SDP е многу слично на Offer. Во функцијата за повратен повик наречена по успешното формирање на одговор, слично на Понуда, ќе дадеме локален опис и ќе го пренесеме добиениот SDP на одговорот на првиот учесник:

Функција pc2_createAnswer_success(desc) ( pc2.setLocalDescription(desc); console.log("pc2_createAnswer_success()", desc.sdp); pc1.setRemoteDescription(desc); )

Функцијата за повратен повик, повикана во случај на грешка при генерирање на одговор, е целосно слична на Понуда:

Функција pc2_createAnswer_error(грешка) (consol.log("pc2_createAnswer_error():", грешка); )

Параметри за формирање Одговор SDP:

Var answerConstraints = ( "задолжително": ( "OfferToReceiveAudio":true, "OfferToReceiveVideo":true ) );

Кога вториот учесник ќе ја добие понудата, ќе создадеме RTCPeerConnection и ќе формираме Одговор на ист начин како и понудата:

Функција pc2_receivedOffer(desc) ( console.log("pc2_receiveOffer()", desc); // Креирај објект RTCPeerConnection за вториот учесник на ист начин како и првиот pc2 = нов webkitRTCPeerConnection(сервери); pc2.ondidacantecante_onite ; // Поставете го управувачот на настани кога ќе се појави ICE кандидат pc2.onaddstream = pc_onaddstream; // Кога ќе се појави пренос, поврзете го со HTML pc2.addStream(localStream); // Префрлете го протокот на локални медиуми (во нашиот пример, вториот учесникот го има истиот како првиот) // Сега, кога втората RTCPeerConnection е подготвена, ќе и ја пренесеме добиената Понуда SDP (го префрливме локалниот поток на првиот) pc2.setRemoteDescription(new RTCSessionDescription(desc)); // Побарајте ја втората врска за генерирање податоци за пораката за одговор pc2.createAnswer(pc2_createAnswer_success, pc2_createAnswer_error, answer Constraints); )

За да ја пренесеме понудата SDP од првиот учесник на вториот во нашиот пример, ајде да го декоментираме во функцијата pc1 креирај Понуда Success() повик линија:

Pc2_receivedOffer(desc);

За да се имплементира обработката на кандидатите за ICE, ајде да го отфрлиме коментарот во управувачот за настани за подготвеност на кандидати за ICE на првиот учесник pc1_onicecandidate() неговиот трансфер на вториот:

Pc2.addIceCandidate(нов RTCIceCandidate(настан.кандидат));

Управувачот со настани за подготвеност за кандидати за ICE на вториот учесник е како огледало на првиот:

Функција pc2_onicecandidate(настан) ( ако (настан.кандидат) ( конзола.log("pc2_onicecandidate():", настан.кандидат.кандидат); pc1.addIceCandidate(нов RTCIceCandidate(настан.кандидат)); ) )

Функција за повратен повик за додавање медиумски поток од првиот учесник:

Функција pc2_onaddstream(настан) ( console.log("pc_onaddstream()"); remoteVideo2.src = URL.createObjectURL(event.stream); )

Завршување на врската

Ајде да додадеме уште едно копче во HTML

Прекини

И функција за прекинување на врската

Функција btnHangupClick() ( // Исклучете го локалното видео од HTML елементи, запрете го преносот на локални медиуми, поставете = null localVideo1.src = ""; localStream.stop(); localStream = null; // За секој учесник, оневозможете видео од HTML елементи, затворете ја врската, поставете го покажувачот = null remoteVideo1.src = ""; pc1.close(); pc1 = null; remoteVideo2.src = ""; pc2.close(); pc2 = null; )

Да го зачуваме како rtctest3.html, да го подигнеме на серверот и да го отвориме во прелистувачот. Овој пример имплементира двонасочен пренос на медиумски струи помеѓу две RTCPeerConnections во рамките на истата картичка на прелистувачот. За да се организира размена на понуда и одговор SDP, кандидати за ICE помеѓу учесниците и други информации преку мрежата, наместо директно повикување процедури, ќе биде неопходно да се спроведе размена помеѓу учесниците користејќи некој вид транспорт, во нашиот случај - веб-сокети.

Емитување на екранот

Функцијата getUserMedia исто така може да го сними екранот и да пренесува како MediaStream со наведување на следните параметри:

Var mediaStreamConstraints = ( аудио: неточно, видео: ( задолжително: ( chromeMediaSource: „екран“), опционално: ) );

За успешен пристап до екранот, мора да се исполнат неколку услови:

• овозможете знаме за слика од екранот во getUserMedia() во chrome://flags/,chrome://flags/;
• изворната датотека мора да се преземе преку HTTPS (SSL потекло);
• аудио потокот не треба да се бара;
• Повеќе барања не треба да се извршуваат во една картичка на прелистувачот.

Библиотеки за WebRTC

Иако WebRTC сè уште не е завршен, веќе се појавија неколку библиотеки базирани на него. JsSIP е дизајниран да создава меко телефони базирани на прелистувач кои работат со SIP прекинувачи како што се Asterisk и Camalio. PeerJS ќе го олесни создавањето на P2P мрежи за размена на податоци, а Holla ќе го намали обемот на развој потребен за P2P комуникации од прелистувачите.

Node.js и socket.io

Со цел да се организира размена на кандидати за SDP и ICE помеѓу две RTCPeerConnections преку мрежата, ние користиме Node.js со модулот socket.io.

Опишано е инсталирањето на најновата стабилна верзија на Node.js (за Debian/Ubuntu).

$ sudo apt-get инсталирај python-software-properties python g++ направи $ sudo add-apt-repository ppa:chris-lea/node.js $ sudo apt-get update $ sudo apt-get install nodejs

Инсталација за други ОСопишан

Ајде да провериме:

$ echo "sys=require("util"); sys.puts("Тест порака");" > nodetest1.js $ nodejs nodetest1.js

Користејќи npm (Управувач со пакети на јазол) ќе инсталираме socket.io и дополнителниот експрес модул:

$ npm инсталирај socket.io express

Ајде да го тестираме со создавање на датотека nodetest2.js за страната на серверот:

$ nano nodetest2.js var app = бара ("експрес")() , сервер = бара ("http").createServer(app) , io = бара ("socket.io").listen(сервер); server.listen(80); // Ако портата 80 е бесплатна app.get("/", функција (req, res) ( // Кога пристапувате до основната страница res.sendfile(__dirname + "/nodetest2.html"); // испратете ја HTML-датотеката ) ) ; io.sockets.on ("поврзување", функција (сокет) ( // При поврзување на socket.emit ("настан на серверот", ( здраво: "свет" )); // испрати порака socket.on ("настан на клиентот" , функција (податоци) ( // и декларирање на управувач со настани кога ќе пристигне порака од клиентската конзола.log(data); )); ));

И nodetest2.html за клиентската страна:

$ nano nodetest2.html var socket = io.connect("/"); ( "име": "вредност" ));));

Ајде да го стартуваме серверот:

$ sudo nodejs nodetest2.js

и отворете ја страницата http://localhost:80 (ако работи локално на портата 80) во прелистувачот. Ако сè е успешно, во конзолата JavaScript на прелистувачот ќе видиме размена на настани помеѓу прелистувачот и серверот при поврзување.

Размена на информации помеѓу RTCPeerConnection преку веб приклучоци Клиент дел

Да го зачуваме нашиот главен пример (rtcdemo3.html) под новото име rtcdemo4.html. Ајде да ја вклучиме библиотеката socket.io во елементот:

И на почетокот на скриптата JavaScript - поврзување со веб-сокети:

Var socket = io.connect ("http://localhost");

Да го замениме директниот повик до функциите на друг учесник со тоа што ќе му испратиме порака преку веб-сокети:

Функција createOffer_success(desc) ( ... // pc2_receivedOffer(desc); socket.emit ("понуда", desc); ... ) функција pc2_createAnswer_success(desc) ( ... // pc1.setRemoteDescription(desc); сокет .emit("одговор", desc); ) функција pc1_onicecandidate(настан) ( ... // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice1", настан.кандидат); .. ).

Во функцијата hangup(), наместо директно да ги повикуваме функциите на вториот учесник, ќе пренесеме порака преку веб-сокети:

Функција btnHangupClick() ( ... // remoteVideo2.src = ""; pc2.close(); pc2 = null; socket.emit ("hangup", ()); )

И додадете ракувачи за примање пораки:

Socket.on ("понуда", функција (податоци) ( console.log ("socket.on ("понуда"):", податоци); pc2_receivedOffer(податоци); )); socket.on("одговор", функција (податоци) (е console.log("socket.on("одговор"):", податоци); pc1.setRemoteDescription(нов RTCSessionDescription(податоци)); )); socket.on ("ice1", функција (податоци) ( console.log ("socket.on ("ice1"):", податоци); pc2.addIceCandidate(нов RTCIceCandidate(податоци)); )); socket.on ("ice2", функција (податоци) ( console.log ("socket.on ("ice2"):", податоци); pc1.addIceCandidate(нов RTCIceCandidate(податоци)); )); socket.on("hangup", функција (податоци) ( console.log("socket.on("hangup"):", data); remoteVideo2.src = ""; pc2.close(); pc2 = null; ) );

Серверски дел

На страната на серверот, зачувајте ја датотеката nodetest2 под новото име rtctest4.js и внатре во функцијата io.sockets.on("поврзување", функција (сокет) ( ... ) ќе додадеме примање и испраќање пораки на клиентот:

Socket.on("понуда", функција (податоци) ( // Кога ќе ја примиме пораката "понуда", // бидејќи има само една клиентска врска во овој пример, // ќе ја испратиме пораката назад преку истиот сокет сокет .emit("понуда" , податоци); // Ако беше неопходно да се препрати пораката преку сите врски, // освен испраќачот: // soket.broadcast.emit("понуда", податоци); )); socket.on ("одговор", функција (податоци) ( socket.emit ("одговор", податоци); )); socket.on("ice1", функција (податоци) ( socket.emit ("ice1", податоци); )); socket.on("ice2", функција (податоци) ( socket.emit ("ice2", податоци); )); socket.on("hangup", функција (податоци) ( socket.emit ("hangup", data); ));

Дополнително, ајде да го смениме името на HTML-датотеката:

// res.sendfile (__dirname + "/nodetest2.html"); // Испрати ја HTML-датотеката res.sendfile(__dirname + "/rtctest4.html");

Стартување на серверот:

$ sudo nodejs nodetest2.js

И покрај фактот дека кодот на двата клиенти се извршува во истото јазиче на прелистувачот, целата интеракција помеѓу учесниците во нашиот пример е целосно извршена преку мрежата и „одвојувањето“ на учесниците не бара никакви посебни тешкотии. Сепак, она што го направивме беше исто така многу едноставно - овие технологии се добри затоа што се лесни за употреба. Дури и ако понекогаш е измамен. Конкретно, да не заборавиме дека без STUN/TURN серверите нашиот пример нема да може да работи во присуство на превод на адреси и заштитен ѕид.

Заклучок

Добиениот пример е многу конвенционален, но ако малку ги универзализираме управувачите на настани за да не се разликуваат помеѓу повикувачот и повиканата страна, наместо два објекти pc1 и pc2, направете низа RTCPeerConnection и имплементирајте динамично создавањеи отстранувајќи ги елементите, ќе добиете целосно употреблив видео разговор. Нема посебни специфики поврзани со WebRTC, а пример за едноставен видео разговор за неколку учесници (како и текстовите на сите примери во статијата) се наоѓа на дискот што доаѓа со списанието. Сепак, веќе можете да најдете доста на Интернет. добри примери. Конкретно, при подготовката на статијата беа искористени: simpl.info getUserMedia, simpl.info RTCPeerConnection, WebRTC Reference App.

Може да се претпостави дека многу скоро, благодарение на WebRTC, ќе има револуција не само во нашето разбирање на гласовните и видео комуникациите, туку и во начинот на кој го перципираме Интернетот како целина. WebRTC е позициониран не само како технологија за повици од прелистувач до прелистувач, туку и како комуникациска технологија во реално време. Видео комуникацијата за која разговаравме е само мал дел можни опциинеговата употреба. Веќе има примери за прикажување екрани и соработка, па дури и мрежа за испорака на содржини P2P базирана на прелистувач со помош на RTCDataChannel.