Peer-to-peer видео разговор базиран на WebRTC. P2P видео разговор базиран на инсталација на WebRTC Webrtc

Европските корисници на Интернет се поделени на два дела: според истражувањето на Институтот за анализа на јавното мислење во Аленбах (Германија), Skype, системите за разговор и инстант пораки станаа составен дел на Секојдневниот животза 16,5 милиони возрасни и деца, 9 милиони ги користат овие услуги повремено, а 28 милиони не ги допираат.

Ова може да се промени бидејќи Firefox сега се интегрира комуникациска технологија во реално време (WebRTC), како и самиот клиент. Започнувањето аудио и видео разговор сега не е потешко од отворањето веб-локација. Услугите како Фејсбук и Скајп, од друга страна, се потпираат на решенија користејќи посебен клиент и креирање сметка.

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

За да започнете разговор, треба само да ја следите врската. Комуникацијата останува приватна, бидејќи протокот на податоци е шифриран. Google започна активно да се вклучи во комуникација во реално време преку прелистувачот уште во 2011 година, кога го објави изворниот код на својата имплементација WebRTC.

Набргу после ова, Chrome и Firefox добија свои WebRTC мотори. Во моментов, нивните мобилни верзии се опремени и со оваа технологија и со моторот WebView 3.6 инсталиран со Android 5.0, кој го користат апликациите.

За комуникација во реално време, соодветните JavaScript интерфејси мора да се имплементираат во веб-прегледувачот. Користење на GetUserMedia софтверго активира снимањето од аудио и видео извори, односно од веб камерата и микрофонот. RTCPeerConnection е одговорен за воспоставување на врската, како и за самата комуникација.

Паралелно со интеграцијата во прелистувачот, работната група на Конзорциумот World Wide Web(W3C) го забрза процесот на стандардизација на WebRTC. Треба да биде завршен во 2015 година.

WebRTC е задоволен со малку

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

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

За да може врската за стриминг да функционира непречено и со добар квалитет, три мотори работат во прелистувачот. Двајца од нив ги оптимизираат и компресираат аудио и видео податоци, третиот е одговорен за нивниот транспорт. Испраќа податоци преку SRTP протокол(Безбеден протокол за транспорт во реално време), кој овозможува шифриран пренос во реално време.

Ако не може да се воспостави директна врска, WebRTC бара друга патека. На пример, ова се случува кога мрежни поставкиспречете го STUN серверот да ја пријави IP адресата. Стандардот WebRTC предвидува дека во овој случај разговорот ќе се одвива, но со средно активирање на серверот TURN (Traversal Using Relays around NAT). Така, на веб-страницата netscan.co можете да проверите дали WebRTC е имплементиран на вашиот компјутер и со вашиот пристап до мрежата.

Како е направена врската

Прво мора да го регистрирате разговорот (1). Услугата WebRTC обезбедува врска што мора да се испрати до соговорникот. Прелистувачот, користејќи го STUN серверот, ја дознава сопствената IP адреса (2), ја испраќа до услугата и ја прима IP-ата на партнерот за да воспостави директна врска (3). Ако STUN не успее, разговорот се пренасочува со помош на серверот TURN (4).

Комуникацијата со помош на технологијата WebRTC во прелистувачот се активира со користење на JavaScript код. После тоа, три мотори се одговорни за комуникација: гласовните и видео моторите собираат мултимедијални податоци од веб камерата и микрофонот, а транспортниот мотор ги комбинира информациите и го испраќа преносот во шифрирана форма користејќи SRTP (Безбеден протокол во реално време).

Кои прелистувачи работат со WebRTC

Chrome и Firefox имаат WebRTC мотор кој користи услуги како talky.io. Прелистувачот на Mozilla може да работи директно со свој клиент.

Google и Mozilla продолжуваат да ја развиваат идејата за комуникација во реално време: Chrome може да биде домаќин на WebRTC конференции со повеќе учесници, а новиот Hello клиент на Firefox е развиен во соработка со подружница на телекомуникацискиот гигант Telefonica. Apple засега останува настрана; сè уште не треба да очекувате WebRTC во Safari. Сепак, ги има многу алтернативни апликацииза iOS и приклучоци за Safari.

Мајкрософт зазема малку поинаков курс. Како сопственик на конкурентна Скајп услугаоваа компанија нема така лесно да капитулира пред WebRTC. Наместо тоа, Microsoft развива технологија наречена ORTC (Object Real-Time Communications) за Internet Explorer.

