Більшість матеріалу з 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має такий пакет:

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

Разом, STUNсервер знає, що йому надійшов пакет від адреси 10.50.200.5:888 . Тепер цю адресу сервер відправляє назад. Тут варто зупинитися і ще раз подивитися, що ми щойно розглядали. Таблиці, наведені вище – це шматочок з заголовкапакету, зовсім не з його вмісту. Про вміст ми не говорили, тому що це не так важливо - воно якось описується в протоколі STUN. Тепер же ми розглядатимемо крім заголовка ще й вміст. Воно буде простим і міститиме адресу роутера – 10.50.200.5:888 , хоча взяли ми його з заголовкапакету. Таке робиться не часто, зазвичай протоколам не важлива інформація про адреси вузлів, важливо, щоб пакети доставлялися за призначенням. Тут ми розглядаємо протокол, який встановлює шлях між двома вузлами.

Отже, тепер у нас з'являється другий пакет, що йде у зворотному напрямку:

Таблиця 7: STUN сервер надсилає пакет з таким вмістом

Далі, пакет подорожує по мережі, поки не опиниться на зовнішньому інтерфейсіроутера r1. Роутер розуміє, що пакет призначений йому. Як він це розуміє? Це можна дізнатися лише по порту. Порт 888 він не використовує для своїх особистих цілей, а використовує для механізму NAT. Тому в цю таблицю роутер дивиться. Дивиться на стовпець External PORTі шукає рядок, який збігається з Dest PORTз пакету, що прийшов, тобто 888 .

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

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

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

Таблиця 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, технологія, розроблена компанією Google, яка дозволяє користувачам говорити безпосередньо у браузері відео та аудіо, не вимагаючи, що використання plugin- Веб-сайти або програми. Відео та аудіо пряме з'єднання між користувачами здійснюється безпосередньо у браузері.
Технологія WebRTC підтримується в Mozilla Firefox браузерів Google Chrome та на будь-який операційній системі, незабаром приєднається і Opera.
Що таке WebRTC?
WebRTC короткий для Web Real Time Comunication, ця технологія дозволяє відкривати аудіо та відео чатів безпосередньо в браузері без необхідності інших плагінів, програм або послуг в Інтернеті для цього. Підключення здійснюється безпосередньо з браузера у браузері.
Якщо відомі послуги (Skype, Yahoo Messenger, Apple FaceTime, Google Hago тощо) вимагають сервера, який з'єднує користувачів, щоб ініціювати та керувати трафіком. Використовуючи ці послуги, нам потрібно зареєструватися і встановив список клієнтів і контактів.
З WebRTC нам не потрібні сервери, програми або сервери, які підключаються до заступитися.
WebRTC переваги:
1. Немає більше програм, що споживають використання ресурсів та акумулятора.
2. У чатах більш приватні (щодо).
3. Як зв'язатись можна зробити на місцевому рівні, а не Flos США сервери для локальних з'єднань.
4. Простота, зручність використання.
5. Можливість подальшого розвитку та в інших напрямках.
6. Зв'язок стабільний і не залежить від зовнішніх з'єднань, які іноді вкрай нестабільні.
У підручнику я використав демо, що люди в Google розробили, це демо досить просто, більш розширені можливості та більш швидкі з'єднання можуть використовувати один із додатків, які підтримують WebRTC, вони простіше у використанні. Незабаром ми робитимемо підручник і про програми WebRTC.
Як використовувати WebRTC демо?
Дуже просто натисніть посилання нижче, він автоматично генерує чат. зв'язати цю кімнату, ви повинні відправити друг / подруга ви хочете, щоб увійти в контакт.
Друг / подруга і ваш, але ви маєте використовувати тільки самі останні версії Mozilla Firefox або Google Chrome.

Demo WebRTC(Вступний чат аудіо-відео)

Увага:
Демо не дуже стабільне, виробляється тільки для демонстрації. Він може бути використаний протягом обмеженого періоду, протягом якого невеликі помилки можуть виникнути з'єднання.
Якщо у вас є проблеми із підключенням, спробуйте створити інший чат.

WebRTC(Web Real-Time Communications) - це технологія, яка дозволяє Web-додаткам та сайтам захоплювати та вибірково передавати аудіо та/або відео медіа-потоки, а також обмінюватися довільними даними між браузерами, без обов'язкового використання посередників. Набір стандартів, які включає технологія WebRTC, дозволяє обмінюватися даними та проводити пірингові телеконференції, без необхідності користувачеві встановлювати плагіни або будь-яке інше стороннє програмне забезпечення.

WebRTC складається з кількох взаємозалежних програмних інтерфейсів (API) та протоколів, які працюють разом. Документація, яку ви знайдете, допоможе вам зрозуміти основи WebRTC, як налаштувати і використовувати з'єднання для передачі даних і медіа-потоку, і багато іншого.

Сумісність

