Rtsp

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

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

Передача самих потокових даних не є завданням протоколу RTSP. Більшість серверів RTSP використовують Real-Time Transport Protocol (RTP) у поєднанні з  Real-time Control Protocol (RTCP) для доставки медіа потоку, проте деякі виробники реалізують власні транспортні протоколи. Серверне програмне забезпечення RTSP від RealNetworks, наприклад, використовує фірмовий протокол RealNetworks Real Data Transport (RDT).

RTSP розроблявся компаніями RealNetworks, Netscape і Колумбійським університетом, з першого проекту, представленого IETF в 1996 році. Він був стандартизований Multiparty Multimedia Session Control Working Group (MMUSIC WG) яка є частиною Internet Engineering Task Force (IETF) і опублікований в RFC 2326 у 1998 році.

RTSP 2.0 знаходиться в стадії розробки як заміна RTSP 1.0. RTSP 2.0 базується на RTSP 1.0, але не має зворотної сумісності з ним в своїй основній версії.

RTSP з використанням RTP і RTCP дозволяє здійснення адаптації швидкості передавання.

При всій своїй подібності до HTTP, RTSP визначає корисні керуючі послідовності в управлінні відтворенням мультимедіа.

Використовується ідентифікатор при необхідності відстежувати одночасні сесії. Як HTTP, RTSP використовує TCP для підтримки з'єднання між кінцевими точками, і в той час як більшість керуючих повідомлень RTSP відправляються клієнтом на сервер, деякі команди відправляються в іншому напрямку (тобто від сервера до клієнта). Деякі типові запити HTTP, як наприклад OPTIONS, також доступні.

За замовчуванням, номер порту транспортного рівня для RTSP —  554.

Список команд (методів)

• OPTIONS — запит підтримуваних методів
• DESCRIBE — запит опису контенту, наприклад, у форматі SDP
• PLAY — запит початку мовлення контента
• PAUSE — запит тимчасової зупинки мовлення
• RECORD — запит на записування контента сервером
• REDIRECT — перенаправлення на інший контент
• SETUP — запит установки транспортного механізму для медіа-контента
• ANNOUNCE — оновлення даних опису контента
• GET_PARAMETER — запит вказаних параметрів в сервера
• SET_PARAMETER — установка параметрів сервера
• TEARDOWN — зупинка потоку і звільнення ресурсів

OPTIONS

Запит OPTIONS повертає типи запитів які сервер може приймати.

 C->S:  OPTIONS rtsp://example.com/media.mp4 RTSP/1.0         CSeq: 1         Require: implicit-play         Proxy-Require: gzipped-messages   S->C:  RTSP/1.0 200 OK         CSeq: 1         Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE 

DESCRIBE

Запит DESCRIBE включає RTSP URL (RTSP:/ / …), і тип відповіді даних, які можуть бути оброблені. Порт за замовчуванням для протоколу RTSP — 554, є однаковим для UDP(використовується в додатках які потребують мінімальних затримок передавання, де якість передавання не є найважливішим критерієм) і TCP протоколів. Відповідь цього запиту включає опис представлення даних, як правило, в форматі Session Description Protocol(SDP). Серед іншого, опис представлення списків медіа потоків контрольованих із URL. У типовому випадку, є один мультимедійний потік для аудіо і відео.

C->S: DESCRIBE rtsp://example.com/media.mp4 RTSP/1.0        CSeq: 2  S->C: RTSP/1.0 200 OK        CSeq: 2        Content-Base: rtsp://example.com/media.mp4        Content-Type: application/sdp        Content-Length: 460         m=video 0 RTP/AVP 96        a=control:streamid=0        a=range:npt=0-7.741000        a=length:npt=7.741000        a=rtpmap:96 MP4V-ES/5544        a=mimetype:string;"video/MP4V-ES"        a=AvgBitRate:integer;304018        a=StreamName:string;"hinted video track"        m=audio 0 RTP/AVP 97        a=control:streamid=1        a=range:npt=0-7.712000        a=length:npt=7.712000        a=rtpmap:97 mpeg4-generic/32000/2        a=mimetype:string;"audio/mpeg4-generic"        a=AvgBitRate:integer;65790        a=StreamName:string;"hinted audio track" 

SETUP

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

C->S: SETUP rtsp://example.com/media.mp4/streamid=0 RTSP/1.0        CSeq: 3        Transport: RTP/AVP;unicast;client_port=8000-8001  S->C: RTSP/1.0 200 OK        CSeq: 3        Transport: RTP/AVP;unicast;client_port=8000-8001;server_port=9000-9001        Session: 12345678 

PLAY

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

C->S: PLAY rtsp://example.com/media.mp4 RTSP/1.0        CSeq: 4        Range: npt=5-20        Session: 12345678  S->C: RTSP/1.0 200 OK        CSeq: 4        Session: 12345678        RTP-Info: url=rtsp://example.com/media.mp4/streamid=0;seq=9810092;rtptime=3450012 

PAUSE

Запит PAUSE тимчасово зупиняє один або всі медіа потоки, так що надалі вони можуть бути відновлені запитом PLAY. Запит містить агрегатну URL або  URL медіа-потоку. Параметр діапазон за запитом паузу вказує, коли слід призупинити. Коли параметр відрізок не вказаний, то пауза відбувається відразу і на невизначений термін.

 C->S: PAUSE rtsp://example.com/media.mp4 RTSP/1.0        CSeq: 5        Session: 12345678   S->C: RTSP/1.0 200 OK        CSeq: 5        Session: 12345678 

RECORD