Разликите од WebRTC, како што се различни кодеци и протоколи за воспоставување контакт со серверот, се мали и со текот на времето најверојатно ќе прераснат во додаток на WebRTC стандардот кој ги вклучува овие разлики. Така, само Apple останува зад себе - како и обично.

Фото:производствени компании; goodluz/Fotolia.com

Поголемиот дел од материјалот на WebRTCсе фокусира на апликациското ниво на кодирање и не придонесува за разбирање на технологијата. Ајде да се обидеме да навлеземе подлабоко и да дознаеме како се јавува врската, што се дескриптор на сесија и кандидати, за што се потребни ЗАПРЕДУВАЊЕИ СВРТИсервер.

WebRTC

Вовед

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

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

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

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

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

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

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

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

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

Две фази на WebRTC

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

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

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

• Иницијатор (повикувач - повикувач):
  1. Понуда за почеток на пренос на видео податоци (креирајПонуда)
  2. Добивање на твоето СДП СДП)
  3. Добивање на твоето Кандидат за мраз Кандидат за мраз)
• Повик на чекање ( callee):
  1. Примање локален (ваш) медиумски поток и негово поставување за пренос (getUserMediaStream)
  2. Примање понуда за почеток на пренос на видео податоци и креирање одговор (createAnswer)
  3. Добивање на твоето СДПобјект и го пренесува преку сигнален механизам ( СДП)
  4. Добивање на твоето Кандидат за мразобјекти и нивно пренесување преку сигнален механизам ( Кандидат за мраз)
  5. Примање далечински (странски) медиумски пренос и негово прикажување на екранот (onAddStream)

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

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

Ментална фаза креирај Понудаили креирај Одговортреба да биде поврзан со фазите на пренос СДПИ Кандидат за мразпредмети.

Основни ентитети

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внесување на табелата NATгенериран само кога податоците ја напуштаат внатрешната мрежа. Затоа јазолот стр1мора прво да ги пренесе податоците, а потоа податоците од јазолот стр2ќе може да стигне до јазолот стр1.

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

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

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

STUN и TURN сервери

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

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

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

Пример (операција на STUN сервер)

ЗАПРЕДУВАЊЕќе го означиме серверот со s1. Рутерот, како и досега, преку r1, а јазолот – преку стр1. Исто така, ќе треба да ја следите табелата NAT– да го означиме како r1_nat. Покрај тоа, оваа табела обично содржи многу записи од различни јазли на подмрежата - тие нема да бидат дадени.

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

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

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

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

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

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

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

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

Src IP	Src PORT	Destin IP	Dest PORT
10.50.200.5	888	12.62.100.200	6000

Табела 5: STUN сервер доби пакет

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

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

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

Следно, пакетот патува низ мрежата додека не стигне до надворешниот интерфејс на рутерот r1. Рутерот разбира дека пакетот не е наменет за него. Како тој го разбира ова? Ова може да го одреди само пристаништето. Пристаниште 888 не го користи за свои лични цели, туку го користи за механизмот NAT. Затоа, рутерот ја гледа оваа табела. Гледа во колоната Надворешна портаи бара низа што се совпаѓа 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	Destin IP	Dest PORT
12.62.100.200	6000	192.168.0.200	35777

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

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

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

Од примерот погоре можете да добиете некоја идеја за тоа како функционира NATи суштината ЗАПРЕДУВАЊЕсервер. Во принцип, механизмот МРАЗИ ЗАПОЧЕНИ/СВРТИсерверите се прецизно насочени кон надминување на ограничувањата NAT.

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

СВРТИсерверот е подобрен ЗАПРЕДУВАЊЕсервер. Од тука веднаш треба да се научи дека било кој СВРТИсерверот може да работи и како ЗАПРЕДУВАЊЕсервер. Сепак, има и предности. Ако p2pкомуникацијата е невозможна (како во 3грмрежи), потоа серверот се префрла во режим на повторувач ( реле), односно работи како посредник. Се разбира, за ништо p2pтогаш нема прашање, но надвор од рамките на механизмот МРАЗјазлите мислат дека директно комуницираат.

