Більшість матеріалу з 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 = router). На першому малюнку ситуація сприятлива: вузли у своїй мережі цілком ідентифікуються мережевими 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 a) необхідно провести деякі попередні дії для встановлення з'єднання. Це перша фаза – встановлення з'єднання. Друга фаза – передача відео даних.

Відразу варто сказати, що хоч технологія WebRTCу своїй роботі використовує безліч різних способівкомунікації ( TCPі UDP) і має гнучке перемикання між ними, ця технологія не має протоколу передачі даних про з'єднання. Не дивно, адже підключити два вузли p2pне так просто. Тому необхідно мати певний додатковийспосіб передачі даних, ніяк не пов'язаний з WebRTC. Це може бути сокетна передача, протокол HTTP, це може бути навіть протокол SMTPабо Пошта Росії. Цей механізм передачі початковихданих називається сигнальним. Передавати потрібно не так багато інформації. Всі дані передаються у вигляді тексту та поділяються на два типи – SDPі Ice Candidate. Перший тип використовується встановлення логічного з'єднання, а другий для фізичного . Докладно про все це пізніше, а поки що важливо пам'ятати, що WebRTCдасть нам інформацію, яку треба буде передати іншому вузлу. Як тільки ми передамо всю потрібну інформацію, вузли зможуть з'єднатися і більше потрібна наша допомога не буде. Таким чином, сигнальний механізм, який ми маємо реалізувати окремо, використовуватиметься тільки при підключенні, а при передачі відео даних не використовуватиметься.

Отже, розглянемо першу фазу – фазу встановлення з'єднання. Вона складається з кількох пунктів. Розглянемо цю фазу спочатку для вузла, який ініціює з'єднання, а потім чекає.

• Ініціатор (телефон – caller):
  1. Пропозиція розпочати відео-передачу даних (createOffer)
  2. Отримання свого SDP SDP)
  3. Отримання своїх Ice candidate Ice candidate)
• Очікуючий дзвінка ( callee):
  1. Отримання локального (свого) медіа потоку та встановлення його передачі (getUserMediaStream)
  2. Отримання пропозиції розпочати відео-передачу даних та створення відповіді (createAnswer)
  3. Отримання свого SDPоб'єкта та передача його через сигнальний механізм ( SDP)
  4. Отримання своїх Ice candidateоб'єктів та передача їх через сигнальний механізм ( Ice candidate)
  5. Отримання віддаленого (чужого) медіа потоку та відображення його на екрані (onAddStream)

Відмінність лише у другому пункті.

Незважаючи на здається заплутаність кроків тут їх насправді три: відправлення свого медіа потоку (п.1), встановлення параметрів з'єднання (пп.2-4), отримання чужого медіа потоку (п.5). Найскладніший – другий крок, тому що він складається із двох частин: встановлення фізичногоі логічногоз'єднання. Перша вказує шлях, Які повинні йти пакети, щоб дійти від одного вузла мережі до іншого. Друга вказує параметри відео/аудіо- Яке використовувати якість, які використовувати кодеки.

Подумки етап createOfferабо createAnswerслід з'єднати з етапами передачі SDPі Ice candidateоб'єктів.

Основні сутності

Медіа потоки (MediaStream)

Основною сутністю є медіа потік, тобто потік відео та аудіо даних, картинка та звук. Медіа потоки бувають двох типів – локальні та віддалені. Локальний отримує дані від пристроїв входу (камера, мікрофон), а віддалений через мережу. Таким чином, у кожного вузла є і локальний, і віддалений потік. В WebRTCдля потоків існує інтерфейс MediaStreamі також існує підінтерфейс LocalMediaStreamспеціально для локального потоку. В JavaScriptможна зіткнутися тільки з першим, а якщо використовувати libjingle, можна зіткнутися і з другим.

В WebRTCІснує досить заплутана ієрархія всередині потоку. Кожен потік може складатися з кількох медіа доріжок. MediaTrack), які в свою чергу можуть складатися з декількох медіа каналів ( MediaChannel). Та й самих медіа потоків може бути також кілька.

Розглянемо все по черзі. Для цього будемо пам'ятати деякий приклад. Припустимо, що ми хочемо передавати не лише відео себе, а й відео нашого столу, на якому лежить аркуш паперу, на якому ми збираємося щось писати. Нам знадобиться два відео (ми + стіл) та одне аудіо (ми). Ясно, що ми і стіл варто розділити на різні потоки, тому що ці дані, мабуть, слабко залежать одна від одної. Тож у нас буде два MediaStream'a – один для нас і один для столу. Перший міститиме і відео, і аудіо дані, а другий – лише відео (Малюнок 4).

Малюнок 4: Два різні медіа потоки. Один для нас, один для нашого столу

Відразу ясно, що медіа потік як мінімум повинен включати можливість містити дані різних типів- Відео та аудіо. Це враховано в технології і тому кожен тип даних реалізується через медіа доріжку MediaTrack. Медіа доріжки мають спеціальну властивість kind, яке визначає, що перед нами – відео або аудіо (Малюнок 5)

Малюнок 5: Медіа потоки складаються з медіа доріжок

