873.18K
Категория: ИнтернетИнтернет

Протокол инициирования сеансов связи SIP

1.

МИНИСТЕРСТВО СВЯЗИ И ИНФОРМАТИЗАЦИИ
РЕСПУБЛИКИ БЕЛАРУСЬ
Учреждение образования
«ВЫСШИЙ ГОСУДАРСТВЕННЫЙ КОЛЛЕДЖ СВЯЗИ»
Кафедра телекоммуникационных систем
ПРОТОКОЛ ИНИЦИИРОВАНИЯ СЕАНСОВ СВЯЗИ
SIP
ПО ДИСЦИПЛИНЕ
«СИГНАЛИЗАЦИЯ В ТЕЛЕКОММУНИКАЦИЯХ»
Методические указания к выполнению практических
занятий для
для студентов дневной формы обучения специальности
1-45 01 03 – Сети телекоммуникаций
Минск
2014

2.

УДК 621.395
ББК 32.88
С34
Рекомендовано к изданию
кафедрой телекоммуникационных систем
5 декабря 2013, протокол № 4
Составитель:
Е. А. Ленковец, старший преподаватель
кафедры
телекоммуникационных систем
Р ецензент
Н. И. Шатило, доцент кафедры защиты информации БГУИР,
канд. техн. наук
С34
Протокол инициирования сеансов связи SIP по
дисциплине «Сигнализация в телекоммуникациях» : для
студентов
специальности
1-45
01
03

Сети
телекоммуникаций / сост. Е. А. Ленковец. – Минск : УО
ВГКС, 2014. – 52 с.
ISBN 978-985-6938-02-6.
Приведены принципы протокола SIP, рассмотрена структура запросов и о т ве тов протокола SIP, порядок следования сообщений протокола SIP.
Предназначено для студентов и преподавателей вузов.
УДК 621.395
ББК 32.88
ISBN 978-985-6938-02-6
2
©Учреждение образования
«Высший государственный
колледж связи», 2014

3.

ПРИНЦИПЫ ПРОТОКОЛА SIP
Протокол инициирования сеансов – Session Initiation
Protocol (SIP) является протоколом прикладного уровня и предназначается для организации, модификации и завершения сеансов связи: мультимедийных конференций, телефонных соединений и распределения мультимедийной информации.
Принципы протокола SIP:
– персональная мобильность пользователей. Пользователи
могут перемещаться без ограничений в пределах сети, поэтому
услуги связи должны предоставляться им в любом месте этой
сети;
– масштабируемость сети характеризуется возможностью
увеличения количества элементов сети при расширении;
– расширяемость протокола характеризуется возможностью дополнения протокола новыми функциями при введении
новых услуг и его адаптации к работе с различными приложениями;
– интеграция в стек существующих протоколов Интернет,
разработанных IETF. Протокол SIP является частью глобальной
архитектуры мультимедиа, разработанной комитетом IETF;
– взаимодействие с другими протоколами сигнализации .
Протокол SIP может быть использован совместно с протоколом
Н.323. Возможно взаимодействие с системами сигнализации
ТфОП – DSS1 и ОКС7.
Важной особенностью протокола SIP является его независимость от транспортных технологий. Но, в то же время, предпочтение отдается технологии маршрутизации пакетов IP и протоколу UDP. Сигнальные сообщения могут переноситься не
только протоколом транспортного уровня UDP, но и протоколом
TCP.
Протокол UDP позволяет быстрее, чем TCP, доставлять сигнальную информацию (даже с учетом повторной передачи неподтвержденных сообщений), а также вести параллельный поиск местоположения пользователей и передавать приглашения к
участию в сеансе связи в режиме многоадресной рассылки. В
3

4.

свою очередь, протокол TCP гарантирует надежную доставку
данных.
Сам протокол SIP непосредственного участия в передаче голосовых, видео и других данных не принимает, он отвечает
только за установление связи (по протоколам SDP, RTP и др.).
В протоколе SIP не реализованы механизмы управления потоками информации и предоставления гарантированного качества обслуживания.
Кроме того, протокол SIP не предназначен для передачи
пользовательской информации, в его сообщениях может переноситься информация лишь ограниченного объема.
Для организации взаимодействия с существующими приложениями IP-сетей и для обеспечения мобильности пользователей протокол SIP использует адрес, подобный адресу электро нной почты.
SIP-адреса бывают четырех типов:
– имя@домен;
– имя@хост;
– имя@IР-адрес;
– №телефона@шлюз.
Определены два основных типа сетевых элементов SIP (рисунок 1):
Рисунок 1 – Пример архитектуры сети SIP
4

5.

– прокси-сервер (proxy server) и
– сервер переадресации (redirect server).
Прокси-сервер (англ. proxy – представитель) представляет
интересы пользователя в сети. Он принимает запросы, обрабатывает их и, в зависимости от типа запроса, выполняет определенные действия.
Предусмотрено два типа прокси-серверов:
– с сохранением состояний (stateful) и
– без сохранения состояний (stateless).
Сервер stateful хранит в памяти входящий запрос, который
явился причиной генерации одного или нескольких исходящих
запросов. Все запросы хранятся в памяти сервера только до
окончания транзакции, т. е. до получения ответов на запросы.
Сервер stateful позволяет предоставить большее количество
услуг, но работает медленнее, чем сервер stateless.
Сервер stateless просто ретранслирует запросы и ответы, которые получает. Он работает быстрее, чем сервер первого типа,
так как ресурс процессора не тратится на запоминание состояний, вследствие чего сервер этого типа может обслужить большее количество пользователей. Недостатком такого сервера
является то, что на его базе можно реализовать лишь наиболее
простые услуги.
Прокси-сервер может функционировать как сервер stateful
для одних пользователей и как сервер stateless – для других.
Сервер переадресации предназначен для определения текущего адреса вызываемого пользователя. Вызывающий польз ователь передает к серверу сообщение с известным ему адресом
вызываемого пользователя, а сервер обеспечивает переадресацию вызова на текущий адрес этого пользователя.
Для реализации этой функции сервер переадресации должен
взаимодействовать с сервером определения местоположения.
Сервер определения местоположения пользователей позволяет определить местоположение вызываемого пользователя в
текущий момент времени. Сервер определения местоположения
пользователей может быть совмещен с прокси-сервером (в таком
5

6.

случае он называется registrar) или быть реализован отдельно от
прокси-сервера, но иметь возможность связываться с ним.
СТРУКТУРА СООБЩЕНИЙ ПРОТОКОЛА SIP
Согласно архитектуре «клиент – сервер» все сообщения делятся на запросы, передаваемые от клиента к серверу, и на отв еты сервера клиенту. На рисунке 2 представлена структура сообщений протокола SIP.
Рисунок 2 – Структура сообщений протокола SIP
Стартовая строка представляет собой начальную строку
любого SIP-сообщения. Если сообщение является запросом, в
этой строке указываются тип запроса, адресат и номер версии
протокола.
Пример – INVITE sip: [email protected] SIP/2.0
Если сообщение является ответом на запрос, в стартовой
строке указываются номер версии протокола, тип ответа и его
короткая расшифровка, предназначенная только для пользователя.
Пример – SIP/2.0 200 OK
Заголовки сообщений содержат сведения об отправителе,
адресате, пути следования и др. Переносят информацию, необходимую для обслуживания данного сообщения.
6

