Малюнок 2 - Схема взаємодії з C + + API
Розробники додатків можуть впровадити в свої додатки C + + API і забезпечити до нього доступ через високорівневе Web API на JavaScript, яке описується стандартом W3C. Стандарт Web API від W3C на даний момент має стабільну версію 1.0. Розробники кінцевих клієнтських додатків можуть використовувати Web API для доступу до функцій WebRTC, не вдаючись у подробиці внутрішньої архітектури WebRTC і концентруючи увагу на архітектурі свого web-додатки. Далі в даній роботі будуть описуватися методи Web API, практична частина буде грунтуватися на ньому ж. Web API, також як і C + + API, має два основні інтерфейсу: MediaStream і RTCPeerConnection.
Однією з цікавих особливостей MediaStream, є те, як він працює з аудіо і відео, приймаючи дані від кожного пристрою і передаючи його у вигляді потоку. При отриманні аудіо і відео MediaStream працює окремо з кожним потоком. Таким чином, є можливість відправляти або отримувати від інших клієнтів відразу кілька незалежних потоків. Це особливо актуально для портативних пристроїв, таких як планшети і смартфони, які можуть мати більше однієї web-камери (задня і фронтальна) або мікрофона. MediaStream не обов'язково повинен бути відправлені через Інтернет. Потік може бути використаний локально, перетворений, сконвертовано або ж записаний у файл.
RTCPeerConnection займається установкою прямого підключення і управляє потоками між клієнтами. Він може бути асоційований з двома наборами потоків: вхідних і вихідних. Вихідний потік відправляється в об'єкт RTCPeerConnection від MediaStream і віщається іншим клієнтам, вхідний потік передається назад в MediaStream для обробки і відображення в інтерфейсі, якщо це необхідно.
1.3 Використання Web API
1.3.1 Створення підключення
Для того, щоб створити об'єкт WebRTC-підключення, необхідно викликати конструктор RTCPeerConnection , який приймає два аргументи як параметрів: об'єкт зі списком ICE серверів і об'єкт з параметрами підключення. Конструктор поверне об'єкт підключення, на якому будуть викликатися всі інші описані нижче методи. [10]
Незважаючи на те, що WebRTC дозволяє реалізувати пряму передачу даних між браузерами, необхідно використовувати проміжні сервера для координації з'єднання, обходу NAT і файерволов. Signaling, процес координації підключення, необхідний для того, щоб браузери перед початком передачі даних могли обмінятися службовою інформацією. Ця службова інформація передається від клієнта до клієнта у форматі SDP і може містити:
? повідомленнями управління сесіями, які необхідні для відкриття або закриття сеансу зв'язку;
? повідомленнями про помилки;
? метаданими, такими як інформація про кодеки, ширині смуги пропускання і тип переданих даних;
? ключовими даними для установки захищеного з'єднання;
? мережевий інформацією, такий як IP-адресу та порт. [13]
Приклад SDP при координації WebRTC-з'єднання для передачі аудіо і відео показаний на малюнку 3.
Рисунок 3 - Приклад SDP-повідомлення
SDP генерується методами об'єкта RTCPeerConnection createOffer і createAnswer . Перший створює SDP для запиту підключення, друга - SDP для відповіді. Коли клієнт отримує від іншого клієнта запит на підключення, він може відправити відповідь, згенерований createAnswer. Після того як обидва клі...