Як все відбуватиметься у програмі? Ми створимо два медіа потоки. Потім створимо дві відео доріжки та одну аудіо доріжку. Отримаємо доступ до камер та мікрофону. Вкажемо кожній доріжці який пристрій використати. Додамо відео та аудіо доріжку у перший медіа потік та відео доріжку від іншої камери у другий медіа потік.

Але як ми помітимо медіа потоки на іншому кінці з'єднання? Для цього кожен медіа потік має властивість label- Мітка потоку, його назва (Малюнок 6). Таку ж властивість мають і медіа доріжки. Хоча, на перший погляд, здається, що відео від звуку можна відрізнити й іншими способами.

Рисунок 6: Медіа потоки та доріжки ідентифікуються мітками

Так, а якщо медіа доріжки можна ідентифікувати через мітку, то навіщо нам для нашого прикладу використовувати два медіа потоки замість одного? Адже можна передавати один медіа потік, а доріжки використовувати у ньому різні. Ми дійшли до важливої ​​властивості медіа потоків – вони синхронізуютьмедіа доріжки. Різні медіа потоки не синхронізуються між собою, але всередині кожного медіа потоку всі доріжки відтворюються одночасно.

Таким чином, якщо ми хочемо, щоб наші слова, наші емоції на обличчі та наш аркушик паперу відтворювалися одночасно, то варто використовувати один медіа потік. Якщо це не так важливо, то вигідніше використовувати різні потоки - картинка буде більш гладкою.

Якщо якусь доріжку необхідно відключати під час передачі, можна скористатися властивістю enabledмедіа доріжки.

Насамкінець варто подумати про стерео звук. Як відомо стерео звук – це два різних звуку. І передавати їх треба також окремо. Для цього використовуються канали MediaChannel. Медіа запис звуку може мати багато каналів (наприклад, 6, якщо потрібен звук 5+1). Усередині медіа доріжки канали, звичайно теж синхронізовані. Для відео зазвичай використовується лише один канал, але можуть використовуватись і кілька, наприклад, для накладання реклами.

Резюмуючи: ми використовуємо медіа потік для передачі відео та аудіо даних. Всередині кожного медіа потоку дані синхронізовані. Ми можемо використовувати кілька медіа потоків, якщо нам не потрібна синхронізація. Всередині кожного медіа потоку є медіа доріжки двох видів – для відео та для аудіо. Доріжок зазвичай не більше двох, але може бути і більше, якщо потрібно передавати кілька різних відео (співрозмовника та його столу). Кожна доріжка може складатися з декількох каналів, що зазвичай використовується тільки для стерео звуку.

У найпростішій ситуації відеочату у нас буде один локальний медіа-потік, який складатиметься з двох доріжок – відео доріжки та аудіо доріжки, кожна з яких складатиметься з одного основного каналу. Відео доріжка відповідає за камеру, аудіо доріжка – мікрофон, а медіа потік – це контейнер їх обох.

Дескриптор сесії (SDP)

У різних комп'ютерах завжди будуть різні камери, мікрофони, відеокарти та інше обладнання. Існує безліч параметрів, які вони мають. Все це необхідно скоординувати для медіа передачі між двома вузлами мережі. WebRTCробить це автоматично та створює спеціальний об'єкт – дескриптор сесії SDP. Передайте цей об'єкт іншому вузлу, і можна передавати дані медіа. Тільки зв'язку з іншим вузлом поки що немає.

Для цього використовується будь-який сигнальний механізм. SDPможна передати хоч через сокети, хоч людиною (повідомити його іншому вузлу телефоном), хоч Поштою Росії. Все дуже просто – Вам дадуть готовий SDPта його треба переслати. А при отриманні з іншого боку – передати до відомства WebRTC. Дескриптор сесії зберігається у вигляді тексту і його можна змінити у своїх додатках, але зазвичай це не потрібно. Як приклад, при з'єднанні десктоп/телефон іноді потрібно примусово вибирати потрібний аудіо кодек.

Зазвичай під час встановлення з'єднання необхідно вказувати якусь адресу, наприклад URL. Тут у цьому немає необхідності, оскільки через сигнальний механізм Ви самі надішлете дані за призначенням. Щоб вказати WebRTC, що ми хочемо встановити p2pЗ'єднання потрібно викликати функцію createOffer. Після виклику цієї функції та вказівки їй спеціального callback'a буде створено SDPоб'єкт і передано в цей же callback. Все, що від Вас вимагається – передати цей об'єкт через мережу іншому вузлу (співрозмовнику). Після цього на іншому кінці через сигнальний механізм надійдуть дані, а саме цей SDPоб'єкт. Цей дескриптор сесії для цього чужого вузла і тому несе корисну інформацію. Отримання цього об'єкта – сигнал початку з'єднання. Тому Ви повинні погодитися на це і викликати функцію createAnswer. Вона - повний аналог createOffer. Знову у Ваш callbackпередадуть локальний дескриптор сесії та його потрібно буде передати по сигнальному механізму назад.

