В предыдущей статье мы рассмотрели простое взаимодействие клиентов SIP без использования Proxy-сервера. Такое взаимодействие на практике встречается чрезвычайно редко, но отлично подходит для того, чтобы понять основы SIP.
Теперь, когда мы разобрались с базовыми вещами, предлагаю перейти к реальной работе протокола.
В этой статье я планирую рассмотреть три вопроса:
- Выбор транспортного протокола и поиск Proxy;
- Работа через Proxy;
- Регистрация на Proxy-сервере.
Выбор транспортного протокола и поиск Proxy
Поскольку протокол SIP поддерживает несколько транспортных протоколов (UDP, TCP, SCTP, TLS), необходимо каким-то образом определять, какой протокол использовать. Для этого существет несколько способов.
Первый способ предполагает явное указание транспорта в SIP URI (кроме TLS). Выглядит это вот так:
Если транспорт явно не указан, то действует следующий алгоритм:
- Если SIP URI содержит IP-адрес, то для SIP URI используется UDP, для SIPS (Secure SIP) – TCP.
- Если IP-адрес не укзаан, но укзаан порт, то для SIP URI используется UDP, для SIPS – TCP.
- Если отсутсвует IP-адрес и порт, но в DNS присутствует соответсвующая NAPTR-запись, тогда “SIP+D2U” соответствует UDP, “SIP-D2T” указывает на TCP и “SIP-D2S” — на SCTP. NAPTR содержит ссылку на SRV-запись, которая будет использоваться для поиска Proxy-сервера. Если NAPTR остуствует, то должен быть выполнен запрос на поиск SRV-записи.
- Результатом SRV запроса будет имя и порт Proxy-сервера.
- Если SRV-запись отсутствует, то выполняется A или AAAA-запрос. При это для SIP URI используется UDP, для SIPS – TCP.
Для того, чтобы лучше разобраться, рассмотрим пример, когда мы хотим связаться с клиентом sip:ivan@domain.ru:
Итак, мы выяснили, параметры Proxy-сервера Ивана. Теперь предлагаю рассмотреть использование Proxy в рамках SIP-диалога.
Ремарка для тех, кто не знает, что такое NAPTR. Я узнал, что есть такой тип DNS-записи только, когда писал эту статью, так что не отчаивайтесь. Чуть подробнее про NAPTR здесь.
Взаимодействие с использованием Proxy
Для чего же нам необходим SIP Proxy? Как я уже сказал, в примере из 1-ой части статьи клиенты знали IP-адреса друг друга и могли общаться напрямую. В реальной жизни клиенты чаще всего получают адреса динамически, поэтому нет смысла «запоминать» тот или иной IP. Первое, что приходит на ум в данной ситуации – использовать A-записи DNS и определить реальный действующий адрес. Однако тут кроется следующая проблема: IP-адрес идентифицирует конкретное устройство, а не пользователя на нем. Особенностью взаимодействия SIP является то, что обмен сообщения происходит не на уровне устройство-устройство, а на пользователь-пользователь. При этом один пользователь может одновременно использовать несколько SIP-клиентов: на мобильном телефоне, на рабочем компьютере, на домашнем компьютере и на SIP-телефоне. Как же быть?
Протокол SIP предлагает следующее решение: создается SIP Proxy и каждый пользователь регистрирует свои устройства на этом Proxy (точнее пользователи регистрируются на сервере регистрации, а Proxy имеет доступ к базе регистрации, но для простоты будем считать, что это один и тот же сервер). Как это делается, я покажу ниже. Пока просто запомните, что Proxy знает, как именно найти тот или иной клиент пользователя.
Когда Петр звонит Ивану, выполняется следующая последовательность действий:
- SIP-клиента Петра определяет адрес и протокол SIP Proxy Ивана (как это делается — см. выше)
- Клиент отправляет на Proxy запрос INVITE
- Proxy-сервер смотрит, на каких устройствах зарегистрировался Иван и отправляет запрос на все эти устройства
- Иван отвечает на звонок на одном из устройств и шлет 200 OK на Proxy
- Proxy перенаправляет 200 OK Петру
- Петр получает SIP-адрес Ивана на конкретном устройстве из поля Contact вответе 200 ОК и шлет ответ напрямую, минуя Prxoy
- Все последующее общение идет также напрямую
На схеме это выглядит следующим образом:
Для тех, кто изучил первую часть статьи, все выглядит довольно знакомо; добавился только промежуточный Proxy-сервер. Соответственно и обмен сообщениями изменился незначительно.
Прежде, чем преступим к детальному рассмотрению, маленькая ремарка. В рамках SIP разделяют два типа URI. Первый из них – ползовательский URI, также известный как address of recorf (AOR). Запрос, отправленный на этот адрес предполагает поиск в базе данных Proxy и отправку запроса одному или несольким устройствам. Второй – URI устройства (а точнее – пользователя на устроястве). URI устройства обычно называется контакт и содержится, соответственно, в поле Contact SIP-сообщения. AOR содердится в полях From и To.
Начало разговора
Итак, Петр посылает INVITE для Ивана на Proxy-сервер:
Proxy-сервер перенаправляет запрос всем SIP-клиентам Ивана. Для простоты предположим, что Иван использует только одно устройство. Чтобы SIP-клиент понимал, что запрос был перенаправлен через Proxy, сервер добавляет свое заголовочное поле via:
SIP-клиент Ивана шлет ответ 180 Ringing (Иван слышит звонок). При этом он добавляет tag в поле To и указывает свой контакт в поле Contact. Кроме того, в первом поле via добавился параметр received этот параметр показывает, с какого адреса клиент Ивана получил запрос (т.е. адрес Proxy-сервера, как его видит Иван). Это бывает полезно знать для решения возникающих проблем:
Proxy, соответственно, перенаправляет запрос клиенту Петра. При этом он убирает свой via:
После отправки 180 Ringing, как только Иван снимет трубку, клиент Ивана отправляет на Prxoy ответ 200 OK:
Proxy передает этот ответ Петру, убирая при этом via:
Теперь самое интересное. Клиент Петра отправляет сообщение АСК непосредственно клиенту Ивана в обход Proxy. Причем, если бы Иван одновременно использовал несколько клиентов SIP, ответ пришел именно на тот, который нужно. Благодаря чему это возможно?
200 ОК отправляется с клиента на котором Иван снял трубку. Более того, в поле Contact ответа 200 ОК содержится URI, соответствующий пользователю Иван на конкретном устройстве. Таким образом клиент Петра отправляет АСК именно на это устройство, после чего участие Proxy больше не требуется:
Все остальные сообщения, включая медиа-траффик идут в обход Proxy.
Конец разговора
В конце разговора клиент Ивана отправляет BYE напрямую клиенту Петра:
Петр в ответ шлет подтверждение:
Здесь все, как в первой части статьи.
Итак, мы рассмотрели взаимодействие SIP-клиентов с участием Proxу-сервера. Остался один единственный вопрос: откуда Proxy узнал адреса клиентов Ивана? С помощью процедуры регистрации. Как это происходит, я расскажу ниже.
SIP-регистрация
Регистрация выглядит следующим образом:
Давайте подробнее рассмотрим каждое из сообщений. Иван отправляет на сервер запрос Register (для простоты считаем, что роль сервера регистрации установлена на proxy.domain.ru). Самое важное в этом запросе – поле Contact. Это адрес Ивана на конкретном устройстве:
В ответ сервер присылает 401 Unauthorized, то есть требование авторизации. Самое важное поле в ответе — WWW-Authenticate. Не сложно догадаться, что realm — это домен, а algorithm указывает, какой хеш-алгоритм мы будем использовать. Интерес вызывает поле nonce:
Nonce — это сокращение от «number used once». Nonce — это одноразовая случайная последовательность, которую клиент Ивана cкомбинирует со строкой пароля, после чего сгенерирует MD5-хеш от полученной строки и поместит результат в новый запрос в поле WWW-Authenticate (на самом деле все несколько сложнее, но для простоты будем считать, что все именно так). Для этого служит параметр response.
Зачем нужен nonce? Если бы клиент генерировал MD5 от пароля и не использовал nonce, то хеш каждый раз получался бы один и тот же. Злоумешленник мог бы перехватить такой хеш и использовать для авторизации. Это было бы столь же небезопасно, как передавать пароль в открытом виде.
Если использовать nonce, MD5 каждый раз берется от новой строки и получается разным. Поэтому даже перехватив хеш, злоумышленник скорее всего не сможет его использовать для авторизации.
Кстати, обратите внимание, что новый запрос на регистрацию имеет CSeq на единицу больше:
Сервер также комбинирует nonce с паролем Ивана и получает MD5-хеш. После этого он сравнивает свой хеш с хешем, полученным от Ивана. Если они совпадают, то сервер присылает 200 ОК. Обратите внимание на то, что в поле Contact добавился параметр expires. В данном случае регистрация будет храниться в базе сервера в течение 3600 секунд или одного часа:
Если Иван хочет продлить регистрацию, то он должен отправить еще один REGISTER в течение этого часа.
Что делать, если Иван использует сразу несколько устройств с поддержкой SIP? Все очень просто – необходимо отправить запрос на регистрацию с каждого из них.
После того, как в базе данного сервера регистрации появится соответствующая запись, Proxy-сервер сможет перенаправлять запросы на SIP-клиенты Ивана.
Bonus для тех, кому интересно
Вы могли заметить, что, в ответ на запрос регистрации, сервер присылает ответ, содержащий To-tag:
Понятно, что при установке диалога данный tag помогает избежать повторного получения одного и того же сообщения. Для этого существует правило: если сообщение не содержит To-tag и UAS уже получал сообщение с таким же CSeq, From-tag и Call-ID, то сообщение отбрасывается. Для чего же нужен To-tag, если мы не устанавливаем диалог с сервером регистрации. Лучший ответ, который я смог найти — в RFC 3261 написано, что ответ 200 ОК, приходящий на запрос без To-tag должен содержать To-tag. То есть, это ни для чего не нужно, но так принято.
Надеюсь, что работа протокола SIP, после прочтения статьи, стала для вас более понятной. Буду рад вашим комментариям.
2.3.1
В соответствии с архитектурой
«клиент-сервер»
все сообщения
SIP
делятся на запросы
клиента
серверу и ответы
сервера
клиенту. Запросы
(команды)
предназначены для выполнения задач при
предоставлении базовых и дополнительных
услуг в сетях фиксированной (стационарной)
и подвижной (мобильной) связи. Ответы
несут разную функциональную нагрузку,
и их тип зависит от принятого запроса.
Сообщения SIP
представляют собой последовательности
текстовых строк. На рисунке 2.5 показана
структура сообщения протокола SIP.
Стартовая
строка
представляет собой начальную строку
любого SIP-сообщения.
Если сообщение
является запросом,
в стартовой строке указываются тип
запроса, текущий узел-адресат и
номер версии протокола.
Если сообщение
является ответом
на запрос, то в стартовой строке
указываются номер
версии протокола, тип ответа и
короткая расшифровка ответа,
предназначенная только для обслуживающего
персонала и не обрабатываемая клиентом.
Заголовки
сообщений
содержат информацию об отправителе,
адресате, пути следования и др., т.е.
переносят информацию, необходимую для
обслуживания сообщения (таблица 2.1).
Заголовок состоит
из названия, за которым после двоеточия
следует значение заголовка. Если сервер
принимает сообщения с неизвестными ему
заголовками, то он их игнорирует при
обработке.
Рисунок 2.5 –
Структура сообщения протокола SIP
Таблица 2.1 – Типы
заголовков протокола SIP
|
Типы заголовков |
Характеристика |
|
|
Название |
Назначение |
|
|
Общие (присутствуют |
Call-ID |
Идентификатор |
|
Contact |
Контакт |
|
|
CSeq |
Порядковый номер |
|
|
Date |
Дата |
|
|
Encryption |
Кодирование |
|
|
From |
Источник запроса |
|
|
To |
Адресат |
|
|
Via |
Через |
|
|
Record-Route |
Запись маршрута |
|
|
Заголовки |
Content-Encoding |
Кодирование |
|
Content-Length |
Размер тела |
|
|
Content-Type |
Тип содержимого |
|
|
Заголовки |
Accept |
Принимается |
|
Accept- Encoding |
Кодирование |
|
|
Accept-Language |
Язык поддерживается |
|
|
Authorization |
Авторизация |
|
|
Hide |
Скрыть |
|
|
Max-Forwards |
Максимальное |
|
|
Organization |
Организация |
|
|
Priority |
Приоритет |
|
|
Proxy- Authorization |
Авторизация |
|
|
Proxy-Require |
Требование |
|
|
Route |
Маршрут |
|
|
Response-Key |
Ключ кодирования |
|
|
Suject |
Тема |
|
|
User-Agent |
Агент пользователя |
|
|
Заголовки |
Allow |
Разрешение |
|
Proxy-Authenticate |
Подтверждение |
|
|
Retry-After |
Повторить через |
|
|
Server |
Сервер |
|
|
Unsupported |
Не поддерживается |
|
|
Warning |
Предупреждение |
|
|
WWW-Authencate |
Аутентификация |
2.3.2 Запросы
(команды)
SIP
в спецификациях называются SIP-методы.
Они предназначены для выполнения задач
предоставления базовых и дополнительных
услуг в сетях фиксированной и подвижной
связи. С помощью команд клиент сообщает
о своем текущем местоположении, приглашает
пользователей принять участие в сеансах
связи, модифицирует уже установленные
сеансы, завершает их и т.д. Сервер
определяет тип принятого запроса по
названию, указанному в стартовой строке
сообщения.
Виды запросов
(команд) и их назначение показаны в
таблице 2.2.
Таблица 2.2 – Типы
запросов (команд) протокола SIP
|
Запрос (команда) |
Назначение |
|
INVITE |
Запрос на |
|
ACK |
Подтверждение |
|
BYE |
Разрушение |
|
REGISTER |
Сообщение |
|
OPTIONS |
Запрос вызывающего |
|
INFO |
Перенос между |
|
SUBSCRIBE |
Запрос на |
|
MESSAGE |
Реализация служб |
|
REFER |
Команда получателю |
После приема и
интерпретации запроса, адресат
(прокси-сервер) передает ответ
на полученный запрос. Протокол SIP
определяет два типа ответов на запрос,
инициирующий соединение: предварительные
и окончательные.
Запросы и ответы на них образуют
SIP-транзакцию.
Она происходит между клиентом
и сервером
и включает в себя все сообщения, начиная
с первого запроса и заканчивая
окончательным ответом.
Предварительные
(информационные)
ответы показывают, что запрос находится
в стадии обработки, передаются без
подтверждения и кодируются трехзначным
числом, начинающимся с единицы 1хх.
Окончательные
ответы несут результат обработки
запроса, передаются с подтверждением
и кодируются трехзначными числами,
начинающимися с цифр 2,
3,
4,
5
и 6.
Все они означают окончание обработки
запроса, а каждый в отдельности –
результат обработки запроса. Ответы
2хх
означают, что запрос был успешно
обработан. Ответы 3хх
информируют оборудование вызывающего
пользователя о новом местоположении
вызываемого пользователя или переносят
другую информацию, которая может быть
использована для организации связи с
ним. Ответы 4хх
информируют об обнаружении ошибки в
запросе, а ответы 5хх
– о невозможности обработки запроса
из-за ошибки сервера. Ответы 6хх
сообщают о невозможности установления
соединения с вызываемым пользователем
(таблица 2.3).
Таблица 2.3 – Примеры
видов ответов протокола SIP
|
Тип ответа |
Характеристики |
||
|
Код |
Название |
Комментарий |
|
|
Предварительные |
100 |
Trying |
Обнуление |
|
180 |
Ringing |
Аналогичен |
|
|
181 |
Call Forwarding |
Перенаправление |
|
|
182 |
Queued for Service |
Постановка |
|
|
Окончательные |
200 |
OK |
Базовый ответ, |
|
300 |
Multiple Choices |
В ответе |
|
|
302 |
Multiple Tempovarily |
Пользователь |
|
|
400 |
Bad Request |
Запрос не понят |
|
|
486 |
Busy Here |
Вызываемый |
|
|
500 |
Server Internal Error |
Сервер не может |
|
|
501 |
Not Implemented |
В сервере не |
|
|
502 |
Bad Gateway |
Сервер, |
Продолжение таблицы 2.3
|
Тип ответа |
Характеристики |
||
|
Код |
Название |
Комментарий |
|
|
503 |
Service Unavailable |
Сервер не может |
|
|
600 |
Busy Everywhere |
Вызываемый |
|
|
603 |
Decline |
Вызываемый |
|
|
604 |
Does Not Exist Anywhere |
Вызываемого |
Протокол SIP
обеспечивает реализацию трех типов
сценариев установления соединения:
-
с участием сервера
перенаправления, -
с участием
прокси-сервера, -
непосредственно
между пользователями.
2.3.3 На
рисунке 2.6 показан сценарий установления
соединения с участием сервера
перенаправления.
Рисунок 2.6 –
Сценарий установления соединения через
сервер перенаправления
Администратор
сети сообщает
пользователям адрес сервера перенаправления.
1. INVITE
– вызывающий пользователь передает
запрос на известный ему адрес сервера
перенаправления и указывает в запросе
адрес вызываемого пользователя в поле
заголовка CSeq.
В заголовке сообщения также указывается
идентификатор соединения в поле Call—ID.
2. Запрос текущего
адреса вызываемого пользователя
– сервер перенаправления запрашивает
текущий адрес у сервера определения
местоположения.
3. Ответ с текущим
адресом
– сервер местоположения сообщает
серверу перенаправления текущий адрес
вызываемого пользователя.
4. 302 Multiple
Tempovarily
– сервер перенаправления сообщает
вызывающей стороне текущий адрес
вызываемого пользователя.
5. АСК
– вызывающая сторона подтверждает
прием ответа 302.
6. INVITE
– вызывающая сторона непосредственно
связывается с вызываемой стороной. Для
этого передается новый запрос на
установление сеанса связи с тем же
идентификатором Call—ID,
но с другим номером CSeq.
В теле сообщения указываются возможности
вызывающей стороны
7. 100 Trying
– вызываемая сторона начинает обработку
запроса и сообщает об этом вызывающей
стороне ответом 100 для рестарта таймеров.
8. 180 Ringing
–после обработки поступившего запроса
оборудование вызываемого пользователя
сообщает ему о поступившем вызове, а
вызывающей стороне выдается ответ 180
для передачи пользователю сигнала
«Ожидайте ответа».
9. 200 ОК
– после приема вызываемым пользователем
входящего вызова передается ответ, в
котором содержится описание возможностей
вызываемого терминала.
10. АСК
– подтверждение приема ответа.
На этом фаза
установления соединения закончена и
начинается разговорная фаза.
11. BYE
– запрос на разрушение соединения.
12. 200 ОК
– подтверждение приема запроса на
разрушение соединения.
2.3.4 На
рисунке 2.7 показан
сценарий
установления соединения с участием
прокси-сервера.
Администратор
сети сообщает
пользователям адрес прокси-сервера.
1. INVITE
– вызывающий пользователь передает
запрос на адрес прокси-сервера и указывает
в запросе известный ему адрес вызываемого
пользователя в поле заголовка CSeq.
В заголовке сообщения также указывается
идентификатор соединения в поле Call—ID.
2. Запрос текущего
адреса вызываемого пользователя
– прокси-сервер запрашивает текущий
адрес у сервера определения местоположения.
3. Ответ с текущим
адресом
– сервер местоположения сообщает
серверу перенаправления текущий адрес
вызываемого пользователя.
4. INVITE
– прокси-сервер передает запрос
непосредственно вызываемому пользователю.
В теле сообщения указываются возможности
вызывающей стороны
5. 180 Ringing
–после обработки поступившего запроса
оборудование вызываемого пользователя
сообщает ему о поступившем вызове, а
вызывающей стороне выдается ответ 180
для передачи пользователю сигнала
«Ожидайте ответа».
6. 200 ОК
– после приема вызываемым пользователем
входящего вызова передается ответ, в
котором содержится описание возможностей
вызываемого терминала.
7. АСК
– подтверждение приема ответа.
На этом фаза
установления соединения закончена и
начинается разговорная фаза.
8. BYE
– запрос на разрушение соединения
9. 200 ОК
– подтверждение приема запроса на
разрушение соединения.
Рисунок 2.7. –
Сценарий установления соединения через
прокси-сервер
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
- #
Планирование масштабных решений
SIP прокси перед сервером Asterisk (например: SER)
SER — это очень хороший маршрутизатор для SIP протокола, намного более сложный, чем Asterisk, поскольку он может просматривать содержимое пакетов и, на основе полученной информации, маршрутизировать вызовы или даже перезаписывает содержимое пакетов, основываясь на логике, специфичной для каждого пользователя.
Мы используем оба решения, SER и Asterisk, для очень масштабных решений. SER — это ЛУЧШИЙ SIP прокси сервер, который мне удалось найти. Но он является только sip прокси сервером. Он может обслуживать _МНОЖЕСТВО_ соединений (10,000 пользователей, 20 вызовов в секунду). Asterisk — это скорее телефонный коммутатор (АТС), реализующий множество функций, но, вследствие этого — более медленный.
Одна из приятных возможностей, присущей прокси серверу SER — это то, что пользователи могут устанавливать свои настройки для доступа по SIP, используя web интерфейс, без необходимости редактирования файлов конфигурации.
Q: В больших проектах (с множеством пользователей) — как Вы уменьшаете нагрузку на сервер Asterisk путем более эффективного управления RTP трафиком?
A: В данной ситуации нет однозначного решения, но вот мое мнение:
- Если все Ваши абоненты находятся в пределах одной локальной сети, убедитесь, что Ваши SIP телефоны поддерживают возможность «re-invites» и используйте ее.
- Если у Вас все пользователи подключаются через Internet, используйте SIP прокси сервер (по типу SER), в роли front-end’а в отношении сервера Asterisk. Вам по прежнему придется обрабатывать некоторое количество RTP потоков (по причине работы через NAT), но Вы можете распределить эту нагрузку с использованием нескольких SIP-прокси серверов в сети, при помощи записей SRV, технологии round-robin для DNS, или Вы можете заставить пользователей регистрироваться на различных прокси серверах.
Пример: FWD и SIPGATE — оба используют SER в паре с сервером Asterisk.
Было несколько пожеланий, где предлагалось сделать из Asterisk полноценный SIP прокси сервер. Если же Вы потратите некоторое время на изучение и понимание архитектуры Asterisk, то Вы поймете, что это все равно не работало бы. Я не говорю, что обработка SIP каналов не может быть улучшена, я только хотел сказать, что все это должно работать еще и с остальной архитектурой, заложенной в сервере Asterisk. Сервер Asterisk в комбинации с отдельным SIP прокси сервером — является очень мощным решением.
При использовании SIP прокси сервера, у нас имеется следующий сценарий:
- UA клиент Alice отправляет сообщение INVITE для bob@domain
- Прокси сервер, отвечающий за данный домен, принимает это сообщение и ищет абонента «bob» в таблице размещения пользователей или таблице псевдонимов пользователей.
- Прокси сервер ПЕРЕСЫЛАЕТ тот же самый запрос INVITE к bob@currentlocation, или, может быть, в несколько мест.
- Когда Bob с какого то места, куда пришел вызов, отвечает на него, прокси отменяет вызов в те места, откуда не последовало ответа и перенаправляет сообщение OK абоненту Alice.
- Абонент Alice сообщением ACK, отправляемого пользователю bob, подтверждает OK и соединение установлено.
В данном сценарии, представлен только диалог по протоколу SIP, между пользователями Alice и Bob, с сервером, находящийся на пути прохождения сигнализации, и работающего в роли прокси сервера, а не пользовательского агента (UA) (прокси сервер не может и не должен отвечать или быть инициатором вызовов).
Цитата
Мы используем SER в связке с Asterisk. SER используется в качестве SIP proxy/registrar, Asterisk — в роли SIP — PSTN шлюза и сервера для голосовой почты, конференций и перевода вызовов.
Преимущества: Масштабируемость, может поддерживаться очень большое количество SIP клиентов с помощью простого доступа к интерфейсу управления пользователями на основе сервера базы данных или RADIUS, расширенные возможности логики и маршрутизации для SIP протокола, лучшая совместимость с другими компонентами SIP сети.
Неудобства: Вам необходимо два сервера, SER не работает с IAX и, как следствие, вся обработка IAX пользователей осуществляется сервером asterisk.
В моем решении, Asterisk общается с SIP клиентами (UA) через SER — это удалось сделать, установив маршрутизационную запись для логики маршрутизации сервера SER. Я так же пропускаю RTP поток через SER — это было сделано с помощью модуля «rtpproxy» (SER).
По моему мнению, если Вы планируете использовать большое число SIP клиентов — то это довольно неплохая идея.
-Dawid Mielnik-
Диаграмма работы Asterisk с SER
Очень хорошая диаграмма, демонстрирующая работу SER совместно с Asterisk.
MWI — message waiting indication (Индикатор наличия новых голосовых сообщений)
Метод 1
Я не использую Asterisk в качестве клиента (UA), SIP пользователи не регистрируются на Asterisk, вместо этого, все это обрабатывается на SER. Итак, серверу Asterisk необходимо знать, как ему добраться до телефона. Для этого Вам необходимо описать секции «peer» для каждого телефона в файле sip.conf (Которые могут быть созданы на основании регистрационных данных сервера SER, с использованием приложений ast_data / res_data, или механизмом «realtime»). Заметьте, что эти записи никогда не будут использованы для исходящих вызовов, а используются только для обеспечения нормальной работы индикатора MWI.
Итак, нам необходимо найти такой путь, чтобы сервер Asterisk мог общаться напрямую с телефонами, когда для какого-то из них имеются новые голосовые сообщения — индикатор MWI (host=<ip адрес телефона>). Один из возможных путей получения этого IP адреса — это использование динамических записей DNS: DDNS.
В любом случае, Вам необходимо создать запись типа «peer», для каждого телефона, примерно такую:
[2114]
type=peer
username=2114
insecure=yes
canreinvite=no
context=default
mailbox=2114
host=SIP003094C274B3.bna01.isdn.net
Метод 2 — от Andreas Granig
Q: Я предполагаю, что asterisk может отправлять SIP сообщения NOTIFY зарегистрированным SIP клиентам через сервер SER. Итак, могу ли я создать специальный модуль для серверов Asterisk и SER, для того, чтобы это работало?
A: Сервер Asterisk отправляет сообщения NOTIFY только для клиентов (UAC), которые зарегистрированы на Asterisk. Если Вы отправляете все вызовы на голосовые ящики в Asterisk и при этом Ваши клиенты (UAC) регистрируются на сервере SER, Вы можете использовать параметр ‘externnotify’ в файле voicemail.conf сервера Asterisk. Мы используем скрипт, который работает с sipsak, для включения и выключения индикатора MWI, отправляя соответствующие сообщения NOTIFY.
Более детальная информация от Paul (Java Rockx): Я использую sipsak, для отправки сообщений с моего сервера Asterisk в SER прокси. Я использую в Asterisk параметр: «externnotify» в файле voicemail.conf, где указываю имя внешнего bash скрипта. Этот скрипт просто создает файл «touch» в директории /var/spool/mwi/, для дальнейшей обработки его через cron.
Задача, запущенная из cron, просматривает и считывает все файлы в директории /var/spool/mwi/ и генерирует соответствующие SIP NOTIFY сообщения, использую sipsak для передачи их в ser прокси сервер. Заметьте, что сервер asterisk — зарегистрирован как клиент (UA) на прокси сервере Ser. Проделывая это, я предполагал, что можно просто использовать вызов sipsak из сервера asterisk, для отправки сообщений NOTIFY в сервер Ser.
У меня это прекрасно работает, когда нужно включить индикатор MWI у клиента (UA). То, что все еще Я не могу сделать — это выключить индикатор MWI, когда нет новых сообщений. Я реально потратил куче времени для того, чтобы понять, как обработать событие «Hang-Up» в Asterisk. По существу, мне нужно иметь «externnotify» для обработки события отсоединения пользователя от его голосового ящика, тогда Я мог бы проверить статус сообщений в голосовом ящике и отменить работу индикатора MWI, если в ящике более нет новых сообщений.
Я также хочу обрабатывать сообщения SUBSCRIBE, которые получает SIP прокси сервер. Я планирую использовать файл ser.cfg для выполнения внешнего скрипта, при приеме сообщения, для дальнейшей переправки его в Asterisk, при помощи задачи в cron. Когда сервер Asterisk получает сообщение SUBSCRIBE, то он обрабатывает его также, как если бы пользователь вышел из голосовой почты и было бы запущено событие, определенное в «externnotify».
…а тут можно найти решение!
Метод 3
Q: Если у Вас имеются [SIP] телефоны, которые регистрируются на прокси сервере [SER], но голосовые ящики обрабатываются сервером asterisk, то, как включить [MWI] (Индикатор наличия голосовых сообщений) на телефонах?
A: В файле sip.conf создайте запись для вашего маршрутизатора [SER].
[ser]
type=friend ; Позволяем входящие и исходящие вызовы.
; используйте «peer», если нужно только управлять индикатором MWI
context=ser ; Контекст для входящих вызовов.
host=ser.server.tld ; имя хоста или IP адрес Вашего SER сервера
fromdomain=ser.server.rld ; Это Ваш SER_DOMAIN
insecure=very ; Этим мы разрешаем входящие вызовы с телефонов,
; которые попадают через ser в наш asterisk
mailbox=user@context ; Это список голосовых ящиков для мониторинга
Это задает серверу asterisk то, что если есть новая голосовая почта для пользователя «user», тогда ему необходимо отправить сообщение SIP NOTIFY на телефон «ser.server.tld». Итак, пока все хорошо, кроме того, как будет SER доставлять это сообщение заданному телефону? Простейший путь, это сделать малюсенькое изменение в исходном коде asterisk, для того, чтобы добавить имя пользователя голосового ящика в SIP сообщение NOTIFY.
--- channels/chan_sip.c.orig Thu Jul 14 12:03:18 2005
+++ channels/chan_sip.c Thu Jul 14 12:05:26 2005
@@ -9710,6 +9710,7 @@
/* Called with peerl lock, but releases it */
struct sip_pvt *p;
int newmsgs, oldmsgs;
+ char *s;
/* Check for messages */
ast_app_messagecount(peer->mailbox, &newmsgs, &oldmsgs);
@@ -9735,6 +9736,10 @@
/* Recalculate our side, and recalculate Call ID */
if (ast_sip_ouraddrfor(&p->sa.sin_addr,&p->ourip))
memcpy(&p->ourip, &__ourip, sizeof(p->ourip));
+ strcpy(p -> username, peer -> mailbox); /* Username = Mailbox name */
+ s = strchr(p -> username, '@'); /* Remove the context part */
+ if (s != NULL)
+ *s = 0;
build_via(p, p->via, sizeof(p->via));
build_callid(p->callid, sizeof(p->callid), p->ourip, p->fromdomain);
/* Send MWI */
После применения этого патча, сообщения NOTIFY для MWI поступают с сервера asterisk с установленном полем URI: user в ser.server.tld. И далее, оно уже будет отправлено прокси сервером Ser на нужный телефон, с использованием нормальной таблицы правил маршрутизации [SER]. Т.е., [SER] делает поиск: lookup(«location»), а потом: t_relay(). Я не надеюсь, что этот патч приведет к побочным эффектам на телефонах, которые управляются не сервером ser.
Для меня, этот метод более прост, чем Метод 2, описанный выше. Вы можете добавить столько голосовых ящиков в параметр «mailbox=», файла конфигурации asterisk sip.conf, сколько Вам необходимо. Одна из возможных проблем — это, если у Вас имеются голосовые ящики с названием «1000@cx1», а другой: «1000@cx2», в результате, данный патч будет включать индикатор MWI для телефона «1000@ser.server.tld» когда есть новые сообщения в одном из этих двух ящиков. Небольшая модификация для этого патча, и сервер SER сможет обрабатывать различные контексты для голосовых ящиков, если есть в этом необходимость. Однако, тот простой вариант, который есть, для меня вполне достаточен.
Метод 4 — использование механизма «realtime» (ARA) и загрузка всех SIP клиентов при запуске Asterisk
Q: Мы используем в Asterisk архитектуру Realtime для голосовых ящиков и для SIP клиентов. Таблицы базы данных с SIP клиентами видна для таблицы subscriber в OpenSER.
Индикатор MWI для пользователей работает только в том случае, если пользовательская запись (sip клиент) загружается в память и видна, при помощи CLI команды «sip show peers». Это случается, например, если пользователь совершает вызов на свой ящик для проверки голосовой почты.
Имеется ли возможность загрузить всех клиентов из базы данных при запуске asterisk, тем самым, давая возможность пользователям получать сообщение NOTIFY, не требуя то пользователей предварительно совершать вызов на свой голосовой ящик?
A: Смотрите эту ссылку: http://article.gmane.org/gmane.comp.telephony.pbx.asterisk.user/134846
Примеры конфигурации
Работа связки Asterisk и SER:
1. Укажите различные порты для приема сообщений по протоколу SIP для SER (/etc/ser/ser.cfg) и Asterisk (/etc/asterisk/sip.conf).
2. Сконфигурируйте прокси сервер SER (/etc/ser/ser.cfg) на переадресацию вызовов на основании пункта назначения вызова. Например, добавив:
if (uri=~»^sip:0[0-9]*@yourdomain») {
forward( 10.10.10.10, 5070 ); //IP адрес и порт, который слушает asterisk
break;
}
Сервер Asterisk и SER на одной машине
>Если для Asterisk указан SIP порт — 5061, а для прокси сервера SER
>он остается равным 5060, тогда как сделать, чтобы Asterisk общался
>с SER и наоборот?
Можно сделать что-нибудь типа этого:
В файле Asterisk, extensions.conf:
[globals]
SERADDRESS=XXX.XXX.XXX.XXX:5060 [context]
exten => <yourexten>,1,Dial(SIP/${EXTEN}@${SERADDRESS},20,r)
В файле ser.cfg:
if (method == «INVITE») {
if (uri =~ «sip:1[0-9]{10}@*»){
log(1, «Forwarding to Asteriskn»);
rewritehostport(«XXX.XXX.XXX.XXX:5061»);
t_relay();
break;
}
}
(Документация в SER admin guide: http://www.iptel.org/ser/doc/seruser/seruser.html)
Вводная информация, о различиях между сервером Asterisk и SER
от Alex Barnes
Многие говорят, что Asterisk позволяет достичь большей масштабируемости
для SIP протокола. Например, можно взвалить на Ваш SIP прокси все, связанное
с обработкой задач, таких как: передача повторных запросов/ перенаправления /
поиск зарегистрированных абонентов / протоколы вызовов / и т.д.,
все из которых могут быть скрыты от Asterisk.
Множественные регистрации клиентов:
Asterisk не поддерживает несколько регистраций одного клиента.
Прокси сервер регистраций (registrar proxy) может поддерживать
данную возможность, позволяя использовать возможность разветвления
вызовов к данному клиенту (последовательные вызовы, параллельные
или комбинация этих случаев).
Grey Areas (Функциональность, которая содержиться в Asterisk, так и в Прокси серверах)
CPL:
Ценность любого прокси сервера, заключается в наличии у него встроенного
механизма CPL, который позволяет создавать хорошие скрипты для обработки
входящих или исходящих вызовов, индивидуально для каждого из пользователей.
Сервера приложений:
Прокси может также быть и сервером приложений. Который может быть
использован для доступа к некоторым дополнительным технологиям.
Например, Ubiquity сделал HA SIP Сервер приложений, который может
делать почти все что угодно, при помощи загрузки соответствующего RMI
для клиентских и серверных приложений, SOAP, связь с Web Application Servers (Websphere /
Weblogic), Java Eventlets, который дает возможность Вам самим написать
свой интерфейс с использованием других SIP SDK, для обработки вызовов.
ТЕМ НЕ МЕНЕЕ
Я не думаю, что сервер Asterisk полностью готов к поддержке
всех, реально существующих, сценариев доставки вызовов, которые
включены в реализации SIP прокси сервера сторонних разработчиков.
Одна из проблем, с которой я столкнулся в Asterisk, это то, что он
не обрабатывает зацикливание звонка обратно на себя.
Например, поступает вызов через PSTN в Asterisk, он переправляет его
на Ваш SIP registrar proxy, который ищет запись, соответствующую
полученному SIP адресу и находит, что пользователь зарегистрирован
на аналоговом телефоне. Если SIP сервер регистраций перенаправит
вызов с использованием ответа: » 3xx», тогда Asterisk дальше успешно
продолжит обработку, однако, если прокси сервер хочет остаться
на пути прохождения вызова (может быть у Вас на нем работает
приложения для билинга), то он добавит заголовок «Record-Route»
в SIP запрос, дабы сообщить, что он желает получать все последующие
сообщения, связанные с этим вызовом, и отправит его обратно к Asterisk.
В этом случае, Asterisk будет всегда игнорировать это сообщение INVITE.
Если же пользователь был бы зарегистрирован на надлежащем SIP узле,
тогда петля не получилась и все сработало бы как надо.
Пример: SER, Asterisk и Lucent TNT
от Michael Shuler
Вы можете сделать то-же, что и мы, настроив два SER сервера, которые балансируют нагрузку от Foundry ServerIron XL (Вы можете использовать бесплатный UltraMonkey, если желаете). Эти две машины с 2 SER обрабатывают сообщения REGISTER, содержат NAT сервер и осуществляют окончательную доставку вызовов к VoIP устройствам и к телефонным шлюзам. Машины с серверами SER не знают, что делать с вызовами, а знают только, что их надо передать серверу Asterisk для дальнейшей классификации и маршрутизации или для всех действий, которые Вы хотите сделать с этими вызовами. У Вас может быть несколько серверов с Asterisk, которые являются только шлюзами или транскодерами голосовых кодеков для медиаданных, имея набор карт PRI на борту. Мы не использовали сервер Asterisk в качестве шлюза медиаданных в своей системе. Мы использовали Lucent TNT, которые использовались в тех же целях, но в больших масштабах. Для совместного использования общих конфигурационных данных мы использовали http://svn.asteriskdocs.org/res_data/, для чтения содержимого всех фалов конфигурации(sip.conf, extensions.conf, и т.д.) в реальном времени из базы данных MySQL. Просто немного пропатчили и все.
Пока мы не обнаружили приделов по расширяемости этой системы. Если нагрузка на эти два SER сервера достигнет предела, мы просто добавим еще один. Если же будет перегружен сервер маршрутизации Asterisk, то мы добавим еще один. Если же у нас кончаться каналы PRI, тогда мы добавим еще один TNT и больше PRI интерфейсов в нашем Plexus 9000. Таким образом, теоретически, данная система не имеет пределов расширяемости, для решения поставленных задач.
Тут можно найти простые примеры конфигурации SER.
Пример: TeleSIP
Q: Знаете ли Вы о какой-либо документации, по вопросу конфигурации SER в роли внешнего интерфейса (front-end) для Asterisk?
A: В TeleSIP мы запустили кластер из нескольких географически распределенных SER серверов, которые обрабатывают всю маршрутизацию SIP протокола. Прокси сервер SER — это грамотная, быстрая и стабильная платформа, которая у нас работала безупречно. Мы использовали Asterisk как внутреннюю АТС компании и шлюз в телефонную сеть общего пользования. В основном, Вам нужно разработать план нумерации так, чтобы логика маршрутизации SER серверов могла переправить вызов к Asterisk, когда это необходимо.
R: Другой пример можно найти в руководстве IPtel.org. Пример показывает, как использовать прокси сервер SER в роли внешнего интерфейса (front-end) к шлюзу Cisco в общую телефонную сеть, но также показывает, как использовать SER в роле внешнего интерфейса (front-end) к Asterisk.
Ссылки по теме:
- Asterisk SIP not-proxy: Почему сервер Asterisk не может быть назван «SIP прокси сервером»
- Asterisk config sip.conf: второй пример показывает, как связать Asterisk с SER
- Asterisk cmd SIPRedirect: Отправка сообщения «302 temporarily moved» в Asterisk 1.2.x
- Asterisk ast_data: Asterisk 1.0.x with SER and MWI integration
- Asterisk High Availability Solutions
- Asterisk dimensioning: Какое оборудование необходимо для обработки XXX вызовов?
- Asterisk administration
- file descriptors
- Linux High Availability Project
- Asterisk
5.5. Пример SIP-сети
Сети SIP обычно строятся из элементов трех основных типов: терминалов, прокси-серверов и серверов переадресации. На
рис.
5.3 приведен пример возможного построения сети SIP.
Терминалы могут быть двух типов:
- Персональный компьютер со звуковой платой и программным обеспечением SIP-клиента.
- SIP-телефон, подключающийся непосредственно к ЛВС Ethernet.
Путем программирования сервер можно настроить на разные алгоритмы работы: он может обслуживать часть пользователей по одним правилам, а другую часть — по иным.
В протоколе SIP определены два вида сигнальных сообщений — запрос и ответ. Они имеют текстовый формат и базируются на протоколе HTTP. В запросе указываются процедуры, вызываемые для выполнения требуемых операций, а в ответе — результаты их выполнения. Определены шесть процедур:
- INVITE — приглашает пользователя принять участие в сеансе связи (служит для установления нового соединения; может содержать параметры для согласования);
- BYE — завершает соединение между двумя пользователями;
- OPTIONS — используется для передачи информации о поддерживаемых характеристиках (эта передача может осуществляться напрямую между двумя агентами пользователей или через сервер SIP);
- АСК — используется для подтверждения получения сообщения или для положительного ответа на команду INVITE ;
- CANCEL — прекращает поиск пользователя;
- REGISTER — передает информацию о местоположении пользователя на сервер SIP, который может транслировать ее на сервер адресов (Location Server).
Рис.
5.4.
Возможный сценарий установления и завершения сеанса связи по протоколу SIP
Переадресация соединения по SIP
Терминалы в протоколе SIP — это оконечные устройства, обеспечивающие двухстороннюю связь в реальном времени с другим устройством, но, в отличие от терминалов, описанных в рекомендациях Н.323, терминалы SIP выполняют функции шлюза.
Прокси-сервер принимает запрос от терминалов и обрабатывает его, после чего отправляет дальше: или на другой прокси-сервер, или оконечному терминалу. Кроме того, прокси-сервер обрабатывает все запросы и ответы от имени того терминала (или другого прокси), запрос от которого обрабатывается в данный момент. Таким образом, прокси-сервер выступает посредником между двумя терминалами.
Сервер переадресации получает запросы от терминала (прокси-серверов), обрабатывает их и возвращает этому терминалу обработанную информацию, необходимую для дальнейшей маршрутизации вызова. Затем терминал (прокси) непосредственно устанавливает соединение, согласно адресу, указанному сервером перенаправления. Существует также и бессерверный вариант соединения, когда один терминал может посылать запросы непосредственно другому терминалу.
Кроме того, в сетях SIP используются серверы местоположения (location server). Принципы его работы не входят в рекомендации SIP. Сервер SIP после принятия запроса обращается к серверу местоположения для того, чтобы узнать адрес, по которому можно найти пользователя; сервер местоположения в ответ либо сообщает список возможных адресов местоположения пользователя, либо информирует о невозможности найти их.
В сети с прокси-сервером (
рис.
5.5) для успешного установления двустороннего соединения между инициирующей и принимающей сторонами требуется выполнить следующие последовательные шаги:
- Прокси-сервер принимает запрос INVITE от инициирующей стороны.
- Прокси-сервер определяет местонахождение клиента, используя предоставленные услуги адресации и определения местоположения.
- По найденному адресу выдается запрос INVITE от сервера к принимающей стороне.
- Вызываемая сторона уведомляет вызывающую сторону и возвращает указание об успехе обратно прокси-серверу.
- От прокси-сервера к вызывающей стороне отправляется ответное сообщение «Все в порядке» (код 200 ).
- Вызывающая сторона подтверждает прием ответного сообщения выдачей запроса ACK, который прокси-сервер отправляет непосредственно к вызываемой стороне.
На
рис.
5.6 представлена архитектура сети SIP с сервером переадресации.
В сети SIP с сервером переадресации (
рис.
5.6) для успешного установления двустороннего соединения требуется выполнить следующие последовательные шаги:
- Сервер переадресации принимает запрос INVITE от вызывающей стороны ( Бориса ) и определяет местонахождение ( Егора ) по предоставленной информации.
- После этого сервер переадресации возвращает адрес вызывающей стороне. В отличие от прокси-сервера, сервер переадресации не выдает INVITE.
- Вызывающая сторона отправляет ACK к серверу переадресации, подтверждая завершенную транзакцию.
- Вызывающая сторона ( Борис ) отправляет запрос INVITE непосредственно Егору.
- Вызываемая сторона предоставляет указание о благоприятном установлении соединения (реакция «Все в порядке» с кодом статуса 200 ), вызывающая сторона возвращает ACK.
Подход, основанный на использовании протокола SIP, ориентирован на интеграцию услуги передачи речевого трафика по IP-сетям с остальными услугами Интернета. Этот подход является намного более простым для реализации в сравнении с H.323, но меньше подходит для организации взаимодействия с обычными телефонными сетями. В основном это связано с тем, что сигнальный протокол SIP, базирующийся на основе протокола HTTP, плохо согласуется с системами сигнализации, используемыми в ТфОП. Кроме того, сервер SIP в общем случае не сохраняет сведений о текущих соединениях ( Stateless ), в то время как узлы ТфОП, напротив, сохраняют информацию обо всех установленных соединениях ( Statefull ). Второй вариант больше подходит для поставщиков услуг Интернета для предоставления еще одной услуги — интернет-телефонии. Эта услуга будет являться всего лишь небольшой частью пакета услуг и будет предоставляться, например, по фиксированным тарифам, при этом будет использоваться
максимально упрощенная схема управления услугами.