Real Time Streaming Protocol, Блог про шифрування

Протокол (RTSP) дає можливість клієнту вимагати живі або попередньо записані потоки з мультимедійних серверів, подібно до того, як HTTP дозволяє клієнтам видавати запити до Web-cepверів. Фактично RTSP перейняв більшу частину свого синтаксису та семантики від НТТР/1.1, оскільки формалию обидва протоколи виконують схожі функції. Подібність підкреслює загальний характер багатьох реалізованих у HTTP концепцій. Однак протоколи мають низку ключових відмінностей, які пов'язані з унікальними вимогами для мультимедійних потоків та обмеженістю можливостей НТТР/1.1 щодо передачі мультимедійних даних. У цьому розділі ми здійснимо порівняння та протиставлення RTSP та HTTP. Потім ми опишемо методи запитів RTSP, коди відповідей та заголовки в порівнянні та протиставленні з НТТР/1.1. В основу обговорення покладено матеріал глави 7 (розділ 7.2), що описує синтаксис НТТР/1.1.

Подібності та відмінності

Будь-який з протоколів, що розглядаються, в принципі може обслужити все завдання з вилучення опису мультимедійного сеансу і запиту мультимедійних даних. Хоча HTTP, можливо, не найкращий протокол для виконання всіх цих дій, оп може застосовуватися для передачі опису сеансу. У відповідь на клацання користувача мишею на гіпертекстовому посиланні браузер може видати HTTP-запит на інформацію з описом сеансу (наприклад, http://www.foo.com/bar.sdp). Відповідь Web-сервера буде включати інформацію, що описує сеапс, у форматі SDP, як показано нижче:

НТТР/1.1 200 OK Content-Type: application/sdp

o=- 2890844526 2890842807 IN IP4 192.16.24.202 s=RTSP Session

m=audio 0 RTP/AVP 0

m=video 0 RTP/AVP 31

У цей момент Web-брайзер вже може активізувати медіаплеєр для виконання інших дій, як булоописано у розділі 12.3.3. Крім того, медіаплеєр може надати користувачеві інтерфейс вибору мультимедійних сеансів. У цьому випадку медіаплеєр може безпосередньо взаємодіяти з RTSP-сервером для отримання описів сеапсів без залучення Web-брайзера.

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

Окремі з'єднання для даних та команд. На противагу HTTP, RTSP-сервер створює передачі даних окреме з'єднання. У цьому значенні RTSP близький до FTP. Клієнт та сервер обмінюються RTSP-повідомленнями через керуюче з'єднання. Завдання передачі даних виконують інші протоколи, такі як RTP і RTCP. Такий поділ дозволяє клієнту та серверу продовжувати обмінюватися RTSP-повідомленнями під час передачі даних, щоб адаптуватися до поточної обстановки або ініціювати додаткові передачі. Крім цього, передача команд та передача даних можуть використовувати різні транспортні протоколи. RTSP-повідомлення Зазвичай передаються через TCP-co-едіпепіє, хоча може бути використаний і UDP. Обмін пакетами RTP і RTCP Зазвичай здійснюється rio UDP, хоча можливе застосування TCP.

Різні формати URI. Для RTSP було зарезервовано норг 554. Вибір протоколу (UDP або TCP) може бути заданий у схемі URI. Схеми rtsp і rtspu відносяться до TCP та UDP відповідно. Наприклад, rtsp://foo.com/bar ідентифікує сеапс, який запитується та керується rio RTSP за допомогою ТСР-з'єднання. З іншого боку, rtspu://foo.com/bar вказує, що клієнт має видати RTSP-запит за допомогою UDP. Запитуваний URI RTSP може ставитися як до всього сеансу, так і до окремих мультимедійних потоків. Рядок запиту у RTSP-запиті повинен містити абсолютний шлях, включаючи ім'я хосга. Цедозволяє уникнути невизначеності щодо того, який RTSP-сервер повинен отримувати запит. На противагу цьому, НТТР/1.1 для цієї мети має окремий заголовок Host, покликаний зберегти зворотну сумісність з НТТР/1.0, як обговорювалося раніше в розділі 7 (розділ 7.8).

Різні методи, заголовки та коди стану. У RTSP є інший набір методів запитів, ніж у HTTP, зокрема методів, використовуваних сервером передачі повідомлення-запиту клієнту. RTSP нереняв багато кодів відповідей, хоча для вказівки помилкових ситуацій були визначені додаткові коди, відсутні в HTTP. У RTSP було запозичено багато заголовків HTTP з низкою важливих додавань і вилучень. Здебільшого неприйняття низки заголовків відбиває те що, що RTSP не передає реальних мультимедійних даних. Більшість RTSP-повідомлень містять лише інформацію, що описує сеанс. Нові заголовки, визначені в RTSP, пов'язані головним чином з (1) параметрами таймування мультимедійного потоку, (2) наявністю окремих протоколів передачі даних і (3) зберіганням інформації про стан на клієнті або на сервері. Ці моменти зумовлені ключовими відмінностями між RTSP і HTTP, які випливають з унікальних вимог, що висуваються до мультимедійних даних.

Методи запитів RTSP

RTSP-сервери повинні підтримувати чотири основні методи, що використовуються клієнтами для отримання мультимедійних сеансів: OPTIONS, SETUP, PLAY і TEARDOWN. На верхньому рівні заголовок OPTIONS дозволяє клієнту визначати функціональні можливості сервера, такі як номер версії RTSP та методи, що підтримуються; цей метод веде себе як і метод OPTIONS НТТР/1.1. Інші три методи маніпулюють збереженою на сервері інформацією про стан для координації передачімультимедійні дані. Клієнт використовує метод SETUP для встановлення транспортного з'єднання кожного потоку в сеансі. Метод PLAY використовується для ініціювання передачі потоків (потоків). Метод TEARDOWN використовується для завершення передачі. Ці чотири методи описані в таблиці 12.2 разом з іншими методами RTSP.

Таблиця 12.2. Методи запитів RTSP

На противагу HTTP RTSP зберігає інформацію про стан у відповідь клієнтські запити. Окрім запитів SETUP, PLAY та TEARDOWN, методи RECORD та PAUSE також впливають на інформацію про сеанс. Метод RECORD наказує RTSP-серверу прийняти та зберегти ноток із зазначеним URI для подальшого відтворення. Метод PAUSE тимчасово припиняє передачу без звільнення системних ресурсів сервера. Наступний запит PLAY (або RECORD) пропонує серверу продовжити передачу (або запис) потоку. І клієнт, і сервер зберігають інформацію про стан на користь кожного потоку. Методи PLAY, RECORD, PAUSE і TEARDOWN можуть бути застосовані до окремого потоку або до всього сеаїсу, залежно від того, чи відповідає URI в RTSP-запиті потоку або сеаїсу. Метод запиту, застосовуваний до сеансу, впливає кожен із складових сеанс потоків. Метод SETUP застосовується лише до окремого потоку.

Механізм керування станом для клієнта та сервера представлений на рис. 12.1. Сервер змінює стан під час обробки методу запиту; клієнт змінює стан після отримання відповіді сервера. Метод SETUP запускає передачу з початкового стану (Ініціалізація) та викликає невхід до стану Готовність. Метод TEARDOWN повертає клієнта та сервер у стан Ініціалізація. Методи PLAY та RECORD переводять у стани Відтворення та Запис, відповідно, а метод PAUSE повертає у станГотовність. Передача даних здійснюється лише у станах Відтворення та Запис. Перебуваючи в одному з цих двох станів, клієнт може ініціювати запит SETUP для зміни транспортних параметрів потоку. Сервер продовжує передачу потоків мультимедійних даних, використовуючи, можливо, інший транспортний протокол або інші порти.

Мал. 12.1. Діаграма станів для клієнтів та серверів RTSP

Щоб надати запит, сервер повинен знати, які методи підтримуються конкретним клієнтом. Для цього сервер може надіслати клієнту запит OPTIONS. Крім методів OPTIONS і ANNOUNCE у RTSP є два інших методи, які можуть використовуватися як клієнтами, і серверами. Методи GET_PARA-METER та SET_PARAMETER дають можливість відправнику дізнатися та скоригувати параметри мультимедійного сеансу або потоку, асоційованого з конкретним URI запиту. Ці два методи забезпечують підтримку операцій читання та запису довільного набору параметрів для конкрегпого клієнта та сервера. Наприклад, сервер може використовувати метод GET_PARAMETER для запиту кількості пакетів даних, отриманих клієнтом певного потоку. Тим самим забезпечується альтернатива протоколу RTCP для отримання інформації про якість транспортування даних. Клієнт має можливість надіслати запит SET_PARAMETER з метою зменшення сервером швидкості передачі. Ці методи забезпечують клієнту та серверу гнучку і розширювану можливість організації взаємодії в управлінні мультимедійним потоком.

Джерело: Web-протоколи. Теорія та практика. - M.: ЗАТ «Видавництво БІНОМ», 2002 р. - 592 c.: Іл.