SIP-телефония.

Данная статья будет посвящена одному из основных протоколов IP телефонии – SIP (Session Initiation Protocol - протокол установления сеанса), разработанный одним из отделений IETF - MMUSIC (Multiparty Multimedia Session Control). Описывается в спецификации RFC 2543 и RFC 3261.

SIP – это протокол прикладного уровня модели OSI, описывающий способы и правила установления интернет-сессий для обмена мультимедийной информацией, такой как: звук, голос, видеоряд, графика и др. Для соединения обычно используется порт 5060 или 5061. В качестве транспортных протоколов SIP поддерживает: UDP, TCP, SCTP, TLS . Протокол SIP широко применяется в офисной IP-телефонии , видео и аудио-конференциях, он-лайн играх и др.

Элементы

Протокол SIP имеет клиент-серверную модель. Основными функциональными элементами являются:

• Абонентский терминал . Устройство, с помощью которого абонент управляет установлением и завершением звонков. Может быть реализован как аппаратно (SIP-телефон), так и программно (Софтфон).
• Прокси-сервер . Устройство, которое принимает и обрабатывает запросы от терминалов, выполняя соответствующие этим запросам действия. Прокси-сервер состоит из клиентской и серверной частей, поэтому может принимать вызовы, инициировать запросы и возвращать ответы.
• Сервер переадресации . Устройство, хранящее записи о текущем местоположении всех имеющихся в сети терминалах и прокси-серверах. Сервер переадресации не управляет вызовами и не генерирует собственные запросы.
• Сервер определения местоположения пользователей . Представляет собой базу данных адресной информации. Необходим для обеспечения персональной мобильности пользователей.

Важные преимущества

Так как группа MMUSIC разрабатывала протокол SIP с учётом недостатков предшествующего ему H.323 , то SIP обзавелся следующими достоинствами:

1. Простота

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

2. Масштабируемость

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

3. Мобильность

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

4. Расширяемость

При появлении новый услуг существует возможность дополнят протокол SIP новыми функциями.

5. Взаимодействие с другими протоколами сигнализации

Имеется возможность использования протокола SIP с протоколами сигнализации сетей ТфОП, такими как DSS-1 и ОКС7.

Типы запросов

Для организации простейшего вызова в протоколе SIP, предусмотрено 6 типов информационных запросов:

• INVITE - Инициирует вызов от одного терминала к другому. Содержит описание поддерживаемых сервисов (которые могут быть использованы инициатором сеанса), а также виды сервисов, которые желает передавать инициатор;
• ACK -Подтверждение установления соединения адресатом. Содержит окончательные параметры сеанса связи, выбранные для установления сеанса связи;
• Cancel - Отмена ранее переданных неактуальных запросов;
• BYE - Запрос на завершение соединения;
• Register - Идентификация местоположения пользователя;
• OPTIONS - Запрос на информацию о функциональных возможностях терминала, обычно посылается до фактического начала обмена сообщениями INVITE, ACK;

SIP - ответы

Определено 6 типов ответов, которым прокси-сервер описывает состояние соединения, например: подтверждение установления соединения, передача запрошенной информации, сведения о неисправностях др.

1. 1хх - Информационные ответы;

Информационные ответы сообщают о ходе выполнения запроса и не являются его завершением. Остальные же классы ответов завершают выполнение запроса.

2. 2хх - Успешное окончание запроса;
3. 3хх - Информация об изменения местоположения вызываемого абонента;
4. 4хх - Информация об ошибке;
5. 5хх - Информация об ошибке на сервере;
6. 6хх - Информация о невозможности вызова абонента (пользователь с таким адресом не зарегистрирован, или пользователь занят).

В следующей статье мы рассмотрим основные сценарии , а также его модификации и дополнительные функции.

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

