Безпечний протокол передачі даних у реальному часі. Протоколи RTP та RTCP у VoIP

2. Основні поняття

3. Протокол передачі даних RTP

Принципи побудови протоколу RTP

Методи контролю роботи

Формат заголовка протоколу RTP

Протокол резервування ресурсів – RSVP

Література

2.1. Груповий аудіоконференцзв'язок

2.2. Відеоконференцзв'язок

2.3. Поняття про мікшери та транслятори

2.4. Порядок байтів, вирівнювання та формат міток часу

3.1. Поля фіксованого заголовка RTP

3.2. Сеанси зв'язку RTP

3.3. Зміни заголовка RTP, що визначаються профілем

3.4. Розширення заголовка RTP

2.3.3. Протокол TCP

2.3.4. Протокол UDP

2.3.5. Протоколи RTP та RTCP

Протоколи RTP та RSVP,

Основні поняття

Груповий аудіо-конференц-зв'язок

Відео-конференц-зв'язок

Поняття про мікшери та транслятори

Протокол керування RTCP

Інтенсивність передачі пакетів RTCP

http://www.isuct.ru/~ivt/books/NETWORKING/NET10/269/pa.html

Найнагальнішою проблемою все частіше стає нестача адресного простору, що потребує зміни формату адреси.

Іншою проблемою є недостатня масштабованість процедури маршрутизації – основи IP-мереж. Швидке зростання мережі викликає навантаження маршрутизаторів, які вже сьогодні змушені підтримувати таблиці маршрутизації з десятками та сотнями тисяч записів, а також вирішувати проблеми фрагментації пакетів. Полегшити роботу маршрутизаторів можна, зокрема шляхом модернізації протоколу IP.

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

В результаті було вирішено піддати протокол IP модернізації, переслідуючи такі основні цілі:

створення нової розширеної схеми адресації;
покращення масштабованості мереж за рахунок скорочення функцій магістральних маршрутизаторів;
забезпечення захисту даних.

Розширення адресного простору. Протокол IP вирішує потенційну проблему нестачі адрес за рахунок розширення розрядності адреси до 128. Однак таке суттєве збільшення довжини адреси було зроблено значною мірою не з метою зняття проблеми дефіциту адрес, а для підвищення ефективності роботи мереж на основі цього протоколу. Головною метою була структурна зміна системи адресації, розширення її функціональних можливостей.

Замість існуючих двох рівнів ієрархії адреси (номер мережі та номер вузла) у протоколі IPv6 пропонується використовувати чотири рівні, що передбачає трирівневу ідентифікацію мереж та один рівень для ідентифікації вузлів.

Тепер адреса записується в шістнадцятковому вигляді, причому кожні чотири цифри відокремлюються одна від одної двокрапкою, наприклад:

FEDC:0A96:0:0:0:0:7733:567A.

Для мереж, що підтримують обидві версії протоколу IPv4 і IPv6, є можливість використовувати для молодших 4 байтів традиційний десятковий запис, а для старших - шістнадцятковий:

0:0:0:0:FFFF 194.135.75.104.

В рамках системи адресації IPv6 є також виділений простір адрес для локального використання, тобто для мереж, що не входять до Інтернету. Існує два різновиди локальних адрес: для "плоських" мереж, не поділених на підмережі (Link-Local), та для мереж, поділених на підмережі (Site-Local), які відрізняються значенням префікса.

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

Основний заголовок дейтаграм IPv6 довжиною 40 байтів має наступний формат (рис. 2.4).

Поле Клас трафіку (Traffic Class)еквівалентно за призначенням полю Тип обслуговування (Type Of Service), а поле Ліміт переходів (Hop Limit)- Полю Час життя (Time To Live)протоколу IPv4.

Поле Мітка потоку (Flow Label)дозволяє виділяти та особливим чином обробляти окремі потоки даних без необхідності аналізувати вміст пакетів. Це дуже важливо з погляду зниження навантаження на маршрутизатори.

Поле Наступний заголовок (Next Header)є аналогом поля Протокол (Protocol) IPv4 і визначає тип заголовка, наступного за основним. Кожен наступний додатковий заголовок також містить поле Next Header.

Протокол управлінняпередачею інформації (Transmission Control Protocol - TCP) було розроблено підтримки інтерактивного зв'язку між комп'ютерами. Протокол TCP забезпечує надійність та достовірність обміну даними між процесами на комп'ютерах, що входять до спільної мережі.

На жаль, протокол TCP не пристосований передачі мультимедійної інформації. Основна причина – наявність контролю за доставкою. Контроль забирає занадто багато часу передачі більш чутливої до затримок інформації. Крім того, TCP передбачає механізми керування швидкістю передачі з метою уникнення перевантажень мережі. Аудіо- та відеодані вимагають, однак, строго певних швидкостей передачі, які не можна змінювати довільним чином.

З одного боку протокол TCP взаємодіє з прикладним протоколом користувача програми, а з іншого - з протоколом, що забезпечує "низькорівневі" функції маршрутизації та адресації пакетів, які, як правило, виконує IP.

Логічна структура мережного програмного забезпечення, реалізує протоколи сімейства TCP/IP у кожному вузлі мережі Інтернет, зображено на рис. 2.5.

Прямокутники позначають модулі, що обробляють дані, а лінії, що з'єднують прямокутники - шляхи передачі даних. Горизонтальна лінія внизу малюнка позначає мережу Ethernet, яка використовується як приклад фізичного середовища.

Мал. 2.5.

Щоб встановити з'єднання між двома процесами на різних комп'ютерах мережі, необхідно знати не тільки інтернет-адреси комп'ютерів, а й номери тих портів ТСР (sockets), які процеси використовують на цих комп'ютерах. Будь-яке TCP-з'єднання в Інтернеті однозначно ідентифікується двома IP-адресами і двома номерами ТСР-портів.

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

Коли протокол TCP передає сегмент даних, копія даних поміщається в чергу повтору передачі і запускається таймер очікування підтвердження.

Протокол передачі дейтаграм (User Datagram Protocol - UDP) призначається для обміну дейтаграмами між процесами комп'ютерів, розташованих в об'єднаній системі комп'ютерних мереж.

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

Транспортний протокол реального часу RTP забезпечує наскрізну передачу мультимедійних даних, таких як інтерактивне аудіо та відео. Цей протокол реалізує розпізнавання типу трафіку, нумерацію послідовності пакетів, роботу з мітками часу та контроль передачі.

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

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

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

Хоча протокол RTP вважається протоколом транспортного рівня, він функціонує зазвичай поверх іншого протоколу транспортного рівня UDP (User Datagram Protocol). Обидва протоколи вносять свої частки у функціональність транспортного рівня. Слід зазначити, що RTP та RTCP є незалежними від нижчих рівнів - транспортного та мережевого, тому протоколи RTP/RTCP можуть використовуватись з іншими відповідними транспортними протоколами.

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

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

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

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

Додаток аудіо-конференц-зв'язку, що використовується кожним учасником конференції, надсилає звукові дані малими порціями, наприклад тривалістю 20 мс. Кожній порції звукових даних передує заголовок RTP; заголовок RTP і дані формуються (інкапсулюються) в пакет UDP. Заголовок RTP показує, який тип кодування звуку (наприклад, ІКМ, АДИКМ або LPC) застосовувався для формування даних у пакеті. Це дає можливість змінювати тип кодування в процесі конференції, наприклад, з появою нового учасника, який використовує лінію зв'язку з низькою смугою пропускання, або під час перевантаження мережі.

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

Оскільки учасники телеконференціїможуть вступати та виходити з неї під час її проведення, то корисно знати, хто бере участь у ній у даний момент і наскільки добре учасники конференції отримують звукові дані. Для цього кожен екземпляр звукової програми під час конференції періодично видає на порт управління (порт RTCP ) для додатків всіх інших учасників повідомлення про прийом пакетів із зазначенням імені свого користувача. Повідомлення про прийом вказує, як добре чуємо поточний оратор, і може використовуватися для керування адаптивними кодерами. Крім імені користувача може бути включена також інша інформація ідентифікації для контролю смуги пропускання. При виході з конференції сайт надсилає пакет BYE протоколу RTCP.

Якщо в телеконференціївикористовуються і звукові, і відеосигнали, вони передаються окремо. Для передачі кожного типу трафіку незалежно від іншого специфікацією протоколу вводиться поняття сеансу зв'язку RTP. Сеанс визначається конкретною парою транспортних адрес призначення (одна мережна адреса плюс пара портів для RTP і RTCP). Пакети для кожного типу трафіку передаються за допомогою двох різних пар портів UDP та/або групових адрес. Ніякого безпосереднього з'єднання на рівні RTP між аудіо- та відеосеансами зв'язку немає, за винятком того, що користувач, що бере участь в обох сеансах, повинен використовувати те саме канонічне ім'я в RTCP-пакетах для обох сеансів, щоб сеанси могли бути пов'язані.

