Какое сообщение обязательно должно быть отправлено элементом сети sip после получения запроса

Обновлено: 07.07.2024

Тем, кто соберётся делать собственную реализацию протокола SIP, пригодится список RFC, описывающих протокол и его дополнения:

SIP- запросы

INVITE — Приглашает пользователя к сеансу связи. Обычно содержит Протокол SDP -описание сеанса. Запрос INVITE, который отправлен для уже установленного сеанса связи, называется методом re-INVITE. re-INVITE позволяет менять адреса или порты сеансов, может добавлять поток медиаданных, удалять поток медиаданных, и т.д.

CANCEL — Отменяет обработку ранее переданных запросов, но не влияет на запросы, которые уже закончили обрабатываться.

REGISTER — Переносит адресную информацию для регистрации пользователя на сервере определения местоположения.

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

Но в процессе развития, в протокол было добавлено еще несколько типов запросов, которые дополнили его функциональность:

SIP- адреса бывают четырех типов:

Во второй части адреса указывается имя домена, рабочей станции или шлюза. Для определения IP- адреса устройства необходимо обратиться к службе доменных имен - Что такое DNS. Если же во второй части SIP- адреса размещается IP- адрес, то с рабочей станцией можно связаться напрямую.

В начале SIP- адреса ставится слово "sip:", указывающее, что это именно SIP- адрес. Примеры SIP- адресов:

SIP поддерживает специальный довольно мощный язык CPL (Call Processing Language -язык обработки звонков) на основе Введение в XML, предназначенный для написания телефонных скриптов, позволяющий указать, кто кому когда и зачем звонит, что делать, если трубку не берут или берут не там, и т. д. В силу всего этого в рамках SIP легко строить самые разнообразные сервисы.

Подобные сервисы могут создавать три группы людей: производители SIP- оборудования, сервис-провайдеры и сами конечные пользователи. Язык CPL несложен, так что, видимо, многие будут способны реализовать вполне изощренную схему работы автоответчика: скажем, если позвонивший набирает цифру 1, он переключается на домашний телефон абонента, если 2 – на сотовый, если 3 – на телефон его родителей и т. д. А почему бы не написать скрипт, который, когда раздастся звонок, показывал бы вам лицо (фотографию) звонящего? Телефон ресторана мог бы, скажем, сразу выдавать на дисплей сегодняшнее меню, – короче говоря, возможности здесь ограничены только фантазией пользователя.

Поскольку все современные ERP-, CRM- и т. п. системы работают по протоколу IP, SIP без особых проблем интегрируется с ними (в отличие от H.323, которому его телефонная природа мешает взаимодействовать с большинством приложений).

между пользователями


в сети предприятия

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


Пользователь Алиса приходит на свое рабочее место в компании Example, включает в корпоративную сеть ноутбук и активизирует имеющийся на нем программный телефон, который автоматически регистрируется на сервере регистрации. Тот, в свою очередь, запрашивает информацию о пользователе в корпоративной базе данных и сообщает о том, как с ним контактировать, серверу локализации. (Оба сервера могут интегрироваться с различными базами данных, службами каталогов типа LDAP или MS Active Directory и т. д.) Теперь, когда кто-нибудь позвонит Алисе, прокси-сервер, запросив сервер локализации, установит связь с ее рабочим местом.

Прохождение авторизации в SIP протоколе зависит от "Что такое realm sip?", различного для каждого защищаемого домена.

Последовательность действий для авторизации клиентского оборудования на сервере.

Вариант №2. Если secret указан. Сервер на запрос REGISTER присылает ответ SIP/2.0 401 Unauthorized (нормальный ответ сервера о том, что пользователь еще не авторизировался; обычно после этого абонентское оборудование отправляет на сервер новый запрос, содержащий логин и пароль).

Где параметр response - строка, состоящая из 32 шестнадцатиричных разрядов и удостоверяющая, что пользователю известен пароль. Формируется с помощью применения функции хеширования к значениям nonce, nc, cnonce, qop, uri, username, realm, типу запроса и паролю password. По умолчанию хеширование производится по алгоритму Алгоритм MD5.

Вариант №3. Если используется внешний сервер для аутентификации (процедура проверки подлинности) по протоколу RADIUS сервер. Сервер на запрос REGISTER присылает ответ SIP/2.0 407 Proxy Authentication Required - необходима аутентификация на прокси-сервере).