Нам жаль, что статья не была полезна для вас:(Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

SIP расшифровывается как Session Initiation Protocol - протокол инициирования сеанса, это протокол, разработанный IETF для VOIP и для других сеансов передачи текста или мультимедиа данных, например, таких как, системы обмена мгновенными сообщениями, видео, игры в реальном времени и другие сервисы.

SIP - это протокол, использующий текстовые сообщения, в которых используется кодировка UTF-8. SIP использует номер порта 5060, как для коммуникации по протоколу UDP, так и для TCP. Для SIP могут использоваться другие .
Протокол SIP предлагает все, потенциально востребованные возможности, используемые в Интернет технологиях, такие как:
передача вызовов или мультимедийных данных конференцсвязь удержание вызовов
Вследствии того, что SIP - это довольно гибкий протокол, есть возможность расширения его возможностей с сохранением обратной совместимости.

Также, протокол SIP может преодолевать ограничение, связанные с использованием NAT или файрволов. (Обратите внимание на раздел: NAT and VOIP)

Протокол SIP

Принципы протокола SIP

Протокол инициирования сеансов – Session Initiation Protocol (SIP) является протоколом прикладного уровня и предназначается для организации, модификации и завершения сеансов связи: мультимедийных конференций, телефонных соединений и распределения мультимедийной информации. Пользователи могут принимать участие в существующих сеансах связи, приглашать других пользователей и быть приглашенными ими к новому сеансу связи. Приглашения могут быть адресованы определенному пользователю, группе пользователей или всем пользователям.

Протокол SIP разработан группой MMUSIC (Multiparty Multimedia Session Control) комитета IETF (Internet Engineering Task Force), а спецификации протокола представлены в документе RFC 2543]. В основу протокола рабочая группа MMUSIC заложила следующие принципы:

Персональная мобильность пользователей. Пользователи могут перемещаться без ограничений в пределах сети, поэтому услуги связи должны предоставляться им в любом месте этой сети. Пользователю присваивается уникальный идентификатор, а сеть предоставляет ему услуги связи вне зависимости от того, где он находится. Для этого пользователь с помощью специального сообщения – – информирует о своих перемещениях .
Масштабируемость сети. Она характеризуется, в первую очередь, возможностью увеличения количества элементов сети при её расширении. Серверная структура сети, построенной на базе протокола SIP, в полной мере отвечает этому требованию.
Расширяемость протокола. Она характеризуется возможностью дополнения протокола новыми функциями при введении новых услуг и его адаптации к работе с различными приложениями.
В качестве примера можно привести ситуацию, когда протокол SIP используется для установления соединения между шлюзами, взаимодействующими с ТфОП при помощи сигнализации ОКС7 или DSS1.
В настоящее время SIP не поддерживает прозрачную передачу сигнальной информации телефонных систем сигнализации. Вследствие этого дополнительные услуги ISDN оказываются недоступными для пользователей IP-сетей.

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

Для расширения возможностей протокола SIP могут быть также добавлены и новые типы сообщений.

Интеграция в стек существующих протоколов Интернет, разработанных IETF. Протокол SIP является частью глобальной архитектуры мультимедиа, разработанной комитетом Internet Engineering Task Force IETF. Эта архитектура включает в себя также протокол резервирования ресурсов (Resource Reservation Protocol – RSVP, RFC 2205), (Real,Time Transport Pro,tocol – RTP, RFC 1889), протокол передачи потоковой информации в реальном времени (Real,Time Streaming Protocol – RTSP, RFC 2326),
(Session Description Protocol – SDP, RFC 2327). Однако функции протокола SIP не зависят ни от одного из этих протоколов.

Взаимодействие с другими протоколами сигнализации. Протокол SIP может быть использован совместно с протоколом Н.323. Возможно также взаимодействие протокола SIP с системами сигнализации ТфОП – DSS1 и ОКС7. Для упрощения такого взаимодействия сигнальные сообщения протокола SIP могут переносить не только специфический SIP адрес, но и телефонный номер формата Е.164 или любого другого формата. Кроме того, протокол SIP, наравне с протоколами H.323 и ISUP/IP, может применяться для синхронизации работы устройств управления шлюзами; в этом случае он должен взаимодействовать с протоколом MGCP. Другой важной особенностью протокола SIP является то, что он приспособлен к организации доступа пользователей сетей IP телефонии к услугам интеллектуальных сетей, и существует мнение, что именно этот протокол станет основным при организации связи между указанными сетями.