Однією з причин такого поділу є те, що деяким учасникам конференції необхідно дозволити отримувати лише один тип трафіку, якщо вони цього бажають. Незважаючи на поділ, синхронне відтворення мультимедійних даних джерела (звуку та відео) може бути досягнуто при використанні інформації таймування, яка переноситься в пакетах RTCP для обох сеансів.

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

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

Усі поля пакетів RTP/RTCP передаються по мережі байтами (октетами); при цьому найбільше байт передається першим. Всі дані полів заголовка вирівнюються відповідно до їхньої довжини. Октети, позначені як додаткові, мають нульове значення.

Протокол управління RTCP (RTCP - Real-Time Control Protocol) заснований на періодичній передачі пакетів управліннявсім учасникам сеансу зв'язку при використанні того самого механізму розподілу, що й протокол RTP. Протокол нижчого рівня повинен забезпечити мультиплексування інформаційних та керуючих пакетів, наприклад, з використанням різних номерів портів UDP. Протокол RTCP виконує чотири основні функції.

Головна функція – забезпечення зворотного зв'язку для оцінки якості розподілу даних. Це невід'ємна функція RTP як транспортного протоколу, вона пов'язана з функціями управління потоком і перевантаженнями інших транспортних протоколів. Зворотний зв'язок може бути корисним для управління адаптивним кодуванням, але експерименти з IP-мультимовленням показали, що зворотний зв'язок з одержувачами також важливо мати для діагностики дефектів при поширенні інформації. Надсилання звітів зворотного зв'язку про прийом даних усім учасникам дозволяє при спостереженні проблем оцінювати, є вони локальними чи глобальними. З механізмом розподілу IPM для таких об'єктів, як постачальники послуг мережі, також можна отримувати інформацію зворотного зв'язку та діяти при діагностиці проблем мережі як монітор третьої сторони. Ця функція зворотного зв'язку забезпечується звітами відправника та приймача RTCP.
RTCP підтримує стійкий ідентифікатор джерела даних RTP на транспортному рівні, що називається "канонічним ім'ям" (CNAME - canonical name). Так як ідентифікатор SSRC може змінюватися, якщо виявлено конфлікт або перезапущено програму, одержувачам для відстеження кожного учасника потрібне канонічне ім'я CNAME . Одержувачі також вимагають CNAME для відображення множинипотоків інформації від даного учасника на безліч пов'язаних сеансів RTP, наприклад, при синхронізації звукового та відеосигналу.
Перші дві функції вимагають, щоб усі учасники надсилали пакети RTCP, отже, для надання можливості масштабування числа учасників протоколом RTP має регулюватися частота передачі таких пакетів. При посиланні кожним учасником телеконференціїкеруючих пакетів всім іншим учасникам, кожен може незалежно оцінювати загальну кількість учасників.
Четверта, додаткова, функція RTCP повинна забезпечувати інформацію про керування сеансом (наприклад, ідентифікацію учасника), яка буде відображена в інтерфейсі користувача. Найімовірніше, що це буде корисним у "вільно керованих" сеансах, де учасники вступають у групу і виходять із неї без контролю належності чи узгодження параметрів.

Функції з першої по третю є обов'язковими, коли RTP використовується в IP-мультимовленні, і рекомендовані у всіх інших випадках. Розробникам додатків RTP пропонується уникати механізмів, що працюють лише у двосторонньому режимі та не масштабуються для збільшення кількості користувачів.

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

Для кожного сеансу передбачається, що трафік даних відповідає агрегованій межі, яка називається смугою пропускання сеансу зв'язку, яка спільно використовується всіма учасниками. Ця смуга пропускання може бути зарезервована, і її межа встановлена мережею. Смуга пропускання сеансу залежить від типу кодування мультимедійних даних, але вибір типу кодування може бути обмежений смугою пропускання сеансу зв'язку. Параметр смуги пропускання сеансу, як очікується, буде забезпечений програмою керування сеансу, коли вона викличе мультимедійну програму, але мультимедійні програми можуть також встановлювати значення за замовчуванням, засноване на смузі пропускання даних з єдиним відправником типу кодування, обраного для даного сеансу.

Обчислення смуги пропускання для трафіку керування та даних виконуються з урахуванням нижченаведених протоколів транспортного та мережевого рівнів (наприклад, UDP та IP). Заголовки рівня ланки передачі (ЗПД) при обчисленнях не враховуються, оскільки пакет у міру його передачі може інкапсулюватися з різними заголовками рівня ЗПД.

Трафік управління повинен бути обмежений малою та відомою частиною смуги пропускання сеансу: малою настільки, щоб не постраждала основна функція транспортного протоколу – передача даних; відомою так, щоб трафік управління міг бути включений до специфікації смуги пропускання, даної протоколу резервування ресурсіві так, щоб кожен учасник міг незалежно вирахувати свою частку. Передбачається, що частина смуги пропускання сеансу, що виділяється для RTCP повинна бути встановлена рівною 5%. Всі учасники сеансу повинні використовувати однакову величину смуги пропускання RTCP так, щоб обчислені значення інтервалу передачі пакетів управління були однаковими. Тому ці константи мають бути встановлені для кожного профілю.

Алгоритм обчислення інтервалу між посилками складових пакетів RTCP для поділу серед учасників смуги пропускання, виділеної для трафіку управління, має такі основні характеристики:

відправники колективно використовують принаймні 1/4 смуги пропускання трафіку управління так, як у сеансах з великою кількістю одержувачів, але з малою кількістю відправників; щойно встановивши з'єднання, учасники протягом короткого інтервалу часу отримують CNAME передавальних сайтів;
потрібно, щоб розрахунковий інтервал між пакетами RTCP , як мінімум, перевищував 5 секунд, щоб уникнути пачок пакетів RTCP , що перевищують дозволену смугу пропускання, коли кількість учасників мало і трафік не згладжується згідно із законом великих чисел;
інтервал між пакетами RTCP змінюється випадково в межах від половини до півтора розрахункових інтервалів, щоб уникнути ненавмисної синхронізації всіх учасників. Перший пакет RTCP , надісланий після вступу в сеанс зв'язку, також затримується випадковим чином (до половини мінімуму інтервалу RTCP ) у випадку, якщо програма розпочата в безлічі сайтів одночасно, наприклад, при оголошенні про початок сеансу зв'язку;
для автоматичної адаптації до змін обсягом переданої інформації управління обчислюється динамічна оцінка середнього розміру складеного пакета RTCP з використанням всіх отриманих і надісланих пакетів;
цей алгоритм можна використовувати для сеансів, у яких передача пакетів допустима всім учасників. У цьому випадку параметр смуги пропускання сеансу - це добуток смуги пропускання індивідуального відправника на число учасників, і смуга пропускання RTP покладається на протокол, що нижче лежить, і для забезпечення індикації довжини. Максимальна довжина пакетів RTP обмежується лише протоколами рівнів нижче.
В одному блоці даних протоколу нижчого рівня, наприклад, у пакеті UDP, можуть передаватися кілька пакетів протоколу RTP. Це дозволяє зменшити надмірність заголовків та спростити синхронізацію між різними потоками.

Стрімке зростання Internet пред'являє нові вимоги до швидкості та обсягів передачі. І для того, щоб задовольнити всі ці запити, одного збільшення ємності мережі недостатньо, необхідні розумні та ефективні методи управління трафіком та завантаженістю ліній передачі.

У додатках реального часу відправник генерує потік даних з постійною швидкістю, а одержувач (або одержувачі) повинен надавати ці дані додатку з тією самою швидкістю. Такі програми включають, наприклад, аудіо- та відеоконференції, живе відео, віддалену діагностику в медицині, комп'ютерну телефонію, розподілене інтерактивне моделювання, ігри, моніторинг у реальному часі та ін.

Найбільш широко використовуваний протокол транспортного рівня – це TCP. Незважаючи на те, що TCP дозволяє підтримувати безліч різноманітних розподілених додатків, він не підходить для додатків реального часу.

Це завдання і покликаний вирішити новий транспортний протокол реального часу. RTP(Real-Time Transport Protocol), який гарантує доставку даних одному чи більше адресатам із затримкою в заданих межах, тобто. дані можуть бути відтворені в реальному часі.

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