Варто зазначити, що викликати функцію createAnswer можна лише після отримання чужого SDPоб'єкт. Чому? Тому що локальний SDPоб'єкт, який буде генеруватися при виклику createAnswer, повинен спиратися на віддалений SDPоб'єкт. Тільки в такому випадку можна скоординувати налаштування відео з налаштуваннями співрозмовника. Також не варто викликати createAnswer і createOffer до отримання локального медіа потоку - їм нічого писати в SDPоб'єкт.

Бо в WebRTCє можливість редагування SDPоб'єкта, після отримання локального дескриптора його необхідно встановити. Це може здатися трохи дивним, що потрібно передавати WebRTCте, що вона сама нам дала, але такий протокол. При отриманні віддаленого дескриптора його необхідно встановити. Тому Ви повинні на одному вузлі встановити два дескриптори – свій і чужий (тобто локальний та віддалений).

Після такого рукостисканнявузли знають про побажання одне одного. Наприклад, якщо вузол 1 підтримує кодеки Aі B, а вузол 2 підтримує кодеки Bі C, то, оскільки кожен вузол знає свій і чужий дескриптори, обидва вузли виберуть кодек B(Малюнок 7). Логіка з'єднання тепер встановлена, і можна передавати медіа потоки, але є інша проблема – вузли, як і раніше, пов'язані лише сигнальним механізмом.

Рисунок 7: Узгодження кодеків

Кандидати (Ice candidate)

Технологія WebRTCнамагається заплутати нас своєю новою методологією. У разі встановлення з'єднання не вказується адреса того вузла, з яким потрібно з'єднатися. Встановлюється спочатку логічнез'єднання, а не фізичне, хоч завжди робилося навпаки. Але це не буде дивним, якщо не забувати, що ми використовуємо сторонній сигнальний механізм.

Отже, з'єднання вже встановлено (логічне з'єднання), але поки немає шляху, яким вузли мережі можуть передавати дані. Тут не все так просто, але почнемо з простого. Нехай вузли знаходяться в одній приватній мережі. Як ми вже знаємо, вони можуть легко з'єднуватися один з одним за своїм внутрішнім IPадресам (або можливо, за якимись іншими, якщо використовується не TCP/IP).

Через деякі callback'і WebRTCповідомляє нам Ice candidateоб'єкти. Вони теж приходять у текстовій формі і також, як із дескрипторами сесії, їх потрібно просто переслати через сигнальний механізм. Якщо дескриптор сесії містив інформацію про наші установки на рівні камери та мікрофона, то кандидати містять інформацію про наше розташування в мережі. Передайте їх іншому вузлу, і той зможе фізично з'єднатися з нами, а оскільки в нього вже є дескриптор сесії, то логічно зможе з'єднатися і дані «потечуть». Якщо він не забуде надіслати нам і свій об'єкт кандидата, тобто інформацію про те, де він знаходиться в мережі, то і ми зможемо з ним з'єднатися. Зауважимо тут ще одну відмінність від класичної клієнт-серверної взаємодії. Спілкування з 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протокол (звідси і Iceкандидати). Вузол p2має одного кандидата (своє розташування в мережі – 10.50.200.10 ), а вузол p1, який знаходиться за роутером з NAT, матиме двох кандидатів – локального ( 192.168.0.200 ) та кандидата роутера ( 10.50.200.5 ). Перший не знадобиться, але він генерується, оскільки WebRTCще нічого не знає про віддалений вузл - він може знаходитися в тій же мережі, а може і ні. Другий кандидат стане в нагоді, і, як ми вже знаємо, важливу роль гратиме порт (щоб пройти через NAT).

Запис у таблиці NATгенерується лише коли дані виходять із внутрішньої мережі. Тому вузол p1повинен першим передати дані і лише після цього дані вузла p2зможуть дістатися до вузла p1.

На практиці обидва вузлибудуть перебувати за NAT. Щоб створити запис у таблиці NATкожного роутера, вузли повинні щось відправити віддаленому вузлу, але цього разу ні перший не може дістатися другого, ні навпаки. Це пов'язано з тим, що вузли не знають своїх зовнішніх IPадрес, а відправляти дані на внутрішні адреси безглуздо.

Однак, якщо зовнішні адреси відомі, з'єднання буде легко встановлено. Якщо перший вузол надішле дані на роутер другого вузла, то роутер їх проігнорує, тому що його таблиця NATпоки що порожня. Однак у роутері першого вузла у таблиці NATвиникла необхідна запис. Якщо другий вузол відправить дані на роутер першого вузла, то роутер їх успішно передасть першому вузлу. Тепер і таблиця NATдругого роутера має дані.

Проблема в тому, щоб дізнатися про свою зовнішній вигляд IPадресу, потрібен вузол що знаходиться в спільної мережі. Для вирішення такої проблеми використовуються додаткові сервери, які безпосередньо підключені до інтернету. З їх допомогою також створюються заповітні записи у таблиці NAT.

STUN та TURN сервера

При ініціалізації WebRTCнеобхідно вказати доступні STUNі TURNсервери, які ми надалі називатимемо ICEсерверами. Якщо сервера не буде вказано, то з'єднатися зможуть лише вузли в одній мережі (підключені до неї без NAT). Відразу варто зазначити, що для 3g-мереж обов'язково використання TURNсерверів.

