Без сохранения состояний(stateless). Такой сервер просто обрабатывает получаемые запросы. Но на его базе нельзя реализовать сложные, интеллектуальные услуги.

Прокси может указать пользователю в ответ на первый запрос, на необходимость информации для аутентификации — как минимум логина (ответ 407 Proxyauthentificationrequired).

Сервер B2BUA

B2BUA — (англ. back-to-backuseragent, буквально: пользовательский агент спина-к-спине) — вариант серверного логического элемента в приложениях, работающих с протоколом SIP. По идеологии работы, B2BUA похож на прокси-сервер SIP, однако есть принципиальные различия. Сервер B2BUA, работает одновременно с несколькими (как правило, двумя) конечными устройствами — терминалами, разделяя вызов или сеанс на разные плечи-участки. С каждым участком B2BUA работает индивидуально, как UAS по отношению к инициатору и как UAC по отношению к терминалу, принимающему вызов. При этом сигнальные сообщения передаются в рамках сеанса в обе стороны синхронно, хотя решение о необходимости передачи сообщения и его формате принимается B2BUA для каждого участка в индивидуальном порядке. Каждый из участников соединения (сеанса связи), на уровне сигнализации взаимодействует с B2BUA, как с оконечным устройством, хотя в действительности, сервер является посредником. Это отражается в адресных полях (таких как From, To и Contact) сообщений, отправляемых сервером B2BUA. Таким образом, ключевое отличие B2BUA — полностью независимая сигнализация всех участков вызова. Это означает, в частности, что для взаимодействия с каждым отдельным пользователем в рамках сеанса связи используются уникальные идентификаторы, а содержимое одних и тех же сообщений для разных участков будет различным. Пользовательские агенты оконечных терминалов могут взаимодействовать с B2BUA и при участии прокси-серверов.

Сервер B2BUA может предоставлять следующие функции:

Управление звонками (биллинг, перевод звонка, автоматическое разъединение и т. д.)

Сопряжение разных сетей (в частности, для адаптации разных диалектов протокола, зависимых от производителей)

Сокрытие структуры сети (частные адреса, сетевая топология и т. п.)

Довольно часто B2BUA является частью медиа-шлюза для того, чтобы полностью контролировать медиа-потоки в рамках сессии. Сигнальный шлюз, являющийся частью пограничного контроллера соединений/сеансов — наглядный пример применения B2BUA.

Сервер переадресации

Сервер переадресации (англ. RedirectServer) используется для перенаправления вызова по адресу текущего местоположения пользователя. Сервер переадресации не терминирует вызовы и не инициирует собственные запросы, а только сообщает адрес необходимого терминала или прокси-сервера при помощи ответов класса 3XX (301 MovedPermanently или 302 MovedTemporarily). Для этих целей сервер переадресации может взаимодействовать с SIP-регистратором или сервером определения местоположения.

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

Сервер регистрации (регистратор)

Процесс регистрации SIP UserAgent на SIP регистраторе с аутентификацией по логину

Протокол SIP подразумевает мобильность пользователя, то есть пользователь может перемещаться в пределах сети, получая новый адрес. Поэтому в SIP существует механизм регистрации — уведомление о новом адресе со стороны пользовательского агента. Сервер регистрации или регистратор (англ. registrar) служит для фиксации и хранения текущего адреса пользователя и представляет собой регулярно обновляемую базу данных адресной информации. В общем случае, пользователь сообщает серверу регистрации свою адресную информацию, такую как IP-адрес или доменное имя и абонентский телефонный номер — при помощи запроса REGISTER. Сервер может подтвердить успешную регистрацию (200 OK) или отклонить, в случае если есть проверка данных и учетная запись пользователя не найдена (404 Notfound) или регистрация для пользователя запрещена в данный момент (403 Forbidden). Регистратор может указать на необходимость логина пользователя для проверки (401 Unauthorized), а также предложить цифровую аутентификацию на основе зашифрованного пароля. В качестве источника информации для аутентификации пользователя, может выступать даже устройство или сервер, не работающее по протоколу SIP (например СУБД, MS Exchange, RADIUS-сервер и т. п.). Регистрация пользователя на сервере имеет определённый «срок жизни» и должна подтверждаться новым запросом REGISTER со стороны клиента, в противном случае адресная информация может быть удалена. Клиент может также прислать запрос с нулевым временем жизни регистрации, что рассматривается, как запрос на принудительное удаление адресной информации из сервера.

В различных реализациях SIP-сетей может встречаться сервера регистрации и других серверов в едином приложении или устройстве, работающем через один сокет на одном порту (обычно 5060) — точку получения запросов. Так зачастую регистраторы совмещаются с сервером переадресации, B2BUA или SIP-прокси. Например, многие софтсвичи (Asterisk, Yate, РТУ и др.) содержат функционал SIP-регистратора с проверкой регистрационных данных каждого пользователя. Информация о возможностях пользователя зарегистрироваться и устанавливать соединения, определяются в данном случае его единой учетной записью. В свою очередь абонентское оборудование IP-телефонии — телефоны, абонентские шлюзы, в большинстве случаев требуют обязательной предварительной регистрации на регистраторе для дальнейшей работы в телефонной сети.

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

Сервер определения местоположения пользователей

Пользователь может перемещаться в пределах разных сетей, кроме того, подлинный адрес пользователя может быть и не известным, даже если его номер известен. Это актуально, в частности для услуги переносимости номера (LNP/MNP). Для решения таких задач существует механизм определения местоположения пользователя при помощи сторонних средств, не имеющих прямого отношения к элементам SIP-сети.

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

Пользователь, которому нужна адресная информация другого пользователя для установления соединения не связывается с сервером определения местоположения напрямую. Эту функцию выполняют другие SIP-серверы при помощи протоколов LDAP, RWHOIS, ENUM, RADIUS или других протоколов.

Запросы

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

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

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

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

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

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

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

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

PRACK — временное подтверждение (RFC 3262)

SUBSCRIBE — подписка на получение уведомлений о событии (RFC 3265)

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

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

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

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

MESSAGE — передача мгновенных сообщений средствами SIP (RFC 3428)

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

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

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

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

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

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

4ХХ — Финальные ответы, информирующие об отклонении или ошибке при обработке или выполнении запроса, например, 403 Forbidden или классический для протокола HTTP ответ 404 NotFound. Другие примеры: 406 NotAcceptable — неприемлемый (по содержанию) запрос, 486 BusyHere — абонент занят или 487 RequestTerminated — вызывающий пользователь разорвал соединение не дожидаясь ответа (отмена запроса).

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

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