Дополнительные типы запросов



Мы поможем в написании ваших работ!


Мы поможем в написании ваших работ!



Мы поможем в написании ваших работ!


ЗНАЕТЕ ЛИ ВЫ?

Дополнительные типы запросов



После испытаний протокола 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, существует вероятность того, что размер запроса или ответа окажется больше максимально допустимого для данной сети, и произойдет фрагментация пакета. Чтобы избежать этого, используется сжатый формат имен основных заголовков.

Ответы на запросы

После приема и интерпретации запроса, адресат (прокси,сервер) передает ответ на этот запрос. Содержание ответов бывает разным: подтверждение установления соединения, передача запрошенной информации, сведения о неисправностях и т.д. Структуру ответов и их виды протокол SIP унаследовал от протокола НТТР.

Код ответа (Status-Code) – это целое трёхзначное число, отражающее результат обработки запроса сервером. Первая цифра – класс ответа.

Описание причины (Reason-Phrase) – краткое описание кода ответа (для визуального восприятия пользователем)

 

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

Все ответы делятся на две группы: информационные и финальные. Информационные ответы показывают, что запрос находится в стадии обработки. Они кодируются трехзначным числом, начинающимся с единицы, – 1хх. Некоторые информационные ответы, например, 100 Trying, предназначены для установки на нуль таймеров, которые запускаются в оборудовании, передавшем запрос. Если к моменту срабатывания таймера ответ на запрос не получен, то считается, что этот запрос потерян и может (по усмотрению производителя) быть передан повторно. Один из распространенных ответов –

180 Ringing; по назначению он идентичен сигналу «Контроль посылки вызова» в ТфОП и означает, что вызываемый пользователь получает сигнал о входящем вызове.

Финальные ответы кодируются трехзначными числами, начинающимися с цифр 2, 3, 4, 5 и 6. Они означают завершение обработки запроса и содержат, когда это нужно, результат обработки запроса.

Ответы 2хх означают, что запрос был успешно обработан. В настоящее время из всех ответов типа 2хх определен лишь один – 200 ОК. Его значение зависит от того, на какой запрос он отвечает:

· ответ 200 ОК на запрос INVITE означает, что вызываемое оборудование согласно на участие в сеансе связи; в теле ответа указываются функциональные возможности этого оборудования;

· ответ 200 ОК на запрос BYE означает завершение сеанса связи, в теле ответа никакой информации не содержится;

· ответ 200 ОК на запрос CANCEL означает отмену поиска, в теле ответа никакой информации не содержится;

· ответ 200 ОК на запрос REGISTER означает, что регистрация прошла успешно;

· ответ 200 ОК на запрос OPTION служит для передачи сведений о функциональных возможностях оборудования, эти сведения содержатся в теле ответа.

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

· в ответе 300 Multiple Choices указывается несколько SIP-адресов, по которым можно найти вызываемого пользователя, и вызывающему пользователю предлагается выбрать один из них;

· ответ 301 Moved Permanently означает, что вызываемый пользователь больше не находится по адресу, указанному в запросе, и направлять запросы нужно на адрес, указанный в поле Contact;

· ответ 302 Moved Temporary означает, что пользователь времен, но (промежуток времени может быть указан в поле Expires) находится по другому адресу, который указывается в поле Contact.

Ответы 4хх информируют о том, что в запросе обнаружена ошибка. После получения такого ответа пользователь не должен передавать тот же самый запрос без его модификации:

· ответ 400 Bad Request означает, что запрос не понят из,за наличия в нем синтаксических ошибок;

· ответ 401 Unauthorized означает, что запрос требует проведения процедуры аутентификации пользователя. Существуют разные варианты аутентификации, и в ответе может быть указано какой из них использовать в данном случае;

· ответ 403 Forbidden означает, что сервер понял запрос, но отказался его обслуживать. Повторный запрос посылать не следует. Причины могут быть разными, например, запросы с этого адреса не обслуживаются и т.д.;

· ответ 485 Ambiguous означает, что адрес в запросе не определяет вызываемого пользователя однозначно;

· ответ 486 Busy Here означает, что вызываемый пользователь в настоящий момент не может принять входящий вызов по данному адресу. Ответ не исключает возможности связаться с пользователем по другому адресу или, к примеру, оставить сообщение в речевом почтовом ящике.

Ответы 5хх информируют о том, что запрос не может быть обработан из-за отказа сервера:

· ответ 500 Server Internal Error означает, что сервер не имеет возможности обслужить запрос из,за внутренней ошибки. Клиент может попытаться повторно послать запрос через некоторое время;

· ответ 501 Not Implemented означает, что в сервере не реализованы функции, необходимые для обслуживания этого запроса. Ответ передается, например в том случае, когда сервер не может распознать тип запроса;

· ответ 502 Bad Gateway информирует о том, что сервер, функционирующий в качестве шлюза или прокси,сервера, принял некорректный ответ от сервера, к которому он направил запрос;

· ответ 503 Service Unavailable говорит о том, что сервер не может в данный момент обслужить вызов вследствие перегрузки или проведения технического обслуживания.