7.

В протоколе SIP определено четыре вида заголовков:
– общие заголовки, присутствующие в запросах и ответах;
– заголовки содержания, переносят информацию о размере
тела сообщения или об источнике запроса (начинаются со слова
«Content»);
– заголовки запросов, передающие дополнительную информацию о запросе;
– заголовки ответов, передающие дополнительную информацию об ответе.
При передаче сообщений протокола SIP, упакованных в
сигнальные сообщения протокола UDP, существует вероятность
того, что размер запроса или ответа превысит максимально допустимый размер для данной сети, что приведет к фрагментации
пакета. Во избежание этого используется сжатый формат имен
основных заголовков, подобно тому, как это делается в протоколе SDP. В таблице 1 приведен список таких заголовков.
Таблица 1 – Сжатые имена заголовков
Сжатая форма имени
Полная форма имени
C
Content-Type
E
Content-Encoding
F
I
From
Call-ID
K
Supported
L
M
Content-Length
Contact (от «moved»)
S
Subject
O
R
Event
Refer-To
T
To
7

8.

U
Allow-Events
V
Via
Сообщения протокола SIP могут содержать тело сообщения.
В запросах ACK, INVITE и OPTIONS тело сообщения содержит описание сеансов связи, например, в формате протокола
SDP. Запрос BYE тела сообщения не содержит.
Любые ответы могут содержать тело сообщения, но содержимое тела в них бывает разным.
Типы заголовков
− Заголовок Accept-Language используется в запросах,
чтобы указать предпочтительные языки для ключевых фраз,
описаний сеансов связи, оповещений о текущем состоянии, содержащихся в ответах в качестве тел сообщения. В случае если
заголовок отсутствует, сервер устанавливает, что клиент поддерживает все языки.
Правило упорядочивания языков в списке по предпочтительности базируется на параметре «q».
Пример – Accept-Language:da, en-gb; q=0.8, en; q=0.7
− Заголовок Call-ID – уникальный идентификатор сеанса
связи или всех регистраций отдельного клиента. Значение идентификатору присваивает сторона, которая инициирует вызов.
Возможна и такая ситуация: к одной мультимедийной конференции относятся несколько соединений − все они будут иметь
разные идентификаторы Call-ID.
Заголовок состоит из буквенно-числового значения и имени
рабочей станции, которая присвоила этому идентификатору.
Между ними должен стоять символ «@». Значения Call-ID регистрозависимы и могут сравниваться побайтно. Примеры
1 Call-ID:[email protected]
2 i:[email protected]
− Заголовок Contact. Поле заголовка Contact несет в себе
8

9.

URI, значение которого зависит от типа передаваемого запроса
или ответа. Как правило, в заголовке Contact находится текущий
адрес пользователя, на который он может принимать входящие
сообщения. Заголовок Contact может содержать отображаемое
имя (display name), адрес с его параметрами и параметры заголовка.
Для заголовка Contact определены параметры «q» и
«expires». Они используются только в случае, когда заголовок
присутствует в запросе REGISTER, ответе на него или в ответе
класса 3хх.
Когда значение поля заголовка содержит отображаемое имя,
URI со всеми его параметрами заключается в символы «<» и
«>». В противном случае все параметры, следующие за URI, будут трактоваться как параметры заголовка. Отображаемым им енем может быть комбинация символьных фраз или строка, заключённая в кавычки, когда существует необходимость в более
длинной характеристике.
В случае, если URI содержит запятую, точку с запятой или
вопросительный знак, он заключается в угловые скобки, даже
если отображаемое имя отсутствует. Между отображаемым
именем и «<» допускается наличие линейного пробела (LWS).
Эти правила действительны также в отношении заголовков To и
From.
Поскольку URI могут содержать запятые и точки с запятой в
качестве скрытых знаков, они могут быть приняты за разграничители значений заголовков или параметров соответственно.
Примеры
1 Contact: "Alexander" <sip:[email protected]> ;q=0.7; e xpires=3600,
2 Contact: "Alexander" <mailto:[email protected]> ;q=0.1
− Заголовок Content-Language. Основное назначение заголовка Content-Language – определить и изменить содержимое
тела сообщения в соответствии с предпочтительным языком
пользователя (имеется в виду национальный язык). Если тело
сообщения содержит информацию на конкретном языке, то это
будет указано в заголовке. В случае отсутствия заголовка
9

10.

Content-Language в сообщении подразумевается, что содержимое предназначено для пользователей любых языковых групп.
Заголовок Content-Language может применяться не только к
текстовым телам, но и к телам других типов.
Пример – Content-Language:fr
− Заголовок Content-Length указывает отображенный в десятичном виде размер тела сообщения, посланного получателю,
в байтах. Приложения должны помещать в данное поле размер
тела сообщения, подлежащего отправке, не взирая на тип тела
сообщения.
Если в качестве транспорта выступает потокоориентированный протокол (такой как TCP), заголовок ContentLength должен использоваться обязательно.
Размер тела сообщения не учитывает пустой строки, отделяющей заголовки от тела сообщения. Разрешенными значениями для Content-Length является любое число, большее или равное нулю. Когда в передаваемом сообщении тело отсутствует, в
поле заголовка Content-Length выставляется ноль.
Возможность не включать заголовок Content-Length в сообщение упрощает создание cgi-подобных сценариев, которые динамически генерируют ответы.
Пример – Content-Length:349
− Заголовок Content-Type определяет тип тела сооб щения,
посланного получателю. Content-Type должен входить в сообщение, если тело сообщения не пустое. Если же тело пустое, а
Content-Type присутствует, он показывает, что тело определенного типа имеет нулевую длину (например, пустой аудиофайл).
Примеры
1 Content-Type: application/sdp
2 c:text/html; charset=ISO-8859-4
− Заголовок CSeq – уникальный идентификатор запроса,
относящегося к одному соединению. Он служит для корреляции
запроса с ответом на него, а также для различия первоначальных
запросов с переадресованными. Заголовок состоит из двух частей: натурального числа из диапазона чисел от 1 до 232 и типа
запроса. Часть типа запроса является регистрозависимой. Сервер
10

11.