Протокол описывает, каким образом клиентское приложение (например, софтфон) может запросить начало соединения у другого, возможно, физически удалённого клиента, находящегося в той же сети, используя его уникальное имя. Протокол определяет способ согласования между клиентами об открытии каналов обмена на основе других протоколов, которые могут использоваться для непосредственной передачи информации (например, RTP ). Допускается добавление или удаление таких каналов в течение установленного сеанса, а также подключение и отключение дополнительных клиентов (то есть допускается участие в обмене более двух сторон — конференц-связь). Протокол также определяет порядок завершения сеанса.

Запросы

INVITE — Приглашает пользователя к сеансу связи. Обычно содержит SDP -описание сеанса.

АСК — Подтверждает приём ответа на запрос INVITE.

BYE — Завершает сеанс связи. Может быть передан любой из сторон, участвующих в сеансе.

CANCEL — Отменяет обработку ранее переданных запросов, но не влияет на запросы, которые уже закончили обрабатываться.

REGISTER — Переносит адресную информацию для регистрации пользователя на сервере определения местоположения.

OPTION — Запрашивает информацию о функциональных возможностях терминала.

Но в процессе развития, в протокол было добавлено еще несколько типов запросов, которые дополнили его функциональность:

PRACK — временное подтверждение

NOTIFY — уведомление подписчика о событии

PUBLISH — публикация события на сервере

INFO — передача информации, которая не изменяет состояние сессии

REFER — запрос получателя о передаче запроса SIP

UPDATE — модификация состояния сессии без изменения состояния диалога

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

1ХХ — Информативные ответы показывают, что запрос находится в стадии обработки. Наиболее распространённые ответы данного типа 100 Trying, 180 Ringing, 183 Session Progress.

2ХХ — Финальные ответы означающие, что запрос был успешно обработан. В настоящее время в данном типе определён только один ответ — 200 OK.

3ХХ — Финальные ответы информирующие оборудование вызывающего пользователя о новом местоположении вызываемого пользователя, например ответ 302 Moved Temporary.

5ХХ — Финальные ответы информирующие о том, что запрос не может быть обработан из-за отказа сервера, 500 Server Internal Error.

6ХХ — Финальные ответы информирующие о том, что соединение с вызываемым пользователем установить невозможно, например ответ 603 Decline означает, что вызываемый пользователь отклонил входящий вызов.


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

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

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



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


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


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

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

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

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




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



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

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


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

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


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

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


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


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

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

Ответы Зхх информируют оборудование вызывающего пользователя о новом местоположении вызываемого пользователя или переносят другую информацию, которая может быть использована для нового вызова:
в ответе 300 Multiple Choices указывается несколько SIP-адресов, по которым можно найти вызываемого пользователя, и вызывающему пользователю предлагается выбрать один из них;
ответ 301 Moved Permanently означает, что вызываемый пользователь больше не находится по адресу, указанному в запросе, и направлять запросы нужно на адрес, указанный в поле Contact;
ответ 302 Moved Temporary означает, что пользователь временно (промежуток времени может быть указан в поле Expires) находится по другому адресу, который указывается в поле Contact.

Ответы 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 означает, что вызываемого пользователя не существует.

1xx = информационные ответы

SIP/2.0 100 Trying - запрос обрабатывается

SIP/2.0 180 Ringing - местоположение вызываемого пользователя определено. Выдан сигнал о входящем вызове

SIP/2.0 181 Call is Being Forwarded - прокси,сервер переадресует вызов к другому пользователю

SIP/2.0 182 Call is Queued - вызываемый абонент временно не доступен, вызов поставлен в очередь

SIP/2.0 183 Session Progress - используется для того, чтобы заранее получить описание сеанса информационного обмена от шлюзов на пути к вызываемому пользователю

2xx = ответы о завершении запроса

SIP/2.0 200 OK - успешное завершение

SIP/2.0 202 Accepted - запрос принят для обработки Используется для справки о состоянии обработки

SIP/2.0 300 Multiple Choices - указывает несколько SIP-адресов, по которым можно найти вызываемого пользователя

SIP/2.0 301 Moved Permanently - вызываемый пользователь больше не находится по адресу, указанному в запросе

SIP/2.0 302 Moved Temporarily - пользователь временно сменил местоположение

