Протокол за поточно предаване в реално време

Протоколът RTSP позволява на клиента да иска живи или предварително записани потоци от медийни сървъри, подобно на HTTP позволява на клиентите да издават заявки към уеб сървъри. Всъщност RTSP пое голяма част от синтаксиса и семантиката си от HTTP/1.1, тъй като и двата протокола формално изпълняват подобни функции. Приликите подчертават общия характер на много от концепциите, внедрени в HTTP. Протоколите обаче имат редица ключови разлики, които са свързани с уникалните изисквания за мултимедийни потоци и ограничените възможности на HTTP/1.1 за прехвърляне на мултимедийни данни. В този раздел ще сравним и сравним RTSP и HTTP. След това описваме методите за заявка RTSP, кодовете за отговор и заглавията в сравнение и контраст с HTTP/1.1. Дискусията се основава на материала в глава 7 (раздел 7.2), който описва синтаксиса на HTTP/1.1.

Прилики и разлики

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

НТТР/1.1 200 OK Тип съдържание: application/sdp

o = - 2890844526 2890842807 IN IP4 192.16.24.202 s = RTSP сесия

m = аудио 0 RTP/AVP 0

m = видео 0 RTP/AVP 31

На този етап уеб браузърът вече може да активира медийния плейър за извършване на други действия, както е описано в раздел 12.3.3. В допълнение, медийният плейър може да предостави на потребителя интерфейс за избор на мултимедийни сесии. В този случай медийният плейър може директно да взаимодейства със сървъра RTSP, за да извлече описания на сесии, без да включва уеб браузър.

Въпреки многото прилики между двата протокола, RTSP се различава от HTTP 110 по редица ключови начини.

Отделни връзки за данни и команди. За разлика от HTTP, RTSP сървърът създава отделна връзка за прехвърляне на данни. В този смисъл RTSP е близък до FTP. Клиентът и сървърът обменят RTSP съобщения по контролната връзка. Други протоколи като RTP и RTCP изпълняват задачата за прехвърляне на данни. Това разделяне позволява на клиента и сървъра да продължат да обменят RTSP съобщения по време на трансфери на данни, за да се адаптират към текущата среда или да инициират допълнителни трансфери. Освен това предаването на команди и предаването на данни могат да използват различни транспортни протоколи. RTSP съобщения Обикновено се изпращат през TCP, въпреки че може да се използва и UDP. Обмен на пакети RTP и RTCP Обикновено rio UDP, въпреки че е възможен и TCP.

Различни URI формати. За RTSP е запазен Norg 554. Изборът на протокол (UDP или TCP) може да бъде определен в схемата на URI. Схемите rtsp и rtspu се отнасят съответно за TCP и UDP. Например rtsp: //foo.com/bar идентифицира сесията, която се изисква и контролира от rio RTSP през TCP връзка. От друга страна, rtspu: //foo.com/bar показва, че клиентът трябва да издава RTSP заявка през UDP. Исканият URI в RTSP може да се отнася както до цялата сесия, така и до отделни медийни потоци. Низът на заявката в заявката RTSP трябва да съдържа абсолютния път, включително името на хоста. Това избягва неяснотата кой RTSP сървър трябва да получи заявката. За разлика от това, HTTP/1.1 има отделна заглавка на хоста за тази цел, за да поддържа обратна съвместимост с HTTP/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 и поддържаните методи; този метод се държи по същия начин като метода HTTP/1.1 OPTIONS. Останалите три метода манипулират информацията за състоянието, съхранявана на сървъра, за да координират предаването на мултимедийни данни. Клиентът използва метода 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 ги поставят съответно в състоянията Play и Record, а методът PAUSE връща състоянието Ready. Прехвърлянето на данни се извършва само в състоянията Play and Record. Докато е в едно от тези две състояния, клиентът може да инициира SETUP заявка за промяна на транспортните параметри на потока. Сървърът продължава да предава потоци от мултимедийни данни, вероятно използвайки различен транспортен протокол или различни портове.

Фигура: 12.1. Диаграма на състоянието за RTSP клиенти и сървъри

За да издаде заявка, сървърът трябва да знае кои методи се поддържат от определен клиент. За да направи това, сървърът може да изпрати заявка OPTIONS до клиента. В допълнение към методите OPTIONS и ANNOUNCE, RTSP има два други метода, които могат да се използват както от клиенти, така и от сървъри. Методите GET_PARA-METER и SET_PARAMETER позволяват на подателя да открие и коригира параметрите на мултимедийна сесия или поток, свързани с URI на конкретна заявка. Тези два метода осигуряват поддръжка за операции за четене и запис върху произволен набор от параметри за конкретен клиент и сървър. Например сървърът може да използва метода GET_PARAMETER, за да поиска броя на пакетите данни, получени от клиента за определен поток. Това осигурява алтернатива на RTCP за получаване на информация за качеството на пренос на данни. Клиентът има опцията да изпрати заявка SET_PARAMETER, за да намали скоростта на предаване на сървъра. Тези методи осигуряват на клиента и сървъра гъвкаво и разширяемо взаимодействие при управлението на медийния поток.

Източник: Уеб протоколи. Теория и практика. - М.: АД "Издателство БИНОМ", 2002 - 592 с.: Ил.