должен проверять значение величины CSeq в каждом принимаемом запросе, и считает его новым, если значение больше пред ыдущего. Этот заголовок копируется из запроса в ответ.
Пример – CSeq: 4711 INVITE
− Заголовок Expires устанавливает время, по истечении которого сообщение или его содержимое станет недействительным. Конкретное значение заголовка зависит от типа запроса.
Присутствует в запросах REGISTER и INVITE.
В запросе REGISTER указывает, сколько времени регистрация остается действительной. В запросах INVITE он ограничивает количество времени, в течение которого URI будет оставаться действительным на приемнике – оставаться в кэшпамяти.
Если этот заголовок отсутствует, на сервере не будет осуществляться буферизация. Значение этого поля – количество
секунд, выраженное в десятичном виде, в интервале между 0 и
(232 –1), измеренное с момента получения запроса.
Пример – Expires: 5
− Заголовок From содержит URI отправителя запроса. Заметим, что адрес отправителя запроса может не совпадать с адресом инициатора диалога. Адрес из заголовка From запроса копируется в одноименный заголовок ответа. Кроме SIP-адреса
здесь может стоять параметр «tag» для идентификации конкретного терминала пользователя (например, домашнего, рабочего
или сотового телефона) в том случае, когда все его терминалы
зарегистрированы под одним адресом. Запрос может множиться
и достичь разных терминалов пользователя; чтобы их различать,
необходимо иметь метку tag.
Отображаемое имя должно информировать пользователя об
инициаторе запроса. В случае если не удается установить личность вызывающего пользователя, в качестве display name
(отображаемого имени) фигурирует «Anonymous». В случае, если URI содержит запятую, точку с запятой или вопросительный
знак, он заключается в угловые скобки, даже если отображаемое
имя отсутствует.
Два заголовка From считаются эквивалентными, когда сов11

12.

падают их URI и параметры. При сравнении параметры расширения, присутствующие лишь в одном из двух заголовков, во
внимание не берутся. Это означает, что отображаемое имя и
наличие либо отсутствие угловых скобок не влияют на результат
сравнения.
Примеры
1 From: "Vladimir" <sip:[email protected]> ;tag=a48s
2 From: sip:[email protected];tag=887s
− Заголовок Max-Forwards используется в любом типе SIPзапросов, чтобы ограничить число серверов или шлюзов, через
которые проходит запрос. Значение заголовка должно быть целым числом в пределах от 0 до 255, отражающим оставшееся
количество пересылок, которое разрешено осуществить сообщению. Это число уменьшается каждым сервером, который пересылает запрос дальше. В качестве первоначального значения
рекомендуется брать 70.
Заголовок Max-Forwards должен вставляться теми элементами, которые иначе не могут гарантировать обнаружение петли.
Пример – Max-Forwards:6
− Заголовок MIME-Version указывает версию стандарта
MIME-информации, помещенной в тело сообщения.
Пример – MIME-Version:1.0
− Заголовок Record-Route вставляется прокси-серверами в
запросы для того, чтобы последующие запросы в процессе диалога маршрутизировались через данные прокси-серверы.
Пример – Record-Route:
<sip:serv10.protei.ru;lr>,
<sip:site3.niits.ru;lr>
− Заголовок Route служит для принудительной маршрутизации запроса в соответствии со списком прокси-серверов.
Пример – Route: <sip:site5.niits.ru;lr>,<sip:serv3.protei.ru;lr>
− Заголовок To определяет логического адресата запроса. В
случае присутствия отображаемого имени, оно должно быть с
помощью пользовательского интерфейса предоставлено вызываемому пользователю.
Процедура сравнения заголовков To аналогична процедуре с
заголовками From.
12

13.

Пример
1 To: The Operator <sip:[email protected]>;tag=287447
2 t: sip:[email protected]
− Заголовок Via служит для того, чтобы избежать ситуации,
в которых запрос пойдет по замкнутому пути, а также для тех
случаев, когда необходимо, чтобы запросы и ответы обязательно
проходили по одному и тому же пути. Запрос может проходить
через несколько прокси-серверов, каждый из которых принимает, обрабатывает и переправляет запрос к следующему проксисерверу, и так до тех пор, пока запрос не достигнет адресата. Таким образом, в заголовке Via указывается весь путь, пройденный
запросом: каждый прокси-сервер добавляет поле со своим адресом. При необходимости (например, чтобы обеспечить секретность) действительный адрес может скрываться.
Например, запрос на своем пути обрабатывался двумя прокси-серверами: сначала сервером loniis.ru, потом sip.telecom.com.
Тогда в запросе появятся следующие поля:
Via: SIP/2.0/UDP sip.telecom.com:5060;branch=721e418c4.1
Via: SIP/2.0/UDP loniis.ru:5060,
где параметр «branch» означает, что на сервере
sip.telecom.com запрос был размножен и направлен одновременно по разным направлениям, и наш запрос был передан по
направлению, которое идентифицируется следующим образом:
721e418c4.1.
Содержимое полей Via копируется из запросов в ответы на
них, и каждый сервер, через который проходит ответ, удаляет
поле Via со своим именем.
Пример
Via: SIP/2.0/UDP serv1.niits.ru:5060;branch=z9hG4bK87asdks7
Via:SIP/2.0/UDP192.0.2.1:5060;received=192.0.2.207;branch=z9h
G4bK77asjd
В этом примере сообщение сформировано на терминале
(multi-homed host) с двумя сетевыми адресами 192.0.2.1 и
192.0.2.207. Отправитель не был уверен, какой сетевой интерфейс необходимо использовать и указал первый. Получив сообщение, узел serv1.niits.ru обнаружил несоответствие и добавил
13

14.

параметр к значению заголовка Via, относящегося к предыдущей пересылке. Параметр содержит действительный адрес, с
которого поступил пакет.
К сетевому или хост-адресу и номеру порта не предъявляется требований подчинения синтаксису SIP URI. А именно, пробел не запрещается по обеим сторонам «:» или «/», как показано:
Via: SIP / 2.0 / UDP serv3.niits.ru: 4000;ttl=16;
maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1
Два заголовка Via считаются равными, если их значения:
название прикладного протокола, версия протокола, используемый транспортный протокол, адрес и порт узла – одинаковы,
имеют один и тот же набор параметров, и значения параметров
равны.
Назначение и формат запросов
SIP-запросы характеризуются наличием Request-Line в стартовой строке. Request-Line состоит из названия типа запроса,
Request-URI и версии протокола, разделенных пробелом.
Пример − ACK sip:[email protected] SIP/2.0
Request-Line заканчивается символами возврата каретки и
перевода строки (CRLF). Оба символа, вместе или по одиночке,
не должны встречаться в других частях строки. Использование
линейного пробела (LWS – произвольное сочетание пробелов и
символов горизонтальной табуляции) не допускается. Структура
Request-Line указана на рисунке 3.
Тип
запроса
Пробел
RequestURI
Пробел
Версия
протокола
СRLF
Рисунок 3 – Структура Request-Line
Пример – INVITE sip: [email protected] SIP/2.0
14

15.