Оскільки реалізація WebRTC знаходиться в процесі становлення і кожен браузер має і WebRTC функцій, рекомендуємо використовувати поліфіл-бібліотеку Adapter.js , від Google, до початку роботи над вашим кодом.

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

Для подальшого вивчення бібліотеки Adapter.js дивимося .

Поняття та використання WebRTC

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

З'єднання між двома вузлами представлене як об'єкт інтерфейсу RTCPeerConnection. Як тільки з'єднання встановлено та відкрито, використовуючи об'єкт RTCPeerConnection , медіапотоки ( MediaStream s) та/або канали даних ( RTCDataChannel s) можуть бути додані до з'єднання.

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

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

more details and links to relevant guides and tutorials needed

WebRTC інтерфейси

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

Налаштування з'єднання та керування

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

Посібники

На сьогоднішній день 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-сервер

Мета цієї статті – на демонстраційному зразку пірингового відеочату (p2p відеочату) ознайомитися з його структурою та принципом роботи. Для цієї мети скористаємося розрахованим на багато користувачів демонстраційним зразком пірингового відеочата webrtc.io-demo. Його можна завантажити за посиланням: https://github.com/webRTC/webrtc.io-demo/tree/master/site.

Слід зазначити, що GitHub - це веб-сайт або веб-сервіс для спільної розробки Web-проектів. На ньому розробники можуть розміщувати коди своїх розробок, обговорювати їх та спілкуватися один з одним. Крім того, деякі великі IT-компанії розміщують офіційні репозиторії на цьому сайті. Сервіс є безкоштовним для проектів із відкритим вихідним кодом. GitHub – це сховище бібліотек відкритого, вільного вихідного коду.

Отже, завантажений з GitHub демонстраційний зразок пірингового відеочату, розмістимо на диску C персонального комп'ютерау створеній директорії для нашої програми "webrtc_demo".

Рис. 1

Як випливає із структури (рис.1) піринговий відеочат складається з клієнтського script.js та серверного server.js скриптів, реалізованих мовою програмування JavaScript. Скрипт (бібліотека) webrtc.io.js (CLIENT) - забезпечує організацію комунікацій у реальному часі між браузерами за одноранговою схемою: "клієнт-клієнт", а webrtc.io.js (CLIENT) та webrtc.io.js (SERVER), використовуючи протокол 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 клацаємо на кнопці download та переходимо на http://nodejs.org/download/. Для користувачів windowsспочатку завантажуємо win.installer (.msi), потім запускаємо win.installer (.msi) на ПК, та встановлюємо nodejs та "npm package manager" в директорію Program Files.

Рис. 2

Таким чином, node.js складається з середовища розробки та виконання JavaScript коду, а також набору внутрішніх модулів, які можна встановити за допомогою менеджера або диспетчера пакетів npm.

Для установки модулів необхідно в командному рядкуз директорії програми (наприклад, "webrtc_demo") виконати команду: npm install ім'я_модуля. У процесі встановлення модулів npm-менеджер створює папку node_modules у директорії, з якої було виконано інсталяцію. У процесі роботи nodejs автоматично підключає модулі директорії node_modules.

Отже, після встановлення node.js відкриваємо командний рядок і оновимо модуль express у папці node_modules директорії webrtc_demo за допомогою менеджера пакетів npm:

C:\webrtc_demo>npm install express

Модуль express – це веб-фреймворк для node.js або веб-платформа для розробки програм. Щоб мати глобальний доступ до express, можна встановити його таким чином: npm install -g express.

Потім оновимо модуль webrtc.io:

C:\webrtc_demo>npm install webrtc.io

Потім у командному рядку запускаємо сервер: server.js:

C:\webrtc_demo>node server.js

Рис. 3

Все сервер працює успішно (рисунок 3). Тепер за допомогою веб-браузера можна звернутися до сервера за ip-адресою та завантажити веб-сторінку index.html, з якої веб-браузер буде вилучати код клієнтського скрипта - script.js та код скрипта webrtc.io.js, та виконувати їх. Для роботи пірингового відеочата (для встановлення з'єднання між двома браузерами) необхідно з двох браузерів, що підтримують webrtc, звернутися по ip-адресі до сигнального сервера, що працює на node.js.

В результаті відкриється інтерфейс клієнтської частини комунікаційної програми (відеочата) із запитом на дозвіл доступу до камери та мікрофону (рис. 4).

Рис. 4

Після клацання на кнопці "Дозволити" підключаються камера та мікрофон для мультимедійного спілкування. Крім того, через інтерфейс відеочату можна спілкуватись текстовими даними (мал. 5).

Рис. 5

Необхідно відмітити, що . Сервер є сигнальним і в основному призначений для встановлення з'єднання між браузерами користувачів. Для роботи серверного скрипта server.js, що забезпечує WebRTC-сигналізацію, використовується Node.js.