STUN сервер– це просто сервер в інтернеті, який повертає зворотну адресу, тобто адресу вузла відправника. Вузол, що знаходиться за роутером, звертається до 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	Dest 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 .

Internal IP	Internal PORT	External IP	External PORT
192.168.0.200	35777	10.50.200.5	888

Таблиця 8: Таблиця NAT

Нам пощастило, такий рядок існує. Якби не пощастило, то пакет просто відкинувся б. Тепер потрібно зрозуміти, кому із вузлів підмережі треба надсилати цей пакет. Не варто поспішати, давайте знову згадаємо важливість портів у цьому механізмі. Одночасно два вузли в підмережі могли б надсилати запити до зовнішньої мережі. Тоді, якщо для першого вузла роутер вигадав порт 888 , то для другого він би придумав порт 889 . Припустимо, що так і сталося, тобто таблиця r1_natвиглядає так:

Таблиця 10: Роутер замінює адресу приймача

Src IP	Src PORT	Dest IP	Dest PORT
12.62.100.200	6000	192.168.0.200	35777

Таблиця 11: Роутер підмінив адресу приймача

Пакет успішно приходить до вузла p1і, подивившись на вміст пакету, вузол дізнається про своє зовнішнє IPадресу, тобто адресу роутера у зовнішній мережі. Також він знає і порт, який роутер пропускає через NAT.

Що ж далі? Яка від цього користь? Користь – це запис у таблиці r1_nat. Якщо тепер будь-хто буде надсилати на роутер r1пакет із портом 888 , то роутер перенаправить цей пакет вузлу. p1. Таким чином, створився невеликий вузький прохід до захованого вузла p1.

З прикладу вище можна отримати деяке уявлення про роботу NATі суті STUNсервера. Взагалі, механізм ICEі STUN/TURNсервери якраз і спрямовані на подолання обмежень NAT.

Між вузлом та сервером може стояти не один роутер, а кілька. У такому випадку вузол отримає адресу того роутера, який є першим, що виходить в ту ж мережу, що і сервер. Іншими словами, отримаємо адресу роутера, підключеного до STUNсерверу. Для p2pкомунікації це саме те, що нам потрібно, якщо не забути той факт, що в кожному роутері додасться необхідний рядок у таблицю NAT. Тому зворотний шлях буде знову так само гладкий.

TURNсервер – це покращений STUNсервер. Звідси відразу слід отримати, що будь-хто TURNсервер може працювати і як STUNсервер. Проте є й переваги. Якщо p2pкомунікація неможлива (як, наприклад, 3gмереж), то сервер переходить в режим ретранслятора ( relay), тобто працює як посередник. Зрозуміло, ні про яке p2pтоді не йдеться, але за рамками механізму ICEвузли думають, що спілкуються безпосередньо.

У яких випадках необхідний TURNсервер? Чому не вистачає STUNсервера? Справа в тому, що існує кілька різновидів NAT. Вони однаково підміняють IPадресу та порт, однак деякі з них мають додатковий захист від “фальсифікації”. Наприклад, в симетричноютаблиці NATзберігаються ще 2 параметри - IPта порт віддаленого вузла. Пакет із зовнішньої мережі проходить через NATу внутрішню мережу тільки в тому випадку, якщо адреса та порт джерела збігаються із записаними в таблиці. Тому фокус зі STUNсервером не вдається - таблиця NATзберігає адресу та порт STUNсервера і, коли роутер отримує пакет від WebRTCспіврозмовника, його відкидає, оскільки він “фальсифікований”. Він прийшов не від STUNсервера.

Таким чином TURNсервер потрібен у тому випадку, коли обидва співрозмовники перебувають за симетричним NAT(кожен за своїм).

Коротке зведення

Тут наведено деякі твердження про сутності WebRTC, які необхідно завжди пам'ятати. Детально вони описані вище. Якщо якісь твердження Вам здадуться не до кінця ясними, перечитайте відповідні параграфи.

• Медіа потік
  • Відео та аудіо дані упаковуються в медіа потоки
  • Медіа потоки синхронізують медіа доріжки, з яких складаються
  • Різні медіа потоки не синхронізовані між собою
  • Медіа потоки можуть бути локальними та віддаленими, до локального зазвичай підключена камера та мікрофон, видалені отримують дані з мережі в кодованому вигляді
  • Медіа доріжки бувають двох типів – для відео та аудіо
  • Медіа доріжки мають можливість увімкнення/вимкнення
  • Медіа доріжки складаються з медіа каналів
  • Медіа доріжки синхронізують медіа канали, з яких складаються
  • Медіа потоки та медіа доріжки мають мітки, якими їх можна розрізняти
• Дескриптор сесії
  • Дескриптор сесії використовується для логічного з'єднання двох вузлів мережі
  • Дескриптор сесії зберігає інформацію про доступні способи кодування відео та аудіо даних
  • WebRTCвикористовує зовнішній сигнальний механізм – завдання пересилання дескрипторів сесії ( sdp) лягає на додаток
  • Механізм логічної сполуки складається з двох етапів – пропозиції ( offer) та відповіді ( answer)
  • Генерація дескриптора сесії неможлива без використання локального медіа потоку у разі пропозиції ( offer) і неможлива без використання віддаленого дескриптора сесії у разі відповіді ( answer)
  • Отриманий дескриптор треба віддати до реалізації WebRTC, причому неважливо, отриманий цей дескриптор віддалено або локально від тієї ж реалізації WebRTC
  • Є можливість невеликої правки дескриптора сесії