Тип запроса. В базовой рекомендации IETF RFC 3261 определено 6 типов запросов.
Запрос INVITE приглашает вызываемого пользователя
принять участие в сеансе связи. Сообщение обычно содержит
описание сессии, в котором передается вид принимаемой информации и параметры (список возможных вариантов параметров), необходимые для приема информации, также может указываться вид информации, который вызываемый пользователь
желает передавать.
Запрос АСК подтверждает прием ответа на запрос INVITE.
Запрос АСК используется только совместно с запросом INVITE,
т. е. этим сообщением оборудование вызывающего пользователя
показывает, что оно получило окончательный ответ на свой запрос INVITE. В сообщении ACK может содержаться окончательное описание сеанса связи, передаваемое вызывающим
пользователем.
Запрос CANCEL отменяет обработку ранее переданных з апросов, но не влияет на те запросы, обработка которых уже завершена. Например, запрос CANCEL применяется тогда, когда
прокси-сервер размножает запросы для поиска пользователя по
нескольким направлениям и в одном из них его находит. Обработку запросов, разосланных во всех остальных направлениях,
сервер отменяет при помощи сообщения CANCEL.
Запросом BYE оборудование вызываемого или вызывающего пользователя завершает соединение. Сторона, получившая
запрос BYE, должна прекратить передачу речевой (мультимедийной) информации и подтвердить его выполнение ответом 200
ОК.
При помощи запроса типа REGISTER пользователь сообщает свое текущее местоположение.
Запросом OPTIONS вызываемый пользователь запрашивает информацию о функциональных возможностях терминального оборудования вызываемого пользователя. В ответ на этот запрос оборудование вызываемого пользователя сообщает требуемые сведения.
15

16.

Каждый из них предназначен для выполнения достаточно
широкого круга задач, что является явным достоинством протокола SIP, так как число сообщений, которыми обмениваются
терминалы и сервера, снижено до минимума. Сервер определяет
тип принятого запроса по названию, указанному в стартовой
строке. В таблице 2 указаны SIP-запросы для второй версии протокола SIP .
Таблица 2 – SIP-запросы
Название
запроса
1
INVITE
ACK
BYE
1
CANCEL
REGISTER
OPTION
INFO
PRACK
UPDATE
16
Описание запроса
2
Приглашает пользователя к сеансу связи.
Подтверждает прием окончательного ответа на
запрос INVITE
Завершает вызов. Посылается любой из сторон, участвующих в соединении.
Продолжение таблицы 2
2
Отменяет обработку запросы с такими же заголовками CallID, To, From и CSeq как и в запросе CANCEL
Переносит адресную информацию для регистрации пользователя на сервере определения
местоположения
Запрашивает информацию о функциональных
возможностях сервера
Переносит управляющую и др. информацию
для разговорной сессии по сигнальному тракту
Используется для надежной транспортировки
предварительных ответов
Служит для изменения параметров сессии до
прихода окончательного ответа (без воздействия на состояние диалога).

17.

SUBSCRIBE
NOTIFY
REFER
MESSAGE
Запрашивает информацию о текущем состоянии и информацию об обновлении состояния
удаленного ресурса
Сообщает подписчику текущее состояние ресурса и уведомляет о том, что запрашиваемое
событие произошло
Предписывает получателю связаться с третьей
стороной, используя контактную информацию,
которая содержится в сообщении
Переносит мгновенные текстовые сообщения
(instant massages)
Request-URI – это SIP или SIPS URI. Он указывает на пользователя или сервис, к которому адресован данный запрос. Поле
Request-URI не должно содержать пробелов и управляющих
символов, а также быть заключенным в угловые скобки «<>».
Элементы сети SIP могут поддерживать поля Request-URI со
схемами, отличными от «sip» и «sips», например «tel»; они в состоянии преобразовать не SIP URI с использованием любых доступных им механизмов. Результатом преобразования будет или
SIP URI, или SIPS URI, или другая схема.
Содержание полей То и Request-URI может быть различным, например, в поле То указан публичный адрес получателя, а
в Request-URI – адрес прокси-сервера, через который проходит
запрос.
Версия протокола. И запросы, и ответы содержат действующую версию SIP-протокола. Приложения, посылающие SIPсообщения, должны в поле SIP-Version указывать "SIP/2.0".
Назначение и формат ответов
Характерное отличие SIP-ответов от запросов – это наличие
строки состояния Status-Line в стартовой строке. Status-Line составляют: версия протокола и код ответа (Status-Code) со связанной с ним текстовой расшифровкой (Reason-Phrase), разде17

18.

ленные пробелом (SP). Символы возврата каретки (СR) и перевода строки (LF) могут использоваться только совместно в завершающей строку последовательности CRLF. Структура StatusLine приведена на рисунке 4.
Версия
протокола
Пробел
StatusСode
Пробел
ReasonPhrase
СRLF
Рисунок 4 – Структура Status-Line
Пример – SIP/2.0 200 OK
Код ответа – это целое трехзначное число, отражающее результат обработки запроса сервером. Reason-Phrase дает краткое
описание кода ответа и предназначена для визуального восприятия пользователем в отличие от Status-Code, который служит для
оповещения технических устройств. К формулировке ReasonPhrase не предъявляется жестких требований: фирмы производители в праве выбрать другой текст на произвольном национальном языке, указанном в поле заголовка Accept-Language запроса.
Первая цифра кода ответа определяет класс ответа. Оставшиеся две цифры носят дополнительный характер и служат для
упорядочивания кодов в пределах категории. В некоторых случаях оборудованию даже необязательно знать все коды ответов,
но оно обязательно должно интерпретировать первую цифру
ответа. После принятия и интерпретации запроса, адресат (прокси-сервер) передает ответ на полученный запрос.
Определено шесть классов ответов, которые несут различную функциональную нагрузку. Все ответы делятся на два типа:
информационные и окончательные.
Информационные ответы кодируются трехзначным числом,
начинающимся с единицы – 1хх.
Окончательные ответы кодируются трехзначными числами,
начинающимися с цифр 2, 3, 4, 5 и 6. Все они означают завершение обработки запроса, а каждый из них в отдельности – результат обработки запроса.
18

19.

Информационные или предварительные ответы (1xx). Информационные или предварительные ответы содержат информацию о том, что запрашиваемый сервер находится на стадии
выполнения действий по обработке запроса и не может в данный
момент выдать окончательный ответ. Сервер посылает ответ
класса 1хх, если он предполагает, что формирование окончательного запроса займет более 200 мс.
Предварительные ответы не требуют от клиента посылки
подтверждающего сообщения ACK; однако при поддержке обоими UA расширения функциональных возможностей «100rel»
возможна передача ответов класса 1хх с подтверждением
PRACK. Предварительные ответы могут содержать тело сообщения, содержащие описание сессий.
Ответы успешной обработки запроса (2xx). Ответы класса
2хх означают, что запрос был успешно обработан.
Ответы перенаправления вызова (3xx). Ответы класса 3хх
информируют оборудование вызывающего пользователя о новом местоположении вызываемого пользователя или об альтернативных сервисах, с помощью которых может быть обслужен
вызов пользователя.
Ответы ошибки в запросе (4xx). Ответы класса 4хх информируют о том, что в запросе обнаружена ошибка. После получения такого ответа пользователь не должен передавать тот же с амый запрос, на который получен ответ 4хх, без его модификации.
Ответы отказа сервера (5xx). Ответы класса 5хх информ ируют о том, что запрос не может быть обработан из-за ошибки
сервера.
Ответы полной невозможности установления соедин ения
(6xx). Передаваемый пользователем запрос не может обслужить
ни один сервер. Соединение с вызываемым пользователем установить невозможно.
Коды ответов представлены в таблице 3.
Таблица 3 – Коды ответов протокола SIP
19

