Отказоустойчивый VoIP-сервер в облаке

Мы в Axmor реализовали более десятка VoIP-проектов, например, такие:

Система унифицированных коммуникаций.
Маршрутизация телефонных звонков.

Хотим обобщить свой опыт и поделиться с вами. Данная статья рассчитана на специалистов, желающих получить знания об архитектуре отказоустойчивых VoIP-систем. Базовое знание FreeSWITCH, Asterisk или аналогов желательно, но не является обязательным. В статье мы приведем примеры реальных конфигураций для организации кластера.

Введение в VoIP

Если слова FreeSWITCH, Asterisk, SIP, RTP, WebRTC для вас не пустой звук, можете смело пропускать эту часть.

Мир VoIP стоит на двух больших слонах: SIP и RTP. Эти 2 протокола были разработаны в конце прошлого века и пришли к нам из мира телефонии. SIP — командный протокол. Отвечает за выбор кодеков, начало/конец звонка, управление звонком (hold/transfer/etc) и имеет огромное количество расширений, в том числе для отсылки текстовых сообщений, нотификации об оставленных голосовых сообщениях и т.д.

IP-телефоны разных производителей могут поддерживать свой собственный набор расширений. Например, весьма распространен BLF (Busy Lamp Field) — поле светодиодов на настольном телефоне, которые можно настроить так, что они будут показывать статус телефона другого сотрудника.

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

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

В архитектуру VoIP заложена идея о том, что SIP- и RTP-сервер — это два разных сервера, поэтому встречаются реализации серверов, поддерживающих только SIP или только RTP. Тем не менее FreeSWITCH и Asterisk — это open source сервера, поддерживающие оба протокола и многое другое. Выбор между ними во многом зависит от личных предпочтений, требований и задач интеграции, но оба позволяют из коробки получить офисную мини-АТС.

Нельзя не упомянуть и WebRTC. Де факто это стандарт для голосовых звонков в web. WebRTC под капотом использует SRTP (secure RTP), оставляя реализацию командного слоя на откуп JS-коду. Для p2p-звонков нам нужно всего лишь передать второй стороне свой адрес и некие параметры звонка, что можно сделать на базе любого протокола. Если же нам нужна интеграция с SIP-сервером, то обычно используется протокол SIP over WebSocket. Реализация — sipjs.com.

FreeSWITCH поддерживает как SIP over WebSocket, так и собственный альтернативный протокол, реализованный модулем mod_vertoo. Он разработан специально для интеграции с WebRTC и решает неприятные проблемы несовместимости WebRTC и SIP, приводящие к задержкам 1-5 секунд перед созданием звонка. Впрочем, эти проблемы можно решать и по-другому, на стороне JS, но это тема для отдельной статьи.

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

Мир VoIP обычно тяготеет к пробросу трафика через сервер. Это решает проблему отсутствия белых IP у клиентов и позволяет централизованно подслушивать/записывать любой разговор.

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

Примечание:

Есть технология, позволяющая в теории устанавливать соединение двум клиентам без белых IP c небольшой помощью сервера, но в наших проектах такой необходимости не возникало. Называется эта технология «симметричный NAT».

Если верить документации, Freeswitch поддерживает симметричный NAT. Но мы советуем тщательно протестировать перед использованием в production.

Настройка поддержки интерфейсных карт

Если планируется подключение сервера Asterisk с помощью специальных интерфейсных плат к обычным телефонным сетям, следует позаботиться о наличии соответствующих драйверов, реализованных в виде модуля ядра. Но даже если таких устройств в компьютере нет, эти драйверы все равно рекомендуется установить. Дело в том, что во всех Zaptel-устройствах есть таймер, и для полноценной работы сервера IP-телефонии он является необходимым. Но если Zaptel-устройства под рукой нет, для его эмуляции можно использовать специальный драйвер — ztdummy.

Из репозитария устанавливаем пакеты zaptel, zaptel-source и собираем модули под свою систему:

$ sudo apt-get install zaptel zaptel-source $ sudo module-assistant prepare $ sudo m-a -t build zaptel

В /usr/src появится пакет zaptel-modules-*_i386.deb, устанавливаем его с помощью dpkg. После этого проверяем работу модулей ядра:

$ sudo depmod -a $ sudo modprobe ztdummy

И если нужна поддержка устройств:

