Сохраняем наш файл, переходим в консоль FS ( /usr/local/freeswitch/bin/fs_cli) .

В консоли перезагружаем XML командой reloadxml. Иногда перезагрузки XML достаточно для того, чтобы изменения вступили в силу, но иногда следует воспользоваться командой reload mod_sofia. Теперь проверяем регистрацию sofia status gateway mtt.

Если все настройки были выполнены правильно, то в консоли вы увидите, что ваш шлюз зарегистрирован. Если шлюз не зарегистрировался, то в консоли вводим sofia global siptrace on и смотрим trace с логами, в поисках решения проблемы.

Теперь можно перейти к настройке диалплана в conf/dialplan/*. Номерной план делится на контексты ( context), которые обрабатывают вызовы для этого SIP профиля и соотнесенных с ним IP адресов и портов.

Создадим диалплан conf/dialplan/office.xml и опишем простой контекст.

context name = «office» >
extension name = «from-mtt» >

condition field = «destination_number» expression = «^(74997099783)$» >

action application = «bridge» data = «user/1234@$$»/>

action application = «hangup»/>
condition >
extension >
context >
include >

Небольшое пояснение про bridge и $$ .С помощью bridge можно установить соединение со шлюзом или другими пользователями.

$$ это домен FreeSwitch по умолчанию, назначенный в vars.xml.

Пример маршрутизации входящего вызова на 2 номера одновременно:

extension name = «1234 and 1235» >

condition field = «destination_number» expression = «^(74997099783)$» >

action application = «bridge» data = «user/1234@$$,user/1235@$$»/>

action application = «hangup»/>
condition >
extension >

Пример маршрутизации входящего вызова на группу:

extension name = «group_dial_voipnotes» >

condition field = «destination_number» expression = «^(74997099783)$» >

action application = «bridge» data = «group/voipnotes@$$»/>
condition >
extension >

Примеры, указанные выше, довольно простые, потому что мы не хотели делать их сложными и нагружать лишним. Если хочется сделать более сложный диалплан с ivr, с маршрутизацией в зависимости от времени суток и т.д., то можно посмотреть примеры в conf/dialplan/default.xml, а мы перейдем к настройке исходящей связи.

Продолжаем настройки нашего диалплана в conf/dialplan/office.xml.Для маршрутизации вызова через шлюз используется выражение: sofia/gateway/имя_шлюза/номер.В нашем случае исходящие вызовы будут осуществляться через созданный нами выше gateway MTT

extension name = «out-moskow» >

condition field = «destination_number» expression = «^(84\d<9>)$» >

action application = «bridge» data = «sofia/gateway/mtt/$1»/>

action application = «hangup»/>
condition >
extension >

Небольшое пояснение по выражению ^(84\d<9>)$

^ — Указывает на начало регулярного выражения (обязательно);

(- Свидетельствует о начале регулярного блока выражения — в блоке важно определить внутренние выражения, чтобы на них можно было ссылаться на переменные $ 1, $ 2, $ 3, и т.д.;

84 — соответствует символу ’84’;

\ d — соответствует любой цифре;

— определяет число вхождений для предыдущего выражения, т.е. ровно 9 цифр

) — Закрывает внутренний блок;

$ — Указывает на конец регулярного выражения (обязательно);

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

include >
context name = «office» >
extension name = «from-mtt» >
condition field = «destination_number» expression = «^(74997099783)$» >
action application = «bridge» data = «user/1234@$$»/>
action application = «hangup»/>
condition >
extension >
extension name = «out-moskow» >
condition field = «destination_number» expression = «^(84\d<9>)$» >
action application = «bridge» data = «sofia/gateway/mtt/$1»/>
action application = «hangup»/>
condition >
extension >
context >
include >

Нам остается отредактировать файлы наших добавочных номеров conf/directory/1234.xml и 1235.xml и вставить user_context со значением office.

Тем самым, мы укажем FS, что звонки от пользователя надо обрабатывать в соответствии с нашим созданным контекстом office.Теперь перезагружаем XML из консоли FS и наслаждаемся проделанной работой.

На этом пока всё. Если вы в статье нашли ошибки или несоответствия, мы будем благодарны, если вы напишите нам о них в комментариях.

udvnl

После установки FreeSWITCH почти готов к работе, в нём по умолчанию есть 20 абонентов с номерами 1000-1019. пароль по умолчанию для абонентов VoIP указан в файле /usr/local/freeswitch/conf/vars.xml и равен 1234.
В директории /usr/local/freeswitch/conf/derectory/default находятся 20 xml файлов, каждый из которых отвечает за абонента с соответствующим номером. Можем добавлять абонентов копированием файлов с подстановкой данных.

Из коробки freeswitch частично работоспособен.
При наборе номера идёт задержка 10 секунд, после установки соединения, через 30 секунд разговорное состояние прерывается.
Исправим это, оттредактирова пару конфигурационных файлов:
Символы начало и конец комментариев,

Редектируем файл c глобальными переменными vars.xml
sudo nano /etc/freeswitch/vars.xml

Изменим пароль по умолчанию с 1234 на 1111 (устраняем задержку в 10 секунд при наборе номер), там же поменяем профиль с external на internal, приведя строки к следующему виду:

Перейдём к sip профилям. Сейчас мы будм использовать профиль internal (внутренний). Причина срывов связи у меня заключается в неправильной настройки сети SIP сервера. отредактируем его заменив пару строк:

Freeswitch имеет модульную структуру, подключаемые модули можно посмотреть в файле modules.conf.xml

Отредактируем его, подключив mod_xml_rpc, включающий поддержку WEB API, расскоментировав строку с этим модулем.

Подробнее о модуле
Описание команд можно найти здесь:
Большинство команд в домашнем использовании не нужно.
На этом можно сказать первоначальная настройка SIP сервера закончена.
Перезапустим FreeSWITCH

Попробуем организовать воздействие на SIP сервер с целью внешнего (со стороны сервера УД MajorDoMo) управления вызовами.

Проверка работы SIP сервера, организация видеовызова и небольшая интеграция с MajorDoMo

Попробуем организовать проверку работы нашей VoIP АТС.
Для начала я использую на ПК с Windows Sip клиенты MicroSIP (мне больше всех сипфонов понравился) и Linphone. На смартфоне с Android Linphone и ряд других.
На Raspberry Pi консольный клиент Linphonec (но в нём на данный момент ограниченная работоспособность)
Приведу для примера настройки MicroSIP:


Сетевый настройки, настройки нат и прочее пока не рассматриваю, для начала всё делаем в своей локальной сети.
Приблизительно такие же настройку и у других SIP клиентов.
Внимание! Старайтесь в настройке кодеков, особенно видео, чтоб предпочтительные были одинаковы. У меня установлен VP8.

Сделаем видеовызов с одного клиента на другой:

В качестве иллюстрации, я сделал звонок на одном ПК с двух sip клиентов. Включена отладочная информация
Так же можно и с двух ПК провести набор и ПК-Смартфон. Главное чтоб они были в одной сети.

Перейдем к небольшой интеграции с системой «Умного Дома»
Проверим работу WEB API
Набрав в браузере http://IP_RASPBERRY:8080/ попадаем на заглушку вебстраницы.
Запустить вебстраницу мне не удалось, но я особо и не пробовал, т.к. это не влияет на работоспособность voip сервера. Внешние команды просмотра и управления через API вполне работают.
О модуле xml_rpc

Набрав в браузере запрос получаем отображение статуса FS:

Откроем консоль MajorDoMo и выполним этот запрос консоли:

Получаем:

Сейчас сделаем вызов с инициатором которого будет наша система «Умного Дома»:
Идея в том, чтобы инициировать звонок (с помощью функции originate) со стороны «MajorDomo» абоненту с номером 1003 (MicroSip), а потом состоявшийся вызов переводить в план набора для исходящих вызовов на абонента 1007 (смартфон Android sip клиент Linphone). Команда API выглядит так: originate user/1003 1007 XML default инициирование вызов в консоли номер 1003, после поднятия (или автоподнятия) трубки вызывается номер 1007 из плана набора default и видеозвонок поступает на смартфон.

Переводим её в понятный вид для MajorDoMo и браузера:

Вначале звонит один софтфон, спустя несколько секунд идёт звонок на второй. Ради эксперемента, последний вызов я поставил оба sip клиента в режим автоответа.
Видеовызов установился автоматически.

Эту же команду можно поставить и в сценарии, действия и т.д.
На этом заканчиваю эту часть, единственное отмечу полу деятельности для последующей как настройки так и интеграции, довольно большое.
Этот способ довольно лёгкий, можно сделать и использовать Websocket, и управление по DTMF с мобильного телефона, так же имеется возможность использования технологии WebRTC и прикрутить к Web серверу УД SIP клиент.

Freeswitch — установка и интеграция с SIPML5

В данной статье я постараюсь описать процесс установки и настройки Freeswitch и SIPML5, а заодно расскажу о решении возникших проблем, надеюсь что статья будет полезна и, как минимум, поможет сэкономить время тем кто столкнулся с подобной задачей. Итак, приступим!

В качестве ОС я использовал CentOS 6.6, но этим не ограничивался и пробовал установку также на Ubuntu 12.04 и 14.04, о проблемах, с которыми довелось столкнуться в процессе установки, я обязательно напишу.

Обновляем систему, отключаем SELinux и устанавливаем необходимые зависимости:

Подключаем необходимые модули, редактируем modules.conf:

Продолжаем процесс установки Freeswitch:

Устанавливаем звуковые файлы, на всякий случай ставим все:

Установим русские звуковые файлы:

Добавим пользователя Freeswitch:

Установим права и владельцев на файлы FreeSwitch:

Уберем дефолтные конфиги FreeSwitch и добавим ссылку на CLI:

Наверное первое что нужно сделать, это поменять пароль по-умолчанию для всех пользователей, а также, сменить пароль для голосовой почты:

Включим сообщения на русском:

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

Если Вам нужно включить запись разговоров всех внутренних звонков:

Находим “Local_Extension” и добавляем строку:

Применяем изменения командой fs_cli -x «reloadxml». Все записи разговоров будут сохраняться в каталог: /usr/local/freeswitch/recordings/.

Переходим к настройке SIPML5. Активируем транспорт Websocket:

Запускаем Freeswitch и проверяем что вебсокет активирован:

Настройка завершена, но оказалось что в работе связки Freeswitch и SIPML5 есть некоторые проблемы, о которых я собираюсь рассказать:

При звонке с SIPML5 на SIP-телефон или на SIPML5 клиента, происходит сброс звонка через n-секунд (обычно через 60 секунд). Причина такого странного поведения оказалась в проблеме обмена пакетами веб-клиента и сервера «Session-Expires: 120;refresher=uas», проблему можно решить отключив таймер по RFC 4028 SIP Session Timers:

Неожиданно возникли проблемы с DTMF для клиентов SIPML5, которые решились включением двойного режима DTMF (принимаем RFC2833 и INFO, а предлагаем RFC2833):