20.

Код
ответа
1
100
180
181
182
200
202
300
301
302
Пояснение
Назначение
2
Trying
Ringing
3
Запрос обрабатывается
Местоположение вызываемого пользователя определено. Ему подается
посылка вызова
Call is being Прокси-сервер переадресует вызов к
forwarded
другому пользователю
Queued
Вызываемый пользователь временно
недоступен, но входящий вызов поставлен в очередь
ОК
Запрос успешно обработан
Accepted
Запрос был принят для обработки, но
обработка еще не завершена
Multiple
Вызываемый пользователь доступен
Choices
по нескольким адресам
Moved
Вызываемый пользователь больше не
Permanently находится по указанному в запросе
адресу
Moved
Вызываемый пользователь временно
Temporarily
изменил свое местоположение
Продолжение таблицы 3
20
1
380
2
Alternative
Service
400
Bad Request
404
Not Found
487
Temporarily
not available
3
Запрошенная услуга недоступна, но
доступны альтернативные варианты
обслуживания
В запросе обнаружена синтаксическая ошибка
Вызываемый пользователь не обнаружен
Запрос был сброшен сообщением
BYE или CANCEL

21.

500
502
600
604
Eternal
Ошибка сервера
Server Error
Bad Gateway Сервер принял некорректный ответ от
шлюза или прокси-сервера на пути к
адресату вызова
Busy
Вызываемый пользователь занят и не
Everywhere желает принимать вызов в данный
момент
Does not ex- Вызываемый абонент не существует
ist anywhere
Описание сеансов связи
При установлении соединений портам шлюзов, участвующим в этих соединениях, предоставляется необходимая информация друг о друге – описание сеансов связи. Описание сеанса
связи вводится в состав некоторых команд и ответов протокола
MGCP и включает в себя IP-адрес, UDP/RTP порт, вид информации, алгоритм кодирования информации, размер речевых пакетов и т. д. Синтаксис описания сеанса связи в протоколе
MGCP соответствует синтаксису протокола описания сеансов
связи – session description protocol (SDP).
Протокол SDP может применяться для описания мультимедийных конференций, но текущая версия протокола MGCP использует протокол SDP только для описания параметров передачи речи и данных.
Для описания такого сеанса речевой связи в протоколе SDP
предусмотрено несколько информационных полей:
– версия протокола SDP. Текущая версия протокола – нулевая. Поле кодируется следующим образом: v=0;
– IP-адрес шлюза. Это поле содержит IP-адрес, который б удет использоваться для обмена пакетами RTP. Если это поле
включено в команды протокола MGCP, то оно означает адрес
удаленного шлюза, если поле включено в ответы – адрес шлюза,
передающего ответ;
21

22.

– поле описания речевого канала. Данное поле содержит индикацию вида передаваемой или принимаемой информации (в
нашем случае - речи), номер порта, используемого для приема
RTP пакетов удаленным шлюзом (если поле описания речевого
канала включено в команды протокола MGCP) или локальным
шлюзом (если это поле включено в ответы), индикацию использования протокола RTP для передачи речи и алгоритмы кодирования речевой информации. Поле кодируется буквой «m»;
– режим соединения. Режимы соединений представлены в
таблице 4.
Таблица 4 – Режимы соединения
Кодировка
Функционирование шлюза
режима
sendonly Шлюзу надлежит только передавать информацию
recvonly Шлюзу надлежит только принимать информацию
sendrecv Шлюзу надлежит передавать и принимать
информацию
inactive
Шлюз не должен ни передавать, ни принимать
информацию
loopback Шлюз должен передавать принимаемую
информацию в обратном направлении
contest
Шлюзу надлежит перевести порт в режим
тестирования
Для описания сеанса речевой связи в протоколе SDP предусмотрено еще несколько необязательных информационных полей. Если в команду или в ответ протокола MGCP включены
описания нескольких сеансов связи, то они отделяются друг от
друга строкой с указанием версии протокола SDP. Пример описания сеанса речевой связи с использованием протокола SDP
приведен ниже:
v=0
с = IN IP4 128.96.41.1
22

23.

m = audio 3456 RTP/AVP 0
Для описания сеанса связи используется протокол SDP, версия 0, в сети используется протокол IP, версия 4, IP-адрес шлюза
– 128.96.41.1, передается или принимается речевая информация,
упакованная в пакеты RTP, номер порта RTP – 3456, алгоритм
кодирования речи PCMU.
Алгоритм кодирования:
– 0 – PCMU;
– 3 – GSM;
– 4 – G.723;
– 5 – DVI4.
В таблице 5 приведены параметры SDP и их описание.
Таблица 5 – Параметры SDP и их описание
Параметры
SDP
1
v (protocol
version)
o (owner/creator
and session identifier)
s (session name)
Описание
2
Версия протокола SDP. Пока – «0»
<username> <session id> <version> <network
type> <address type> <address> Информация
об инициаторе сессии: имя абонента, код
сессии, сколько раз уже в рамках сессии
встречался SDP , тип сети, тип адреса, сам
адрес
Имя сессии
Продолжение таблицы 5
1
i (session
information)
e (email address)
p (phone number)
2
Информация по сессии
Почтовый адрес для связи с ответственным
за проведение конференции
Телефонный номер для связи с ответствен23

24.

c (connection
information)
b (bandwidth
information)
t (time the session is active)
m (media name
and transport address)
a (zero or more
media attribute
lines)
a=rtpmap:
a=fmtp:Частный
случай 2
a=candidate
ным за проведение конференции
<network type> <address type> <connection
address> Куда следует пересылать трафик
медиа: тип сети, тип адреса, сам адрес
Максимальная возможная полоса пропускания
<start time> <stop time>
Время начала и окончания сессии. 0 означает отсутствие ограничений
<media> <port> <transport> <fmt list>
Тип медиа (аудио/видео), порт по которому
пересылать поток, транспортный протокол,
список поддерживаемых форматов (обычно–
кодеков)
a=<attribute>a=<attribute>:<value>
Ниже – несколько примеров
rtpmap:<payload type> <encoding
name>/<clock rate>[/<encoding parameters>]
Тип кодека, имя кодека / параметры кодека
(обычно – частота дискретизации в герцах)
<format> <format specific parameters>
Номер кодека, параметры формата. MS таким образом обозначает используемую полосу пропускания кодека
Куда переслать трафик медиа. Используется
когда нужно указать несколько возможных
вариантов
ЗАДАНИЯ ПО АНАЛИЗУ СООБЩЕНИЙ SIP
1 Произвести анализ сообщения:
INVITE sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
Max-Forwards: 70
From: <sip:[email protected];user=phone>;tag=76
24