• Кандидати
  • Кандидат ( Ice candidate) – це адреса вузла в мережі
  • Адреса вузла може бути своєю, а може бути адресою роутера або TURNсервера
  • Кандидатів завжди багато
  • Кандидат складається з IPадреси, порту та типу транспорту ( TCPабо UDP)
  • Кандидати використовуються для встановлення фізичного з'єднання двох вузлів у мережі
  • Кандидатів також потрібно пересилати через сигнальний механізм
  • Кандидатів також слід передавати реалізації WebRTC, однак лише віддалених
  • У деяких реалізаціях WebRTCкандидатів можна передавати лише після встановлення дескриптора сесії
• STUN/TURN/ICE/NAT
  • NAT– механізм забезпечення доступу до зовнішньої мережі
  • Домашні роутери підтримують спеціальну таблицю NAT
  • Роутер підміняє адреси в пакетах – адреса джерела на свою, якщо пакет йде у зовнішню мережу, і адреса приймача на адресу вузла у внутрішній мережі, якщо пакет прийшов із зовнішньої мережі
  • Для забезпечення багатоканального доступу до зовнішньої мережі NATвикористовує порти
  • ICE– механізм обходу NAT
  • STUNі TURNсервери – сервери-помічники для обходу NAT
  • STUNсервер дозволяє створювати необхідні записи у таблиці NAT, а також повертає зовнішню адресу вузла
  • TURNсервер узагальнює STUNмеханізм і робить його працюючим завжди
  • У найгірших випадках TURNсервер використовується як посередник ( relay), тобто p2pперетворюється на клієнт-сервер-клієнтний зв'язок.

На сьогоднішній день WebRTC є гарячою технологією для потокового аудіо та відео в браузерах. Консервативні технології, такі як HTTP Streaming і Flash, більше підходять для роздачі записаного контенту (video on demand) і значно поступаються WebRTC щодо реалтайму і онлайн трансляцій, тобто. там, де потрібна мінімальна затримка відео, що дозволяє глядачам бачити те, що відбувається у прямому ефірі.

Можливість якісної комунікації в реальному часі походить від самої архітектури WebRTC, де для транспорту відеопотоків використовується UDP протокол, що є стандартною основою для передачі відео з мінімальними затримками та широко використовується в комунікаційних системах реального часу.

Комунікаційна затримка важлива в системах онлайн трансляцій, вебінарах та інших додатках, де потрібний інтерактивний зв'язок із джерелом відео, кінцевих користувачів та потребує вирішення.

Інша вагома причина спробувати WebRTC це, безумовно, тренд. Сьогодні кожен Android Chrome браузерпідтримує цю технологію, що гарантує мільйони пристроїв, які готові до перегляду трансляції без встановлення будь-якого додаткового ПЗ та конфігурацій.

Для того, щоб перевірити технологію WebRTC у справі та запустити на ній просту онлайн трансляцію, ми використовували серверне програмне забезпечення Flashphoner WebRTC Media & Broadcasting Server. У фічах заявлена ​​можливість транслювати WebRTC потоки в режимі "один до багатьох" (one-to-many), а також підтримка IP камер і систем відеоспостереження через протокол RTSP; У цьому огляді ми зосередимося на web-web трансляціях та їх особливостях.

Встановлення WebRTC Media & Broadcasting Server

Бо для Windows системиверсії сервера не виявилося, а встановлювати віртуалку типу VMWare+Linux не хотілося протестувати онлайн трансляції на домашньому Windowsкомп'ютері не вдалося. Щоб заощадити час, вирішили взяти інстанс на хмарному хостингу на кшталт такого:

Це був Centos x86_64 версії 6.5 без будь-якого попередньо встановленого ПЗ в датацентрі Амстердама. Таким чином, все, що ми отримали в розпорядження, це сервер і ssh доступ до нього. Для тих, хто знайомий з консольними командами Linux, встановлення WebRTC сервера обіцяє пройти просто і безболісно. Отже, що ми зробили:

1. Завантажити архів:

$wget https://сайт/download-wcs5-server.tar.gz

2. Розпакувати:

$tar -xzf download-wcs5-server.tar.gz

3. Встановити:

$cd FlashphonerWebCallServer

Під час інсталяції ввести IP адресу сервера: XXX.XXX.XXX.XXX

4. Активувати ліцензію:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. Запустити WCS сервер:

$service webcallserver start

6. Перевірити лог:

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

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

$ps aux | grep Flashphoner

Процес встановлення закінчено.

Тестування WebRTC онлайн-трансляцій