Во кои случаи е потребно СВРТИсервер? Зошто нема доволно ЗАПРЕДУВАЊЕсервери? Факт е дека има неколку сорти NAT. Подеднакво заменуваат IPадреса и пристаниште, но некои од нив имаат вградена дополнителна заштита од „фалсификување“. На пример, во симетричнимаса NATЗачувани се уште 2 параметри - IPи пристаништето на оддалечениот јазол. Пакет од надворешната мрежа поминува низ NATна внатрешната мрежа само ако изворната адреса и портата се совпаѓаат со оние што се запишани во табелата. Затоа, фокусот ЗАПРЕДУВАЊЕсерверот не успее - табела NATпродавници адреса и пристаниште ЗАПРЕДУВАЊЕсервер и кога рутерот прима пакет од WebRTCсоговорник, го отфрла затоа што е „фалсификуван“. Тој не дојде од ЗАПРЕДУВАЊЕсервер.

Така СВРТИпотребен е сервер кога се наоѓаат двајцата соговорници симетрични NAT(секој на своето).

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

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

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

WebRTC (Web Real Time Communications) е стандард кој го опишува преносот на стриминг аудио податоци, видео податоци и содржини од и до прелистувачот во реално време без инсталирање приклучоци или други екстензии. Стандардот ви овозможува да го претворите вашиот прелистувач во терминал за видео конференции; само треба да отворите веб-страница за да започнете да комуницирате.

Што е WebRTC?

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

Што треба да знаете за WebRTC?

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

Сергеј Јуцаитис, Cisco, Видео+конференција 2016 година

Како работи WebRTC

Клиентска страна

• Корисникот отвора страница која содржи ознака HTML5
• Прелистувачот бара пристап до веб-камерата и микрофонот на корисникот.
• Кодот JavaScript на корисничката страница ги контролира параметрите за поврзување (IP адреси и порти на WebRTC серверот или други WebRTC клиенти) за да се заобиколат NAT и Firewall.
• Кога добивате информации за соговорникот или за преносот од конференцијата измешан на серверот, прелистувачот започнува да преговара за користените аудио и видео кодеци.
• Започнува процесот на кодирање и преносот на стриминг податоци помеѓу клиентите на WebRTC (во нашиот случај, помеѓу прелистувачот и серверот).

На страната на серверот WebRTC

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

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

Исто така, серверот WebRTC ќе добива медиумски сообраќај од врсниците на WebRTC и ќе го пренесува до учесниците на конференцијата кои користат апликации за десктоп компјутериили Мобилни уреди, доколку ги има.

Предности на стандардот

• Не е потребна инсталација на софтвер.
• Многу висок квалитет на комуникација, благодарение на:
  • Употреба на модерни видео (VP8, H.264) и аудио кодеци (Opus).
  • Автоматско прилагодување на квалитетот на преносот на условите за поврзување.
  • Вграден систем за ехо и намалување на шумот.
  • Автоматско прилагодување на нивото на чувствителност на микрофоните на учесниците (AGC).
• Високо ниво на безбедност: сите врски се заштитени и шифрирани со помош на протоколи TLS и SRTP.
• Има вграден механизам за снимање содржина, на пример, работната површина.
• Можност за имплементација на кој било интерфејс за управување базиран на HTML5 и JavaScript.
• Способност да се интегрира интерфејсот со кој било заден систем користејќи WebSockets.
• Проект со отворено изворен код— може да се имплементира во вашиот производ или услуга.
• Вистинска крос-платформа: истата WebRTC апликација ќе работи подеднакво добро на која било операционен систем, десктоп или мобилен, под услов прелистувачот да поддржува WebRTC. Ова значително заштедува ресурси за развој на софтвер.

Недостатоци на стандардот

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

Тајните на WebRTC: Како продавачите имаат корист од пробивот на веб-технологијата

Цачи Левент-Леви, Bloggeek.me, Видео+конференција 2015 година

WebRTC за пазарот на видео конференции

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

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

Користете во специјализирани решенија

Користењето на различни библиотеки на JavaScript и API-и за облак услуги со поддршка за WebRTC го олеснува додавањето поддршка за видео комуникација на кој било веб-проект. Претходно, за пренос на податоци во реално време, програмерите мораа да ги проучат принципите на работење на протоколот и да ги користат случувањата на други компании, кои најчесто бараа дополнителна лиценца, што ги зголеми трошоците. WebRTC веќе активно се користи во услуги како што се „Повик од страницата“, „Поддршка за онлајн разговор“ итн.

Поранешни корисници на Skype за Linux