Цей метод ініціює запис медіа-даних відповідно до опису. Мітка часу позначає час початку і час закінчення (UTC). Також, можна використовувати лише час початку або закінчення. Якщо сеанс вже почався, почати запис негайно. Сервер вирішує, де слід зберігати записані дані: на URI з якого прийшов запит, чи іншому URI. Якщо запис відбудеться з використанням URL відмінного від URL з якого надійшов запит, то відповідь сервера має бути 201 і містити об'єкт, який описує стану запиту і посилається на новий ресурс, у який буде виконуватися збереження.

 C->S: RECORD rtsp://example.com/media.mp4 RTSP/1.0        CSeq: 6        Session: 12345678   S->C: RTSP/1.0 200 OK        CSeq: 6        Session: 12345678 

ANNOUNCE

Метод ANNOUNCE служить двом цілям: При відправці від клієнта до сервера, ANNOUNCE повідомляє опис представлення або медіа-об'єкт, визначений в URL запиту до сервера.

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

 C->S: ANNOUNCE rtsp://example.com/media.mp4 RTSP/1.0        CSeq: 7        Date: 23 Jan 1997 15:35:06 GMT        Session: 12345678        Content-Type: application/sdp        Content-Length: 332         v=0        o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4        s=SDP Seminar        i=A Seminar on the session description protocol        u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps        c=IN IP4 224.2.17.12/127        t=2873397496 2873404696        a=recvonly        m=audio 3456 RTP/AVP 0        m=video 2232 RTP/AVP 31   S->C: RTSP/1.0 200 OK        CSeq: 7 

TEARDOWN

Запит TEARDOWN використовується для завершення сеансу. Він зупиняє всі медіа потоки і видаляє із сервера всі дані пов'язані із сесією.

 C->S: TEARDOWN rtsp://example.com/media.mp4 RTSP/1.0        CSeq: 8        Session: 12345678   S->C: RTSP/1.0 200 OK        CSeq: 8 

GET_PARAMETER

Запит GET_PARAMETER витягує значення параметра представлення або потоку, заданого в URI. Зміст відповіді залежить від реалізації. GET_PARAMETER без тіла може бути використаний для тестування живучості клієнта або сервера («пінг»).

 S->C: GET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0        CSeq: 9        Content-Type: text/parameters        Session: 12345678        Content-Length: 15        packets_received        jitter   C->S: RTSP/1.0 200 OK        CSeq: 9        Content-Length: 46        Content-Type: text/parameters        packets_received: 10        jitter: 0.3838 

SET_PARAMETER

Цей метод встановлює значення параметра для представлення або потоку який задається URI.

 C->S: SET_PARAMETER rtsp://example.com/media.mp4 RTSP/1.0        CSeq: 10        Content-length: 20        Content-type: text/parameters        barparam: barstuff   S->C: RTSP/1.0 451 Invalid Parameter        CSeq: 10        Content-length: 10        Content-type: text/parameters        barparam 

REDIRECT

Запит REDIRECT повідомляє клієнту, що він повинен підключитися до іншого сервера. Він містить обов'язкове поле header Location, яке вказує, що клієнт повинен посилати запити для цього URL. Він може містити діапазон значень, які вказують, на те коли перенаправлення має відбутися. Якщо клієнт хоче продовжувати відправляти і отримувати медіа з поточного URI, клієнт повинен видати запит TEARDOWN для поточного сеансу і SETUP для нової сесії.

 S->C: REDIRECT rtsp://example.com/media.mp4 RTSP/1.0        CSeq: 11        Location: rtsp://bigserver.com:8001        Range: clock=19960213T143205Z-
 

Сервери

• Darwin Streaming Server: open source версія  QuickTime Streaming Server яка підтримується Apple
• Erlyvideo: має клієнт RTSP і може передавати відео в інші протоколи.
• Feng: потоковий сервер з акцентом на дотриманні стандарту RFC.
• FFmpeg: включає ffserver в GPL або LGPL потокові сервери RTSP.
• GStreamer:основний RTSP сервер і клієнт.
• Helix DNA Server: потоковий сервер від RealNetworks. Поставляється в вигляді відкритого коду
• Helix Universal Server:  комерційний потоковий сервер від RealNetworks для RTSP, RTMP, МО, Silverlight і HTTP потокових мультимедіа клієнтів.
• LIVE555: Реалізована на C++ бібліотека з відкритим кодом, включає сервер і клієнт які використовуються у добре відомих додатках VLC і mplayer.
• pvServer: Повна назва: PacketVideo Streaming Server, це потоковий сервер, продукт Alcatel-Lucent.
• QuickTime Streaming Server:  потоковий сервер Apple, який поставляється разом з Mac OS X Server.
• ViaMotion: Інтегрований RTSP сервер для відео на вимогу, розроблений Anevia
• VideoLAN: медіа-плеєр і потоковий сервер з відкритим вихідним кодом.
• VX30: Сервер потокового відео і вбудований JAVA клієнт від  Мауа X-Stream
• Windows Media Services: потоковий сервер Microsoft, раніше включався в Windows Server . Він використовує модифікований RTSP і розширення Windows Media
• Wowza Media Server: Мультиформатний потоковий сервер для RTSP / RTP, RTMP, MPEG-TS, ICY, HTTP (HTTP Live Streaming, HTTP Dynamic Streaming, SmoothStreaming)
• Xenon Streaming Server: Мобільний потоковий сервер від Vidiator Technology (US) Inc.
• YouTube : Доступна опція потокового відтворення при перегляді сайту через мобільну версію HTTPS на комп'ютері.

Клієнти

• cURL
• FFmpeg
• GStreamer
• Media Player Classic
• MPlayer
• MythTV через Freebox
• QuickTime
• RealPlayer
• Skype
• Spotify
• VLC media player
• Winamp
• Windows Media Player
• xine
• JetAudio

• RFC2326 — RTSP

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

Це незавершена стаття про Інтернет. Ви можете допомогти проєкту, виправивши або дописавши її.