Протоколи за поточно предаване на медии, блог за криптиране
• Трансфер на данни. Поточното предаване на медии изисква доставка на данни със същите времеви характеристики до един или повече получатели. Поточният транспорт се обслужва от два тясно свързани протокола. Протоколът за транспортиране в реално време (RTP) разделя потока на пакети, всеки от които съдържа клеймо за време, пореден номер и информация за изпращача [SCFJ96]. RTP спецификацията дефинира и RTP Control Protocol (RTCP), който осигурява обратна връзка за качеството на предаването и самоличността на участниците в потока.
• Описание на сесията. Участниците в сесията трябва да получат метаданни като параметрите за предаване и кодиране на компонентните потоци, продължителността, името и целта на сесията. Тази информация се предава с помощта на протокола за описание на сесията (SDP) [HJ98J.
• Описание на изгледа. Създаването на мултимедийни документи изисква ефективен начин за организиране на възпроизвеждане на сесии във времето. Като алтернатива на HTML, езикът за синхронизирана мултимедийна интеграция (SMIL) предоставя възможността да се контролира кога, къде и как се възпроизвеждат мултимедийни сепове [Syn98, Hos00, SmiJ.
Поръчване. На RTP липсва механизъм за надеждна доставка и контрол на информационния поток. Доставката на RTP пакети зависи от транспортния протокол. RTP не предполага, че транспортният протокол осигурява подреден, надежден поток от байтове, тъй като повторното предаване на загубени пакети е нежелателно за много медийни потоци. В действителност RTP обикновено работи върху UDP и всеки RTP пакет се изпраща в един UDP пакет. Алтернатива е да използвате TCP за осигуряване на регистъртранспортиране или поточно предаване през защитна стена, която отхвърля UDP пакети. IP пакетите обаче могат да бъдат загубени или да пристигнат неправилно, а UDP не извършва никакво препредаване или пренареждане на пакети. RTP хедърът съдържа измервател на последователност, който позволява на приемника да обработва входящите пакети в правилния ред и да открива загуба на пакети. Получателят може да поддържа статистика за загуба на пакети, за да предостави обратна връзка на подателя. Тази статистика може да принуди подателя да коригира скоростта на данни.
Идентификация на източника. В допълнение към информацията за времето и последователността, RTP хедърът идентифицира източника(ите), отговорен(и) за данните в пакета. Това е особено полезно за приложения, които могат да имат множество източници на данни (например дискусионни групи). Всеки източник се идентифицира с 32-битово число. Всеки RTP пакет има източник на часовник, отговорен за времевия печат и поредния номер на данните. В някои ситуации източникът на часовник генерира данни от един или повече допълнителни източници. Помислете за приложение за организиране на телеконференция с множество участници. Всеки участник генерира аудио поток и изпраща RTP пакети към междинна система - миксер. Миксерът комбинира пакети от участници и генерира един аудио поток. Миксерът е източникът на часовник за изходния поток. Първоначалните сътрудници са допринасящите източници. Когато комбинира отделни аудио потоци, миксерът генерира списък с участващи източници, за да синхронизира бележките на компонента. Чрез включването на идентификаторите на участващите податели в RTP хедъра, миксерът информира получателите за всички спирки, отговорни за комбинирания поток.
Формат на презентация.Интерпретацията на RTP данните от страна на получателя зависи от избрания формат на кодиране. RTP хедърът съдържа 7-битово поле за тип полезен товар, идентифициращо формата на медийните данни. Типът полезен товар е свързан с името и описанието на кодирането, включително честотата на времевия печат. Форматът на полезен товар дефинира синтаксиса и семантиката на RTP данните, включително заглавки, специфични за съдържанието. Първият набор от типове полезен товар е дефиниран в RFC 1890 [Sch96J. Нови типове кодиране са регистрирани от Internet Assigned Numbers Authority (IANA). Подробните описания на типовете полезен товар, съдържащи се в съответните документи като RFC, позволяват на разработчиците да поддържат схеми за кодиране. Типовете полезен товар също са дефинирани за общи потребителски мултимедийни услуги, включително RTP миксери и толерантно към загуба на пакети излишно аудио кодиране. За постигане на гъвкавост и разширяемост, RTP също поддържа използването на типове динамичен полезен товар, които не са регистрирани в IANA.
Въпреки че RTP предоставя по-голямата част от информацията, необходима за прехвърляне на медийни данни от подател към един или повече получатели, понякога се изисква допълнителна контролна информация. Дефиниран в същия RFC като RTP [SCFJ96], RTCP изпълнява следните три функции:
• Обратна връзка. RTCP осигурява обратна връзка за качеството на приемане, като статистика за загубите на RTP пакети от приемника. Това помага на RTP-or-ruler да идентифицира проблеми с производителността и съответно да адаптира скоростта на данни.
• Идентификация. RTCP асоциира всеки идентификатор на източник от RTP пакети с уникално канонично име. Товапозволява на получателя да асоциира набор от потоци, вероятно имащи различни 32-битови идентификатори на източник, с един подател.
Подателите и получателите трябва да имат начин да изразят интереса си към участие в конкретна мултимедийна сесия. Подробностите за установяване на връзка между двама или повече партньори варират в зависимост от типа приложение, както беше обсъдено по-рано в раздел 12.1.3. Това е въплътено в няколко различни протокола:
• Протокол за започване на сесия (SIP). SIP [SSR99, SR99J] поддържа приложения като IP телефония, при които получаващата страна получава лична покана за участие в сесия. Страната, която инициира seap, може да използва SIP, за да намери един или повече потребители и да ги покани да участват в сесията. SIP изпълнява пет основни функции: (1) решава с кой компютър да се свърже, (2) определя кои параметри да използва, (3) определя дали потребителят иска да приеме повикването, (4) установява връзка с потребителя, (5) управлява прехвърлянето и прекратява повикването.
Описанието на SDP се състои от един или повече редове ASCII текст. Всеки низ включва тип от един знак и стойност като текстов низ, разделени със знак за равенство. Форматът на стойностния низ зависи от типа. Описанието съдържа един или повече редове информация на ниво сесия, която може да бъде последвана от допълнителна информация за отделните нишки в сесията. Информацията за сесийния слой се отнася за цялата сесия и за всеки от медийните потоци. Информацията за нивото на сесията включва името и целта на сесията като текстови низове, като напр
i=Какво всеки трябва да знае за World Wide Web
Мултимедийна подготовкасъдържанието се усложнява от факта, че клиентите могат да варират значително по отношение на честотна лента, размер на екрана, възможности на плейъра и потребителски предпочитания. Например един потребител може да има 21-инчов монитор с висока разделителна способност и високопроизводителна интернет връзка. Друг потребител може да има Pocket PC с безжична връзка. Потребител с увреден слух може да предпочете да получава текстов съпровод вместо аудио поток. SMIL може да дефинира различни параметри на представяне, съответстващи на различни медийни потоци. Медийният плейър определя кои потоци да извлече и как да се показват. Това е удобна алтернатива на клиента, който се обажда на сървъра, за да определи подходящите параметри за потоците. SMIL може също така да посочи различни опции за представяне за определена област, които показват как потребителят може да взаимодейства с презентацията. Например даден регион може да поддържа увеличаване и намаляване на изображение.
Източник: Уеб протоколи. Теория и практика. - М .: ЗАО "Издателство БИНОМ", 2002 - 592 с.: ил.