Во 2014 година, Мајкрософт објави крај на поддршката за проектот Skype за Linux, што предизвика голема иритација кај ИТ специјалистите. WebRTC технологијата не е врзана за оперативниот систем, туку е имплементирана на ниво на прелистувач, т.е. Линукс кориснициќе може да ги гледа производите и услугите базирани на WebRTC како полноправна замена за Skype.

Натпревар со Flash

WebRTC и HTML5 беа смртен удар за Flash технологијата, која веќе минуваше низ своите најлоши години. Од 2017 година, водечките прелистувачи официјално престанаа да го поддржуваат Flash и технологијата целосно исчезна од пазарот. Но, мораме да му го дадеме на Флеш своето право, бидејќи тој го создаде пазарот за веб-конференции и понуди техничките можностиза комуникација во живо во прелистувачите.

WebRTC видео презентации

Дмитриј Одинцов, TrueConf, Видео+конференција октомври 2017 година

Кодеци во WebRTC

Аудио кодеци

WebRTC користи кодеци Opus и G.711 за да го компресира аудио сообраќајот.

Г.711- најстариот гласовен кодек со висока бит-стапка (64 kbps), кој најчесто се користи во традиционалните телефонски системи. Главната предност е минималното пресметковно оптоварување поради употребата на лесни алгоритми за компресија. Кодекот има ниско ниво на компресија на гласовните сигнали и не воведува дополнително аудио доцнење за време на комуникацијата помеѓу корисниците.

G.711 е поддржан од голем број уреди. Системите што го користат овој кодек се полесни за користење од оние базирани на други аудио кодеци (G.723, G.726, G.728, итн.). Во однос на квалитетот, G.711 доби оценка од 4,2 во MOS тестирањето (оценката помеѓу 4-5 е највисока и значи добар квалитет, сличен на квалитетот на пренос на гласовниот сообраќај во ISDN и уште повисок).

Опусе кодек со мала латентност на кодирање (од 2,5 ms до 60 ms), поддршка за променливи бит-стапки и високи нивоа на компресија, кој е идеален за пренос на стриминг аудио сигнали во мрежи со променливи пропусната моќ. Opus е хибридно решение кое ги комбинира најдобрите карактеристики на кодеците SILK (гласовна компресија, елиминирање на изобличувањето на човечкиот говор) и CELT (кодирање на аудио податоци). Кодекот е слободно достапен; програмерите кои го користат не треба да плаќаат авторски права на носителите на авторски права. Во споредба со другите аудио кодеци, Opus несомнено победува во многу аспекти. Засени доста популарни кодеци со ниска бит-стапка како што се MP3, Vorbis, AAC LC. Opus ја враќа „сликата“ на звукот поблиску до оригиналот отколку AMR-WB и Speex. Овој кодек е иднината, поради што креаторите на WebRTC технологијата го вклучија во задолжителниот опсег на поддржани аудио стандарди.

Видео кодеци

Прашањата за избор на видео кодек за WebRTC им одзедоа на програмерите неколку години, и на крајот тие решија да ги користат H.264 и VP8. Речиси сите модерни прелистувачи ги поддржуваат двата кодека. Серверите за видео конференции треба само да поддржат еден за да работат со WebRTC.

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

Платен видео кодек H.264стана познат многу порано од неговиот брат. Ова е кодек со висок степен на компресија на видео потокот при зачувување Висок квалитетВидео. Високата распространетост на овој кодек меѓу хардверските видео-конференциски системи укажува на неговата употреба во стандардот WebRTC.

Google и Mozilla активно го промовираат VP8 кодекот, а Microsoft, Apple и Cisco активно го промовираат H.264 (за да се обезбеди компатибилност со традиционалните системи за видео конференции). И тука се јавува многу голем проблем за развивачите на решенија за облак WebRTC, затоа што ако сите учесници на конференција користат ист прелистувач, тогаш доволно е да се измеша конференцијата еднаш со еден кодек, а ако прелистувачите се различни и Safari / Edge се меѓу нив, тогаш на конференцијата ќе треба да се кодираат двапати различни кодеци, што ќе го удвои системски барањана медиумскиот сервер и, како резултат на тоа, трошоците за претплати на услугите на WebRTC.

WebRTC API

Технологијата WebRTC се заснова на три главни API:

• (одговорен за веб-прелистувачот што прима аудио и видео сигнали од камерите или од работната површина на корисникот).
• RTCPeerConnection(одговорен за поврзувањето помеѓу прелистувачите за „размена“ медиумски податоци добиени од камерата, микрофонот и работната површина. Исто така, „одговорностите“ на овој API вклучуваат обработка на сигналот (чистење од необичен шум, прилагодување на јачината на звукот на микрофонот) и контрола врз користени аудио и видео кодеци) .
• Канал RTCData(обезбедува двонасочен пренос на податоци преку воспоставена врска).

