ості потокової передачі даних були закритими і вимагали від розробника наявності ліцензії на використання. Це сильно загальмовує розвиток цієї області web-технологій. Ситуація стала мінятися, коли цією проблемою впритул зайнялася корпорація Google. У 2008 році компанія On2 Technologies розробила відео кодек VP8 як заміну попереднім кодекам VP7 і VP6. У 2010 році компанія Google придбала фірму-творця і 19 травня 2010 представляє відкриті вихідні коди. У 2009 році корпорація GIPS створила аудіо кодек iSAC, ядро ??аудіо і відео обробки і протокол WebRTC. GIPS на той момент був лідером в розробці технологій, що використовуються для RTC. GIPS був куплений Google разом з патентними правами на їх розробки, які були опубліковані Google в 2011 під ліцензією BSD - 3 як WebRTCProject. І вже в листопаді 2012 Google оголосив про впровадження підтримки WebRTC в свій браузер GoogleChrome. У початку 2013 року здійснено перший відеодзвінок між Chrome і Firefox. [12]
На момент написання даної роботи технологія підтримується браузерами:
? GoogleChrome;
? GoogleChromeMobile;
? MozillaFirefox;
? MozillaFirefoxMobile;
? Opera.
Для інших браузерів можна використовувати розширення webrtc4all. Таким чином, за заявами інженерів компанії Google, на даний момент існує більше мільярда кінцевих точок, що підтримують WebRTC.
В рамках даної дипломної роботи буде вивчена технологія WebRTC і можливість її практичного застосування вже зараз.
1 ВНУТРІШНЯ АРХІТЕКТУРА І API WEBRTC
1.1 Порівняння з аналогічними технологіями
1.1.1 Java
Першої технологією, яка мала можливості організації браузернихвідеозвонков, була Java. JRE, як правило, присутня на більшості ПК або предустановлена ??в вигляді плагіна в браузері. У підсумку Java-код може виконуватися ПК або браузерні плагіном, захоплювати медіа і відправляти його на сервер за стандартним протоколу RTP. [5]
В подібних програмах на Java була забезпечена належна безпека, так як аплет повинен бути підписаний, і при запуску відбувається запит дозволів у користувача, чи бажає він запустити підписаний аплет від даного виробника, який може отримати доступ до тих або інших функцій.
Плюси:
? немає зайвих ланок, можливість прямої взаємодії з сервером по RTP;
? широка поширеність і доступність JRE для кінцевого користувача;
? протокол RTP має можливість відновлення загублених в мережі пакетів за рахунок Jitter-буфера.
Мінуси:
? слабке придушення луни;
? ручне регулювання підсилення;
? слабке придушення шуму;
? низька швидкодія Java в порівнянні з C + + (на якому написаний WebRTC);
? клієнт-серверна архітектура.
1.1.2 Flash
Випущений в 2002 році FlashPlayer 6 вмів взаємодіяти з FCS MX 1.0, захоплювати медіапотоків користувача і обмінюватися з сервером аудіопотоки по протоколу RTMP. Ехоподавлення в цій технології не було, але платформа справно передавала медіапотоків від плеєра до плеєра через сервер і на той момент могла претендувати на монопольність. Протокол працював поверх TCP, наслідком цього було збереження загублених пакетів. Великий розмір буфера був причиною досить великих затримок при передачі потоку. У результаті на базі RTMP розвивалися, в основному, livevideo...
