Уголок связиста Четверг, 04 Июн 2020, 20:44
Приветствую Вас гость | RSS
Новые сообщения
  • Вопрос по для С... (0)
    13 Окт 2015 [borisenko2077]
  • Группы пользова... (4)
    10 Янв 2014 [Кикманэ]
  • GPRS (1)
    17 Июл 2013 [Кикманэ]
  • Для вновь прише... (5)
    05 Окт 2012 [Alex]
  • снятие "ул... (0)
    21 Май 2012 [stepakov]
  • Список дополнен... (0)
    20 Май 2012 [Alex]
  • Игра - "Я ... (19)
    01 Дек 2009 [vicksol]
  • Игра "АССО... (199)
    01 Ноя 2009 [vicksol]
  • Мобильник все-т... (4)
    28 Май 2009 [Alex]
  • Nod32 (2)
    28 Май 2009 [Alex]

  • Меню сайта

    Топ-пользоватлей
    1. Alex (388 - 53 - 70)
    2. natapin (62 - 0 - 0)
    3. vicksol (50 - 0 - 0)
    4. misterX (24 - 0 - 0)
    5. Olga (21 - 0 - 0)
    6. Lizard (18 - 0 - 0)
    7. genaha (11 - 0 - 0)
    8. Кикманэ (3 - 0 - 0)
    9. 345678 (2 - 0 - 0)
    10. megaeregi (1 - 0 - 0)

    Сегодня:

    Друзья сайта

    Форма входа

    Статистика

    [ Новые сообщения · Участники · Правила форума · Поиск · RSS ]


    • Страница 1 из 1
    • 1
    Наш форум » Уголок связиста » Статьи » Протокол SDP
    Протокол SDP
    AlexДата: Пятница, 12 Дек 2008, 14:04 | Сообщение # 1
    Главный админ
    Группа: Администраторы
    Город:
    Сообщений: 388
    Статус: отсутствует
    Описание сессии состоит из описания на уровне сессии (детали, относящиеся к сессии вцелом и ко всем медиа-потокам) и нескольких необязательных описаний на уровне медиа-носителя (детали, относящиеся к отдельному медиа-потоку).

    Блок уровня сессии начинается со строки “v=” и продолжается до первого блока уровня медиа. Описание медиа начинается со строки “m=” и продолжается до описания следующего медиа или до конца описания сессии.

    Когда SDP передается посредством SAP, допускается только одно описание сессии в пакете. Когда SDP передается другими средствами, несколько описаний может быть собрано (конкатенировано) вместе (строка “v=”, начинающая описание сессии, заканчивает предыдущее описание).

    Некоторые строки обязательно должны присутствовать в каждом описании сессии, другие – необязательно, но все строки должны появляться строго в порядке, указанном в данном документе (фиксированный порядок упрощает обнаружение ошибок и позволяет реализовать простой грамматический разбор). Необязательные пункты отмечены знаком *.

    Описание сессии

    1. версия протокола

    Поле «v=» содержит версию протокола SDP

    v=0 [Меньшего номера версии не существуетъ]

    2. владелец/создатель и идентификатор сессии

    Источник (Origin)

    o=<username> <session id> <version> <network type> <address type> <address>.

    <username> - login пользователя на исходящем хосте или символ «-», если исходящий хост не поддерживает концепцию идентификаторов пользователей. <username> не должен содержать пробелов

    <session id> - это числовая строка, такая, что кортеж значений: <username>, <session id>, <network type>, <address type> и <address>; формирует глобальный уникальный идентификатор для сессии. Метод назначения “session id” определяется средством создания сессии, но предполагается, что будет использоваться отсчет времени (timestamp) протокола Network Time Protocol (NTP), чтобы гарантировать уникальность [RFC 1305].

    <version> -<version> - номер версии данного объявления. Он необходим для прокси, чтобы определить, какое из нескольких объявлений последнее для данной сессии. Его использование также соответствует моменту создания до тех пор, пока <version> не будет повышена в связи с модификацией данных сессии. Рекомендуется (но не обязательно) использовать отсчеты времени (timetamp) протокола NTP.

    <network type> -<network type> - текстовая строка, содержащая тип сети. Изначально “IN” имеет значение Internet.

    <address type> -<address type> - текстовая строка, передающая тип адреса, который следует далее. Изначально определены значения <IP4> и <IP6>

    <address> - представляет собой глобальный уникальный адрес хоста, с которого была создана данная сессия. Для типа адреса IP4 это или полностью определенное доменное имя хоста или десятичное с точками представление адреса хоста.

    В общем случае, поле «o=» служит как глобальный идентификатор версии описания сессии, а подполя, исключая версию, взятые вместе, идентифицируют сессию независимо от любых модификаций.

    3. имя сессии

    s=(имя сессии).

    В описании сессии должно быть одно и только одно поле «s=», и оно должно содержать знаки ISO 10646 (также см. атрибут “charset”).

    4. информация о сессии

    i=*(информация о сессии)

    Поле “i=” – это информация о сессии. В каждом описании сессии может быть не больше одного поля “i=” на уровне сессии и не более одного поля “i=” в описании каждого медиа. Несмотря на то, что это поле может быть пропущено, это не одобряется для объявлений сессии, и пользовательские интерфейсы должны требовать, чтобы текст был введен. Если поле “i=” включено, то оно должно содержать знаки ISO 10646 (см. также описание атрибута “charset”).

    Одиночное поле “i=” может использоваться для определения каждого медиа. В описаниях медиа эти поля в первую очередь предназначены для маркировки медиа-потоков. Они наиболее подходят для использования, когда одиночная сессия имеет более одного различимого медиа потока одного и того же типа медиа. Например, должно быть две различные электронные доски объявлений (white board), одна – для слайдов, а другая – для передачи материалов (feedback) и вопросов.

    5. URI описания сессии

    u=*(URI описания сессии)

    URI – универсальный идентификатор ресурса, который используется клиентами www. URI должен быть указателем на дополнительную информацию о конференции. Данное поле не обязательно, но если оно присутствует, оно должно быть определено перед первым полем описания медиа.

    В каждом описании сессии должно быть не более одного поля URI.

    6. e-mail адрес

    e=*(e-mail адрес)

    7. телефонный номер

    p=*(телефонный номер)

    Должно быть определено или поле E-mail или поле телефонного номера. Допустимы дополнительные поля E-mail и номера. Если эти поля присутствуют, они должны быть определены перед первым полем медиа. В каждом описании сессии может присутствовать более одного поля e-mail или телефонного номера.

    Телефонные номера должны быть представлены в общепринятом международном формате – номеру должен предшествовать «+» и международный код страны.

    Оба поля могут содержать необязательную текстовую строку свободного формата, ассоциированную с адресом или телефонным номером; обычно она содержит имя лица, с которым можно связаться. Текст должен быть заключен в скобки. Например: E=mjh@isi.edu(Mark Handley)

    Свободная текстовая строка должна быть представлена в символах ISO10646 в кодировке UTF-8, или, альтернативно, в кодировке ISO 8859-1, или других кодировках, если установлен соответствующий атрибут “charset” уровня сессии.

    8. информация о соединении

    c=*(информация о соединении – не требуется, если включена во все медиа).

    c=<network type><address type><connection address>

    Поле «c=» содержит данные о соединении. Объявление сессии должно содержать одно поле «c=» в каждом описании медиа (см. ниже) или поле «c=» уровня сессии. Объявление может содержать поле «c=» уровня сессии и одно дополнительное поле «c=» в описании каждого медиа, в этом случае значение «c=» уровня медиа перекрывает установки уровня сессии для соответствующего медиа.

    <network type> > - тип сети – текстовая строка, содержащая тип сети. Изначально “IN” имеет значение “INTERNET”.

    <address type> Второе подполе <address type> - тип адреса, позволяет использовать SDP для не IP-сессий. В настоящее время определен только тип IP4.

    <connection address> Третье подполе <connection address> - адрес соединения. Необязательные дополнительные подполя могут добавляться после адреса соединения, зависящего от значения поля <address type>.

    Конференции, использующие IP-адрес многоадресной рассылки, в дополнение к адресу должны в своем описании содержать значение времени жизни time to life (TTL). TTL и адрес вместе определяют область, в которой должны передаваться многоадресные пакеты данной конференции. Значения TTL должны существовать в диапазоне 0-255.

    TTL для сессии добавляется к адресу после разделителя «/». Например: C=IN IP4 224.2.1.1/127

    Для приложений, требующих нескольких групп многоадресной рассылки, допускается использование следующих описаний адреса соединения:

    <base multicast address>/<ttl>/<number of address>

    Если количество адресов <number of address> не дано, то принимается, что должен быть один адрес. Назначенные таким образом адреса многоадресной рассылки последовательно размещены над основным адресом. Например: с=IN IP4 224.2.1/127/3

    Это семантически идентично включению нескольких строк «с=» в описание медиа:

    с=IN IP4 224.2.1/127

    с=IN IP4 224.2.2/127

    с=IN IP4 224.2.3/127

    Несколько адресов или строк «с=» могут быть определены только на основе медиа, а не для поля «с=» уровня сессии.

    Недопустимо использование разделителя «/» для IP-адресов одноадресной рассылки.

    9. информация о ширине полосы пропускания

    b=*(информация о ширине полосы пропускания).

    b=<modifier>:<bandwidth-value>

    Этот атрибут определяет желаемую ширину полосы пропускания, которая должна использоваться сессией и медиа и является не обязательным.

    <modifier> -Изначально определены два модификатора:

    CT (Conference Total): это подразумеваемая максимальная ширина полосы пропускания, ассоциированная с каждым TTL в Mbonе или с конкретным регионом административного управления (полоса пропускания Mbone дается в Mbone FAQ вместо пределов TTL). Если ширина полосы пропускания сессии или медиа в сессии отличается от подразумеваемой ширины полосы пропускания данной области действия, то для сессии должна быть запись “b=CT:…”, задающая предполагаемый верхний предел используемой ширины полосы пропускания. Основная цель этого – дать приблизительное знание, о том могут ли две или более конференции существовать одновременно.

    AS (Application Specific Maximum): максимум, характерный для приложения. Ширина полосы пропускания, интерпретируется как характерная для приложения, т.е. представляет собой потребность приложения в отношении максимальной ширины полосы пропускания. Обычно это значение будет совпадать с тем, которое установлено в данных управления максимальной шириной полосы пропускания приложения, если таковые используется.

    Отметим, что СТ определяет общее значение ширины полосы пропускания для всех медиа на всех участках (sites). AS определяет значение ширины полосы пропускания для одного медиа одного участка, хотя может быть много участков, передающих одновременно.

    Синтаксический анализатор SDP должен игнорировать поля полосы пропускания с неизвестными модификаторами.

    Описание времени (Одно или больше)

    10. время, в которое сессия активна

    t=(время, в которое сессия активна)

    t=<start time> <stop time>

    Поля «t=» определяют время начала и конца сессии. Может использоваться несколько полей «t=», если сессия активна на нескольких нерегулярных интервалах времени; каждое дополнительное поле «t=» определяет дополнительный период времени, на котором сессия будет активна. Если сессия активна в регулярные периоды времени, должно дополнительно использоваться поле «r=» (см. ниже) после поля «t=»; в этом случае поле «t=» определяет начало и конец последовательности повторов сессии.

    Первое и второе подполя указывают время начала <start time> и конца <stop time> конференции соответственно. Эти значения являются десятичным представлением значений протокола NTP (Network Time Protocol) в секундах. Чтобы преобразовать эти значения в значения времени UNIX, надо вычесть десятичное число 2208988800.

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

    Когда показываются сессии, которые не имеют времени ограничения для пользователя, может быть сделано общее допущение, что неограниченная сессия будет активна только до получаса от текущего времени или от времени начала сессии, но не позже. Если требуется иной режим, то время окончания сессии должно быть задано и соответствующим образом модифицировано, когда будет доступна новая информация о действительном завершении сессии.

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


     
    AlexДата: Пятница, 12 Дек 2008, 14:06 | Сообщение # 2
    Главный админ
    Группа: Администраторы
    Город:
    Сообщений: 388
    Статус: отсутствует
    11. интервалы повторения сессий

    r=*(Поле «r=» определяет интервалы повторения сессий; ноль или большее число повторов)

    r=<repeat interval><active duration><list of offsets from start-time>

    Например, если сессия активна в 10 утра в понедельник и в 11 утра во вторник в течение одного часа каждую неделю в течение 3х месяцев, тогда <start time> в соответствующем поле «t=» должно представлять собой NTP представление: 10 часов утра первого понедельника, <repeat interval> должен быть равен 1 неделе, <active duration> должен быть 1 час, и сдвиги (offsets) должны быть 0 и 25 часов. Соответствующие поля «t=» времени окончания сессии должно иметь NTP представление окончания последней сессии через 3 месяца.

    По умолчанию все поля заполняются в секундах, так поля “r=” и “t=” могут содержать:

    t = 3034423619 3042462419

    r = 604800 3600 0 90000

    Чтобы сделать сообщение более компактным, время также может быть указано в днях, часах и минутах. Синтаксис для этого – число, непосредственно следующее за одиночной буквой, соответствующей конкретному случаю. Дробные единицы не разрешены – вместо них должны использоваться меньшие единицы времени. Допустимы следующие буквы определения единиц времени:

    d – день (86400 секунд)

    h – час (3600 секунд)

    M – минута (60 секунд)

    s – секунда (разрешена для полноты, но не рекомендуется)

    Таким образом, приведенное выше объявление должно быть записано следующим образом:

    r = 7d 1h 0 25 h

    12. объявление временной зоны

    z=*(объявление временной зоны)

    z=<adjustment time> <offset><adjustment time> <offset>

    Для составления расписания повторяющейся сессии, которая охватывает переход с летнего времени на стандартное время и обратно, необходимо определить сдвиги времени по отношению к базовому времени повторов сессий. Это требуется, потому что различные временные зоны сменяют время в различные моменты суток, различные страны переходят на летнее время и обратно в разные дни календаря, а некоторые страны вообще не переходят на летнее время. Таким образом, чтобы составить расписание сессии, которая проводится и зимой и летом, должна быть возможность однозначно определить, в какой временной зоне описана сессия. Чтобы упростить задачу приемников, мы допускаем, что передатчик должен определить NTP-время, как отсчет зонового времени и значение сдвига (offset) от момента, когда сессия была впервые внесена в расписание. Поле “z” позволяет определить список этих временных регулировок и сдвигов по отношению к базовому времени. Например:

    z=2882844526 –1h 2898848070 0

    Данная запись определяет, что во время 2882844526 базовое время, посредством которого рассчитываются повторы сессии, переводится на 1 час назад, и что во время 2898848070 первоначальное базовое время сессии восстанавливается. Регулировки времени всегда рассматриваются относительно определенного стартового времени – они не накапливаются.
    Если есть вероятность, что сессия длится несколько лет, ожидается, что описание сессии будет периодически модифицироваться, что предпочтительнее, чем передавать несколько лет изменения одного описания.

    13. криптографический ключ (Encryption keys)

    k=*(криптографический ключ)

    k=<method>

    k=<method>:<encryption key>

    SDP может использоваться для передачи криптографических ключей. Поле криптографического ключа допустимо перед первым вводом медиа (в этом случае он применяется ко всем медиа данной сессии), или перед вводом каждого медиа – как потребуется.

    Формат и использование криптографических ключей находится за рамками данного документа [см. RFC 1890].

    14. атрибуты сессии

    a=*(ноль или больше строк атрибутов сессии)

    a=<attribute>

    a=<attribute>:<value>

    Атрибуты являются основным средством расширения SDP. Атрибуты могут быть определены для использования как атрибуты «уровня сессии», атрибуты «уровня медиа» или обоими способами.

    Описание медиа может содержать любое количество атрибутов (полей «a=»), определяющих особенности медиа. Они применяются как атрибуты «уровня медиа» и дополняют информацию о медиа-потоке. Поля атрибутов также могут быть добавлены перед первым полем медиа; эти атрибуты «уровня сессии» передают дополнительную информацию, которая применяется к конференции в целом, а не к отдельному медиа; примером может служить политика управления пределом (floor) конференции.

    Поля атрибутов могут быть двух форматов:

    - атрибуты, отражающие свойства; эти атрибуты имеют простой формат: “a=<flag>”. Это двоичные атрибуты, и наличие атрибута передает информацию о свойстве сессии. Например: “a=recvonly”.

    - атрибуты, отражающие значения; эти атрибуты имеет форму записи
    «a=<attribute>:<value>».Примером может служить, что доска объявлений (whiteboard) должна иметь значение атрибута “a=orient:landscape” (а=ориентировать:горизонтально).

    Описание медиа (Ноль или более описаний медиа)

    15. имя медиа и адрес транспорта

    m=(имя медиа и адрес транспорта)

    m=<media> <port> <transport> <fmt list>

    Описание сессии может содержать несколько описаний медиа. Каждое описание медиа начинается с поля «m=» и заканчивается или следующим полем «m=» или концом описания сессии. Поле медиа имеет различные подполя.

    <media> Первое подполе <media> содержит тип медиа. В настоящее время определены типы медиа “audio”, “video”, “application”, “data” и “control”, хотя этот список может быть расширен, так как появляются новые коммуникационные возможности (например, телеприсутствие). Разница между “application” и “data” заключается в том, что первый представляет собой медиа-поток такой, как информация электронной доски объявлений, а второй – передачу объема данных, таких как многоадресная рассылка исполняемых программ, которые обычно не выводятся на дисплей пользователя. “control” используется для определения дополнительного канала управления конференцией для конкретной сессии.

    <port> Второе подполе <port> - это транспортный порт, в который будет передаваться медиа поток. Значение транспортного порта зависит от используемой сети, определяемой в соответствующем поле <c> и от транспортного протокола, который определяется в третьем подполе <transport>. Другие порты, используемые приложениями медиа (такие как RTCP-порт, см. [RFC 1889]) должны алгоритмически определяться в зависимости от базового порта медиа.

    Примечание: для транспортных протоколов, основанных на UDP, значение должно выбираться в диапазоне от 1024 до 65535 включительно. Для совместимости с RTP оно должно быть четным числом.

    <transport> Третье подполе <transport> - это транспортный протокол. Значения транспортного протокола зависят от значения типа адреса <address type> в полях «с=». Так, поле «с=» IP4 устанавливает, что транспортный протокол проходит над IP4. Для IP4 обычно ожидается, что наибольший медиа-трафик будет переноситься как RTP поверх UDP.

    Следующие транспортные протоколы предварительно определены, но могут быть расширены благодаря регистрации новых протоколов с IANA:

    - RTP/AVP – RTP протокол IETF, использующий Audio/video профиль, переносимый поверх UDP,

    - UDP – User Datagram Protocol.

    Если приложение использует одиночный комбинированный собственный (proprietary) формат и транспортный протокол поверх UDP, то в таком случае рекомендуется определить транспортный протокол, как UDP, и использовать поле формата для распознавания комбинированного протокола. Если транспортный протокол используется поверх UDP для передачи нескольких различных типов медиа, которые нужно различать, используя справочник сессии, то в таком случае необходимо отдельно определить транспортный протокол и формат медиа. RTP – это пример транспортного протокола, который переносит различные форматы полезной нагрузки, которые должны характеризоваться указателем сессии, чтобы было известно, как запускать соответствующие инструментальные средства, трансляторы, микшеры или передатчики.

    Основная причина определять транспортный протокол в дополнение к формату медиа заключается в том, что одни и те же стандартные форматы медиа могут передаваться различными транспортными протоколами даже при одном и том же сетевом протоколе – исторический пример этого – vat PCM-аудио и RTP PCM-аудио. Кроме того, возможно наличие средств трансляции и мониторинга, которые характерны для транспортного протокола, но не зависят от формата.

    Для обработки RTP медиа потоков c профилем RTP Audio/video [RFC 1890 (3)] поле протокола является - “RTP/AVP”. Если в будущем будут определяться другие RTP-профили, они будут специфицироваться таким же образом. Например, поле протокола “RTP/XYZ” должно определять обработку RTP с профилем, короткое имя которого – “XYZ”.

    <fmt list> Четвертое и последующие подполя – это форматы медиа. Для аудио и видео обычно это будут типы полезной медиа нагрузки, как определено в профиле RTP Audio/video.

    Если дан список форматов полезной нагрузки, это означает, что все эти форматы могут использоваться в сессии, а первый из этих форматов является форматом сессии по умолчанию.

    Для медиа, чей транспортный протокол не RTP или UDP, поле формата определяется протоколом. Такие форматы должны быть описаны в документе дополнительной спецификации.

    Для медиа, использующих транспортный протокол RTP, SDP может использоваться, чтобы обеспечить динамическую привязку способа кодирования данных к типу полезной нагрузки RTP. Наименования кодировок в AV-профиле RTP не определяют уникальные аудио-кодировки (в единицах тактовой частоты и количестве аудио-каналов), и поэтому они не используются непосредственно в полях формата SDP. Чтобы определить формат для типов статической нагрузки, вместо этого должен использоваться номер типа полезной нагрузки, а номер типа нагрузки с дополнительной информацией о кодировании должен использоваться для динамически размещаемых типов нагрузки.

    Примером типа статической нагрузки является один аудио канал с u-law PCM кодированием и частотой дискретизации 8 кГц. Он полностью определен в audio/video RTP-профиле как тип нагрузки 0, поэтому поле для определения медиа для такого потока, передаваемого в UDP-порт 49232 имеет следующий вид:

    m = video 49232 RTP/AVP 0

    Пример типа динамической нагрузки – 16 битовый линейно кодированный стерео аудио сигнал с частотой дискретизации 16 кГц. Если мы хотим использовать динамическую нагрузку RTP/AVP типа 98 для такого потока, требуется дополнительная информация для его декодирования:

    m = video 49232 RTP/AVP 98

    a = rtpmap: 98 L16/1600/2

    Основная форма атрибута rtpmap следующая:

    a = rtpmap: <payload type> <encoding name>/<clock rate>[/<encoding parameters>]

    Для аудио потоков <encoding parameters> могут определять количество аудио каналов. Этот параметр может быть пропущен, если количество каналов равно одному при условии, что не требуется дополнительных параметров. В настоящее время параметры кодирования для видео потоков не определены.

    Параметры, добавленные к атрибуту rtpmap, должны быть только такими, которые требуются каталогу сессии, чтобы выбрать подходящее для участия в сессии медиа-средство. Специфические для кодека параметры должны добавляться в других атрибутах.

    Для каждого медиа-формата может быть определено не более одного атрибута rtpmap. Таким образом, мы можем иметь:

    m = audio 49230 RTP/AVP 96 97 98

    a = rtpmap: 96 L8/8000

    a = rtpmap: 97 L16/8000

    a = rtpmap: 98 L16/11025/2

    Профили RTP, которые определяют использование типов полезной динамической нагрузки, должны определять набор допустимых имен схем кодирования и/или средств регистрации наименований схем кодирования, если этот профиль должен использоваться в SDP.

    Экспериментальные форматы кодирования также могут определяться с использованием атрибута rtpmap. RTP-форматы, не зарегистрированные как стандартные имена форматов, должны предваряться знаком «X-». Таким образом, новый экспериментальный аудио поток с избыточным кодированием, названный GSMLPC, использующий тип динамической нагрузки 99 должен быть описан как:

    m= video 40232 RTP/AVP 99

    a = rtpmap: 99 Х-GSMLPC/8000

    Такой экспериментальный формат кодирования обязывает, чтобы любая сторона, желающая принимать медиа-поток, имела соответствующее сконфигурированное состояние в ее каталоге сессии для того, чтобы знать, какие средства для этого предназначены.

    Отметим, что RTP аудио форматы обычно не включают информацию о скорости пакетизации. Если требуется пакетизация не по-умолчанию, то используется атрибут “ptime”, как описано ниже.
    Для более детального знакомства с аудио и видео форматами RTP см. [RFC 1890 (3)].


     
    Наш форум » Уголок связиста » Статьи » Протокол SDP
    • Страница 1 из 1
    • 1
    Поиск:
    FreeTechnologyCorp © 2020Конструктор сайтов - uCoz