Тестування трансляцій виявилося справою нехитрою. Крім сервера є web-клієнт, який складається з десятка Javascript, HTML і CSS файлів і був розгорнутий нами в папку /var/www/html на етапі установки. Єдине, що довелося зробити, це вписати IP адресу сервера в конфіг flashphoner.xml, щоб web-клієнт міг встановити з'єднання з сервером HTML5 Websockets. Опишемо процес тестування.

1. Відкриваємо сторінку тестового клієнта index.html у Chrome браузері:

2. Щоб розпочати трансляцію, потрібно натиснути кнопку «Start» посередині екрана.
Перед тим, як це зробити, необхідно переконатися, що веб-камера підключена та готова до роботи. Особливих вимог до вебкамери немає, ми, наприклад, використовували стандартну вбудовану в ноутбук камеру з роздільною здатністю 1280х800.

Chrome браузер обов'язково попросить доступ до камери та мікрофону для того, щоб користувач розумів, що його відео буде надіслано на Інтернет-сервер і дозволив це зробити.

3. Інтерфейс є успішною трансляцією відеопотоку з камери на WebRTC сервер. У верхньому правому куті індикатор вказує, що потік йде на сервер, у нижньому куті кнопка «Стоп» для зупинки відправки відео.

Зверніть увагу на посилання у полі знизу. Вона містить унікальний ідентифікатор цього потоку, тому будь-хто може приєднатися до перегляду. Досить відкрити це посилання у браузері. Щоб її скопіювати в буфер обміну, потрібно клікнути по кнопці «Copy».

У реальних додатках на кшталт вебінарів, лекцій, онлайн відео трансляцій чи інтерактивного TV розробникам доведеться реалізовувати роздачу цього ідентифікатора певним групамглядачів для того, щоб вони змогли підключитися до потрібних потоків, але це вже логіка роботи програми. WebRTC Media & Broadcasting Server її не зачіпає, а займається лише роздачею відео.

5. З'єднання встановлено та глядач бачить потік на екрані. Тепер він може надіслати посилання комусь іншому, зупинити відтворення потоку або увімкнути повноекранний режим, користуючись контролами у правому нижньому кутку

Результати тестування WebRTC сервера онлайн трансляцій

Під час тестів затримка виглядала бездоганною. Пінг до датацентру склав близько 100 мілісекунд і затримка була не помітна оком. Звідси можна припустити, що реальна затримка становить ті ж 100 плюс мінус кілька десятків мілісекунд на час буферизації. Якщо порівнювати з Flash відео: у подібних тестах Flash поводиться не так добре, як WebRTC. Так, якщо на схожій мережі ворухнути рукою, рух на екрані можна побачити тільки через одну/дві секунди.

Щодо якості зазначимо, що на рухах іноді можна розрізнити кубики. Це відповідає природі кодека VP8 та його основне завдання – забезпечити відео зв'язок у реальному часі з прийнятною якістю і без затримок у комунікації.

Сервер досить простий в установці та налаштуванні, для його запуску не потрібні будь-які серйозні навички крім знання Linux на рівні просунутого користувача, що вміє виконувати команди з консолі через ssh і користуватися текстовим редактором. У результаті нам вдалося налагодити онлайн-трансляцію one-to-many між браузерами. Підключення додаткових глядачів до потоку також не викликало проблем.

Якість трансляції виявилася цілком прийнятною для вебінарів та онлайн мовлень. Єдине, що викликало деякі питання, - це дозвіл відео. Камера підтримує 1280х800, але дозвіл на тестовій картинці дуже схоже на 640х480. Мабуть, це питання слід уточнювати у розробників.

Відео з тестування трансляції з веб-камери
через WebRTC-сервер

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).
  • Автоматичне настроювання якості потоку під умови з'єднання.
  • Вбудована система ехо- та шумозаглушення.
  • Автоматичне регулювання рівня чутливості мікрофонів (АРУ).
• Високий рівень безпеки: всі з'єднання захищені та зашифровані відповідно до протоколів TLS та SRTP.
• Існує вбудований механізм захоплення контенту, наприклад, робочого столу.
• Можливість реалізації будь-якого інтерфейсу управління на основі HTML5 та JavaScript.
• Можливість інтеграції інтерфейсу з будь-якими системами back-end за допомогою WebSockets.
• Проект з відкритим вихідним кодом можна впровадити у свій продукт або сервіс.
• Справжня крос-платформність: те саме WebRTC додаток буде однаково добре працювати на будь-якій операційній системі, десктопній або мобільній, за умови, що браузер підтримує WebRTC. Це значно економить ресурси для розробки ПЗ.

Недоліки стандарту

• Для організації групових аудіо та відеоконференцій потрібен сервер ВКС, який мікшував відео та звук від учасників, т.к. браузер не вміє синхронізувати кілька потоків, що входять між собою.
• Усі WebRTC рішення несумісні між собою, т.к. Стандарт визначає лише методи передачі відео та звуку, залишаючи реалізацію методів адресації абонентів, відстеження їх доступності, обміну повідомленнями та файлами, планування та іншого за вендором.
• Іншими словами, ви не зможете зателефонувати з WebRTC програми одного розробника в WebRTC додаток іншого розробника.
• Мікшування групових конференцій вимагає великих обчислювальних ресурсів, тому такий тип відеозв'язку вимагає покупки платної підпискиабо інвестування у свою інфраструктуру, де на кожну конференцію потрібно 1 фізичне ядро ​​сучасного процесора.