Методы SIP протокола, определенные в SIP RFC.

В протоколе SIP определено несколько методов, используемых при коммуникации.

Месяц назад я начал свое знакомство с IP-телефонией, а именно с Lync и Asterisk. И заметил следующую картину: в сети очень много интересных статей по практической стороне вопроса (как и что делать) и очень мало внимания уделено теории (в конце статьи приведены ссылки). Если Вы хотите разобраться с SIP, то извольте либо читать RFC 3261, либо одну из «этих толстых книг». Это, естественно, полезно, но многим хочется в начале изучить некую выжимку, а уж потом бросаться в омут с головой. Эта статья как раз для таких людей.

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

Простое взаимодействие клиентов

Взаимодействие клиентов в рамках SIP чаще всего осуществляется в виде диалога.

Диалог – это равноправное взаимодействие двух User Agent (UA) в виде последовательности SIP-сообщений между ними. При этом, существуют запросы, не образующие диалогов. Однако обо всем по-порядку.

Ниже приведен пример простого взаимодействия между двумя устройствами с поддержкой SIP:

Петр хочет начать обмен сообщениями с Иваном, для этого он посылает INVITE-сообщение с данными о типе сессии (простая, мультимедиа и т.д.). Сообщения имеют следующий формат: стартовая строка, одно или несколько полей заголовка, пустая строка, обозначающая конец полей заголовка и необязательное тело сообщения.

Стартовая строка содержит метод, Request-URI и версию SIP (актуальная – 2.0). Request-URI – это SIP-адрес ресурса, которому посылается запрос.

Поля заголовков имеют следующий формат: <Заголовок>: <Значение> <Перевод строки>

Первая строка начинается с заголовка Via. Каждое SIP-устройство, создающее или пересылающее сообщение, добавляет свой адрес в поле Via (как это происходит, я планирую показать в следующей части статьи). Обычно адрес представляет собой имя хоста, которое может быть разрешено с помощью DNS-запроса. Поле Via содержит версию SIP, знак “/”, пробел, транспортный протокол (UDP, TCP, TLS, SCTP), двоеточие, номер порта и branch – идентификатор транзакции. Ответы на этот запрос будут содержать такой же номер транзакции.

Чаще всего, значение branch начинается с “z9hG4bK”. Это значит, что запрос был сгенерирован клиентом, поддерживающим RFC 3261 и параметр уникален для каждой транзакции этого клиента.

Следующее поле, Max-Forwards, содержит относительно большое целое число. Каждый сервер SIP, который пересылает сообщение, уменьшает это число на единицу. Данное поле обеспечивает простой механизм обнаружение петель (loop).

Следом идут поля From и To, которые описывают отправителя и получателя запроса. Важно, что SIP-запросы маршрутизируются исходя из Request-URI, указанного в стартовой строке (см. выше). Это объясняется тем, что поля From и To могут быть изменены при пересылке. Если используется отображаемое имя (например, Ivan Ivanov), то SIP URI помещается внутрь пары угловых скобок. Параметр tag в поле From генерирует отправляющая сторона. В свою очередь принимающая сторона поместит свой tag в поле To.

Поле Call-ID – идентификатор вызова. Совокупность tag’ов из полей From и To и Call-ID однозначно идентифицируют данный диалог. Это необходимо, так как между клиентами может идти сразу несколько диалогов.

Следующее поле, Cseq, содержит порядковый номер запроса и название метода. В данном случае – INVTITE. Номер увеличивается с каждым новым запросом.

Поля Via, Max-Forwards, To, From, Call-ID и CSeq составляют минимальный необходимый набор полей заголовков SIP-сообщения.

