SIP- сети
Резюмируя все сказанное выше, отметим, что сети SIP строятся из элементов трех основных типов: терминалов, прокси-серверов и серверов переадресации. На рис. 7.3 приведен пример возможного построения сети SIP.
Рис. 7.3 Пример построения сети SIP
Стоит обратить внимание на то что, что StP-серверы, представленные на рис. 7.3, являются отдельными функциональными сетевыми элементами. Физически они могут быть реализованы на базе серверов локальной сети, которые, помимо выполнения своих основных функций, будут также обрабатывать SIP-сообщения. Терминалы же могут быть двух типов: персональный компьютер со звуковой платой и программным обеспечением SIP-клиента (UA) или SIP-телефон, подключающийся не посредственно к ЛВС Ethernet <SIР-телефоны, производимые компанией Cisco Systems, недавно появились на российском рынке). Таким образом, пользователь локальной вычислительной сети передает все запросы к своему SlP-серверу, а тот обрабатывает их и обеспечивает установление соединений. Путем программирования сервер можно застроить на разные алгоритмы работы: он может обслуживать часть пользователей (например, руководство предприятия или особо важных лиц) по одним правилам, а другую часть - по иным. Возможно также, что сервер будет учитывать категорию и срочность вызовов, а также вести начисление платы за разговоры.
Структурная схема организации услуг SIP-сервера представлена на рисунке 7.4.
Рис. 7.4 Структурная схема организации услуг SIP-сервера
Модуль управления услугами отвечает за предоставление услуг и за общее управление сервером. Принятые сервером запросы и ответы поступают в модуль управления услугами и обрабатываются им, на основании чего определяется реакция на полученные сообщения. Интерфейс человек-машина позволяет гибко менять настройки сервера и вести мониторинг сети.
7.5 Сообщения протокола SIP
7.5.1 Структура сообщений
Согласно архитектуре “клиент-сервер” все сообщения делятся на запросы, передаваемые от клиента к серверу, и на ответы сервера клиенту.
Например, чтобы инициировать установление соединения, вызывающий пользователь должен сообщить серверу ряд параметров, в частности, адрес вызываемого пользователя, параметры информационных каналов и др. Эти параметры передаются в специальном SIP-запросе. От вызываемого пользователя к вызывающему передается ответ на запрос, также содержащий ряд параметров.
Все сообщения протокола SIP (запросы и ответы), представляют собой последовательности текстовых строк, закодированных в соответствии с документом RFC 2279. Структура и синтаксис сообщений SIP, как уже упоминалось ранее, идентичны используемым в протоколе HTTP. На рисунке 7.5 представлена структура сообщений протокола SIP.
|
Стартовая строка |
| Заголовки |
| Пустая строка |
| Тело сообщения |
Рис. 7.5 Структура сообщений протокола SIP
Стартовая строка представляет собой начальную строку любого SIP-сообщения. Если сообщение является запросом, в этой строке указываются тип запроса, адресат и номер версии протокола. Если сообщение является ответом на запрос, в стартовой строке указываются номер версии протокола, тип ответа и его короткая расшифровка, предназначенная только для пользователя.
Заголовки сообщений содержат сведения об отправителе, адресате, пути следования и др., в общем, переносят информацию, необходимую для обслуживания данного сообщения. О типе заголовка можно узнать по его имени. Оно не зависит от регистра (т.е. буквы могут быть прописные и строчные), но обычно имя пишут с большой буквы, за которой идут строчные.
Сообщения протокола SIP могут содержать так называемое тело сообщения. В запросах АСК, INVITE и OPTIONS тело сообщения содержит описание сеансов связи, например, в формате протокола SDP. Запрос BYE тела сообщения не содержит, а ситуация с запросом REGISTER подлежит дальнейшему изучению. С ответами дело обстоит иначе: любые ответы могут содержать тело сообщения, но содержимое тела в них бывает разным.
7.5.2 Заголовки сообщений
В протоколе SIP определено четыре вида заголовков (Таблица 7.1):
• Общие заголовки, присутствующие в запросах и ответах;
• Заголовки содержания, переносят информацию о размере тела сообщения или об источнике запроса (начинаются со слова “Content”);
• Заголовки запросов, передающие дополнительную информацию о запросе;
• Заголовки ответов, передающие дополнительную информацию об ответе.
Заголовок содержит название, за которым, отделенное двоеточием, следует значение заголовка. В поле значения содержатся передаваемые данные. Следует отметить, что если сервер принимает сообщения, заголовки которых ему не известны, то эти заголовки игнорируются.
Ниже представлены наиболее часто используемые заголовки.
Заголовок Call-ID - уникальный идентификатор сеанса связи или всех регистрации отдельного клиента, он подобен метке соединения (call reference) в сигнализации DSS-1 [7]. Значение идентификатору присваивает сторона, которая инициирует вызов. Заголовок Call-ID состоит из буквенно-числового значения и имени рабочей станции, которая присвоила значение этому идентификатору. Между ними должен стоять символ @, например, 2345call@rts.loniis.ru Возможна следующая ситуация: к одной мультимедийной конференции относятся несколько соединений, тогда все они будут иметь разные идентификаторы Call-ID.
Заголовок То - определяет адресата. Кроме SIP-адреса здесь может стоять параметр “tag” для идентификации конкретного терминала пользователя (например, домашнего, рабочего или сотового телефона) в том случае, когда все его терминалы зарегистрированы под одним адресом SIP URL. Запрос может множиться и достичь разных терминалов пользователя; чтобы их различать, необходимо иметь метку tag. Ее вставляет в заголовок терминальное оборудование вызванного пользователя при ответе на принятый запрос.
Если необходим визуальный вывод имени пользователя, например, на дисплей, то имя пользователя также размещается в поле То.
Заголовок From - идентифицирует отправителя запроса; по структуре аналогичен полю То.
Таблица 7.1 Виды заголовков сообщений SIP
| Общие заголовки | Заголовки содержания | Заголовки запросов | Заголовки ответов |
| Call-ID (идентификатор сеанса связи) | Content-Encoding (кодирование тела сообщения) | Accept (принимается) | Allow (разрешение) |
| Contact (контактировать) | Content-Length (размер тела сообщения) | Accent-Encoding (метод кодирования поддерживается) | Proxy-Authenticate (подтверждение подлинности прокси-сервера) |
| CSeq (последовательность) | Content-Type (тип содержимого) | Accent-Language (язык поддерживается) | Retro-After (повторить через некоторое время) |
| Date (Дата) | Authorization (авторизация) | Server (сервер) | |
| Encryption (шифрование) | Unsupported (не поддерживается) | ||
| Expires (срабатывание таймера) | Hide (скрыть) | Warning (предупреждение) | |
| From (источник запроса) | Max-Forwards (максимальное количество переадресаций) | VWVW-Authenticate (подтверждение подлинности WWW-сервера) | |
| Record-Route (запись маршрута) | Organization (организация) | ||
| Timestamp (метка времени) | Priority (приоритет) | ||
| То (Адресат) | Proxy-Authorization (авторизация прокси-сервера) | ||
| Via (через) | Proxy-Require (требуется прокси-сервер) | ||
| Route (маршрут) | |||
| Require (требуется) | |||
| Response-Key (ключ кодирования ответа) | |||
| Subject (тема) | |||
| User-Agent (агент пользователя) |
Заголовок CSeq - уникальный идентификатор запроса, относящегося к одному соединению. Он служит для корреляции запроса с ответом на него. Заголовок состоит из двух частей: натурального числа из диапазона от 1 до 232 и типа запроса. Сервер должен проверять значение CSeq в каждом принимаемом запросе и считать запрос новым, если значение CSeq больше предыдущего. Пример заголовка: CSeq: 2 INVITE.
Заголовок Via служит для того, чтобы избежать ситуации, в которых запрос пойдет по замкнутому пути, а также для тех случаев, когда необходимо, чтобы запросы и ответы обязательно проходили по одному и тому же пути (например, в случае использования межсетевого экрана - firewall). Дело в том, что запрос может проходить через несколько прокси-сервером, каждый из которых принимает, обрабатывает и переправляет запрос к следующему прокси-серверу, и так до тех пор, пока запрос не достигнет адресата. Таким образом, в заголовке Via указывается весь путь, пройденный запросом: каждый прокси-сервер добавляет поле со своим адресом. При необходимости (например, чтобы обеспечить секретность) действительный адрес может скрываться.
Например, запрос на своем пути обрабатывался двумя прок си-серверами: сначала сервером loniis.ru, потом sip.telecom.com. Тогда в запросе появятся следующие поля:
Via: SIP/2.0/UDP sip.telecom.com:5060;branch=721 e418c4.1 Via: SIP/2.0/UDP loniis.ru: 5060,
где параметр “branch” означает, что на сервере sip.telecom.com запрос был размножен и направлен одновременно по разным направлениям, и наш запрос был передан по направлению, которое идентифицируется следующим образом: 721е418c4.1.
Содержимое полей Via копируется из запросов в ответы на них, и каждый сервер, через который проходит ответ, удаляет поле Via со своим именем.
В заголовок Record-route прокси-сервер вписывает свой адрес - SIP URL, - если хочет, чтобы последующие запросы прошли через него.
Заголовок Content-Type определяет формат описания сеанса связи. Само описание сеанса, например, в формате протокола SDP, включается в тело сообщения.
Заголовок Content-Length указывает размер тела сообщения.
После того, как мы рассмотрели наиболее часто встречающиеся заголовки сообщений протокола SIP, следует обратить внимание на то, что запросы и ответы на них могут включать в себя лишь определенный набор заголовков (Таблица 7.2). Здесь опять буква “М” означает обязательное присутствие заголовка в сообщении, буква “О” -необязательное присутствие, буква “F” запрещает присутствие заголовка.
Таблица 7.2 Связь заголовков с запросами и ответами протокола SIPv2.Q
| Название заголовка | Место использования заголовка | АСК | BYE | CAN | INV | OPT | REG |
| Accept | Заголовок в запросах | F | F | F | 0 | 0 | 0 |
| Accept | Заголовок в ответе 415 | F | F | F | 0 | 0 | 0 |
| Accent-Encoding | Заголовок в запросах | F | F | F | 0 | 0 | 0 |
| Accent-Encoding | Заголовок в ответе 415 | F | F | F | 0 | 0 | 0 |
| Accent-Language | Заголовок в запросах | F | 0 | 0 | 0 | 0 | 0 |
| Accent-Language | Заголовок в ответе 415 | F | 0 | 0 | 0 | 0 | 0 |
| Allow | Заголовок в ответе 200 | F | F | F | F | М | F |
| Allow | Заголовок в ответе 405 | 0 | 0 | 0 | 0 | 0 | 0 |
| Authorization | Заголовок в запросах | 0 | 0 | 0 | 0 | 0 | 0 |
| Call-ID | Общий заголовок - копируется из запросов в ответы | М | М | М | М | М | М |
| Contact | Заголовок в запросах | 0 | F | F | 0 | 0 | 0 |
| Contact | Заголовок в ответах 1хх | F | F | F | 0 | 0 | F |
| Contact | Заголовок в ответах 2хх | F | F | F | 0 | 0 | 0 |
| Contact | Заголовок в ответах Зхх | F | 0 | F | 0 | 0 | 0 |
| Contact | Заголовок в ответе 485 | F | 0 | F | 0 | 0 | 0 |
| Content-Encoding | Заголовки содержания | 0 | F | F | 0 | 0 | 0 |
| Content-Length | Заголовки содержания | 0 | F | F | 0 | 0 | 0 |
| Content-Type | Заголовки содержания | * | F | F | * | * | * |
| Cseq | Общий заголовок - копируется из запросов в ответы | М | М | М | М | М | М |
| Date | Заголовок в ответах | 0 | 0 | 0 | 0 | 0 | 0 |
| Encryption | Заголовок в ответах | 0 | 0 | 0 | 0 | 0 | 0 |
| Expires | Заголовок в ответах | F | F | F | 0 | F | 0 |
| From | Общий заголовок - копируется из запросов в ответы | М | М | М | М | М | М |
| Hide | Заголовок в запросах | 0 | 0 | 0 | 0 | 0 | 0 |
| Max-Forwards | Заголовок в запросах | 0 | 0 | 0 | 0 | 0 | 0 |
| Organization | Общий заголовок | F | F | F | 0 | 0 | 0 |
| Proxy-Authenticate | Заголовок в ответе 407 | 0 | 0 | 0 | 0 | 0 | 0 |
| Proxy-Authorization | Заголовок в запросах | 0 | 0 | 0 | 0 | 0 | 0 |
| Proxy-Require | Заголовок в запросах | 0 | 0 | 0 | 0 | 0 | 0 |
| Priority | Заголовок в запросах | F | F | F | 0 | F | F |
| Require | Заголовок в запросах | 0 | 0 | 0 | 0 | 0 | 0 |
| Retry-After | Заголовок в запросах | F | F | F | P | F | 0 |
| Retry-After | Заголовок в ответах 404, 480, 486, 503, 600 и 603 | 0 | 0 | 0 | 0 | 0 | 0 |
| Response-Key | Заголовок в запросах | F | 0 | 0 | 0 | 0 | 0 |
| Record-Route | Заголовок в запросах | 0 | 0 | 0 | 0 | 0 | 0 |
| Record-Route | Заголовок в ответах 2хх | 0 | 0 | 0 | 0 | 0 | 0 |
| Route | Заголовок в запросах | 0 | 0 | 0 | 0 | 0 | 0 |
| Server | Заголовок в ответах | 0 | 0 | 0 | 0 | 0 | 0 |
| Subject | Заголовок в запросах | F | F | F | 0 | F | F |
| Timestamp | Общий заголовок | 0 | 0 | 0 | 0 | 0 | 0 |
| To | Общий заголовок - копируется из запросов в ответы | М | М | М | М | М | М |
| Unsupported | Заголовок в ответе 420 | 0 | 0 | 0 | 0 | 0 | 0 |
| User-Agent | Общий заголовок | 0 | 0 | 0 | 0 | 0 | 0 |
| Via | Общий заголовок - копируется из запросов в ответы | М | М | М | М | М | М |
| Warning | Заголовок в ответах | 0 | 0 | 0 | 0 | 0 | 0 |
| WWW-Authenticate | Заголовок в ответе 401 | 0 | 0 | 0 | 0 | 0 | 0 |
* Примечание - поле необходимо только в случае, когда тело сообщения содержит какую-либо информацию, т.е. не является пустым.
7.5.3 Запросы
В настоящей версии протокола SIP определено шесть типов запросов. Каждый из них предназначен для выполнения довольно широкого круга задач, что является явным достоинством протокола SIP, так как благодаря этому число сообщений, которыми обмениваются терминалы и серверы, сведено к минимуму. С помощью запросов клиент сообщает о текущем местоположении, приглашает пользователей принять участие в сеансах связи, модифицирует уже установленные сеансы, завершает их и т.д. Сервер определяет тип принятого запроса по названию, указанному в стартовой строке. В той же строке в поле Request-URI указан SIP-адрес оборудования, которому этот запрос адресован. Содержание полей То и Request-URI может различаться, например, в поле То может быть указан публикуемый адрес абонента, а в поле Request-URI - текущий адрес пользователя.
Запрос 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/coTOBbix сетей между шлюзами в течение разговорной сессии;
• для переноса сигналов DTMF в течение разговорной сессии;
• для переноса биллинговой информации.
Завершив описание запросов протокола SIР, рассмотрим, в качестве примера, типичный запрос типа INVITE (рис. 7.6).
INVITE sip: watson@boston.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell <sip: a.g.bell@bell-tel.com> To: T. Watson <sip: watson@bell-tel.com> Call-ID: 3298420296@kton.bell-tel.com 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
Рис. 7.6 Пример запроса INVITE
В этом примере пользователь Bell (a.g.bell@bell-tel.com) вызывает пользователя Watson (watson@bell-tel.com). Запрос передается к прокси-серверу (boston.bell-tel.com). В полях То и From перед адресом стоит запись, которую вызывающий пользователь желает вывести на дисплей вызываемого пользователя. В теле сообщения оборудование вызывающего пользователя указывает в формате протокола SDP, что оно может принимать в порту 3456 речевую информацию, упакованную в пакеты RTP и закодированную по одному из следующих алгоритмов кодирования: 0 - PCMU, 3 - GSM, 4 - G.723 и 5 - DVI4.
При передаче сообщений протокола SIP, упакованных в сигнальные сообщения протокола UDP, существует вероятность того, что размер запроса или ответа окажется больше максимально допустимого для данной сети, и произойдет фрагментация пакета. Чтобы избежать этого, используется сжатый формат имен основных заголовков, подобно тому, как это делается в протоколе SDP, Ниже приведен список таких заголовков (Таблица 7.3).
Таблица 7.3 Сжатые имена заголовков
| Сжатая форма имени | Полная форма имени |
| с | Content-Type |
| е | Content- Encoding |
| f | From |
| i | Call-ID |
| m | Contact (от "moved") |
| 1 | Content-Length |
| s | Subject |
| t | To |
| v | Via |
При написании имен заголовков в сжатом виде сообщение INVITE, показанное ранее на рисунке 6, будет выглядеть следующим образом (рис. 7.7):
INVITE sip: watson@boston.bell-tel.com SIP/2.0 v: SIP/2.0/UDP kton.bell-tel.com f: A. Bell <sip: a.g.bell@bell-tel.com> t: T. Watson <sip: watson@bell-tel.com> i: 3298420296@kton.bell-tel.com Cseq: 1 INVITE с: application/sdp 1: ...
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.7 Пример запроса INVITE с сокращенными заголовками
В заключение параграфа, как и в предыдущих главах, сведем все запросы, с их кратким описанием, в таблицу 7.4.
Таблица 7.4 Запросы SIP
| Тип запроса | Описание запроса |
| INVITE | Приглашает пользователя к сеансу связи. Содержит SDP-описание сеанса |
| АСК | Подтверждает прием окончательного ответа на запрос INVITE |
| BYE | Завершает сеанс связи. Может быть передан любой из сторон, участвующих в сеансе |
| CANCEL | Отменяет обработку запросов с теми же заголовками Call-ID, То, From и CSeq, что и в самом запросе CANCEL |
| REGISTER | Переносит адресную информацию для регистрации пользователя на сервере определения местоположения |
| OPTION | Запрашивает информацию о функциональных возможностях терминала |
7.5.4 Ответы на запросы
После приема и интерпретации запроса, адресат (прокси-сервер) передает ответ на этот запрос.
Содержание ответов бывает разным:
подтверждение установления соединения, передача запрошенной информации, сведения о неисправностях и т.д. Структуру ответов и их виды протокол 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 говорит от том, что сервер не может в данный момент обслужить вызов вследствие перегрузки или проведения технического обслуживания.
Ответы бхх информируют о том, что соединение с вызываемым пользователем установить невозможно:
• ответ 600 Busy Everywhere сообщает, что вызываемый пользователь занят и не может принять вызов в данный момент ни по одному из имеющихся у него адресов. Ответ может указывать время, подходящее для вызова пользователя;
• ответ 603 Decline означает, что вызываемый пользователь не может или не желает принять входящий вызов. В ответе может быть указано подходящее для вызова время;
• ответ 604 Does Not Exist Anywhere означает, что вызываемого пользователя не существует.
Напомним, что запросы и ответы на них образуют SIP-транзакцию. Она осуществляется между клиентом и сервером и включает в себя все сообщения, начиная с первого запроса и заканчивая финальным ответом. При использовании в качестве транспорта протокола TCP все запросы и ответы, относящиеся к одной транзакции, передаются по одному TCP-соединению.
На рисунке 7.8 представлен пример ответа на запрос INVITE.
SIP/2.0 200 OK
Via: SIP/2.0/UDP kton.bell-tel.соm
From: A.
Bell <sip:a.g.bell@bell-tel.com>
To: <sip:watson@bell-tel .com>;
Call-ID: 3298420296@kfcon.bell-fcel.com 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
Рис. 7.8 Пример SIP-ответа 200 OK
В этом примере приведен ответ пользователя Watson на приглашение принять участие в сеансе связи, полученное от пользователя Bell. Наиболее вероятный формат приглашения рассмотрен нами ранее (рис. 7.7). Вызываемая сторона информирует вызывающую о том, что она может принимать в порту 5004 речевую информацию, закодированную в соответствии с алгоритмами кодирования PCMU, GSM. Поля From, To, Via, Call-ID взяты из запроса, показанного на рисунке 7.7. Из примера видно, что это ответ на запрос INVITE с полем CSeq:1.
После того, как мы рассмотрели запросы и ответы на них, можно отметить, что протокол SIP предусматривает разные алгоритмы установления соединения. При этом стоит обратить внимание, что одни и те же ответы можно интерпретировать по-разному в зависимости от конкретной ситуации. В таблицу 7.5 сведены все ответы на запросы, определенные протоколом SIP.
Таблица 7.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, полоса пропускания и т.д. неприемлемы |