Примітка

Для кожного учасника RTP сеанс визначається парою транспортних адрес призначення пакетів (одна мережна адреса - IP і пара портів: RTP і RTCP).

Пакети RTP містять такі поля: ідентифікатор відправника, що вказує, хто з учасників генерує дані, позначки про час генерування пакета, щоб дані могли бути відтворені стороною, що приймає з правильними інтервалами, інформація про порядок передачі, а також інформація про характер вмісту пакета, наприклад, про типі кодування відео (MPEG, Indeo та ін). Наявність такої інформації дозволяє оцінити величину початкової затримки та обсягу буфера передачі.

Примітка

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

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

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

Протокол RTP використовується тільки для передачі даних - зазвичай багатоадресної - всім учасникам сеансу. Спільно з RTP працює протокол RTCP (Real-time Transport Control Protocol), основне завдання якого полягає у забезпеченні керування передачею RTP. RTCP використовує той же базовий транспортний протокол, що і RTP (зазвичай UDP), але інший номер порту.

RTCP виконує кілька функцій:

Забезпечення та контроль якості послуг та зворотний зв'язок у разі перевантаження. Оскільки RTCP-пакети є багатоадресними, всі учасники сеансу можуть оцінити, наскільки хороша робота та прийом інших учасників. Повідомлення відправника дозволяють одержувачам оцінити швидкість даних та якість передачі. Повідомлення одержувачів містять інформацію про проблеми, з якими вони стикаються, включаючи втрату пакетів та надмірну нерівномірність передачі. Зворотний зв'язок з одержувачами є важливим також для діагностування помилок при поширенні. Аналізуючи повідомлення всіх учасників сеансу, адміністратор мережі може визначити, стосується ця проблема одного учасника або має загальний характер. Якщо додаток-відправник приходить до висновку, що проблема характерна для системи в цілому, наприклад, з причини відмови одного з каналів зв'язку, воно може збільшити ступінь стиснення даних за рахунок зниження якості або взагалі відмовитися від передачі відео - це дозволяє передавати дані по з'єднанню низька ємність.
Ідентифікація відправника. Пакети RTCP містять стандартний текстовий опис відправника. Вони надають більше інформації про відправника пакетів даних, ніж випадково обраний ідентифікатор джерела синхронізації. Крім того, вони допомагають користувачеві ідентифікувати потоки, що стосуються різних сеансів.
Оцінка розмірів сеансу та масштабування. Для забезпечення якості послуг та зворотного зв'язку з метою керування завантаженістю, а також з метою ідентифікації відправника всі учасники періодично надсилають пакети RTCP. Частота передачі цих пакетів знижується зі зростанням кількості учасників. При невеликій кількості учасників один пакет RTCP надсилається максимум кожні 5 секунд. RFC-1889 описує алгоритм, за яким учасники обмежують частоту RTCP-пакетів залежно від загальної кількості учасників. Мета полягає в тому, щоб трафік RTCP не перевищував 5% загального трафіку сеансу.

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

Кожен пакет RTP має основний заголовок, а також можливо додаткові поля, специфічні для програми.

Використання TCP як транспортного протоколу для цих додатків неможливе з кількох причин:

Цей протокол дозволяє встановити з'єднання між двома кінцевими точками, отже, він підходить для многоадресной передачі.
TCP передбачає повторну передачу втрачених сегментів, що прибувають, коли програма реального часу вже на них не чекає.
TCP не має зручного механізму прив'язки інформації про синхронізацію до сегментів – додаткова вимога додатків реального часу.

Інший широко використовуваний протокол транспортного рівня - LJDP немає частини обмежень TCP, але він не надає критичної інформації про синхронізації.

Незважаючи на те, що кожна програма реального часу може мати свої власні механізми для підтримки передачі в реальному часі, вони мають багато спільних рис, а це робить визначення єдиного протоколу дуже бажаним.

Це завдання покликаний вирішити новий транспортний протокол реального часу - RTP (Real-time Transport Protocol), який гарантує доставку даних одному чи більше адресатам із затримкою в заданих межах, тобто. дані можуть бути відтворені в реальному часі.

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

Мал. 1. Фіксований RTP-заголовок.

V(2 біти). Поле версії. Поточна версія – друга.
Р(1 біт). Поле заповнення. Це поле сигналізує про наявність октетів, що заповнюють, в кінці корисного навантаження. Заповнення застосовується, коли програма вимагає, щоб розмір корисного навантаження був кратний, наприклад, 32 біт. У цьому випадку останній октет вказує кількість октетів, що заповнюють.
Х(1 біт). Поле розширення заголовка. Коли це поле задано, то за основним заголовком слідує ще один додатковий, який використовується в експериментальних розширеннях RTP.
СС(4 біти). Поле числа відправників. Це поле містить кількість ідентифікаторів відправників, чиї дані знаходяться в пакеті, причому самі ідентифікатори йдуть за основним заголовком.
М(1 біт). Поле маркер. Сенс біта маркера залежить від типу корисного навантаження. Біт маркера зазвичай використовується для вказівки меж потоку даних. У разі відео він задає кінець кадру. У разі голосу він задає початок промови після періоду мовчання.
РТ(7 біт). Поле типу корисного навантаження. Це поле ідентифікує тип корисного навантаження та формат даних, включаючи стиснення та шифрування. У стаціонарному стані відправник використовує лише один тип корисного навантаження протягом сеансу, але може його змінити у відповідь зміна умов, якщо це сигналізує протокол управління передачею у часі (Real-Time Transport Control Protocol).
Sequence Number(16 біт). Поле порядку. Кожне джерело починає нумерувати пакети з довільного номера, який потім збільшується на одиницю з кожним посланим пакетом даних RTP. Це дозволяє виявити втрату пакетів та визначити порядок пакетів з однаковою відміткою про час. Декілька послідовних пакетів можуть мати одну й ту саму відмітку про час, якщо логічно вони породжені в той самий момент, як, наприклад, пакети, що належать до того самого відеокадру.
Timestamp(32 біти). Поле позначки часу. Це поле містить момент часу, коли перший октет даних корисного навантаження було створено. Одиниці, в яких час вказується у цьому полі, залежить від типу корисного навантаження. Значення визначається по локальному годиннику відправника.
Synchronization Source (SSRC) Identifier(32 біти). Поле ідентифікатора джерела синхронізації: генерується випадковим чином число, що унікально ідентифікує джерело протягом сеансу і незалежне від мережевої адреси. Це число відіграє важливу роль при обробці порції даних, що надійшла, від одного джерела.
Contributing source (CSRC) Identifier(32 біти). Список полів ідентифікаторів джерела "підмішаних" в основний потік, наприклад, за допомогою мікшера. Мікшер вставляє список SSRC ідентифікаторів джерел, які брали участь у побудові даного RTP-пакета. Цей список називається CSRC. Кількість елементів у списку: від 0 до 15. Якщо число учасників більше 15 - вибираються перші 15. Прикладом може бути аудіо-конференція, в RTP-пакети якої зібрані промови всіх учасників, кожен зі своїм SSRC - вони і утворюють список CSRC. У цьому вся конференція має загальний SSRC.

Протокол RTCP, як і будь-який керуючий протокол, значно складніше і за структурою, і за функціями, що виконуються (порівняйте, наприклад, протоколи IP і TCP). Хоча основу протоколу RTCP становить RTP, містить безліч додаткових полів, з допомогою яких реалізує свої функції.

Вирішити проблему пріоритетності для чутливих до затримок даних, на противагу традиційним даним, котрим затримки менш критичні, покликаний протокол резервування ресурсів - RSVP, що у час на розгляді групи інженерної підтримки Internet (IETF). RSVP дозволяє кінцевим системам резервувати мережеві ресурси для отримання необхідної якості послуг, особливо ресурси для графіка реального часу за протоколом RTP. RSVP стосується насамперед маршрутизаторів, хоча програми в кінцевих вузлах також повинні знати, як використовувати RSVP з метою резервування необхідної смуги пропускання для даного класу послуг або рівня пріоритету.

RTP разом з іншими описаними стандартами дозволяє з успіхом передавати відео та аудіо звичайними IP-мережами. RTP/RTCP/RSVP – стандартизоване рішення для мереж із передачею даних у реальному часі. Єдиним його недоліком є те, що воно призначене лише для IP-мереж. Однак це обмеження тимчасове: мережі так чи інакше розвиватимуться у цьому напрямі. Дане рішення обіцяє вирішити проблему передачі чутливих до затримок даних Internet.

Опис протоколу RTP можна знайти у RFC-1889.