Для сообщения INVITE также необходимо поле заголовка Contact, в котором содержится SIP URI, относящийся к коммуникационному устройству отправляющей стороны. Это поле используется, чтобы из всех устройств, которыми одновременно может пользоваться Петр, ответ был отправлен именно на данное устройство. Обратите внимание на значения полей From и Contact. Первый раз я не заметил разницу:

В сообщении присутствует опциональное поле Subject, то есть тема сообщения. Некоторые SIP-клиенты могут выводить значение этого поля на экран. Для маршрутизации и идентификации диалога поле не используется и может быть произвольным.

Поля Content-Type и Content-Length отвечают за описание тела сообщения. В данном случае будет использоваться Session Description Protocol (SDP). Размер сообщения вычисляется с учетом символов перевода строки:

Детальное описание работы протокола SDP заслуживает отдельной статьи, поэтому ниже приведена только краткая расшифровка:

В ответ на INVITE SIP-клиент Ивана отправляет два сообщения: 180 Ringing и 200 OK. Первое сообщает, что на стороне Ивана SIP-клиент подает звуковой сигнал звонка, второе – подтверждает установку диалога. Разберемся с каждым из них.

Так будет выглядеть сообщение 180 Ringing:

Бледным выделен текст, который не изменился по сравнению с сообщением INVITE.

Обратите внимание на поля заголовков To и From. Несмотря на то, что данное сообщение идет со стороны Ивана, значения полей остаются такими же, как были в первоначальном запросе (от Петра к Ивану). Это объясняется тем, что данные поля определяют направление запроса, а не сообщения.

Строка Via также перекочевала из исходного запроса, в конце строки добавлен параметр received этот параметр содержит IP-адрес, с которого пришел запрос. Обычно это адрес, который может быть получен путем разрешения URI, содержащегося в Via.

Наконец, в поле Contact содержится актуальный адрес Ивана.

Так выглядит сообщение 200 ОК, которое отправил SIP-клиент Ивана:

Думаю, смысл всех полей, относящихся к протоколу SIP теперь ясен.

В ответ на 200 ОК клиент Петра отправляет подтверждение:

Данное сообщение подтверждает, что клиента Петра успешно получил ответ от клиента Ивана. Оба клиента договорились о параметрах меди-сессии, которая будет осуществляться по протоколу RTP.

Обратите внимание, что номер последовательности CSeq все еще равен единице, но в качестве метода уже стоит ACK. Параметр Branch в поле Via содержит новый идентификатор транзакции, так как ACK, отправляемый в ответ на 200 OK считает новой транзакцией.

Теперь давайте рассмотрим, как происходит завершение медиа-сессии. Клиент Петра посылает BYE-запрос для завершение сессии:

Получив запрос на завершение сессии, клиент Ивана посылает подтверждение:

Сессия завершена.

Мы рассмотрели простой вариант работы протокола SIP. Обратите внимание, что в разные моменты времени клиенты Ивана и Петра выступали то в роли сервера, то в роли клиента, поэтому во всех SIP-клиентах должна функционировать как серверная (User Agent Server или UAS), так и клиентская часть (User Agent Client или UAC).

В следующей статье я планирую рассмотреть взаимодействие клиентов SIP с использованием Proxy-сервера и регистрацию клиентов на Proxy-сервере.

В данном разделе приведено описание Протокола инициирования сеансов связи - SIP, его принципы, адресация, архитектура, приведено сравнение с протоколом H323. За основу взята 7 глава книги Б.С. Гольдштейн IP-Телефония .

Сообщения протокола SIP

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

Запросы SIP

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

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

Запрос АСК подтверждает прием ответа на запрос INVITE. Следует отметить, что запрос АСК используется только совместно с запросом INVITE, т.е. этим сообщением оборудование вызывающего пользователя показывает, что оно получило окончательный ответ на свой запрос INVITE. В сообщении АСК может содержаться окончательное описание сеанса связи, передаваемое вызывающим пользователем.