Секрети WebRTC: як вендори отримують користь із проривної веб-технології

Цахи Левент-Леві, Bloggeek.me, Відео+Конференція 2015

WebRTC для ринку ВКС

Збільшення числа ВКС-терміналів

Технологія WebRTCвплинула на розвиток ринку ВКС. Після появи перших браузерів з підтримкою WebRTC в 2013 році потенційна кількість терміналів відеоконференцзв'язку по всьому світу відразу збільшилася на 1 млрд. пристроїв. По суті, кожен браузер став ВКС терміналом, який не поступається своїм апаратним аналогам з точки зору якості зв'язку.

Використання у спеціалізованих рішеннях

Використання різноманітних JavaScript бібліотек та API хмарних сервісів із підтримкою WebRTC дозволяє легко додати підтримку відеозв'язку у будь-які веб-проекти. Раніше для передачі даних у реальному часі розробникам доводилося вивчати принципи роботи протоколів та використовувати напрацювання інших компаній, які найчастіше вимагали додаткового ліцензування, що збільшувало витрати. Вже зараз WebRTC активно використовується в сервісах виду "Зателефонувати з сайту", "Онлайн-чат підтримки" тощо.

Ex-користувачам Skype для Linux

У 2014 році Microsoft оголосила про припинення підтримки проекту Skype для Linux, що викликало велике роздратування у IT-фахівців. Технологія WebRTC не прив'язана до операційної системи, а реалізована лише на рівні браузера, тобто. Linux користувачі зможуть побачити у продуктах та сервісах на основі WebRTC повноцінну заміну Skype.

Конкуренція з Flash

WebRTC і HTML5 стали смертельним ударом для технології Flash, яка і так переживала свої далеко не найкращі роки. З 2017 року провідні браузери офіційно перестали підтримувати Flash та технологія остаточно зникла з ринку. Але потрібно віддати Flash належне, адже саме він створив ринок веб-конференцій та запропонував технічні можливості для живого спілкування у браузерах.

Відеопрезентації WebRTC

Дмитро Одинцов, TrueConf, Відео+Конференція жовтень 2017

Кодеки у WebRTC

Аудіокодеки

Для стиснення аудіо-трафіку WebRTC використовуються кодеки Opus і G.711.

G.711— найстаріший голосовий кодек із високим бітрейтом (64 kbps), який найчастіше застосовується у системах традиційної телефонії. Основною перевагою є мінімальне обчислювальне навантаження через використання легких алгоритмів стиснення. Кодек відрізняється низьким рівнем компресії голосових сигналів і не вносить додаткову затримку звуку під час спілкування між користувачами.

G.711 підтримується великою кількістю пристроїв. Системи, в яких використовується цей кодек, більш легкі у застосуванні, ніж ті, що базуються на інших аудіокодеках (G.723, G.726, G.728 тощо). За якістю G.711 отримав оцінку 4.2 у тестуванні MOS (оцінка в межах 4-5 є найвищою і означає хорошу якість, аналогічну до якості передачі голосового трафіку в ISDN і навіть вище).