Пред да пристапи до микрофонот и камерата на корисникот, прелистувачот бара дозвола да го стори тоа. ВО Гугл хромМожете да го конфигурирате пристапот однапред во делот „Поставки“; во Opera и Firefox, уредите се избираат директно во моментот на добивање пристап, од паѓачката листа. Барањето за дозвола ќе се појавува секогаш кога користите HTTP протокол и еднаш ако користите HTTPS:

RTCPeerConnection. Секој прелистувач што учествува на конференција WebRTC мора да има пристап до овој објект. Благодарение на употребата на RTCPeerConnection, медиумските податоци од еден прелистувач до друг може дури и да минуваат низ NAT и заштитни ѕидови. За успешно пренесување на медиумски преноси, учесниците мора да ги разменат следните податоци користејќи транспорт, како што се веб-сокети:

• учесникот кој иницира испраќа до вториот учесник Понуда-SDP (структура на податоци со карактеристиките на медиумскиот тек што ќе го пренесе);
• вториот учесник генерира „одговор“ - Одговор-SDP и го испраќа до иницијаторот;
• тогаш се организира размена на ICE кандидати помеѓу учесниците, доколку се откриени такви (ако учесниците се зад NAT или заштитните ѕидови).

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

Канал RTCData. Поддршката за протоколот податочен канал се појави во прелистувачите релативно неодамна, така што ова API може да се смета само во случаи на користење WebRTC во прелистувачи Mozilla Firefox 22+ и Google Chrome 26+. Со негова помош, учесниците можат да разменуваат текстуални поракиво прелистувачот.

Поврзување преку WebRTC

Поддржани десктоп прелистувачи

• Google Chrome (17+) и сите прелистувачи базирани на моторот Chromium;
• Mozilla FireFox (18+);
• Опера (12+);
• Сафари (11+);

Поддржани мобилни прелистувачи за Android

• Google Chrome (28+);
• Mozilla Firefox (24+);
• Opera Mobile (12+);
• Сафари (11+).

WebRTC, Microsoft и Internet Explorer

Долго време, Microsoft молчеше за поддршката на WebRTC во Internet Explorer и неговиот нов прелистувач Edge. Момците од Редмонд баш и не сакаат да ги ставаат технологиите што не ги контролираат во рацете на корисниците, тоа е нивната политика. Но, постепено работата тргна од мртва точка, бидејќи ... Веќе не беше можно да се игнорира WebRTC и беше најавен проектот ORTC, дериват на стандардот WebRTC.

Според програмерите, ORTC е продолжение на WebRTC стандардот со подобрен сет на API базирани на JavaScript и HTML5, што, преведено на обичен јазик, значи дека сè ќе биде исто, само Microsoft, а не Google, ќе го контролира стандардот. и нејзиниот развој. Комплетот кодеци е проширен со поддршка за H.264 и некои аудио кодеци од серијата G.7ХХ, кои се користат во телефонија и хардверски системи за видео конференции. Може да има вградена поддршка за RDP (за пренос на содржина) и пораки. Патем, корисниците на Internet Explorer немаат среќа; ORTC поддршката ќе биде достапна само во Edge. И, се разбира, овој сет на протоколи и кодеци лесно се поврзува со Skype за бизнис, што отвора уште повеќе деловни апликации за WebRTC.

Целта на овој напис е да се користи демо-примерок од peer-to-peer видео разговор (p2p видео разговор) за да се запознаете со неговата структура и принципот на работа. За таа цел, ќе користиме повеќекориснички peer-to-peer видео разговор демо webrtc.io-demo. Може да се преземе од врската: https://github.com/webRTC/webrtc.io-demo/tree/master/site.

Треба да се напомене дека GitHub е страница или веб-услуга за заеднички развој на веб-проекти. На него, програмерите можат да ги објавуваат шифрите на нивните случувања, да разговараат за нив и да комуницираат едни со други. Покрај тоа, некои големи ИТ компании ги објавуваат своите официјални складишта на оваа страница. Услугата е бесплатна за проекти со отворен код. GitHub е складиште за отворени, бесплатни библиотеки со изворен код.