25.

To: <sip:[email protected];user=phone>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 ngw1.a.loniis.ru
s=c=IN IP4 ngw1.a.loniis.ru
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
2 Произвести анализ сообщения:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/UDP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
Max-Forwards: 69
Record-Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 ngw1.a.loniis.ru
s=c=IN IP4 ngw1.a.loniis.ru
t=0 0
m=audio 3456 RTP/AVP 0
25

26.

a=rtpmap:0 PCMU/8000
3 Произвести анализ сообщения:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/UDP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>
Call-ID: [email protected]
CSeq: 1 INVITE
Content-Length: 0
4 Произвести анализ сообщения:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/UDP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
Record-Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Length: 0
5 Произвести анализ сообщения:
SIP/2.0 200 OK
Via: SIP/2.0/UDP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/UDP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
Record-Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=76
26

27.

To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
Contact: <sip:[email protected]>
CSeq: 1 INVITE
Content-Type: application/sdp
Content-Length: 151
v=0
o=Anton 2890844527 2890844527 IN IP4 client.b.loniis.ru
s=c=IN IP4 client.b.loniis.ru
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
6 Произвести анализ сообщения:
SIP/2.0 200 OK
Via: SIP/2.0/UDP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
Record-Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 151
v=0
o=Anton 2890844527 2890844527 IN IP4 client.b.loniis.ru
s=c=IN IP4 client.b.loniis.ru
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
27

28.

7 Произвести анализ сообщения:
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
Max-Forwards: 70
Route: sip:ss1.a.loniis.ru;lr
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 ACK
Content-Length: 0
8 Произвести анализ сообщения:
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/UDP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
Max-Forwards: 69
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 ACK
Content-Length: 0
9 Произвести анализ сообщения:
BYE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
Max-Forwards: 70
Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 2 BYE
Content-Length: 0
10 Произвести анализ сообщения:
BYE sip:[email protected] SIP/2.0
28

29.

Via: SIP/2.0/UDP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/UDP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
Max-Forwards: 69
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 2 BYE
Content-Length: 0
11 Произвести анализ сообщения:
SIP/2.0 200 OK
Via: SIP/2.0/UDP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/UDP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
From:
<sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 2 BYE
Content-Length: 0
12 Произвести анализ сообщения:
SIP/2.0 200 OK
Via: SIP/2.0/UDP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 2 BYE
Content-Length: 0
13 Произвести анализ сообщения:
INVITE sip:[email protected];user=phone SIP/2.0
29

30.

Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
Max-Forwards: 70
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected];transport=tcp>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 ngw1.a.loniis.ru
s=c=IN IP4 ngw1.a.loniis.ru
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
14 Произвести анализ сообщения:
INVITE [email protected] SIP/2.0
Via: SIP/2.0/TCP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
Max-Forwards: 69
Record-Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected];transport=tcp>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 ngw1.a.loniis.ru
s=30

31.

c=IN IP4 ngw1.a.loniis.ru
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
15 Произвести анализ сообщения:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.201
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>
Call-ID: [email protected]
CSeq: 1 INVITE
Content-Length: 0
16 Произвести анализ сообщения:
SIP/2.0 200 OK
Via: SIP/2.0/TCP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
Record-Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected];transport=tcp>
Content-Type: application/sdp
Content-Length: 151
v=0
o=Anton 2890844527 2890844527 IN IP4 client.b.loniis.ru
s=c=IN IP4 client.b.loniis.ru
t=0 0
m=audio 3456 RTP/AVP 0
31

32.

a=rtpmap:0 PCMU/8000
17 Произвести анализ сообщения:
SIP/2.0 200 OK
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
Record-Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected];transport=tcp>
Content-Type: application/sdp
Content-Length: 151
v=0
o=Anton 2890844527 2890844527 IN IP4 client.b.loniis.ru
s=c=IN IP4 client.b.loniis.ru
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
18 Произвести анализ сообщения:
ACK [email protected] SIP/2.0
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
Max-Forwards: 70
Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 ACK
Content-Length: 0
19 Произвести анализ сообщения:
ACK [email protected] SIP/2.0
32

33.

Via: SIP/2.0/TCP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=130.131.132.14
Max-Forwards: 69
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 ACK
Content-Length: 0
20 Произвести анализ сообщения:
BYE sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
Max-Forwards: 70
Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 2 BYE
Content-Length: 0
21 Произвести анализ сообщения:
BYE sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
Max-Forwards: 69
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 2 BYE
Content-Length: 0
22 Произвести анализ сообщения:
SIP/2.0 200 O
Via: SIP/2.0/TCP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
33

34.

Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 2 BYE
Content-Length: 0
23 Произвести анализ сообщения:
SIP/2.0 200 OK
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 2 BYE
Content-Length: 0
24 Произвести анализ сообщения:
INVITE sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP gw1.a.loniis.ru:5060;branch=z9hG4bKwqwee65
Max-Forwards: 70
From: <sip:[email protected];user=phone>;tag=jwdkallkzm
To: <sip:[email protected];user=phone>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected];user=phone>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 ngw1.a.loniis.ru
s=c=IN IP4 gw1.a.loniis.ru
t=0 0
m=audio 3456 RTP/AVP 0
34

35.

a=rtpmap:0 PCMU/8000
25 Произвести анализ сообщения:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/UDP gw1.a.loniis.ru:5060;branch=z9hG4bKwqwee65
;received=192.0.2.201
Max-Forwards: 69
Record-Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=jwdkallkzm
To: sip:[email protected];user=phone
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected];user=phone>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 gw1.a.loniis.ru
s=c=IN IP4 gw1.a.loniis.ru
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
27 Произвести анализ сообщения:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.201
From: <sip:[email protected];user=phone>;tag=jwdkallkzm
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 INVITE
Content-Length: 0
27 Произвести анализ сообщения:
35

36.

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/UDP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.201
Record-Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=jwdkallkzm
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Length: 0
28 Произвести анализ сообщения:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP gw1.a.loniis.ru:5060;branch=z9hG4bKwqwee65
;received=192.0.2.201
Record-Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=jwdkallkzm
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Length: 0
29 Произвести анализ сообщения:
SIP/2.0 200 OK
Via: SIP/2.0/UDP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/UDP gw1.a.loniis.ru:5060;branch=z9hG4bKwqwee65
;received=192.0.2.201
Record-Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=jwdkallkzm
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
Contact: <sip:[email protected]>
36

37.