Запрос CANCEL отменяет обработку ранее переданных запросов с теми же, что и в запросе CANCEL, значениями полей Call-ID, To, From и CSeq, но не влияет на те запросы, обработка которых уже завершена. Например, запрос CANCEL применяется тогда, когда прокси-сервер размножает запросы для поиска пользователя по нескольким направлениям и в одном из них его находит. Обработку запросов, разосланных во всех остальных направлениях, сервер отменяет при помощи сообщения CANCEL.

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

При помощи запроса типа REGISTER пользователь сообщает свое текущее местоположение. В этом сообщении содержатся следующие поля:

• Поле То содержит адресную информацию, которую надо сохранить или модифицировать на сервере;
• Поле From содержит адрес инициатора регистрации. Зарегистрировать пользователя может либо он сам, либо другое лицо, например, секретарь может зарегистрировать своего начальника;
• Поле Contact содержит новый адрес пользователя, по которому должны передаваться все дальнейшие запросы INVITE. Если в запросе REGISTER поле Contact отсутствует, то регистрация остается прежней. В случае отмены регистрации здесь помещается символ;
• В поле Expires указывается время в секундах, в течение которого регистрация действительна. Если данное поле отсутствует, то по умолчанию назначается время - 1 час, после чего регистрация отменяется. Регистрацию можно также отменить, передав сообщение REGISTER с полем Expires, которому присвоено значение О, и с соответствующим полем Contact.

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

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

• Для переноса сигнальных сообщений ТФОП/ISDN/сотовых сетей между шлюзами в течение разговорной сессии;
• Для переноса сигналов DTMF в течение разговорной сессии;
• Для переноса биллинговой информации.

Завершив описание запросов протокола SIР, рассмотрим, в качестве примера, типичный запрос типа INVITE (рис. 6). INVITE sip: [email protected] SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell To: T. Watson Call-ID: [email protected] Cseq: 1 INVITE Content-Type: application/sdp Content-Length: ... v=0 o=bell 53655765 2353687637 IN IР4 12&.3.4.5 C=IN IP4 kton.bell-tel.com m=audio 3456 RTP/AVP 0345

Рис. 6 Пример запроса INVITE

В этом примере пользователь Bell ([email protected]) вызывает пользователя Watson ([email protected]). Запрос передается к прокси-серверу (boston.bell-tel.com). В полях То и From перед адресом стоит запись, которую вызывающий пользователь желает вывести на дисплей вызываемого пользователя. В теле сообщения оборудование вызывающего пользователя указывает в формате протокола SDP, что оно может принимать в порту 3456 речевую информацию, упакованную в пакеты RTP и закодированную по одному из следующих алгоритмов кодирования: 0 - PCMU, 3 - GSM, 4 - G.723 и 5 - DVI4.

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

Таблица 3. Сжатые имена заголовков SIP

При написании имен заголовков в сжатом виде сообщение INVITE, показанное ранее на рисунке 6, будет выглядеть следующим образом (рис. 7): INVITE sip: [email protected] SIP/2.0 v: SIP/2.0/UDP kton.bell-tel.com f: A. Bell t: T. Watson i: [email protected] Cseq: 1 INVITE с: application/sdp l: ... v=0 o=bell 53655765 2353687637 IN IP4 128.3.4.5 C=IN IP4 kton.bell-tel.com m=audio 3456 RTP/AVP 0345

Рис. 7 Пример запроса INVITE с сокращенными заголовками

Таблица 4. Запросы SIP

Тип запроса	Описание запроса
INVITE	Приглашает пользователя к сеансу связи. Содержит SDP-описание сеанса
АСК	Подтверждает прием окончательного ответа на запрос INVITE
BYE	Завершает сеанс связи. Может быть передан любой из сторон, участвующих в сеансе
CANCEL	Отменяет обработку запросов с теми же заголовками Call-ID, То, From и CSeq, что и в самом запросе CANCEL
REGISTER	Переносит адресную информацию для регистрации пользователя на сервере определения местоположения
OPTION	Запрашивает информацию о функциональных возможностях терминала

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

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

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

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

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

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

