Інтернет аb ovo | Стандарти в сфері Інтернет | адресація | Рівні архітектури Інтернет | Протокол IP версії 4 | Протокол IP версії 6 | протокол TCP | Потоки, стек протоколів, механізм портів і мультиплексування | Встановлення TCP-з'єднання і передача даних | Механізми забезпечення достовірності |

загрузка...
загрузка...
На головну

Протоколи RTP і RTCP

  1. Апаратні засоби та протоколи обміну інформацією. Поняття про URL.
  2. Підтримувані протоколи
  3. Протоколи NetWare NetBIOS, NetBEUI
  4. Протоколи канального рівня
  5. протоколи маршрутизації
  6. Протоколи мережі PROFIBUS

Додатки, що забезпечують передачу мовної та відеоінформації, використовують сервіс транспортного рівня без встановлення з'єднань (наприклад, 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-1 889.



Вимоги до сучасних IP-мереж | Багатоадресна розсилка
загрузка...
© um.co.ua - учбові матеріали та реферати