SIP/2.0 305 Use Proxy - вызываемый пользователь не доступен непосредственно, входящий вызов должен пройти через прокси-сервер

SIP/2.0 380 Alternative Service - запрошенная услуга недоступна, но доступны альтернативные услуги

4xx = невозможность обработать запрос

SIP/2.0 400 Bad Request - запрос не понят из-за синтаксических ошибок в нем, ошибка в сигнализации, скорее всего что-то с настройками оборудования

SIP/2.0 401 Unauthorized - нормальный ответ сервера о том, что пользователь еще не авторизировался; обычно после этого абонентское оборудование отправляет на сервер новый запрос, содержащий логин и пароль

SIP/2.0 401 Expired Authorization - время регистрации истекло

SIP/2.0 402 Payment Required - требуется оплата (зарезервирован для использования в будущем)

SIP/2.0 403 No Such User - нет такого пользователя, ошибка в номере, логине или пароле

SIP/2.0 403 User Disabled - пользователь отключен

SIP/2.0 403 Wrong Guess - ошибка в пароле

SIP/2.0 403 Conflict - такой SIP-номер уже используется

SIP/2.0 403 Empty Route Set - нет ни одного шлюза в роутинге

SIP/2.0 403 Caller Not Registered - нет такого пользователя

SIP/2.0 403 Out of Look-Ahead Retries - перебор узлов закончен

SIP/2.0 403 Invalid Phone Number - нет такого направления

SIP/2.0 403 No Money Left on RFC Account - на счету нет денег для совершения звонка

SIP/2.0 404 Not found - вызываемый абонент не найден, нет такого SIP-номера

SIP/2.0 404 Undefined Reason - неопределенное направление

SIP/2.0 404 Unknown user account - логин и пароль не найдены

SIP/2.0 404 Out of Order - в заявке на маршрутизацию по этому направлению нет ни одного шлюза, проверьте настройку маршрутизации по этому направлению.

SIP/2.0 405 Method Not Allowed - метод не поддерживается, может возникать если пользователь пытается отправлять голосовую почту и т.п.

SIP/2.0 406 No codecs match - неправильная конфигурация кодеков

SIP/2.0 406 Not Acceptable - пользователь не доступен

SIP/2.0 407 Proxy Authentication Required - необходима аутентификация на прокси-сервере

SIP/2.0 408 Request Timeout - время обработки запроса истекло: Абонента не удалось найти за отведенное время

SIP/2.0 408 Login timed out - за отведенное время не получен ответ от сервера на запрос авторизации

SIP/2.0 410 No Route - вариант SIP/2.0 403 Empty Route Set; нет доступа к ресурсу: Ресурс по указанному адресу больше не существует

SIP/2.0 413 Request Entity Too Large - размер запроса слишком велик для обработки на сервере

SIP/2.0 415 No Media - звонок совершается неподдерживаемым кодеком

SIP/2.0 416 Unsupported Scheme - сервер не может обработать запрос из-за того, что схема адреса получателя ему непонятна

SIP/2.0 420 Bad extension - неизвестное расширение: Сервер не понял расширение протокола SIP

SIP/2.0 421 Extension Required - в заголовке запроса не указано, какое расширение сервер должен применить для его обработки

SIP/2.0 423 Interval Too Brief - сервер отклоняет запрос, так как время действия ресурса короткое

SIP/2.0 480 Invalid Phone Number - неправильный номер телефона, не соответствует к-во цифр или неправильный код страны или города

SIP/2.0 480 Destination Not Found In Client Plan - направления нет в тарифном плане абонента

SIP/2.0 480 Wrong DB Response - проблемы с центральной базой сети

SIP/2.0 480 DB Timeout - проблемы с центральной базой сети

SIP/2.0 480 Database Error - проблемы с центральной базой сети

SIP/2.0 480 Codec Mismatch - несоответствие кодеков

SIP/2.0 480 No Money Left on RFC Account - нет денег на счету, обратитесь к администратору сети.

SIP/2.0 480 Empty Route Set - пустое направление, нет принемающих шлюзов

SIP/2.0 480 No money left - недостаточно денег на счете

SIP/2.0 480 Temporarily Unavailable - временно недоступное направление попробуйте позвонить позже

SIP/2.0 481 Call Leg/Transaction Does Not Exist - действие не выполнено, нормальный ответ при поступлении дублирующего пакета