• ответ 200 OK на запрос INVITE означает, что вызываемое оборудование согласно на участие в сеансе связи; в теле ответа указываются функциональные возможности этого оборудования;
• ответ 200 OK на запрос BYE означает завершение сеанса связи, в теле ответа никакой информации не содержится;
• ответ 200 OK на запрос CANCEL означает отмену поиска, в теле ответа никакой информации не содержится;
• ответ 200 OK на запрос REGISTER означает, что регистрация прошла успешно;
• ответ 200 OK на запрос OPTION служит для передачи сведений о функциональных возможностях оборудования, эти сведения содержатся в теле ответа.

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

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

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

• ответ 600 Busy Everywhere сообщает, что вызываемый пользователь занят и не может принять вызов в данный момент ни по одному из имеющихся у него адресов. Ответ может указывать время, подходящее для вызова пользователя;
• ответ 603 Decline означает , что вызываемый пользователь не может или не желает принять входящий вызов. В ответе может быть указано подходящее для вызова время;
• ответ 604 Does Not Exist Anywhere означает, что вызываемого пользователя не существует.

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

На рисунке 8 представлен пример ответа на запрос INVITE:

SIP/2.0 200 OK Via: SIP/2.0/UDP kton.bell-tel.соm From: A. Bell To: ; Call-ID: [email protected] Cseq: 1 INVITE Content-Type: application/sdp Content-Length: ... v=0 o=watson 4858949 4858949 IN IP4 192.1.2.3 t=3149329600 0 c=IN IP4 bostcon.bell-tel.com m=audio 5004 RTP/AVP 0 3 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000

Рис. 8 Пример SIP-ответа 200 OK

В этом примере приведен ответ пользователя Watson на приглашение принять участие в сеансе связи, полученное от пользователя Bell. Наиболее вероятный формат приглашения рассмотрен нами ранее (рис. 7). Вызываемая сторона информирует вызывающую о том, что она может принимать в порту 5004 речевую информацию, закодированную в соответствии с алгоритмами кодирования PCMU, GSM. Поля From, To, Via, Call-ID взяты из запроса, показанного на рисунке 7. Из примера видно, что это ответ на запрос INVITE с полем CSeq:1.

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

Таблица 5. Ответы на Запросы SIP