CSeq: 1 INVITE
Content-Type: application/sdp
Content-Length: 151
v=0
o=Anton 2890844527 2890844527 IN IP4 client.b.loniis.ru
s=c=IN IP4 client.b.loniis.ru
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
30 Произвести анализ сообщения:
SIP/2.0 200 OK
Via: SIP/2.0/UDP gw1.a.loniis.ru:5060;branch=z9hG4bKwqwee65
;received=192.0.2.201
Record-Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=jwdkallkzm
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
Content-Type: application/sdp
Content-Length: 151
v=0
o=Anton 2890844527 2890844527 IN IP4 client.b.loniis.ru
s=c=IN IP4 client.b.loniis.ru
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
31 Произвести анализ сообщения:
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP gw1.a.loniis.ru:5060;branch=z9hG4bKwqwee65
37

38.

Max-Forwards: 70
Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=jwdkallkzm
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 ACK
Content-Length: 0
32 Произвести анализ сообщения:
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/UDP gw1.a.loniis.ru:5060;branch=z9hG4bKwqwee65
;received=192.0.2.201
Max-Forwards: 69
From: <sip:[email protected];user=phone>;tag=jwdkallkzm
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 ACK
Content-Length: 0
33 Произвести анализ сообщения:
BYE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP gw1.a.loniis.ru:5060;branch=z9hG4bKwqwee65
Max-Forwards: 70
Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=jwdkallkzm
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 2 BYE
Content-Length: 0
34 Произвести анализ сообщения:
BYE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/UDP gw1.a.loniis.ru:5060;branch=z9hG4bKwqwee65
;received=192.0.2.201
Max-Forwards: 69
38

39.

To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 2 BYE
Content-Length: 0
35 Произвести анализ сообщения:
SIP/2.0 200 OK
Via: SIP/2.0/UDP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/UDP gw1.a.loniis.ru:5060;branch=z9hG4bKwqwee65
;received=192.0.2.201
From: <sip:[email protected];user=phone>;tag=jwdkallkzm
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 2 BYE
Content-Length: 0
36 Произвести анализ сообщения:
SIP/2.0 200 OK
Via: SIP/2.0/UDP gw1.a.loniis.ru:5060;branch=z9hG4bKwqwee65
;received=192.0.2.201
From: <sip:[email protected];user=phone>;tag=jwdkallkzm
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 2 BYE
Content-Length: 0
37 Произвести анализ сообщения:
INVITE sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
Max-Forwards: 70
From: <sip:[email protected];user=phone>;tag=076
To: <sip:[email protected];user=phone>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact:
39

40.

<sip:[email protected];user=phone;transport=tcp>
Content-Type: application/sdp
Content-Length: 144
v=0
o=GW 2890844527 2890844527 IN IP4 gw1.a.loniis.ru
s=c=IN IP4 gw1.a.loniis.ru
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
38 Произвести анализ сообщения:
SIP/2.0 604 Does Not Exist Anywhere
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.201
From: <sip:[email protected];user=phone>;tag=076
To: <sip:[email protected];user=phone>;tag=6a34d4
Call-ID: [email protected]
CSeq: 1 INVITE
Error-Info: sip:[email protected]
Content-Length: 0
39 Произвести анализ сообщения:
ACK sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
Max-Forwards: 70
From: <sip:[email protected];user=phone>;tag=076
To: <sip:[email protected];user=phone>;tag=6a34d4
Call-ID: [email protected]
CSeq: 1 ACK
Content-Length: 0
40 Произвести анализ сообщения:
INVITE sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
40

41.

Max-Forwards: 70
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected];transport=tcp>
Content-Type: application/sdp
Content-Length: 144
v=0
o=GW 2890844527 2890844527 IN IP4 gw1.a.loniis.ru
s=c=IN IP4 gw1.a.loniis.ru
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
41 Произвести анализ сообщения:
INVITE [email protected] SIP/2.0
Via: SIP/2.0/TCP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.201
Max-Forwards: 69
Record-Route: sip:ss1.a.loniis.ru;lr
From: <sip:[email protected];user=phone>;tag=76
To: sip:[email protected];user=phone
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected];transport=tcp>
Content-Type: application/sdp
Content-Length: 144
v=0
o=GW 2890844527 2890844527 IN IP4 gw1.a.loniis.ru
s=c=IN IP4 gw1.a.loniis.ru
41

42.

t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
42 Произвести анализ сообщения:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.201
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 INVITE
Content-Length: 0
43 Произвести анализ сообщения:
SIP/2.0 600 Busy Everywhere
Via: SIP/2.0/TCP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.201
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 INVITE
Content-Length: 0
44 Произвести анализ сообщения:
ACK [email protected] SIP/2.0
Via: SIP/2.0/TCP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
Max-Forwards: 70
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 ACK
Content-Length: 0
42

43.

45 Произвести анализ сообщения:
SIP/2.0 600 Busy Everywhere
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.201
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 INVITE
Content-Length: 0
46 Произвести анализ сообщения:
ACK [email protected] SIP/2.0
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
Max-Forwards: 70
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 ACK
Content-Length: 0
47 Произвести анализ сообщения:
INVITE sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
Max-Forwards: 70
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: sip:[email protected];transport=tcp
Content-Type: application/sdp
Content-Length: 146
43

44.

v=0
o=GW 2890844527 2890844527 IN IP4 ngw1.a.loniis.ru
s=c=IN IP4 ngw1.a.loniis.ru
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
48 Произвести анализ сообщения:
INVITE [email protected] SIP/2.0
Via: SIP/2.0/TCP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
Max-Forwards: 69
Record-Route: <sip:ss1.a.loniis.ru;lr>
From: <sip:[email protected];user=phone>;tag=76
To: sip:[email protected];user=phone
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected];transport=tcp>
Content-Type: application/sdp
Content-Length: 146
v=0
o=GW 2890844527 2890844527 IN IP4 ngw1.a.loniis.ru
s=c=IN IP4 ngw1.a.loniis.ru
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
49 Произвести анализ сообщения:
SIP/2.0 100 Trying
Via: SIP/2.0/TCP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
44

45.

;received=192.0.2.103
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>
Call-ID: [email protected]
CSeq: 1 INVITE
Content-Length: 0
50 Произвести анализ сообщения:
SIP/2.0 600 Busy Everywhere
Via: SIP/2.0/TCP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
;received=192.0.2.111
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 INVITE
Content-Length: 0
51 Произвести анализ сообщения:
ACK [email protected] SIP/2.0
Via: SIP/2.0/TCP ss1.a.loniis.ru:5060;branch=z9hG4bK2d4790.1
Max-Forwards: 70
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 ACK
Content-Length: 0
52 Произвести анализ сообщения:
SIP/2.0 600 Busy Everywhere
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
45

46.

CSeq: 1 INVITE
Content-Length: 0
53 Произвести анализ сообщения:
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
Max-Forwards: 70
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>;tag=314159
Call-ID: [email protected]
CSeq: 1 ACK
Content-Length: 0
54 Произвести анализ сообщения:
CANCEL sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
Max-Forwards: 70
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>
Call-ID: [email protected]
CSeq: 1 CANCEL
Content-Length: 0
55 Произвести анализ сообщения:
SIP/2.0 200 OK
Via: SIP/2.0/UDP ngw1.a.loniis.ru:5060;branch=z9hG4bKlueha2
;received=192.0.2.103
From: <sip:[email protected];user=phone>;tag=76
To: <sip:[email protected];user=phone>
Call-ID: [email protected]
CSeq: 1 CANCEL
Content-Length: 0
46

