Алгоритмы мультимедиа

Сообщения SIP

Как было замечено, SIP является протоколом, базирующемся на текстах, с синтаксисом, сходным с HTTP. Существует два разных типа SIP сообщений: запросы и отклики. Различие форматов этих сообщений проявляется в первой строке. Первая строка запроса содержит метод, определяющий природу запроса, и URI запроса, указывающий, куда следует послать запрос. Первая строка отклика содержит код отклика. Все сообщения имеют заголовок, состоящий из нескольких строк, каждая строка начинается с метки заголовка. Сообщение может содержать в себе описание транспортируемых данных SDP. Для запросов SIP RFC-3261 определяет следующие методы.

Рис. 10.37.

• REGISTER (регистр). Используется агентом пользователя, чтобы проинформировать конфигурацию SIP о своем текущем IP адресе и URL, для которого желательно получать вызовы.
• INVITE (приглашение). Применяется, чтобы установить медийную сессию между агентами пользователей.
• ACK. Подтверждает надежную доставку сообщения.
• CANCEL (аннулирование). Прерывает обслуживание незавершенного запроса, но не изменяет статуса завершенных вызовов.
• BYE. Завершает сессию между двумя пользователями.
• OPTIONS (опции). Запрашивает информацию об источнике запроса, но не реализует сам запрос.

Например, заголовок сообщения (1) на рис. 10.35 может выглядеть следующим образом:

INVITE sip:bbb@ itep.com SIP/2.0
Via: SIP/2.0/UDP 12.26.17.91:5060
MaxForwards: 70
To: B <sip:bbb@ itep.com
From: A <sip:aaa@iae.com;tag=1928301774
CallID: a84b4c76e66710@12.26.17.91
CSeq: 314159 INVITE
Contact: <sip:aaa@iae.com>
ContentType: application/sdp
ContentLength: 142

Первая строка содержит название метода ( INVITE ), SIP URI, номер используемой версии протокола SIP. Последующие строки представляют собой список полей заголовка. В данном примере представлен минимально необходимый набор.

Заголовки Via показывают путь запроса через конфигурацию SIP (отправитель и промежуточные прокси), и используются при передаче по тому же маршруту откликов. Когда посылается сообщение INVITE, оно имеет только заголовок, вставленный А. Строка содержит IP адрес (12.26.17.91), номер порта (5060), и транспортный протокол (UDP), которые B должен применить в отклике.

Заголовок MaxForwards ограничивает число шагов, которые запрос может сделать до точки назначения. Содержимое этого поля является целым числом, которое декрементируется на 1 каждым прокси, переадресующим запрос. Если значение MaxForwards станет равным 0, прежде чем запрос достигнет места назначения, он отвергается с кодом ошибки в отклике, равным 483 (Too Many Hops – слишком много шагов).

Поле заголовка To содержит имя (B) и URI SIP или SIPS (sip:bbb@ itep.com), которому первоначально предназначался запрос. Поле заголовка From также содержит имя (A) и URI SIP или SIPS (sip:aaa@iae.com), которое указывает на отправителя запроса. Это поле заголовка имеет также свободный параметр, который содержит произвольную строку (1928301774), добавляемую к URI UAC. Она используется для идентификации сессии.

Поле заголовка Call-ID содержит глобально уникальный идентификатор данного вызова, генерируемый из комбинации псевдослучайной строки и имени ЭВМ или IP-адреса. Комбинация тэгов To, From и Call-ID полностью определяет отношение SIP партнеров А и B.

CSeq или поле заголовка Command Sequence содержит целое число и имя метода. Число CSeq инициализируется в начале вызова (в данном примере 314159), инкрементируется для каждого нового запроса в рамках диалога и является традиционным порядковым номером. CSeq используется, чтобы отличить повторную передачу от нового запроса.

Поле заголовка Contact содержит SIP URI для непосредственной коммуникации между агентами пользователя. Несмотря на то, что поле заголовка Via говорит другим элементам, куда следует посылать отклик, поле заголовка Contact сообщает другим элементам, куда посылать будущие запросы для заданного диалога.

Поле заголовка ContentType указывает на тип тела сообщения. Поле заголовка ContentLength содержит длину тела сообщения в октетах.

Типы откликов SIP, определенных в RFC-3261, имеют следующие категории.

• Условный (переходной 1xx): Запрос получен и обрабатывается.
• Успех (2xx): Задание успешно получено, понято и воспринято.
• Перенаправление (3xx): Нужны дальнейшие действия, чтобы завершить реализацию запроса.
• Ошибка клиента (4xx): Запрос содержит некорректный синтаксис или не может быть обслужен сервером.
• Ошибка сервера (5xx): Сервер не смог выполнить заведомо корректный запрос.
• Глобальный отказ (Global Failure: 6xx): Запрос не может быть выполнен любым сервером.

Например, заголовок сообщения (13) на рис. 10.35 может выглядеть следующим образом:

SIP/2.0 200 OK
Via: SIP/2.0/UDP server10.itep.com
Via: SIP/2.0/UDP bgb3.site3.iae.com
Via: SIP/2.0/UDP 12.26.17.91:5060
To: B <sip:bbb@itep.com;tag=a6c85cf
From: A <sip:aaa@iae.com;tag=1928301774
CallID: a84b4c76e66710@12.26.17.91
CSeq: 314159 INVITE
Contact: <sip:bbb@itep.com>
ContentType: application/sdp
ContentLength: 131

Первая строка содержит номер версии SIP, которая используется, код отклика и имя. Последующие строки представляют собой список полей заголовка. Поля заголовка Via, To, From, Call-ID и CSeq копируются из запроса INVITE. (Существует три значения поля заголовка Via — одно связано с UAC А, другое введено прокси iae.com proxy и еще одно добавлено прокси itep.com). Телефонный номер B записан в тэг параметра поля заголовка To. Этот тэг вводится обеими сторонами диалога и включается во все будущие запросы в рамках заданного вызова.

Протокол описания сессии

Протокол SDP (Session Description Protocol), определенный в RFC-2327, описывает содержимое сессий, включая телефонию, Интернет-радио, приложения мультимедиа. SDP содержит информацию о [10.8]:

медиа-потоках. Сессия может реализовывать несколько потоков данных. В протоколе SDP в настоящее время определены аудио, видео, данные, управление и приложения (поточные), сходные с MIME типами электронной почты в Интернет;

адресах. SDP указывает адреса места назначения, которые могут быть для медиа-потоков мультикастинг-адресами;

портах. Для каждого потока специфицируются номера UDP портов для отправителя и получателя;

типах данных. Для каждого используемого типа потока (например, телефония) тип поля данных указывает на медиа-форматы, которые могут применяться во время сессии;

времени старта и остановки. Эти данные используются в случае широковещательных сессий, например, телевизионных или радиопрограмм. Указываются время начала, завершения и времена повторов сессии;

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

Несмотря на то, что SDP предоставляет возможность описания мультимедиа-данных, здесь не хватает механизмов согласования параметров сессии, которые намерены использовать партнеры. Документ RFC-3264 [10.7] предоставляет модель согласования на основе механизма предложения/отклика, в которой партнеры обмениваются SDP сообщениями с целью достичь согласия относительно природы данных, подлежащих пересылке.