2. У релятивізм "світло" є міфічне явище саме по собі, а не фізична хвиля, що є хвилюванням певного фізичного середовища. Релятивістське "світло" - це хвилювання нічого в нічому. У нього немає середовища-носія коливань.

3. У релятивізм можливі маніпуляції з часом (уповільнення), тому там порушуються основоположні для будь-якої науки принцип причинності та принцип суворої логічності. У релятивізм при швидкості світла час зупиняється (тому в ньому абсурдно говорити про частоту фотона). У релятивізмі можливі такі насильства над розумом, як твердження про взаємне перевищення віку близнюків, що рухаються із субсвітловою швидкістю, та інші знущання з логіки, властиві будь-якій релігії.

Протоколи RTP та RTCP у VoIP

RTP є основним транспортним протоколом у мережах IP-телефонії. RTP (Real Time Protocol) - протокол реального часу, був створений для передачі мультимедійної (ауді, відео), закодованої та упакованої в пакети, інформації IP мереж в строгих часових рамках. Передача сегментів RTP відбувається поверх протоколу UDP та IP відповідно на різних рівнях моделі OSI. Використання протоколу UDP, що не гарантує доставку, пов'язане із строгими часовими рамками передачі мультимедійної інформації в реальному часі, а також нездатністю протоколу TCP працювати в режимі реального часу. Тому, незважаючи на втрату частини даних, своєчасність доставки більш важлива в даному випадку.
У загальному вигляді розподіл протоколом за рівнями моделі OSI виглядає так:
Транспортний рівень: RTP поверх UDP
Мережевий: IP
Канальний: Ethernet
Фізичний: Ethernet
Під час передачі мультимедійної інформації з використанням протоколу RTP використовується інкапсуляція наступного виду:

Мінімальним розміром сегмента RTP є 12 байт. Перші два біти визначають версію протоколу. На сьогоднішній день використовується RTPv.2. Наступне поле Р також має розмір 2 біти та вказує на наявність символів заповнювачів у полі даних, при використанні сегментів однакової довжини. Поле X визначає, чи використовується розширений заголовок. Потім поле СС, що складається з 4 біт, визначає число CSRC-полів наприкінці RTP заголовка, тобто кількість джерел, що формують потік. Потім йде поле М - маркерний біт, який використовується виділення важливих даних. Наступне поле РТ має 7 біт. Призначено для визначення типу корисного навантаження – дані необхідні для застосування. За вказаним кодом програма визначає тип мультимедійної інформації та спосіб декодування.
Решта заголовка складається з поля порядкового номера (SequenceNumber) - послідовний номер сегмента, який відстежує порядок пакетів та їх втрату; поля мітки часу (Time Stamp) - код синхронізації, що вказує на час першої кодованої вибірки в корисному навантаженні, дана позначка використовується буферами відновлення синхронізації для ліквідації втрат якості, викликаного варіацією затримки; поля джерела синхронізації SSRC - довільне число, яке відрізняє один RTP-сеанс від іншого, для створення можливості мультиплексування. Після постійної фіксованої частини заголовка RTP можуть додаватися до 15 тридцяти двох розрядних CSRC-полів, які ідентифікують джерела даних.
Опишемо процедуру встановлення RTP сеансу. Протоколом встановлено, що трафік різного типу передається окремих сеансах зв'язку. Для встановлення сеансу потрібно визначити пару транспортних адрес призначення тобто. одна мережна адреса та два порти для RTP та RTCP. Так для відеоконференції необхідно аудіо та відео передавати у різних сеансах з відповідно різними портами призначення. Передача різних типів трафіку з використанням перемежування в одному сеансі могла б викликати такі проблеми:
- при зміні одного з типів трафіку неможливо визначити, який параметр у сеансі необхідно замінити на нове значення;
- для встановлення сеансу використовується лише один інтервал таймінгу, а при передачі різнорідного трафіку кожного типу буде свій інтервал, і вони будуть відрізнятися;
- мікшер RTP не може поєднувати перемежовані потоки різних типів трафіку в один потік;
- передача кількох типів трафіку в одному сеансі RTP неможлива з наступних причин: застосування різних мережевих шляхів або розподіл мережевих ресурсів; прийом підмножини мультимедійних даних, коли це потрібно, наприклад, лише звуку, якщо відеосигнал перевищив доступну смугу пропускання; реалізації приймача, які використовують окремі процеси для різних типів трафіку, тоді як використання окремих сеансів RTP допускає реалізації як з одним, так і з безліччю процесів.

Однак протокол RTP (Real-time Transport Protocol) та UDP (User Datagram Protocol) не гарантують якість, тобто не працюють з QoS (Quality of Service). Тому протокол RTP підтримується RTCP (Real-Time Transport Control Protocol), який надає додаткову інформацію про стан сеансу зв'язку RTP.
Протокол RTCP виконує чотири основні функції:
I. Основне завдання протоколу RTCP - це забезпечення зворотний зв'язок гарантування якості під час передачі даних. Зворотний зв'язок може бути корисним при застосуванні при передачі адаптивного кодування. Також при використанні IP мультикастингу для одержувачів дуже важливо діагностувати помилки під час передачі повідомлень (пакетів). Надсилання повідомлень зі звітами про прийом дозволяють передавальній стороні визначити причину невдалої передачі повідомлень, у разі виникнення такої.
ІІ. RTCP містить незмінний ідентифікатор транспортного рівня для джерела RTP, який має назву «канонічне ім'я» або «Сname» (Canonical Name). Оскільки SSRC-ідентифікатор може бути змінено, у разі знаходження колізій (зіткнень) , для одержувача необхідно значення Сname, щоб відстежувати кожного з учасників. Одержувачам також використовує Cname, щоб встановити відповідність між багатьма потоками даних від одного учасника під час встановлення кількох сесій одночасно, наприклад, щоб синхронізувати аудіо та відео канали під час передачі відео зі звуком.
ІІІ. Перелічені вище дві функції мають на увазі, що всі учасники сеансів надсилали RTCP-пакети, тому швидкість передачі повинна контролюватись для того, щоб RTP міг встановлювати сеанси з більшим числом користувачів. При передачі кожним учасником своїх керуючих пакетів решті будь-який партнер може незалежно визначити повну кількість учасників сесії. Це необхідно для розрахунку частоти передачі повідомлень RTCP.
IV. Ця функція служить для передачі мінімально необхідної інформації, що управляє, такий як ідентифікатор учасників, яка використовується графічним інтерфейсом користувача. Ця функція використовується для слабко контрольованих сесій, коли користувачі входять і виходять без належного узгодження параметрів та характеристик. RTCP виконує функції зручного каналу для контакту з усіма учасниками, але він необов'язково підтримує всі комунікаційні вимоги програми.
В мережах IP з використанням мультикастингу функції один, два і три є обов'язковими при використанні RTP сесій. Також рекомендується їх використання при передачі в інших мережах і середовищах. На сьогоднішній день рекомендується розробникам додатків RTP використовувати засоби, що дозволяють працювати в мультикастному режимі, а не тільки в унікальному.
Розглянемо формат пакетів RTCP.
Стандартом протоколу визначено кілька типів пакетів RTCP. RTCP призначений для передачі службової інформації:
sr: Звіт відправника. Необхідний для статистики прийому та передачі учасників сеансу, які безпосередньо є активними відправниками;
rr: Звіт одержувача. Необхідний статистики від учасників, які є одержувачами;
sdes: описує джерело, включає Cname;
bye: Служить для індикації завершення (виходу) сеансу;
app: Специфічні функції додатків;
Кожен пакет RTCP складається з постійної частини, як і для протоколу RTP, яка використовується RTP-пакетами, за нею слідують поля, які можуть змінюватися по довжині в залежності від типу пакета, але кратну 32 біт. Вимоги вирівнювання та поле довжини у фіксованій частині заголовка введені для того, щоб зробити RTCP-пакети, що об'єднуються. Декілька RTCP-пакетів можуть бути з'єднані один з одним без введення будь-яких сепараторів, щоб отримати складовий RTCP-пакет, який надсилається в рамках транспортного протоколу низького рівня, наприклад UDP. Немає спеціального лічильника індивідуальних RTCP-пакетів, оскільки протокол низького рівня задасть загальну довжину і визначить кінець складеного пакета.

Формат RTCP пакета повідомлення відправника виглядає так, як показано на малюнку вище.