47.

СЦЕНАРИИ УСТАНОВЛЕНИЯ СОЕДИНЕНИЯ
Установление соединения с участием сервера
переадресации
Администратор сети сообщает пользователям адрес сервера
переадресации. Вызывающий пользователь передает запрос
INVITE (1) на известный ему адрес сервера переадресации (рисунок 5).
Рисунок 5 – Сценарий установления соединения через
сервер переадресации
Сервер переадресации запрашивает текущий адрес нужного
пользователя у сервера определения местоположения (2), который сообщает ему этот адрес (3). Сервер переадресации в ответе
302 Moved temporarily передает вызывающей стороне текущий
адрес вызываемого пользователя (4). Вызывающая сторона под47

48.

тверждает прием ответа 302 посылкой сообщения ACK (5). Теперь вызывающая сторона может связаться непосредственно с
вызываемой стороной. Для этого она передает новый запрос
INVITE (6). Вызываемая сторона принимает запрос INVITE и
начинает его обработку, о чем сообщает ответом 100 Trying (7).
После завершения обработки поступившего запроса оборудование вызываемой стороны сообщает своему пользователю о входящем вызове, а встречной стороне передает ответ 180 Ringing
(8). После приема вызываемым пользователем входящего вызова
удаленной стороне передается сообщение 200 ОК (9). Терминал
вызывающего пользователя подтверждает прием ответа запросом АСК (10). По завершении разговорной фазы любой из
сторон передается запрос BYE (11), который подтверждается
ответом 200 ОК (12).
Установление соединения с участием прокси-сервера
Администратор сети сообщает адрес этого сервера пользователям (рисунок 6).
48

49.

Рисунок 24 – Сценарий установления соединения через
прокси-сервер
Вызывающий пользователь передает запрос INVITE (1). В
запросе пользователь указывает известный ему адрес вызываемого пользователя. Прокси-сервер запрашивает текущий адрес
вызываемого пользователя у сервера определения местоположения (2), который и сообщает ему этот адрес (3). Далее проксисервер передает запрос INVITE непосредственно вызываемому
оборудованию (4). После приема и обработки запроса вызываемое оборудование сообщает своему пользователю о входящем
вызове, а встречной стороне передает ответ 180 Ringing (5). После приема вызова пользователем встречной стороне передается
сообщение 200 ОК (6). Терминал вызывающего пользователя
подтверждает прием ответа запросом АСК (7). По завершении
разговорной фазы одной из сторон передается запрос BYE (8),
который подтверждается ответом 200 ОК (9).
Дополнительная услуга «Переадресация вызова»
Данная услуга позволяет пользователю назначить адрес, на
который, при определенных условиях, следует направлять входящие к нему вызовы. Оборудование пользователя, заказавшего
эту услугу, получив сообщение INVITE B, проверяет условия, в
которых оно получено, и если условия требуют переадресации,
передает сообщение INVITE с заголовком Also, указывая в нем
адрес пользователя, к которому следует направить вызов. Терминал вызывающего пользователя, получив сообщение INVITE
с таким заголовком, инициирует новый вызов по адресу, указанному в поле Also. В данном случае пользователь А вызывает
пользователя В, а терминал последнего переадресует вызов к
пользователю С (рисунок 7).
49

50.

Рисунок 7 – Дополнительная услуга «Переадресация вызова»
Неуспешное установление соединения. Линия занята
В данном сценарии абонент вызывает пользователя Bob через Узел 1 и Proxy1. Прокси-сервер находит пользователя Bob и
направляет ему вызов. Терминал пользователя Bob отклоняет
вызов, возвращая ответ с кодом 600 (Busy Everywhere).
Диаграмма обмена сообщениями при неуспешном установлении соединения представлена на рисунке 8.
50

51.

Рисунок 8 – Диаграмма обмена сообщениями при
неуспешном установлении соединения
51

52.

ЛИТЕРАТУРА
1 Гольдштейн, Б. С. Сети связи : учебник для вузов / Б. С.
Гольдшетейн, Н. А. Соколов, Г. Г. Яновский. – БХВ – СанктПетербург, 2010. – 460 с.
2 Кучерявый, А. Е. Пакетная сеть связи общего пользования/
А. Е Кучерявый, Л. З. Гильченок, А. Ю. Иванов. – СПб. : Наука
и техника, 2004. – 272 с.
3 Гольдштейн, Б. С. Протокол SIP : справочник по телекоммуникационным протоколам / Б. С. Гольдшетейн, А. А. Зарубин, В. В. Саморезов. – БХВ – Санкт-Петербург, 2005. – 510 с.
52

53.

СОДЕРЖАНИЕ
ПРИНЦИПЫ ПРОТОКОЛА SIP ............................................ 3
СТРУКТУРА СООБЩЕНИЙ ПРОТОКОЛА SIP ................. 6
Типы заголовков .................................................................. 8
Назначение и формат запросов......................................... 14
Назначение и формат ответов ........................................... 17
Описание сеансов связи .................................................... 21
ЗАДАНИЯ ПО АНАЛИЗУ СООБЩЕНИЙ SIP .................. 24
СЦЕНАРИИ УСТАНОВЛЕНИЯ СОЕДИНЕНИЯ.............. 47
Установление соединения с участием сервера
переадресации .................................................................... 47
Установление соединения с участием прокси-сервера .. 48
Дополнительная услуга «Переадресация вызова».......... 49
Неуспешное установление соединения. Линия занята .. 50
ЛИТЕРАТУРА........................................................................ 52
53

54.

Учебное издание
ПРОТОКОЛ ИНИЦИИРОВАНИЯ СЕАНСОВ
СВЯЗИ SIP
ПО ДИСЦИПЛИНЕ
«СИГНАЛИЗАЦИЯ В ТЕЛЕКОММУНИКАЦИЯХ»
Методические указания к выполнению практических
занятий для
для студентов дневного обучения специальности
1-45 01 03 – Сети телекоммуникаций
Составитель:
Ленковец Екатерина Александровна
Редактор О. С. Кипнис
Компьютерная верстка Е. А. Ленковец
План 2013/2014 уч.г., поз.
Подписано в печать 31.01.2014. Формат 60*84/16.
Бумага офсетная. Гарнитура «Times».
Печать цифровая.
Усл. печ. л. 3,66. Уч.-изд. л. 3,5.
Тираж 120 экз. Заказ 106.
Издатель и полиграфическое исполнение:
54

55.

учреждение образования
«Высший государственный колледж связи»
ЛИ № 02330/622 от 03.11.2011.
Ул. Ф. Скорины, 8/2, 220114, Минск
55
English     Русский Правила