$ sudo modprobe zaptel $ sudo modprobe wcfxo

Чтобы обеспечить их автоматическую загрузку, выполняем следующую команду:

$ echo ‘ztdummy\nzaptel\nwcfxo’ >> /etc/modules

Создаем правила для UDEV:

$ sudo mcedit /etc/udev/rules.d/51-zaptel.rules

KERNEL=»zapctl», NAME=»zap/ctl» KERNEL=»zaptimer», NAME=»zap/timer» KERNEL=»zapchannel», NAME=»zap/channel» KERNEL=»zappseudo», NAME=»zap/pseudo» KERNEL=»zap0-9*», NAME=»zap/%n»

Также можно использовать исходные тексты или CVS-версию драйвера. При самостоятельной компиляции понадобятся заголовочные файлы ядра (или исходные тексты):

$ sudo apt-get install linux-headers-`uname -r`

Создадим символическую ссылку, чтобы Asterisk нашел исходники ядра:

$ sudo ln -s /usr/src/linux-headers-2.6.20-15-generic /usr/src/linux-2.6

Теперь получаем последнюю версию драйверов:

$ cd /usr/src $ wget -c downloads.digium.com/pub/zaptel/zaptel-1.4-current.tar.gz

Компилируем и устанавливаем:

$ tar xzvf zaptel-1.4-current.tar.gz $ cd /usr/src/zaptel-1.2.17.1 $ ./configure $ make $ sudo make install

И чтобы вручную не создавать конфигурационные файлы:

$ sudo make config

После этой команды будет создан скрипт для автоматического запуска модулей, входящих в состав Zaptel, и конфиг /etc/default/zaptel (или /etc/sysconfig/zaptel), в котором будет указано, какие модули необходимо загружать. Рекомендую в этом файле оставить только необходимое. Пробуем загрузить модуль:

$ sudo modprobe ztdummy $ lsmod | grep ztdummy ztdummy 6184 0 zaptel 189860 1 ztdummy

Все нормально. После установки в системе появятся еще два файла:

/etc/zaptel.conf – описывает конфигурацию аппаратного обеспечения;
/etc/Asterisk/zapata.conf — настройки сервера Asterisk для работы драйвера Zap-канала.

Подробные указания для всевозможных устройств даны в документации. На русском по этому поводу можно почитать в документе «Конфигурация драйвера ядра Zaptel». Но на этом не останавливаемся, впереди у нас еще много работы. После настройки проверяем работу командой ztcfg -vv.

Масштабирование SIP-траффика с помощью OpenSIPs

FreeSWITCH и Asterisk позволяют обрабатывать на одной машине огромное количество одновременных звонков — 500-1000. Но что делать, если нам надо больше? Или если в ТЗ сразу заложена необходимость облака с балансировкой нагрузки?

Тут на помощь приходит SIP-балансировщик нагрузки. Мы выделяем одну машину под балансировщик, который на уровне SIP выбирает конечный узел и перенаправляет туда обработку медиатрафика. Через балансировщик не проходит RTP media-трафик, поэтому он способен выдержать значительно большее количество одновременных звонков. Фактически после создания звонка нагрузка исчезает.

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

Многие уже успели поработать с FreeSWITCH и/или Asterisk, в сети достаточно how-to примеров, но настройка SIP-балансировщика в OpenSIPs или Kamailio — это совершенно другое.

FreeSWITCH и Asterisk требуют всего лишь задать список пользователей и довольно простых правил роутинга звонков. Более того, есть бесплатные админпанели, которые позволят вам сконфигурировать всё в веб-интерфейсе.

В противовес, OpenSIPs и Kamailio заставляют пользователя разобраться с протоколом SIP хотя бы на начальном уровне и вручную прописать, что делать с каждым SIP-сообщением.

Конфигурация OpenSIPs — это программа на верхнеуровневом псевдоязыке, которая должна увязать между собой в единую систему 10+ разных модулей. Список модулей значительно больше, но часть дублирует друг друга, а часть может не понадобиться.

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

Если же вы хотите добавить много кастомной логики, то в какой-то момент может оказаться проще вынести бизнес-логику в FreeSWITCH (Asterisk) и/или отдельный сервер, который и будет управлять роутингом звонков, очередями и т.д.

Простейший скрипт для балансировки нагрузки выглядит следующим образом:

Если входящее SIP-сообщение не первое, и уже известно куда его роутить, передаем управление модулю dialog.
Иначе вызываем модуль balancer для поиска менее загруженной ноды, проставляем её адрес в target и передаем управление модулю dialog.
Обрабатываем ошибки:
Модуль balancer может вернуть ошибку и сказать, что свободных нод нет.

Очень важный момент:

Когда вы пишете программы обработки для OpenSIPs, помните, что вы должны обработать как сообщения, идущие снаружи в ваше облако, так и сообщение, идущее из вашего облака наружу. Поэтому зачастую программа бьется на 2-3 огромных If-блока в зависимости от направления SIP-пакета.

Пример:

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

route { if (!has_totag()) { #Первое сообщение в диалоге, запоминаем его в базе и не выходим, надо найти куда его роутить record_route(); } else { #Не первое сообщение, роутим по уже проторенной дороге и выходим loose_route(); t_relay(); exit; } // Ищем свободный узел. 1 — вес нашего запроса, call-ресурс. // Можно сделать сложную логику и выделять под разные звонки разный набор машин load_balance(«1″,»call»); if ($retcode

Особенности OpenSIPs:

Значения заголовков не меняются в процессе выполнения программы. Если вы что-то присвоите и потом попробуете вывести в лог, выведется первоначальное значение.
Есть 2 разных типа пользовательских переменных, и они несовместимы. Часть модулей использует одни, часть другие.
Многие функции ничего не возвращают, а просто делают что-то полезное, а что именно, можно узнать только полностью прочитав документацию и иногда — исходники. Например, load_balance() проставляет значение переменной $du. А record_route() сохраняет в заголовке сообщения $du, но при этом вызывается раньше load_balance(). Явное нарушение причинно-следственной связи. Предполагаем, что заголовки считаются в самом конце, и record_route() скорее проставляет некий флажок или ссылку.
Stateless-парадигма. SIP позволяет все необходимые для роутинга данные хранить прямо в заголовках сообщений. Клиент же обязан их копировать при ответе, что позволяет серверу быть stateless. Тем не менее, по необходимости можно сохранять в базе таблицу роутинга и не оповещать весь мир о внутренней структуре своего кластера, но это добавляет нагрузку на базу и задержки. Выбор за вами.

Установка Asterisk

К сожалению, четких указаний насчет аппаратных средств дать невозможно — слишком много тонкостей и нюансов, поэтому за примерными конфигурациями компьютеров отсылаю на страницу сайта voip.rus.net «Производительность Asterisk-систем». Если твоя цель — знакомство с Asterisk, можно использовать один из дистрибутивов, в которых уже имеется настроенный и полностью готовый к работе сервер: AsteriskNow, Trixbox, VoIPonCD.

Asterisk присутствует в репозитариях пакетов большинства дистрибутивов. Так, в Ubuntu команда sudo apt-cache search Asterisk выдает приличный список пакетов, после установки которых сразу же можно приступать к настройке. Но установка из репозитария имеет один минус — как правило, в нем версия Asterisk прилично отстает от текущей, которую можно скачать с официального сайта. Поэтому рассмотрим универсальный способ установки на примере того же Ubuntu, хотя все сказанное (за редким исключением) относится и к остальным дистрибутивам.

Устанавливаем пакеты, необходимые для компиляции:

$ sudo apt-get install build-essential automake autoconf bison flex libtool libncurses5-dev libssl-dev

Кроме того, настоятельно рекомендуется установить библиотеку libpri, даже если не нужна поддержка Primary Rate ISDN (первичный тип цифровой сети с интеграцией услуг). Это можно сделать либо через репозитарий: sudo apt-get install libpri1.2, либо используя исходные тексты:

$ wget -c downloads.digium.com/pub/libpri/libpri-1.4-current.tar.gz

Компиляция библиотеки стандартна, поэтому не будем на этом останавливаться.

Теперь скачиваем с сайта исходные тексты Asterisk и конфигурируем:

$ wget -c downloads.digium.com/pub/Asterisk/Asterisk-1.4.11.tar.gz $ tar xzvf Asterisk-1.4.11.tar.gz $ cd Asterisk-1.4.11 $ ./configure —prefix=/usr

По окончании работы скрипта в консоли мы увидим эмблему проекта и некоторую информацию о настройках.

$ make $ sudo make install

Примечание: если производится установка версии 1.2, то для поддержки формата mp3 перед командой make следует ввести «make mpg123», версия 1.4 уже никак не реагирует на эту команду.

После компиляции, помимо всего прочего, будут установлены следующие исполняемые файлы:

/usr/sbin/Asterisk — демон сервера Asterisk, который и обеспечивает всю работу;
/usr/sbin/safe_Asterisk — скрипт для запуска, перезапуска и проверки работы сервера Asterisk;
/usr/sbin/astgenkey – скрипт для создания закрытого и публичного RSA ключей в формате PEM, которые необходимы для работы Asterisk.

Чтобы установить шаблоны конфигурационных файлов и документацию, набираем:

$ sudo make samples

Примеры конфигурационных файлов будут скопированы в /etc/Asterisk. Если в этом каталоге уже находятся файлы конфигурации, они будут переименованы с префиксом «.old». Для сборки документации потребуется пакет doxygen, если его нет, устанавливаем:

$ sudo apt-get install doxygen $ sudo make progdocs

Аналогично ставим и пакет с расширениями Asterisk-addons (этот шаг не обязательный, его можно смело пропустить). Многие модули, входящие в состав этого набора, являются экспериментальными. Их стоит устанавливать, только если требуется запись информации в БД, поддержка mp3-файлов и протокола ooh323c (Objective Systems Open H.323 for C):

$ wget -c downloads.digium.com/pub/Asterisk/Asterisk-addons-1.4.2.tar.gz $ tar xzvf Asterisk-addons-1.4.2.tar.gz $ cd Asterisk-addons-1.4.2 $ ./configure; make; sudo make install; sudo make samples

Установка Asterisk закончена. Сначала рекомендуется запустить сервер в отладочном режиме и просмотреть вывод на наличие ошибок:

$ sudo /usr/sbin/Asterisk -vvvgc

Если получаем сообщение «Asterisk Ready» и приглашение консоли управления, значит все в порядке. Выходим:

*CLI> stop now

Теперь можно переходить к дальнейшей настройке.

Отказоустойчивость и масштабирование VoIP-систем

Отказоустойчивость и масштабирование — связанные вещи. Невозможно продумать архитектуру отказоустойчивости без учёта схемы масштабирования. Но можно реализовать только отказоустойчивость в самом простом варианте. Для начала, немного теории.

На уровне протокола VoIP поддерживает возможность восстановления звонка даже при отказе сервера.

SIP failure. По умолчанию SIP использует протокол UDP, который в отличие от TCP не устанавливает постоянного соединения. Но клиент перерегистрируется примерно каждую минуту (настраивается). Фактически на каждый пакет от клиента может отвечать новый сервер. Единственное ограничение — IP-адрес ответного пакета не должен меняться, и нам надо где-то хранить состояние звонков пользователя (если они есть в данный момент), чтобы любой сервер мог работать с этими данными.
RTP failure. Если у нас по каким-то причинам отказал RTP-сервер, который также использует UDP-протокол, мы не можем легко восстановить медиапоток, но мы можем послать через SIP-протокол команду пересоздания потока (reinvite). В идеале клиент заметит всего лишь выпадение нескольких секунд аудио. Под вопросом остается реализация обнаружения падения. Решения из коробки нет.

Рассмотрим разные варианты архитектур.

Нужен VoIP-проект? Напишите нам, и мы оценим его бесплатно.

Отказ от услуги

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

Несмотря на развитие различных систем обмена информацией, таких как электронная почта и службы мгновенного обмена сообщениями, обычный телефон еще долго будет оставаться самым популярным средством связи. Ключевым событием в истории телекоммуникаций и интернета стало появление технологии передачи голоса поверх IP-сетей, поэтому за последние годы изменилось само понятие телефона. Использование VoIP современно, удобно, дешево, так как можно объединить удаленные офисы, даже не прибегая к услугам операторов телефонной связи. Какие еще доводы нужны для того, чтобы поднять свой сервер IP-телефонии?

Резервирование SIP-сервера

Детали реализации сильно отличаются в зависимости от используемого сервера, не меняется только одно — необходимость в Virtual (floating) IP, который мы можем динамически переназначить на другой сервер.

Задача решается на уровне shell-скриптов, которыми мы проверяем, работает ли сервер, и если нет, переназначаем IP на другой. Главная проблема — баланс между ложными срабатываниями и долгим ожиданием перед переключением.

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

Масштабирование SIP-серверов

Правильно реализованное масштабирование заодно решает и проблему отказоустойчивости. Умер один сервер — возьмем другой. Главная проблема — SIP-клиент игнорирует пакеты, посланные с другого IP. Пример «Как работать не будет»:

Клиент B просто проигнорирует входящий звонок (invite), потому что его source IP отличается от сервера, на котором клиент зарегистрирован.

Как работать будет? В зависимости от конкретного проекта, имеющегося железа и наших возможностей, проблему можно решать 3 способами.

Лучший софтфон для лучших абонентов

Абонентам сайт не придется терзаться дилеммой выбора: существует универсальная и одновременно простая программа, доступная всем пользователям, — телефонный IP-сервер — YouMagic Softphone. Кроме очевидных преимуществ работы с самим провайдером, абонент получит такие «бонусы»:

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

Эти и многие другие возможности делают использование максимально комфортным на любой платформе, включая Windows, Android и другие ОС.
Теги:

Подмена IP-адреса пакетов

Самый простой вариант — поставить ещё более простой (и быстрый) load balancer, который подменит source IP на свой для всех исходящих пакетов. И спрятать все SIP-сервера за него. Но нам нужно настроить все SIP-сервера на использование общей базы данных.

Очевидный плюс — простота настройки.

Очевидные минусы:

Single Poing of Failure в виде load balancer.
Может не хватить пропускной способности load balancer.

Проброс команды Invite

Настраиваем ферму SIP-серверов с разными IP-адресами, DNS в режиме round robin. Клиенты цепляются случайным образом к одному из множества серверов.

Программируем SIP-сервер пересылать invite нужному серверу (на котором зарегистрирован другой клиент), чтобы уже он от своего имени переслал команду клиенту.

Плюс — всё замечательно масштабируется.

Небольшой минус — SIP register действительно хорошо масштабируется, а вот SIP invite и прочие команды, относящиеся к звонку, масштабируются чуть хуже, потому что с большой вероятностью будут проходить через 2 узла. Впрочем, register случается значительно чаще.

Шардинг

Если наше приложение — это SaaS для бизнеса, то с большой вероятностью клиентам разных компаний не надо звонить друг другу, и с помощью хорошо подобранной hash-функции мы можем раскидать множество наших кастомеров по разным SIP-серверам.

Нам даже не обязательно иметь общую базу данных SIP-регистраций. Но надо как-то сообщить SIP-клиенту адрес нужного SIP-сервера и придумать, что делать, если он умер (вероятно, переключиться на другой). Если мы говорим про UC-решение, то, как правило, SIP-клиент встроен в бизнес-приложение и получает все настройки с сервера — проблемы нет.

Хуже, если мы используем чисто SIP-клиент. Тогда имеет смысл решать проблему на уровне DNS и/или роутинга. Например, выдать каждой компании свой адрес VoIP-сервера и динамически менять таблицы DNS.

Возможности интернет-телефонии

Виртуальные номера. Один абонент может иметь несколько номеров, которые называются виртуальными. Например, три номера — для Москвы, Урала и США, но все звонки принимать на один телефон.

Многоканальность. Позволяет на один номер принимать сразу несколько звонков. Сколько именно — зависит от количества линий, которые выделяет IP-провайдер при подключении тарифа. Многоканальность выгодна для продаж. Когда клиенты начнут звонить одновременно, линия не будет занята — звонки распределяются между свободными менеджерами.

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

IVR-меню. Это голосовое меню, которое слышит абонент, когда звонит на линию. Оно распределяет звонки между отделами. Робот проговаривает разделы и называет номера кнопок на телефоне, которые им соответствуют. Например: «Нажмите 2, если нужно узнать, зачислен ли платеж», «Нажмите 3, если хотите узнать баланс».

А также дополнительные возможности, которые позволят:

Автоматизировать рутинные операции за счет интеграции с CRM-системой и бизнес-приложениями. Например, карточка клиента будет автоматически создаваться при звонке, а при пропущенном звонке — задача на перезвон.
Анализировать разговоры менеджеров.
Вести статистику по входящим и исходящим звонкам.
Использовать короткие номера для внутренней связи.
Организовать конференц-связь с любым количеством участников.
Создать «черный список» абонентов и настроить для них голосовое сообщение.

Резервирование RTP-сервера

В общем случае, нам необходимо отследить падение RTP-сервера и послать reinvite обоим клиентам.

Задача разбивается на несколько подпунктов:

Сохранить SIP-диалог в базу данных.
Отследить смерть сервера.
Послать reinvite для каждого диалога.

Детали реализации сильно отличаются в зависимости от конфигурации кластера.

В качестве примера: FreeSWITCH имеет встроенную команду ‘sofia recover’ для восстановления звонков после рестарта сервера. Но судя по отзывам, эта команда не будет работать в случае кластера из FreeSWITCH-серверов. Здесь вам наверняка понадобится кастомная разработка.

Перечень достоинств

Проект Flexisip написан на С++ и успешно используется в качестве SIP-сервера в проекте Linphone c 2011 года. Благодаря своей легковесности и лояльности к аппаратным ресурсам Листинг конфигурации Flexisip может быть развернут на встроенных системах, небольших аппаратных модулях, виртуальных и облачных платформах. Помимо небольших платформ, Flexisip поддерживает возможность кластеризации (используется бекенд Redis для синхронизации нод) и множественного масштабирования. Таким образом, Flexisip представляет собой весьма гибкий и универсальный продукт для различного рода задач.

Перечислим достоинства системы Flexisip:

легковесность и нетребовательность к аппаратным ресурсам;
простота установки и конфигурирования;
модульность, возможность размещения модулей на различных физических серверах;
возможность использования в качестве сервера push-уведомлений;
аутентификация абонентов по хеш-сумме или TLS-сертификатам;
возможность кластеризации и масштабирования встроенными средствами.

OpenSIPs|Kamailio + RTP proxy

SIP load balancer в лице OpenSIPs или Kamailio управляет RTP Proxy или его аналогом. Общение между ними осуществляется неким протоколом (не SIP), в рамках которого load balancer должен суметь сделать запрос на выделение портов для RTP-протокола, чтобы отправить эти данные клиентам. Клиент открывает новое соединение по полученному IP и порту, соединяясь с RTP proxy.

Вся бизнес-логика сосредоточена внутри SIP load balancer. Решение подходит, если у вас очень мало бизнес-логики, и всё, что вам нужно — коммутировать звонки.

Фактически тут даже не обязательно использовать SIP-сервер. Один из наших проектов коммутации для службы 911 был реализован на Java: Маршрутизация телефонных звонков.

OpenSIPs|Kamailio + FreeSWITCH|Asterisk

SIP load balancer в лице OpenSIPs или Kamailio пробрасывает через себя SIP-пакеты до выбранного FreeSWITCH|Asterisk сервера. Самая близкая аналогия — http load balancer с липкими сессиями. OpenSIPs cам обрабатывает только регистрацию. При инициализации нового диалога (звонка), он по какой-то стратегии выбирает наименее загруженную ноду Freeswitch и перенаправляет туда все SIP-пакеты, связанные с этим диалогом. И уже сам Freeswitch, обрабатывая SIP-пакеты клиента, выделяет у себя RTP-порт и шлёт номер порта и собственный белый IP через OpenSIPs клиенту.

Бизнес-логику имеет смысл вынести на FreeSWITCH|Asterisk, которые значительно больше для этого подходят и имеют большой набор различных модулей из коробки.

Это решение лучше подойдёт для систем с IVR, Voicemail, Call Center и прочими фичами продвинутых PBX-систем.

Пример:

Система унифицированных коммуникаций

OpenSIPs|Kamailio + FreeSWITCH + App server

Решение аналогично предыдущему, но вся бизнес-логика вынесена на Application server. Такой подход позволяет избавиться от необходимости использования lua-скрипта, но добавляет потенциальную точку отказа.

С другой стороны, если у вас уже есть Application server, и он уже является жизненно важным элементом вашего Unified Communication-решения, то почему бы и нет. В FreeSWITCH есть модуль xml_curl, который позволяет всю конфигурацию загружать по http со стороннего сервера. На каждый запрос, будь то авторизация или входящий звонок, FreeSWITCH сначала запрашивает по http xml инструкции, а потом их выполняет. В остальном схема аналогична.

Нужен VoIP-проект? Напишите нам, и мы оценим его бесплатно.