Opus- Це кодек з низькою затримкою кодування (від 2.5 мс до 60 мс), підтримкою змінного бітрейту і високим рівнем стиснення, що ідеально підходить для передачі потокового аудіосигналу в мережах зі змінною пропускною здатністю. 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 Channel(забезпечує двосторонню передачу даних через встановлене з'єднання).

Перш ніж отримати доступ до мікрофона та камери користувача, браузер запитує на це дозвіл. В Google Chromeможна заздалегідь налаштувати доступ у розділі "Налаштування", в Opera і Firefox вибір пристроїв здійснюється безпосередньо в момент отримання доступу зі списку. Запит на дозвіл буде з'являтися завжди при використанні протоколу HTTP і одноразово, якщо використовувати HTTPS:

RTCPeerConnection. Кожен браузер, що бере участь у WebRTC конференції, повинен мати доступ до цього об'єкта. Завдяки використанню RTCPeerConnection медіадані від одного браузера до іншого можуть проходити навіть через NAT та мережні екрани. Для успішної передачі медіапотоків учасники повинні обмінятися такими даними за допомогою транспорту, наприклад веб-сокетів:

• учасник-ініціатор направляє другому учаснику Offer-SDP (структура даних, з характеристиками медіапотоку, які він передаватиме);
• другий учасник формує "відповідь" - Answer-SDP і пересилає його ініціатору;
• потім між учасниками організується обмін ICE-кандидатами, якщо вони виявлені (якщо учасники знаходяться за NAT або мережевими екранами).

Після успішного завершення обміну між учасниками організується безпосередньо передача медіапотоків (аудіо та відео).

RTCData Channel. Підтримка протоколу Data Channel з'явилася в браузерах порівняно недавно, тому цей API можна розглядати виключно у випадках використання WebRTC у браузерах Mozilla Firefox 22+ та Google Chrome 26+. За його допомогою учасники можуть обмінюватися текстовими повідомленнями у браузері.

Підключення через WebRTC

Десктопні браузери, що підтримуються

• Google Chrome (17+) та всі браузери на основі двигуна Chromium;
• Mozilla FireFox (18+);
• Opera (12+);
• Safari (11+);

Підтримувані мобільні браузери для Android

• Google Chrome (28+);
• Mozilla Firefox (24+);
• Opera Mobile (12+);
• Safari (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 for Business, що відкриває для WebRTC ще більше бізнес застосувань.

Європейські користувачі Мережі розділилися на дві частини: згідно з опитуванням Інституту аналізу громадської думки в Алленбаху (Німеччина), Skype, чат та системи миттєвого обміну повідомленнями стали невід'ємною частиною повсякденного життя для 16,5 млн. дорослих та дітей, 9 млн. використовують ці служби від випадку, а 28 млн. до них не торкаються.

Ситуація може змінитися, оскільки тепер у Firefox інтегрована технологія комунікацій у реальному часі (WebRTC), і навіть сам клієнт. Запустити аудіо- та відеочат тепер нітрохи не складніше, ніж відкрити сайт. Такі послуги, як Facebook і Skype, навпаки, роблять ставку на рішення з використанням окремого клієнта та створенням облікового запису.

WebRTC відрізняється не лише простотою застосування. Цей метод дозволяє навіть встановити пряме з'єднання між двома браузерами. Таким чином, аудіо- та відеодані не проходять через сервер, де може статися перевантаження або адміністратор якого не відрізняється особливою ретельністю щодо приватної сфери або захисту даних. Завдяки прямому з'єднанню для WebRTC не потрібна ні реєстрація, ні обліковий запису будь-якій службі.

Для початку розмови потрібно лише пройти за посиланням. Спілкування залишається приватнимоскільки потік даних шифрується. Комунікацією в реальному часі через браузер компанія Google почала активно займатися ще в 2011 році, коли опублікувала вихідний код своєї реалізації WebRTC.

Незабаром після цього Chrome та Firefox отримали власні WebRTC-движки. В даний час їх мобільні варіанти оснащені як цією технологією, так і движком WebView 3.6, який використовується додатками, що встановлюється разом з Android 5.0.

Для комунікації в реальному часі у веб-браузері повинні бути впроваджені відповідні інтерфейси JavaScript. За допомогою GetUserMedia програмне забезпеченняактивує захоплення з аудіої відеоджерел, тобто з веб-камери та мікрофона. RTCPeerConnection відповідає за встановлення з'єднання, а також за саму комунікацію.

Паралельно з інтеграцією до браузера робоча група Консорціуму Всесвітньої павутини (W3C) форсувала процес стандартизації WebRTC. Він має завершитися вже 2015-го року.

WebRTC задовольняється малим

Для використання служби WebRTC не потрібно багато ресурсів, оскільки сервер з'єднує лише співрозмовників. Установка з'єднання також не становить особливої ​​складності. Спочатку браузер подає серверу WebRTC сигнал, що він планує розпочати дзвінок. Від сервера він отримує HTTPS-посилання – зв'язок здійснюється в зашифрованому вигляді. Цей лінк користувач надсилає своєму співрозмовнику. Після цього браузер запитує у користувача дозвіл на доступ до веб-камери та мікрофону.

Щоб встановити пряме потокове з'єднання зі співрозмовником, браузер отримує від служби WebRTC її IP-адресу та дані конфігурації. Веб-переглядач співрозмовника надходить так само.

Щоб потокове з'єднання функціонувало без збоїв і хорошій якості, у браузері працюють три двигуни. Два з них оптимізують і стискають аудіо відео, третій відповідальний за їх транспортування. Він пересилає дані за допомогою протоколу SRTP(Secure Real-time Transport Protocol), який дозволяє здійснювати зашифровану потокову передачу реального часу.

Якщо пряме з'єднання не вдається встановити, 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 (Secure Real-time Protocol).

Які браузери працюють із WebRTC

Chrome і Firefox оснащені двигуном WebRTC, який використовує такі служби, як talky.io. Браузер від Mozilla може працювати безпосередньо зі своїм клієнтом.

Google та Mozilla продовжують розвивати ідею комунікації в реальному часі: Chrome може проводити конференцію WebRTC з кількома учасниками, а новий клієнт Hello у Firefox розроблений за сприяння з дочірньою компанією телекомунікаційного гіганта Telefonica. Apple поки що залишається осторонь, у Safari WebRTC чекати поки що не варто. Однак існує безліч альтернативних додатківдля iOS та плагінів для Safari.

Корпорація Microsoft йде дещо іншим курсом. Як власник конкурентного сервісу Skype ця компанія не збирається так просто капітулювати перед WebRTC. Натомість Microsoft розробляє технологію під назвою ORTC (Object Real-Time Communications) для Internet Explorer.

Такі відмінності від WebRTC, як інші кодеки та протоколи для встановлення контакту з сервером, незначні і з часом, швидше за все, перетворяться на додаток до WebRTC стандарту, який включає ці розбіжності. Таким чином, за бортом залишається лише Apple - як завжди.

Фото:компанії-виробники; goodluz/Fotolia.com