Пакети RTCP піддаються наступним перевіркам на коректність.
- RTP поле версії має дорівнювати 2.
- Поле типу даних першого пакета RTCP у складеному пакеті повинно бути SR або RR.
- Біт заповнювача (P) повинен дорівнювати нулю для першого пакета складеного RTCP пакета, оскільки заповнювач може бути присутнім тільки в останньому.
- Довжина полів індивідуальних RTCP-пакетів повинна в сумі дорівнювати повній довжині складеного пакета.

Сучасні програми не можуть допустити, щоб їх пакети надходили із запізненням. Два протоколи (RTP та PSVP) дозволяють гарантувати своєчасність доставки із забезпеченням якості послуг.

Безперервне зростання Інтернету та приватних мереж висуває нові вимоги до пропускної спроможності. Клієнт-серверні програми далеко перевершують Telnet за обсягами даних, що передаються. World Wide Web призвів до величезного збільшення графіка графічної інформації. Сьогодні до того ж голосові та відеододатки висувають свої специфічні вимоги до і без того перевантажених мереж.

Щоб задовольнити всі ці запити, одного збільшення ємності мережі недостатньо. Що дійсно необхідно, то це розумні ефективні методи управління графіком і контроль завантаженості.

Історично мережі на базі IP надавали всім програмам лише найпростішу послугу з доставки даних у міру можливості. Проте потреби згодом змінилися. Організації, що витратили мільйони доларів на встановлення мережі на базі IP для передачі даних між локальними мережами, стикаються тепер з тим, що такі конфігурації не здатні ефективно підтримувати нові мультимедійні програми реального часу з багатоадресною розсилкою.

АТМ - єдина мережева технологія, яка спочатку розроблялася підтримки звичайного трафіку TCP і UDP поруч із трафіком реального часу. Однак орієнтація на АТМ означає або створення нової мережевої інфраструктури для трафіку реального часу, або заміну наявної конфігурації на базі IP, причому обидва варіанти коштуватимуть дуже недешево.

Тому потреба у підтримці кількох типів трафіку з різними вимогами до якості послуг у межах архітектури TCP/IP є дуже нагальною. Це завдання покликані вирішити два ключові інструменти: транспортний протокол реального часу (Real-Time Transport Protocol, RTP) і протокол резервування ресурсів (Resource Reservation Protocol, RSVP).

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

Найбільш широко використовуваний протокол транспортного рівня – це TCP. Хоча TCP дозволяє підтримувати безліч різноманітних розподілених додатків, він підходить для додатків реального часу.

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

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

Інший широко використовується протокол транспортного рівня - UDP не має перших двох