Така, ќе го поставиме демо-примерокот од видео разговор од peer-to-peer преземен од GitHub на уредот C персонален компјутерво креираниот директориум за нашата апликација „webrtc_demo“.

Ориз. 1

Како што следува од структурата (сл. 1), видео разговорот peer-to-peer се состои од скрипти за клиент script.js и сервер server.js, имплементирани во програмскиот јазик JavaScript. Скрипта (библиотека) webrtc.io.js (КЛИЕНТ) - обезбедува организација на комуникации во реално време помеѓу прелистувачите користејќи peer-to-peer шема: „клиент-клиент“, и webrtc.io.js (КЛИЕНТ) и webrtc. io.js (СЕРВЕР), Користејќи го протоколот WebSocket, тие обезбедуваат дуплекс комуникација помеѓу прелистувачот и веб-серверот користејќи архитектура клиент-сервер.

Скриптата webrtc.io.js (SERVER) е вклучена во библиотеката webrtc.io и се наоѓа во директориумот node_modules\webrtc.io\lib. Интерфејсот за видео разговор index.html е имплементиран во HTML5 и CSS3. Содржината на датотеките на апликацијата webrtc_demo може да се прегледа со помош на еден од html уредниците, на пример „Notepad++“.

Ќе го провериме принципот на работа на видео разговорот датотечен системкомпјутер. За да го извршите серверот (server.js) на компјутер, треба да ја инсталирате околината за извршување на node.js. Node.js ви овозможува да извршите JavaScript код надвор од прелистувачот. Можете да го преземете node.js од врската: http://nodejs.org/ (верзија v0.10.13 од 15.07.13). На главната страница на веб-страницата node.org, кликнете на копчето за преземање и одете на http://nodejs.org/download/. За корисниците на Windows, прво преземете го win.installer (.msi), потоа стартувајте го win.installer (.msi) на компјутерот и инсталирајте ги nodejs и „npm менаџер на пакети“ во директориумот Program Files.

Ориз. 2

Така, node.js се состои од средина за развивање и извршување на JavaScript код, како и збир на внатрешни модули кои можат да се инсталираат со помош на менаџерот или npm менаџерот на пакети.

За да инсталирате модули мора командна линијаОд директориумот со апликации (на пример, "webrtc_demo") извршете ја командата: npm инсталирај module_name. За време на инсталацијата на модулите, менаџерот npm создава папка node_modules во директориумот од кој е извршена инсталацијата. За време на работата, nodejs автоматски ги поврзува модулите од директориумот node_modules.

Значи, откако ќе го инсталирате node.js, отворете ја командната линија и ажурирајте го експресниот модул во папката node_modules на директориумот webrtc_demo користејќи го менаџерот на пакети npm:

C:\webrtc_demo>npm инсталирај експрес

Експресниот модул е ​​веб-рамка за node.js или веб-платформа за развој на апликации. За да имате глобален пристап до изразување, можете да го инсталирате вака: npm инсталирај -g express.

Потоа ажурирајте го модулот webrtc.io:

C:\webrtc_demo>npm инсталирај webrtc.io

Потоа на командната линија го стартуваме серверот: server.js:

C:\webrtc_demo>јазол сервер.js

Ориз. 3

Тоа е сè, серверот работи успешно (Слика 3). Сега, користејќи веб-прелистувач, можете да го контактирате серверот по IP адреса и да ја вчитате веб-страницата index.html, од која веб-прелистувачот ќе го извлече кодот за скрипта на клиентот - script.js и кодот за скрипта webrtc.io.js, и изврши ги. За да управувате со видео разговор од peer-to-peer (за да воспоставите врска помеѓу два прелистувачи), треба да го контактирате серверот за сигнал кој работи на node.js од два прелистувачи што поддржуваат webrtc.

Како резултат на тоа, интерфејсот на клиентскиот дел од апликацијата за комуникација (видео разговор) ќе се отвори со барање за дозвола за пристап до камерата и микрофонот (сл. 4).

Ориз. 4

Откако ќе кликнете на копчето „Дозволи“, камерата и микрофонот се поврзани за мултимедијална комуникација. Покрај тоа, можете да комуницирате преку текстуални податоци преку интерфејсот за видео разговор (сл. 5).

Ориз. 5

Треба да се напомене дека. Серверот е сигнален сервер и главно е дизајниран да воспоставува врски помеѓу корисничките прелистувачи. Node.js се користи за ракување со скриптата за серверот server.js што обезбедува WebRTC сигнализација.