Протоколи передачі мультимедійного трафіку

У IP-мережах можлива втрата пакетів і зміна їх порядку в процесі доставки. Для узгодження вимог мультимедійних прикладних програм з можливостями IP-мереж був розроблений протокол транспортного рівня RTP (Real-Time Protocol), призначений для доставки даних в реальному масштабі часу. RTP зазвичай використовує UDP як транспортний протокол. RTP підтримує режим Multicast, якщо даний режим підтримується мережевим рівнем.

Сам по собі RTP не забезпечує своєчасної доставки і не надає яких-небудь гарантій QоS. Цей протокол не може гарантувати також коректного порядку доставки даних. Відновлення потоку даних може бути забезпечене приймаючою стороною за допомогою порядкових номерів пакетів, які надає протокол RTP.

При необхідності дотримання конфіденційності інформація і пакети управління можуть бути зашифровані. При аудіо-конференціях кожен з учасників пересилає невеликі закодовані звукові фрагменти тривалістю порядка 20 мсек, кожен з яких поміщається в поле даних RTP-пакета, який у свою чергу вкладається в UDP-дейтаграму.

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

На практиці протокол RTP використовується у поєднанні з протоколом RTCP (RTP control protocol). RTCP служить для моніторингу якості обслуговування (QоS), організації зворотнього зв'язку у разі перевантаження, а також ідентифікації відправника. Він базується на періодичній передачі пакетів, що управляють, всім учасникам сесії. Цей протокол не має самостійного значення і використовується лише спільно з RTP. При організації аудіо-конференції кожен учасник повинен мати адресу і два порти, один для звукових даних, інший для RTCP-пакетів, що управляють.

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

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

Деякі учасники конференції можуть бути недоступними для IP- Multicast (наприклад, знаходитися за Firewall). Для таких вузлів використовується RTP-трансляція. Встановлюється два транслятори поодинці з кожною із сторін Firewall. Зовнішній транслятор передає Multicast -пакети внутрішньому транслятору, а внутрішній транслятор розсилає їх у внутрішню мережу звичайним способом.

Протокол прикладного рівня RTSP надає користувачеві можливість управління медіапотоком. За допомогою протоколу RTSP можна реалізувати такі функції, як “пауза”, “перемотування вперед/назад” тощо. RTSP не займається транспортом даних. RTSP багато в чому подібний HTTP. Кожен медіафайл ідентифікується своїм URL виду “rtsp://..”.

Для того щоб інформувати маршрутизатор про наявність учасників Multicast -обміну в субмережі, пов'язаної з тим чи іншим інтерфейсом, використовується протокол IGMP. Протокол IGMP (internet group management protocol) використовується для відеоконференцій, передачі звукових повідомлень, а також групового виконання команд різними кінцевими пристроями. Цей протокол використовує групову адресацію (Multicast).

Групова форма адресації потрібна тоді, коли якесь повідомлення або послідовність повідомлень необхідно надіслати кільком (але не всім) адресатам одночасно. При цій формі адресації прикінцева система має можливість вибрати, чи хоче вона брати участь у цій процедурі. Коли група вузлів хоче взаємодіяти один з одним, використовується одна Multicast-адреса. При груповій адресації один і той же пакет може бути доставлений заданій групі. Членство в цій групі може динамічно змінюватися з часом. Будь-який вузол може увійти в групу і вийти з групи в будь-який час за своєю ініціативою. У той же час вузол може бути членом великого числа таких груп. Вузол може посилати пакети членам групи, не будучи їм самим. Кожна група має свою адресу класу D (рис. 2.1).

Рисунок 2.1 - Формат групової адреси

Адреса 224.0.0.1 призначена для звернення до всіх груп (всі вузли і сервери залучені в даний момент в мультікастінга - обмін, наприклад, беруть участь у відеоконференції).

Для того щоб брати участь в колективних обмінах в локальній мережі вузол повинний бути забезпечений програмою, яка підтримує цей режим. При цьому сервер локальної мережі інформується про намір використовувати режим Multicast. Сервер передає цю інформацію іншим зовнішнім серверам IP -мережі. Слід мати на увазі, що Multicast також як і широкомовний режим, помітно завантажує мережу. IGMP для передачі своїх повідомлень використовує IP- дейтаграми. Для підключення до групи спочатку надсилається IGMP - повідомлення "всім вузлам" про включення до групи, при цьому локальний Multicast-сервер готує маршрут. Локальний Multicast-сервер час від часу перевіряє вузли і визначає, чи не покинули вони групу (вузол не підтверджує своє членство в групі). Всі обміни між вузлами і Multicast –сервером здійснюються в режимі ip - Multicast, тобто, будь-яке повідомлення адресується всім вузлам групи. Вузол, який не належить групі, IGMP-повідомлень не отримує, що скорочує завантаження мережі.

Поиск по сайту: