Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
metoda.doc
Скачиваний:
65
Добавлен:
01.03.2016
Размер:
8.2 Mб
Скачать
      1. Дополнительные типы запросов

После испытаний протокола SIP в реальных сетях оказалось, что для решения ряда задач вышеуказанных шести типов запросов недостаточно. Поэтому в протокол будут введены новые сообщения.

INFO – обмен сигнальной информацией в процессе установления и поддержания соединения

    • Информация – в заголовках или теле сообщения

    • Не изменяет состояния сессии

Возможности и применение:

    • Перенос DTMF сигналов

    • Перенос текущих сигнальных сообщений PSTN между шлюзами PSTN во время разговорной сессии

    • Перенос биллинговой информации

    • Перенос непотоковой информации между участниками сессии

INFO sip:1@192.168.0.1 SIP/2.0

From: <sip:7021@192.168.0.1>;tag=97fb388ee7a1945o0

To: <sip:1@192.168.0.1>;tag=as6a482322

User-Agent: Sipura/SPA941-4.1.8

Content-Length: 24

Content-Type: application/dtmf-relay

Signal=5

Duration=100

Рисунок 3.10 – Пример запроса INFO

PRACK– Реализация расширения 100rel – надежная передача предварительных ответов.

Протокол SIP определяет два типа ответов на запрос, инициирующий соединение – предварительные и окончательные. Окончательные ответы передают результат обработки запроса и отсылаются надёжно (с подтверждением). Предварительные ответы обеспечивают информацию о текущей стадии обработки запроса, но отсылаются ненадёжно. Однако, в некоторых случаях, включающих взаимодействие с ТфОП, необходим механизм обеспечения надёжности передачи предварительных ответов. В целях поддержки функции надёжной транспортировки предварительных ответов требуется наличие у элемента SIP соответствующей опции (идентифицирующейся с помощью option tag «100rel»)

Повторная передача PRACK при получении уже подтвержденного предварительного ответа не осуществляется

UPDATE – изменение параметров сессии до ее окончательного установления (без воздействия на состояние диалога). Early media – установление мультимедиа сессии в целях передачи информации о текущем состоянии вызова до окончательного ответа UAS на INVITE. UPDATE может быть отослан в режиме диалога (находящегося на ранней стадии или установленного) для обновления параметров сессии без воздействия на состояние диалога.

SUBSCRIBE – запрос информации о текущем состоянии и обновлении состояния удалённого ресурса (подписка), обновление или отказ от подписки.

Subscriber– агент пользователя, запрашивающий и получающий информацию о состоянии ресурса.

Заголовок Event – событие или класс событий, на которое осуществляется подписка (event package).

Запрос SUBSCRIBE должен быть подтверждён окончательным ответом. После того, как подписка была успешно создана или обновлена, уведомитель должен незамедлительно отослать сообщение NOTIFY, чтобы сообщить подписчику текущее состояние ресурса. Запрос NOTIFY посылается в том же диалоге, который был создан ответом на запрос SUBSCRIBE.

Используемые поля:

Request-URI – идентификация ресурса, для которого требуется провести процедуру уведомления (notification)

Event – событие или класс событий, на которое осуществляется подписка (id – идентификатор подписки в пределах диалога), event package.

NOTIFY – уведомление подписчика о текущем или запрашиваемом состоянии ресурса, уведомление о наступлении события, на которое подписан UA.

Уведомитель (Notifier) – агент пользователя, информирующий пользователя о состоянии ресурса. Заголовок Subscription-state отображает состояние подписки.

REFER – указание получателю связаться с 3-ей стороной. Заголовок Refer-To содержит адрес третьей стороны, с которой отправитель предлагает связаться получателю. Не явно создается подписка на событие передачи вызова – «refer» event packege

MESSAGE – перенос мгновенных текстовых сообщений (Instant Messaging). Интерактивный режим обмена текстовыми сообщениями (Instant Messaging). Как правило, сообщения имеют малый размер и не сохраняются. Прямая связь между сообщениями отсутствует. Тело сообщения включает текстовое сообщение, которое нужно доставить, обычно в формате text/plain.

При передаче сообщений протокола SIP, упакованных в сигнальные сообщения протокола UDP, существует вероятность того, что размер запроса или ответа окажется больше максимально допустимого для данной сети, и произойдет фрагментация пакета. Чтобы избежать этого, используется сжатый формат имен основных заголовков.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]