Код ответа	Пояснение	Назначение
100	Trying	Запрос обрабатывается, например, сервер обращается к базам данных, но местоположение вызываемого пользователя в настоящий момент не определено
180	Ringing	Местоположение вызываемого пользователя определено. Ему дается сигнал о входящем вызове
181	Call Is Being Forwarded	Прокси-сервер переадресует вызов к другому пользователю
182	Queued	Вызываемый пользователь временно не доступен, но входящий вызов поставлен в очередь. Когда вызываемый пользователь станет доступным, он передаст финальный ответ
200	OK	Команда успешно выполнена
300	Multiple Choices	Вызываемый пользователь доступен по нескольким адресам. Вызывающий пользователь может выбрать любой из них
301	Moved Permanently	Пользователь изменил свое местоположение, его новый адрес указан в поле Contact
302	Moved Temporarily	Пользователь временно изменил свое местоположение, его новый адрес указан в поле Contact
305	Use Proxy	Вызываемая сторона может принять входящий вызов только в том случае, когда он проходит через прокси-сервер. Вызывающей стороне рекомендуется обратиться к прокси-серверу, адрес которого указан в поле Contact. Ответ передается только терминальным оборудованием (UAS)
380	Alternative Service	Вызов не достиг адресата, но существует альтернативный вариант обслуживания, который указан в теле ответа. Например, вызов может быть переадресован к речевому почтовому ящику
400	Bad Bequest	В запросе обнаружена синтаксическая ошибка
401	Unauthorised	Требуется проведение процедуры авторизации пользователя
402	Payment Required	Требуется предварительная оплата услуг
403	Forbidden	Запрос не будет обслуживаться сервером и не должен передаваться повторно
404	Not Found	Сервер не обнаружил вызываемого пользователя в домене, указанном в поле Request-URI
405	Method Not Allowed	Не разрешается передавать запрос этого типа на адрес, указанный в поле Request-URI. В поле Allow ответа указываются разрешенные типы запросов
406	Not Acceptable	Ответы, генерируемые вызываемой стороной, не будут поняты вызывающей стороной
407	Proxy Authentication Required	Клиент должен подтвердить свое право доступа к прокси-серверу
408	Request Timeout	Сервер не может передать ответ, например, указать местоположение вызываемого пользователя, в течение промежутка времени, специфицированного в поле Expires запроса. Вызывающий пользователь может повторно передать запрос через некоторое время
409	Conflict	Обработка запроса REGISTER не может быть завершена из-за конфликта между действием, определенным в параметре action запроса, и текущим состоянием ресурсов
410	Gone	Сервер больше не имеет доступа к запрашиваемому ресурсу и не знает, куда переадресовать запрос
411	Length Required	Требуется указать длину тела сообщения в поле Content-Length
413	Request Entity Too Large	Размер запроса слишком велик для обработки
414	Request-URI Too Large	Адрес, указанный в поле Request-URI, оказался слишком большим, поэтому его интерпретация невозможна
415	Unsupported Media Type	Запрос содержит не поддерживаемый формат тела сообщения
420	Bad Extension	Сервер не понял расширение протокола, специфицированное в поле Require
480	Temporarily not available	Вызываемый пользователь временно недоступен
481	Call Beg/Transaction Does Not Exist	Посылается в ответ на получение запроса ВYЕ, не относящегося к текущим соединениям, или запроса CANCEL, не относящегося к текущим запросам
482	Loop Detected	Сервер обнаружил, что принятый им запрос передается по замкнутому маршруту (в поле Via уже имеется адрес этого сервера)
483	Too Many Hops	Сервер обнаружил в поле Via, что принятый им запрос прошел через большее количество прокси-сервером, чем разрешено в поле Max-Forwards
484	Address Incomplete	Сервер принял запрос с неполным адресом в поле То или Request-URI. Требуется дополнительная адресная информация
485	Ambiguous	Адрес вызываемого пользователя неоднозначен. В заголовке Contact ответа может содержаться список адресов, по которым этот запрос можно передать
486	Busy Here	В настоящий момент вызываемый пользователь не желает или не может принять вызов на этот адрес. Ответ не исключает возможности связаться с пользователем по другому адресу
500	Internal Server Error	Внутренняя ошибка сервера
501	Not Implemented	В сервере не реализованы функции, необходимые для обслуживания запроса. Ответ передается в том случае, когда сервер не может распознать тип полученного им запроса
502	Bad Gateway	Сервер, функционирующий в качестве шлюза или прокси-сервера, принимает некорректный ответ от сервера, к которому он направил запрос
503	Service Unavailable	Сервер не может в данный момент обслужить вызов вследствие перегрузки или проведения технического обслуживания
504	Gateway Timeout	Сервер, функционирующий в качестве шлюза или прокси-сервера, в течение установленного интервала времени не получил ответ от сервера (например, от сервера определения местоположения), к которому он обратился для завершения обработки запроса
505	SIP Version not supported	Сервер не поддерживает данную версию протокола SIP
600	Busy Everywhere	Вызываемый пользователь занят и не желает принимать вызов в данный момент. Ответ может указывать подходящее для вызова время
603	Decline	Вызываемый пользователь не может или не желает принимать входящие вызовы. В ответе может быть указано подходящее для вызова время
604	Does not exist anywhere	Вызываемого пользователя не существует
606	Not Acceptable	Вызываемый пользователь не может принять входящий вызов из-за того, что вид информации, указанный в описании сеанса связи в формате SDP, полоса пропускания и т.д. неприемлемы