Протоколи RTP і RTCP
Технологія VoIP >> Розділ 4. Протоколи мережі Інтернет
[ << 4.9 Вимоги до сучасних IP-мереж ] [ 4.11 Багатоадресна розсилка >> ]
4.10 Протоколи RTP і RTCP
Додатки, що забезпечують передачу мовної та відеоінформації, використовують сервіс транспортного рівня без встановлення з'єднань (наприклад, UDP). При цьому кожне застосування може забезпечувати формування корисного навантаження пакетів специфічним чином, включаючи необхідні для функціонування поля і дані. Однак, як показав наведений у попередньому параграфі аналіз, дані різної природи (мова, відео) мають спільні особливості, які вимагають забезпечення цілком певної функціональності при їх передачі по мережі. Це дозволяє сформувати якийсь загальний транспортний рівень, який об'єднує функції, загальні для потокових даних різної природи, і який використовується усіма відповідними додатками, надавши протоколу цього рівня статус стандарту. Комітетом IETF був розроблений протокол транспортування інформації в реальному часі - Realtime Transport Protocol (RTP), який став базисом практично для всіх додатків, пов'язаних з інтерактивною передачею мовної та відеоінформації по мережі з маршрутизацією пакетів.
Характерні для IP-мереж тимчасові затримки і варіація затримки пакетів (джиттер) можуть серйозно спотворити інформацію, чутливу до затримки, наприклад, мова та відеоінформацію, зробивши її абсолютно непридатною для сприйняття. Відзначимо, що варіація затримки пакетів набагато сильніше впливає на суб'єктивну оцінку якості передачі, ніж абсолютне значення затримки.
Вже тривалий час ведеться робота зі створення методів зменшення джитер і затримок. Для цього можуть застосовуватися розглянуті в главі 10 механізми, що забезпечують користувачеві заданий рівень якості обслуговування. Вони, звичайно, покращують якість послуг, що надаються мережею, але не можуть зовсім усунути утворення черг в мережевих пристроях і зовсім прибрати джиттер.
Саме протокол RTP дозволяє компенсувати негативний вплив джитер на якість мовної та відеоінформації. У той же час, він не має власних механізмів, що гарантують своєчасну доставку пакетів або інші параметри якості послуг,-це здійснюють нижележащие протоколи. Він навіть не забезпечує всі ті функції, які зазвичай надають транспортні протоколи, зокрема функції виправлення помилок і управління потоком. Зазвичай протокол RTP базується на протоколі UDP і використовує його функції, але може працювати і поверх інших транспортних протоколів.
Існує кілька серйозних причин, по яких такий поширений транспортний протокол, як TCP, погано підходить для передачі чутливою до затримок інформації. По-перше, це алгоритм надійної доставки пакетів. Поки відправник повторно передасть зниклий пакет, одержувач буде чекати, результатом чого може бути неприпустиме збільшення затримки. По-друге, алгоритм управління при перевантаженні в протоколі TCP далеко не оптимальний для передачі мови та відеоінформації. При виявленні втрат пакетів протокол TCP зменшує розмір вікна, а потім буде його повільно збільшувати. Однак передача мовної та відеоінформації здійснюється на цілком певних, фіксованих швидкостях, які не можна миттєво зменшити, не погіршивши якість надаваних послуг. Правильною реакцією на перевантаження для інформаційних потоків цих типів було б зміна методу кодування, частоти відеокадрів або розміру відеозображення.
Протокол RTP передбачає індикацію типу корисного навантаження і порядкового номера пакета в потоці, а також застосування тимчасових міток. Відправник позначає кожен RTP-пакет тимчасової міткою, одержувач витягує її і обчислює сумарну затримку. Різниця у затримці різних пакетів дозволяє визначити джиттер і пом'якшити його вплив - всі пакети будуть видаватися додатком з однаковою затримкою.
Отже, головна особливість RTP - це обчислення середньої затримки деякого набору прийнятих пакетів і видача їх для користувача додатком з постійною затримкою, що дорівнює цього середнього значення. Проте слід мати на увазі, що тимчасова мітка RTP відповідає моменту кодування першого дискретного сигналу пакета. Тому, якщо RTP-пакет, наприклад, з відео, розбивається на блоки даних нижчого рівня, то тимчасова мітка вже не буде відповідати істинному часу їх передачі, оскільки вони перед передачею можуть бути встановлені в чергу.
На рис. 4.7 представлений основний заголовок RTP-пакета, що містить ряд полів, які ідентифікують такі елементи, як формат пакета, порядковий номер, джерело інформації, межі і тип корисного навантаження.
Рис. 4.7. Основний заголовок RTP-пакету
V (2 біта) - поле версії протоколу. Поточна версія протоколу-друга.
Р (1 біт) - поле заповнення. Сигналізує про наявність заповнення в кінці поля корисного навантаження. Заповнення застосовується, коли додаток вимагає, щоб розмір корисного навантаження був кратний, наприклад, 32 бітам.
Х (1 біт) - поле розширення заголовка. Служить для індикації того, що за основним заголовком слід додатковий заголовок, який використовується в експериментальних розширеннях протоколу RTP.
СС (4 біти) - поле відправників. Містить ідентифікатори відправників, чиї дані знаходяться в пакеті, причому самі ідентифікатори слідують за основним заголовком.
М (1 біт) - поле маркера. Зазвичай використовується для вказівки кордонів потоку даних. Сенс біта маркера залежить від типу корисного навантаження. У разі передачі відеоінформації він визначає кінець кадру. При передачі мовної інформації маркер вказує початок періоду активності після періоду мовчання.
РТ (7 бітів) - поле типу корисного навантаження. Ідентифікує тип корисного навантаження і формат даних, включаючи стиснення і шифрування. У стаціонарному стані відправник використовує тільки один тип корисного навантаження протягом сеансу, але він може його змінити у відповідь на зміну умов, якщо про це сигналізує протокол управління транспортуванням інформації в реальному часі (Real-Time Transport Control Protocol).
Порядковий номер пакету (Sequence Number, 16 бітів). Кожен джерело починає нумерувати пакети з довільного номера, що збільшується потім на одиницю з кожним переданим пакетом RTP.
Це дозволяє виявляти втрати пакетів і визначати порядок пакетів з однаковим тимчасовим штампом. Декілька послідовних пакетів можуть мати один і той же штамп, якщо логічно вони породжені в один і той же момент, як, наприклад, пакети, належать одному і тому ж відеокадру.
Тимчасової штамп (Timestamp, 32 біта). Момент часу, в який був створений перший октет даних корисного навантаження. Одиниці, в яких час вказується в цьому полі, залежать від типу корисного навантаження. Значення визначається по локальних годинах відправника.
Ідентифікатор SSRC (Synchronization Source Identifier, 32 біта)-поле ідентифікатора джерела синхронізації. Псевдовипадкове число, яке унікальним чином ідентифікує джерело протягом сеансу і не залежить від мережевого адреси. Це число грає важливу роль при обробці порції даних, що надійшла від одного джерела.
Ідентифікатор CSRC (Contributing Source Identifier, 32 біта) - список полів ідентифікаторів джерел, що беруть участь у створенні RTP-пакета. Пристрій змішування інформації (міксер) вставляє цілий список SSRC ідентифікаторів джерел, які брали участь у побудові даного RTP-пакета. Кількість елементів у списку: від 0 до 15. Якщо число учасників більше 15, вибираються перші 15. Прикладом може служити мовна конференція, в якій передаються RTP-пакети з промовою всіх учасників - кожен зі своїм ідентифікатором SSRC. Вони-то і утворюють список ідентифікаторів CSRC. Вся конференція має загальний ідентифікатор SSRC.
Доставка RTP-пакетів контролюється спеціальним протоколом RTCP (Real Time Control Protocol).
Основною функцією протоколу RTCP є організація зворотного зв'язку приймача з відправником інформації для звіту про якість одержуваних даних. Протокол RTCP передає відомості (як від приймача, так і від відправника) про кількість переданих і втрачених пакетів, значенні джитер, затримки і т.д. Ця інформація може бути використана відправником для зміни параметрів передачі, наприклад для зменшення коефіцієнта стиснення інформації з метою поліпшення якості її передачі. Більш докладний опис протоколів RTP і RTCP можна знайти в RFC-1889.
--Козінцев Олексій 36 гр. 06:18, 20 листопада 2010 (EET)