Ответы 6xx информируют о том, что соединение с вызываемым пользователем установить невозможно:

· ответ 600 Busy Everywhere сообщает, что вызываемый пользователь занят и не может принять вызов в данный момент ни по одному из имеющихся у него адресов. Ответ может указывать время, подходящее для вызова пользователя;

· ответ 603 Decline означает, что вызываемый пользователь не может или не желает принять входящий вызов. В ответе может быть указано подходящее для вызова время;

· ответ 604 Does Not Exist Anywhere означает, что вызываемого пользователя не существует.

Порядок выполнения работы

1. Запустить сервер IP телефонии, предварительно сконфигурированный на основе лабораторной работы №2.

2. Зарегистрировать 2 UA на сервере, проверить работоспособность, путем совершения тестовых звонков.

Схема соединения сервера и клиентов (аппаратный телефон и программный телефон) представлена на рисунке 3.11.

Рисунок 3.11 – Схема соединения сервера и клиентов

3. Запустить программу wireshark на ПК с сервером IP телефонии.

4. Создать фильтр пакетов между нашими UA и сервером.

5. Исследовать сценарий регистрации UA на сервере, успешной и не успешной (например, с неправильными данными аутентификации).

Ниже приведены скриншоты хода неудачной (рисунок 3.12) и удачной регистрации (рисунок 3.13).

Рисунок 3.12 – Неудачная регистрация клиента 192.168.73.150

REGISTER sip:192.168.73.14 SIP/2.0

Via: SIP/2.0/UDP 192.168.73.160:10644;branch=z9hG4bK-d8754z-b23f8143a96a9820-1---d8754z-;rport

Max-Forwards: 70

Contact: <sip:222@192.168.73.160:10644;rinstance=8074ab90cd18e621>

To: "222"<sip:222@192.168.73.14>

From: "222"<sip:222@192.168.73.14>;tag=a27a4302

Call-ID: MDEzYTk2Njc2NmE1ODk2Y2VhYTRlNDA1YzNiY2FlYTY.

CSeq: 1 REGISTER

Expires: 3600

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO

User-Agent: X-Lite release 1103k stamp 53621

Content-Length: 0

 

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 192.168.73.160:10644;branch=z9hG4bK-d8754z-b23f8143a96a9820-1---d8754z-;received=192.168.73.160;rport=10644

From: "222"<sip:222@192.168.73.14>;tag=a27a4302

To: "222"<sip:222@192.168.73.14>

Call-ID: MDEzYTk2Njc2NmE1ODk2Y2VhYTRlNDA1YzNiY2FlYTY.

CSeq: 1 REGISTER

User-Agent: Asterisk PBX

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces

Content-Length: 0

 

SIP/2.0 401 Unauthorized

Via: SIP/2.0/UDP 192.168.73.160:10644;branch=z9hG4bK-d8754z-b23f8143a96a9820-1---d8754z-;received=192.168.73.160;rport=10644

From: "222"<sip:222@192.168.73.14>;tag=a27a4302

To: "222"<sip:222@192.168.73.14>;tag=as34e1976a

Call-ID: MDEzYTk2Njc2NmE1ODk2Y2VhYTRlNDA1YzNiY2FlYTY.

CSeq: 1 REGISTER

User-Agent: Asterisk PBX

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces

WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="2837e571"

Content-Length: 0

 

REGISTER sip:192.168.73.14 SIP/2.0

Via: SIP/2.0/UDP 192.168.73.160:10644;branch=z9hG4bK-d8754z-5a4f7d3cc5673455-1---d8754z-;rport

Max-Forwards: 70

Contact: <sip:222@192.168.73.160:10644;rinstance=8074ab90cd18e621>

To: "222"<sip:222@192.168.73.14>

From: "222"<sip:222@192.168.73.14>;tag=a27a4302

Call-ID: MDEzYTk2Njc2NmE1ODk2Y2VhYTRlNDA1YzNiY2FlYTY.

CSeq: 2 REGISTER

Expires: 3600

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO

User-Agent: X-Lite release 1103k stamp 53621

Authorization: Digest username="222",realm="asterisk",nonce="2837e571",uri="sip:192.168.73.14",response="32a7e0e12a607ef34b349ff1206528d7",algorithm=MD5

Content-Length: 0

 

SIP/2.0 100 Trying

Via: SIP/2.0/UDP 192.168.73.160:10644;branch=z9hG4bK-d8754z-5a4f7d3cc5673455-1---d8754z-;received=192.168.73.160;rport=10644

From: "222"<sip:222@192.168.73.14>;tag=a27a4302

To: "222"<sip:222@192.168.73.14>

Call-ID: MDEzYTk2Njc2NmE1ODk2Y2VhYTRlNDA1YzNiY2FlYTY.

CSeq: 2 REGISTER

User-Agent: Asterisk PBX

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO

Supported: replaces

Content-Length: 0

 



Последнее изменение этой страницы: 2016-04-23; Нарушение авторского права страницы; Мы поможем в написании вашей работы!

infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 3.236.214.224 (0.019 с.)