обмежень (з'єднання «крапка-крапка» та передача втрачених сегментів), але і він не надає критичної інформації про синхронізацію. Таким чином, UDP сам по собі не має будь-яких інструментів загального призначення додатків реального часу.

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

У середовищі реального часу відправник генерує пакети з постійною швидкістю. Вони відправляються їм через однакові інтервали часу, проходять через мережу та приймаються одержувачем, який відтворює дані в реальному часі після їх отримання.

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

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

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

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

Приклад програми для мікшера – комбінування кількох джерел звуку. Наприклад, припустимо, що частина систем аудіосеансу генерує кожна свій власний потік RTP. Більшість часу лише одне джерело активне, хоча іноді одночасно «говорять» кілька джерел.

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

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

Кожен пакет RTP має основний заголовок, а також можливо додаткові поля, специфічні для програми. Мал. 4 ілюструє структуру основного заголовка. Перші 12 октетів складаються з наступних полів:

поле версії (2 біти): поточна версія – друга;
поле заповнення (1 біт): це поле сигналізує про наявність октетів, що заповнюють, в кінці корисного навантаження. (Заповнення застосовується, коли програма вимагає, щоб розмір корисного навантаження був кратний, наприклад, 32 біт.) У цьому випадку останній октет вказує кількість октетів, що заповнюють;
поле розширення заголовка (1 біт): коли це поле задано, то за основним заголовком слідує ще один, додатковий, що використовується в експериментальних розширеннях RTP;
поле числа відправників (4 біти): це поле містить число ідентифікаторів відправників, чиї дані знаходяться в пакеті, причому самі ідентифікатори слідують за основним заголовком;
поле маркера (1 біт): значення біта маркера залежить від типу корисного навантаження. Біт маркера зазвичай використовується для вказівки меж потоку даних. У разі відео він задає кінець кадру. У разі голосу він задає початок промови після періоду мовчання;
поле типу корисного навантаження (7 біт): це поле ідентифікує тип корисного навантаження та формат даних, включаючи стиснення та шифрування. У стаціонарному стані відправник використовує лише один тип корисного навантаження протягом сеансу, але він може його змінити у відповідь на зміну умов, якщо про це сигналізує протокол управління передачею в реальному часі (Real-Time Transport Control Protocol);
поле порядкового номера (16 біт): кожне джерело починає нумерувати пакети з довільного номера, який потім збільшується на одиницю з кожним посланим пакетом даних RTP. Це дозволяє виявити втрату пакетів та визначити порядок пакетів з однаковою відміткою про час. Декілька послідовних пакетів можуть мати одну й ту саму відмітку про час, якщо логічно вони породжені в той самий момент (наприклад, пакети, що належать одному й тому ж відеокадру);
поле позначки часу (32 біта): тут записується момент часу, коли було створено перший октет даних корисного навантаження. Одиниці, у яких у цьому полі вказується час, залежить від типу корисного навантаження. Значення визначається по локальному годиннику відправника;
поле ідентифікатора джерела синхронізації: генероване випадковим чином число, що унікально ідентифікує джерело протягом сеансу.

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

Протокол RTP використовується тільки для передачі даних - зазвичай багатоадресної - всім учасникам сеансу. Окремий протокол керування передачею в реальному часі (Real-Time Transport Control Protocol, RTCP) працює з кількома адресатами для забезпечення зворотного зв'язку з відправниками даних RTP та іншими учасниками сеансу.

RTCP використовує той же базовий транспортний протокол, що і RTP (зазвичай UDP), але інший номер порту. Кожен учасник сеансу періодично надсилає RTCP-пакет решті учасників сеансу. RFC 1889 описує три функції, що виконуються RTCP.

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

Зворотний зв'язок з одержувачами є важливим також для діагностування помилок при поширенні.

Аналізуючи повідомлення всіх учасників сеансу, адміністратор мережі може визначити, чи ця проблема стосується одного учасника чи має загальний характер.

Друга основна функція RTCP – ідентифікація відправника. Пакети RTCP містять стандартний текстовий опис відправника. Вони надають більше інформації про відправника пакетів даних, ніж випадково обраний ідентифікатор джерела синхронізації. Крім того, вони допомагають користувачеві ідентифікувати потоки, що стосуються різних сеансів. Так, вони дають користувачеві можливість визначити, що одночасно відкриті окремі сеанси для аудіо та відео.

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

При невеликій кількості учасників один пакет RTCP надсилається максимум кожні п'ять секунд. RFC 1889 описує алгоритм, за яким учасники обмежують частоту RTCP-пакетів залежно від загальної кількості учасників. Мета полягає в тому, щоб трафік RTCP не перевищував 5% загального трафіку сеансу.

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

Лише реагувати на перевантаження - вже недостатньо. Необхідний інструмент, за допомогою якого перевантажень можна було б уникнути взагалі, тобто зробити так, щоб програми могли резервувати мережеві ресурси відповідно до необхідної якості послуг.

Превентивні заходи корисні як за одноадресної, і при багатоадресної передачі. При одноадресній передачі дві програми домовляються про конкретний рівень якості послуг для цього сеансу. Якщо мережа сильно завантажена, то вона може не в змозі надати послуги необхідної якості. У цій ситуації програмам доведеться відкласти сеанс до кращих часів або спробувати знизити вимоги до якості послуг, якщо це можливо.

Рішення у разі полягає у резервуванні одноадресними додатками ресурсів задля забезпечення необхідного рівня послуг. Тоді маршрутизатори на передбачуваному шляху виділяють ресурси (наприклад, місце у черзі та частина ємності вихідної лінії). Якщо маршрутизатор немає можливості виділити ресурси внаслідок раніше взятих він зобов'язань, він сповіщає про це додаток. При цьому програма може спробувати ініціювати інший сеанс із меншими вимогами до якості послуг або перенести його на більш пізній термін.

Багатоадресне розсилання ставить набагато складніші завдання щодо резервування ресурсів. Вона веде до генерації величезних обсягів мережного графіка - у разі, наприклад, таких програм, як відео, або за наявності великої та розосередженої групи одержувачів. Однак трафік від джерела багатоадресної розсилки може бути значно знижений.

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

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

Деякі одержувачі можуть не мати достатньої обчислювальної потужності для обробки компонентів з високою роздільною здатністю або бути підключені до мережі через підмережу або канал, що не мають достатньої ємності, щоб пропустити повний сигнал.

Резервування ресурсів дозволяє маршрутизаторам заздалегідь визначити, чи вони зможуть здійснити доставку багатоадресного трафіку всім одержувачам.

У попередніх спробах реалізації резервування ресурсів та у прийнятих у frame relay та АТМ підходах необхідні ресурси запитує джерело потоку даних. Цей метод достатній у разі одноадресної передачі, тому що програма передає дані в певному темпі, а необхідний рівень якості послуг закладений у схему передачі.

Однак такий підхід не можна використовувати для багатоадресної розсилки. У різних членів групи можуть бути різні вимоги до ресурсів. Якщо вихідний потік може бути розділений на підпотоки, деякі члени групи, цілком можливо, побажають отримувати тільки один з них. Зокрема, деякі одержувачі зможуть обробляти лише компонент відеосигналу з низькою роздільною здатністю. Або якщо кілька відправників ведуть мовлення на одну групу, то одержувач може вибрати тільки одного відправника або деяке їх підмножина. Нарешті, вимоги різних одержувачів до якості послуг можуть змінюватись в залежності від обладнання виводу, потужності процесора та швидкості каналу.

З цієї причини резервування ресурсів одержувачем є кращим. Відправники можуть надати маршрутизаторам загальні характеристики трафіку (наприклад, темп передачі та варіабельність), але одержувачі повинні самі визначити необхідний рівень якості послуг. Маршрутизатори потім зводять докупи запити на виділення ресурсів на загальних ділянках дерева поширення.

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

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

Специфікація фільтравизначає набір пакетів, під які запитуються ресурси. Разом із сеансом вона визначає набір пакетів (або потік), для яких потрібна якість послуг має бути забезпечена. Будь-які інші пакети, що направляються цьому адресату, обробляються остільки, оскільки мережа може це зробити.

RSVP не визначає вмісту специфікації потоку, він просто передає запит. Специфікація потоку зазвичай включає клас послуг, Rspec (R означає резерв) та Tspec (T означає трафік). Два інших параметри є набір чисел. Параметр Rspec визначає потрібну якість послуг, а Tspec описує потік даних. Вміст Rspec та Tspec прозорий для RSVP.

У принципі, специфікація фільтра визначає довільне підмножина пакетів одного сеансу (тобто тих пакетів, адресат яких визначається цим сеансом). Наприклад, специфікація фільтра може визначати лише конкретних відправників або визначати протоколи чи пакети, поля протокольних заголовків яких збігаються із заданими.

Мал. 3 ілюструє зв'язок між сеансом, специфікацією потоку та специфікацією фільтра. Кожен пакет, що приходить, відноситься принаймні до одного сеансу і розглядається відповідно до логічного потоку для цього сеансу. Якщо пакет не належить до будь-якого сеансу, він доставляється остільки, оскільки є вільні ресурси.

Основна складність RSVP пов'язана з багатоадресною розсилкою. Приклад багатоадресної конфігурації наведено на рис. 6 . Ця конфігурація складається із чотирьох маршрутизаторів. Канал між двома будь-якими маршрутизаторами, що зображується лінією, може бути як прямий канал, так і підсіти. Три хости - Gl, G2 і G3 - входять в одну групу і одержують дейтаграми з відповідною груповою адресою. Дані на цю адресу передаються двома хостами - S1 і S2. Червона лінія відповідає дереву маршрутизації для S1 та цієї групи, а синя лінія - для S2 та цієї групи. Лінії зі стрілками вказують напрямок передачі пакетів від S1 (червона) і від S2 (синя).

Малюнок показує, що всі чотири маршрутизатори повинні знати резервування ресурсів кожним одержувачем. Таким чином, запити на виділення ресурсів поширюються у напрямку по дереву маршрутизації.

RSVP використовує два основних типи повідомлень: Resv та Path. Повідомлення Resv генеруються одержувачами і поширюються вгору деревом, причому кожен вузол по дорозі об'єднує і компонує пакети від різних одержувачів, коли це можливо. Ці повідомлення призводять до переходу маршрутизатора до резервування ресурсів для даного сеансу (групової адреси). Зрештою, всі об'єднані повідомлення Resv досягають хостів-відправників. Грунтуючись на отриманій інформації, вони задають належні параметри управління графіком першого транзитного вузла.

Мал. 7 показує потік повідомлень Resv. Зверніть увагу: повідомлення об'єднуються; отже, лише одне повідомлення передається вгору по будь-якій гілки комбінованого дерева доставки. Однак ці повідомлення повинні періодично надсилатися знову для продовження терміну резервування ресурсів.

Повідомлення Path використовується для поширення інформації про зворотний маршрут. Усіми сучасними протоколами багатоадресної маршрутизації підтримується лише прямий маршрут як дерева поширення (вниз від відправника). Але повідомлення Resv повинні передаватися у зворотному напрямку через усі проміжні маршрутизатори всім хостам-відправникам.

Оскільки протокол маршрутизації не надає інформації про зворотний маршрут, вона передається RSVP у повідомленнях Path. Будь-який хост, який бажає стати відправником, надсилає повідомлення Path всім членам групи. По дорозі кожен маршрутизатор і кожен хост-адресат переходить у стан path, що вказує на те, що пакети для цього відправника повинні пересилатися на транзитний вузол, з якого даний пакет отримано. Мал. 5 показує, що пакети Path передаються тими самими шляхами, як і пакети даних.

Розглянемо роботу протоколу RSVP. З погляду хоста робота протоколу складається з наступних етапів (перші два етапи у цій послідовності мають іноді зворотну черговість).

Отримувач вступає до групи багатоадресної розсилки за допомогою відправлення повідомлення протоколу IGMP сусідньому маршрутизатору.
Потенційний відправник надсилає повідомлення на адресу групи.
Отримувач приймає повідомлення Path, що ідентифікує відправника.
Тепер, коли одержувач має інформацію про зворотний шлях, може надсилати повідомлення Resv з дескрипторами потоку.
Повідомлення Resv надсилаються по мережі відправнику.
Відправник починає передачу даних.
Отримувач починає прийом пакетів даних.

Вчорашні методи роботи з великими обсягами графіка непридатні для сучасних систем. Без нових інструментів задовольняти зростаючим вимогам передачі даних у зв'язку зі зростанням їх обсягу, поширенням додатків реального часу і багатоадресної розсилки неможливо. RTP та RSVP забезпечують надійний фундамент для мереж наступного покоління LAN.

Як приклад реального застосування цих протоколів можна навести модель VoIP (Voice over IP) – передачі голосу по IP-мережах, яка описана в стандарті H.232 та передбачає передачу аудіо-, відеоінформації та даних через IP-мережу. У цьому випадку протокол реального часу RTP використовується для з'єднання, а протокол RSVP – для резервування ресурсів мережі.

Однією з найважливіших тенденцій в еволюції сучасних телекомунікацій є розвиток засобів IP-телефонії - безлічі нових технологій, що забезпечують передачу мультимедійних повідомлень (мовлення, даних, відео) через інформаційно-обчислювальні мережі (ІТТ), побудовані на базі протоколу IP (Internet Protocol), у тому числі локальні, корпоративні, глобальні обчислювальні мережі та мережа Internet. Поняття IP-телефонії включає Internet-телефонію, що дозволяє організувати телефонний зв'язок між абонентами мережі Internet, між абонентами телефонних мереж загального користування (ТСОП) через Internet, а також телефонний зв'язок абонентів ТСОП і Internet один з одним.

IP-телефонія має низку безперечних переваг, що забезпечують її швидкий розвиток та розширення ринку комп'ютерної телефонії. Вона вигідна кінцевим користувачам, які забезпечуються телефонним зв'язком за досить низької похвилинної оплати. Компаніям, які мають віддалені філії, IP-технологія дозволяє організувати мовний зв'язок за допомогою вже існуючих корпоративних IP-мереж. Замість кількох мереж зв'язку у своїй використовується одна. Безумовною перевагою IP-телефонії перед звичайним телефоном є можливість надання додаткових послуг за рахунок використання мультимедійного комп'ютера та різних Інтернет-додатків. Таким чином, завдяки IP-телефонії підприємства та приватні особи можуть розширити можливості організації зв'язку шляхом включення до них сучасного відеоконференцзв'язку, спільного використання додатків, засобів типу електронної креслярської дошки (whiteboard) тощо.

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

У мережах, що не забезпечують гарантовану якість обслуговування (до них належать мережі, побудовані на основі протоколу IP), пакети можуть губитися, може змінюватися порядок їх надходження, дані, що передаються в пакетах, можуть спотворюватися. Для забезпечення надійної доставки інформації в цих умовах використовуються різні процедури транспортного рівня. При передачі цифрових даних цієї мети застосовується протокол ТСР (Transmission Control Protocol). Цей протокол забезпечує надійну доставку даних та відновлює вихідний порядок проходження пакетів. Якщо в пакеті виявлено помилку, або пакет втрачається, процедури TCP надсилають запит на повторну передачу.

Для додатків аудіо- та відеоконференцзв'язку затримки пакетів значно більшою мірою впливають на якість сигналу, ніж окремі спотворення даних. Відмінності у затримках можуть призводити до появи пауз. Для таких додатків необхідний інший протокол транспортного рівня, що забезпечує відновлення вихідної послідовності пакетів, їх доставку з мінімальною затримкою, відтворення в реальному масштабі часу точно задані моменти, розпізнавання типу трафіку, груповий або двосторонній зв'язок. Таким протоколом є транспортний протокол реального часу RTP (Real-Time Transport Protocol). Цей протокол регламентує передачу мультимедійних даних у пакетах через ІТТ на транспортному рівні та доповнюється протоколом управління передачею даних у реальному масштабі часу RTCP (Real-Time Control Protocol). Протокол RTCP, у свою чергу, забезпечує контроль доставки мультимедійних даних, контроль якості обслуговування, передачу інформації про учасників поточного сеансу зв'язку, управління та ідентифікацію, і іноді вважається частиною протоколу RTP.

У багатьох публікаціях, присвячених IP-телефонії, зазначається, що більшість мережного обладнання та спеціального програмного забезпечення для даної технології розробляється на базі Рекомендації Сектора стандартизації електрозв'язку Міжнародного союзу електрозв'язку (МСЕ-Т) Н.323 (у тому числі, TAPI 3.0, NetMeeting 2.0 і т.д.). Як співвідноситься Н.323 з протоколами RTP та RTCP? Н.323 - це широкий концептуальний каркас, що включає безліч інших стандартів, кожен із яких відповідає за різні аспекти передачі інформації. Більшість із цих стандартів, наприклад, стандарти аудіо- та відеокодеків, мають широке застосування не тільки в IP-телефонії. Що ж до протоколів RTP/RTCP, всі вони становлять основу стандарту H.323, орієнтовані забезпечення саме IP-технологии, лежать основу організації IP-телефонії. Розгляду даних протоколів та присвячена ця стаття.

Транспортний протокол реального часу RTP забезпечує наскрізну передачу мультимедійних даних, таких як інтерактивне аудіо та відео. Цей протокол реалізує розпізнавання типу трафіку, нумерацію послідовності пакетів, роботу з мітками часута контроль передачі.

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

Хоча протокол RTP вважається протоколом транспортного рівня, він функціонує зазвичай поверх іншого протоколу транспортного рівня UDP (User Datagram Protocol). Обидва протоколи вносять свої частки у функціональність транспортного рівня. Слід зазначити, що RTP і RTCP є незалежними від рівнів нижче - транспортного і мережевого, тому протоколи RTP/RTCP можуть використовуватися з іншими відповідними транспортними протоколами.

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

Для того, щоб протокол RTP був гнучкішим і міг застосовуватися для різних додатків, деякі його параметри зроблені навмисно не визначеними, зате в ньому передбачено поняття профілю. Профіль - це набір параметрів протоколів RTP і RTCP для конкретного класу додатків, що визначає особливості їх функціонування. У профілі визначаються використання окремих полів заголовків пакетів, типи трафіку, доповнення до заголовків та розширення заголовків, типи пакетів, послуги та алгоритми забезпечення безпеки зв'язку, особливості використання протоколу нижчого рівня тощо (як приклад у розділі 11 розглянуто запропонований у RFC 1890 профіль RTP для аудіо- та відеоконференцій з мінімальним керуванням). Кожна програма зазвичай працює тільки з одним профілем, і завдання типу профілю відбувається шляхом вибору відповідної програми. Жодної явної індикації типу профілю номером порту, ідентифікатором протоколу тощо. не передбачено.

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

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

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

Додаток аудіоконференцзв'язку, який використовується кожним учасником конференції, посилає звукові дані малими порціями, наприклад, тривалістю 20 мс. Кожній порції звукових даних передує заголовок RTP; заголовок RTP і дані формуються (інкапсулюються) в пакет UDP. Заголовок RTP показує, який тип кодування звуку (наприклад, ІКМ, АДИКМ або LPC) використовувався для формування даних у пакеті. Це дає можливість змінювати тип кодування в процесі конференції, наприклад, з появою нового учасника, який використовує лінію зв'язку з низькою смугою пропускання, або під час перевантаження мережі.

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

Так як учасники телеконференції можуть вступати і виходити з неї під час її проведення, то корисно знати, хто бере участь у ній в даний момент, і як добре учасники конференції отримують звукові дані. Для цього кожен екземпляр звукової програми під час конференції періодично видає на порт управління (порт RTCP) для додатків всіх інших учасників повідомлення про прийом пакетів із зазначенням імені свого користувача. Повідомлення про прийом вказує, як добре чуємо поточний оратор, і може використовуватися для керування адаптивними кодерами. Крім імені користувача, може бути включена також інша інформація ідентифікації для контролю смуги пропускання. При виході з конференції сайт надсилає пакет BYE протоколу RTCP.

Якщо в телеконференції використовуються і звукові, і відеосигнали, вони передаються окремо. Для передачі кожного типу трафіку незалежно від іншого специфікацією протоколу вводиться поняття сеансу зв'язку RTP (див. список скорочень і термінів, що використовуються). Сеанс визначається конкретною парою транспортних адрес призначення (одна мережна адреса плюс пара портів для RTP і RTCP). Пакети для кожного типу трафіку передаються за допомогою двох різних пар портів UDP та/або групових адрес. Ніякого безпосереднього з'єднання на рівні RTP між аудіо- та відеосеансами зв'язку немає, за винятком того, що користувач, що бере участь в обох сеансах, повинен використовувати те саме канонічне ім'я в RTCP-пакетах для обох сеансів так, щоб сеанси могли бути пов'язані.

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

Мікшери та транслятори можуть бути розроблені для низки цілей. Приклад: мікшер відеосигналу, який масштабує відеозображення окремих людей у незалежних потоках відеосигналу і виконує їхню композицію в один потік відеосигналу, моделюючи групову сцену. Приклади трансляції: з'єднання групи хостів, які використовують лише протоколи IP/UDP з групою хостів, які сприймають тільки ST-II, або перекодування відеосигналу пакет за пакетом з індивідуальних джерел без пересинхронізації або мікшування. Деталі роботи мікшерів та трансляторів розглянуті у розділі 5.

Усі поля пакетів RTP/RTCP передаються мережею байтами (октетами); при цьому найбільше байт передається першим. Всі дані полів заголовка вирівнюються відповідно до їхньої довжини . Октети, позначені як додаткові, мають нульове значення.

Абсолютний час (час Wallclock) у RTP представлений з використанням формату тимчасової мітки мережного протоколу часу NTP (Network Time Protocol), який є відліком часу в секундах щодо нуля годин 1 січня 1900 року. Повний формат тимчасової мітки NTP - 64-розрядне число без знака з фіксованою комою з цілою частиною в перших 32 бітах і дробової - в останніх 32 бітах. У деяких полях з більш компактним поданням використовуються лише середні 32 біти - молодші 16 бітів цілої частини та старші 16 бітів дробової частини.

У наступних двох розділах цієї статті (3 та 4) розглядаються формати пакетів та особливості функціонування протоколів RTP та RTCP відповідно.

Як було зазначено вище, пакет RTP включає до свого складу фіксований заголовок, необов'язкове розширення заголовка зі змінною довжиною та поле даних. Фіксований заголовок пакетів протоколу RTP має такий формат: .

Перші дванадцять октетів присутні в кожному пакеті RTP, в той час як поле ідентифікаторів джерел CRC (сontributing source), що включаються, присутній тільки тоді, коли воно вставлено мікшером. Поля мають такі призначення.

Версія (V): 2 біти. Це поле ідентифікує версію RTP. У цій статті розглядається версія 2 протоколу RTP (величина 1 використовувалася першої чорнової версії RTP).

Додаток (P): 1 біт. Якщо біт доповнення встановлено в одиницю, то пакет в кінці містить один або більше октетів доповнення, які не є частиною трафіку. Останній акт доповнення містить вказівку на число таких октетів, які повинні ігноруватися. Додаток може вимагатися деяким алгоритмам шифрування з фіксованими розмірами блоку або для перенесення декількох пакетів RTP в одному блоці даних протоколу рівня нижче.

Розширення (X): 1 біт. Якщо біт розширення встановлений, то за фіксованим заголовком слідує розширення заголовка з форматом, визначеним в .

Лічильник CSRC (CC): 4 біти. Лічильник CSRC містить кількість ідентифікаторів джерел, що включаються CSRC (див. список використовуваних скорочень і термінів), які йдуть за фіксованим заголовком.

Маркер (M): 1 біт. Інтерпретація маркера визначається профілем. Він призначений для того, щоб дозволити маркувати у потоці пакетів значні події (наприклад, межі відеокадру). Профіль може вводити додаткові біти маркера або визначати, що ніякого біта маркера немає, змінюючи кількість бітів у полі типу трафіку (див. ).

Тип трафіку (PT): 7 біт. Це поле ідентифікує формат трафіку RTP та визначає його інтерпретацію додатком. Профіль визначає задану за умовчанням статичну відповідність значень РТ та форматів трафіку. Додаткові коди типу трафіку можна визначити динамічно через не-RTP кошти. Відправник пакету RTP у будь-який час видає єдине значення типу трафіку RTP; це поле призначене для мультиплексування окремих мультимедійних потоків (див. ).

Порядковий номер: 16 біт. Значення порядкового номера збільшується на одиницю з кожним надісланим інформаційним пакетом RTP і може використовуватися одержувачем для виявлення втрат пакетів та відновлення їх вихідної послідовності. Початкова величина порядкового номера вибирається випадковим чином, щоб ускладнити спроби зламування ключа з опорою на відомі значення даного поля (навіть якщо шифрування не використовується джерелом, оскільки пакети можуть проходити через транслятор, який застосовує шифрування). Тимчасова мітка: 32 біти. Тимчасова мітка відображає момент дискретизації першого октету в інформаційному пакеті RTP. Момент дискретизації повинен бути отриманий від таймера, який збільшує свої значення монотонно та лінійно в часі для забезпечення синхронізації та визначення джиттера (див. розділ 4.3.1). Роздільна здатність таймера повинна бути достатньою для бажаної точності синхронізації та вимірювання джиттера надходження пакетів (одного звіту таймера на відеокадр зазвичай буває недостатньо). Частота таймування залежить від формату трафіку, що передається, і задається статично у профілі або специфікації формату трафіку або може задаватися динамічно для форматів трафіку, визначених через «не-RTP засоби». Якщо пакети RTP періодично генеруються, то повинні використовуватися номінальні моменти дискретизації, що визначаються таймером дискретизації, а не значення системного таймера. Наприклад, для звукового сигналу з фіксованою швидкістю бажано, щоб датчик тимчасової мітки збільшувався на одиницю кожного періоду дискретизації. Якщо звуковий додаток з пристрою введення читає блоки, що містять 160 відліків, то тимчасова мітка при цьому повинна збільшуватися на 160 для кожного такого блоку, незалежно від того, чи блок передано в пакеті або скинутий, як пауза. Початкове значення тимчасової мітки, як і початкове значення порядкового номера, є випадковою величиною. Декілька послідовних пакетів RTP можуть мати рівні тимчасові мітки, якщо вони логічно генеруються одночасно, наприклад, належать тому самому відеокадру. Послідовні пакети RTP можуть містити немонотонні тимчасові мітки, якщо дані не передаються в порядку дискретизації, як у випадку відеокадрів MPEG, що інтерполюються (проте порядкові номери пакетів при передачі все ж таки будуть монотонними).

SSRC: 32 біти. Поле SSRC (synchronization source) ідентифікує джерело синхронізації (див. список скорочень і термінів, що використовуються). Цей ідентифікатор вибирається випадково так, щоб жодні два джерела синхронізації в рамках одного і того ж сеансу зв'язку RTP не мали однакових ідентифікаторів SSRC. Хоча ймовірність того, що кілька джерел виберуть один і той же ідентифікатор, низька, все ж таки всі реалізації RTP повинні бути готові виявляти і дозволяти подібні колізії. У розділі 6 розглянуто ймовірність колізій разом із механізмом для їх вирішення та виявлення зациклювань рівня RTP, заснованим на унікальності ідентифікатора SSRC. Якщо джерело змінює свою вихідну транспортну адресу, він повинен також вибрати новий ідентифікатор SSRC, щоб його не інтерпретували як зациклене джерело.

Список CSRC: від 0 до 15 пунктів, 32 біти кожен. Список CSRC (сontributing source) ідентифікує джерела трафіку, що містяться в пакеті. Число ідентифікаторів задається полем CC. Якщо є більше п'ятнадцяти джерел, що включаються, то тільки 15 з них можуть бути ідентифіковані. Ідентифікатори CSRC вставляються мікшерами при використанні ідентифікаторів SSRC для джерел, що включаються. Наприклад, для звукових пакетів ідентифікатори SSRC всіх джерел, які були змішані під час створення пакета, перераховуються у списку CSRC, забезпечуючи коректну індикацію джерел повідомлень для одержувача.

Як згадувалося вище, відповідно до протоколу RTP трафік різних типів повинен передаватися окремо, у різних сеансах зв'язку RTP. Сеанс визначається конкретною парою транспортних адрес призначення (одна мережна адреса плюс пара портів для RTP і RTCP). Наприклад, у телеконференції, що складається зі звукового та відеосигналу, кодованих окремо, трафік кожного типу потрібно передавати в окремому сеансі RTP зі своєю власною транспортною адресою призначення. Не передбачається, що звуковий та відеосигнал передаватимуться в одному сеансі RTP і розділятимуться на основі типу трафіку або полів SSRC. Перемежування пакетів, що мають різні типи трафіку, але використовують один і той же SSRC, викликало б деякі проблеми:

Якщо протягом сеансу один із типів трафіку зміниться, то не буде жодних загальних засобів, щоб визначити, яка зі старих величин була замінена на нову.
SSRC ідентифікує єдине значення інтервалу таймування та простір порядкового номера. Перемежування безлічі типів трафіку зажадало б різних інтервалів синхронізації, якщо тактові частоти різних потоків різняться, і різних просторів порядкових номерів для індикації типу трафіку, якого відноситься втрата пакета.
Повідомлення відправника та одержувача протоколу RTCP (див. розділ 4.3) описують лише одне значення інтервалу таймування та простір порядкових номерів для SSRC та не передають полі типу трафіку.
Мікшер RTP не здатний поєднувати перемежовані потоки різних типів трафіку в один потік.
Передачі безлічі типів трафіку в одному сеансі RTP перешкоджають наступним факторам: використання різних мережних шляхів або розподіл мережних ресурсів; прийом підмножини мультимедійних даних, коли це потрібно, наприклад, лише звуку, якщо відеосигнал перевищив доступну смугу пропускання; реалізації приймача, які використовують окремі процеси для різних типів трафіку, тоді як використання окремих сеансів RTP допускає реалізації як з одним, так і з безліччю процесів.

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

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

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

Додаткова інформація, потрібна для конкретного формату трафіку (наприклад, тип кодування відеосигналу), повинна передаватися в поле даних пакета. Вона може розміщуватись на певному місці на початку або всередині масиву даних.

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

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

Synchronization Source (SSRC) Identifier

Contributing Source (CSRC) Identifiers

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

Якщо біт X в заголовку RTP встановлений в одиницю, то до фіксованого заголовка RTP (слід за списком CSRC, якщо він є) приєднується розширення заголовка зі змінною довжиною. Зауважимо, що це розширення заголовка призначене лише обмеженого використання. Розширення заголовка пакета RTP має такий формат:

Розширення містить 16-розрядне поле довжини, яке показує кількість 32-розрядних слів у ньому, виключаючи чотирихоктетний заголовок розширення (отже, довжина може мати нульове значення). Тільки одне розширення може бути додане до фіксованого заголовка інформаційного пакета RTP. Щоб дозволити кожному з безлічі взаємодіючих реалізацій експериментувати незалежно з різними розширеннями заголовка або дозволяти конкретної реалізації експериментувати з більш ніж одним типом розширення заголовка, використання перших 16 бітів розширення не визначено, залишено для розрізняючих ідентифікаторів або параметрів. Формат із цих 16 біт повинен бути визначений специфікацією профілю, з яким працюють додатки.