SIP/2.0 482 Loop Detected - обнаружен замкнутый маршрут передачи запроса

SIP/2.0 483 Too Many Hops - запрос на своем пути прошел через большее число прокси-серверов, чем разрешено

SIP/2.0 484 Address Incomplete - принят запрос с неполным адресом

SIP/2.0 485 Ambiguous - адрес вызываемого пользователя не однозначен

SIP/2.0 486 Busy Here - абонент занят

SIP/2.0 487 Request Terminated - запрос отменен, обычно приходит при отмене вызова

SIP/2.0 488 Codec Mismatch - нет шлюзов с поддержкой заказанного кодека

SIP/2.0 488 Private IP Address - адрес RTP media из сетей RFC1918

SIP/2.0 491 Request Pending - запрос поступил в то время, когда сервер еще не закончил обработку другого запроса, относящегося к тому же диалогу

SIP/2.0 499 Codec Mismatch - отсутствует кодек

5xx = ошибки сервера

SIP/2.0 500 Internal Server Error - внутренняя ошибка сервера

SIP/2.0 500 DB Timeout - нет ответа от базы данных

SIP/2.0 500 Database Error - то же самое, но в другой момент

SIP/2.0 500 Wrong DB Response - неправильный ответ базы данных, редкая ошибка

SIP/2.0 500 Undefined Reason - неопределенная причина

SIP/2.0 500 account has been moved to a remote system - аккаунт перенесен в удаленную систему (дословно)

SIP/2.0 501 Method Not Supported Here - в сервере не реализованы какие-либо функции, необходимые для обслуживания запроса: Метод запроса SIP не поддерживается

SIP/2.0 502 Bad Gateway - сервер, функционирующий в качестве шлюза или прокси-сервера, принимает некорректный ответ от сервера, к которому он направил запрос

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

SIP/2.0 504 Server time-out - сервер не получил ответа в течение установленного промежутка времени от сервера, к которому он обратился для завершения вызова

SIP/2.0 505 SIP Version not supported - версия не поддерживается: Сервер не поддерживает эту версию протокола SIP

6xx = глобальная ошибка

SIP/2.0 600 Busy everywhere - вызываемый пользователь занят и не желает принимать вызов в данный момент

SIP/2.0 603 Decline - вызываемый пользователь не желает принимать входящие вызовы, не указывая причину отказа

SIP/2.0 604 Does Not Exist Anywhere - вызываемого пользователя не существует

SIP/2.0 606 Not Acceptable - соединение с сервером было установлено, но отдельные параметры, такие как тип запрашиваемой информации, полоса пропускания, вид адресации не доступны

В интернете существует достаточно большое количество приложений, которые заточены на создание и взаимодействие с так называемыми сессиями, где сессия — это обмен данными между связанными ею участниками (диалог). SIP — это протокол программного уровня, который позволяет устанавливать, модифицировать и терминировать мультимедийные сессии, в разрезе интернет-телефонии. С помощью SIP возможно подключать новых участников к уже существующим […]


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

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

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

Status-Code представляет собой трехсимвольное цифровое значение, символизирующее собой результат попытки сервера понять и обработать переданный ему запрос. Reason-Phrase служит для более удобного восприятия данных кодов, и несет в себе их короткое текстовое описание. Можно сказать, что Status-Code предназначен для программной расшифровки протокола, а Reason-Phrase для человеческой(инженерной). Более подробно этой темы мы коснемся во второй части статьи.

рис. 1 рис. 2

```Имя поля: значение поля```

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

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

Subject: Я знаю, что ты здесь, подними трубку!

Порядок следования заголовков роли не играет, ровно до тех пор, покуда не передаются заголовки с одинаковыми именами полей!

Так или иначе, рекомендуется использовать в шапке заголовки, которые имеют прямое отношения к службам перенаправления запроса(прокси-серверам) и подобным ей. Такими заголовками могут быть: Via, Route, Record-Route, Proxy-Require, Proxy-Authorization, Max-Forwards, и другие.

В целом, порядок следования заголовков значения не имеет, кроме случаев, когда должны передаваться заголовки с одинаковыми именами полей! За редким исключением, такие заголовки можно объединить в одну пару >, отделив с помощью запятой их значения друг от друга.

Читайте также: