Настройка Freeswitch 1.6 в CentOS 7
Место программного обеспечения Freeswitch в системе можно представить схематически следующим образом:
Здесь 10.200.16.215 – это IP адрес сетевого интерфейса ens32 сервера Linux.
По умолчанию в Freeswitch уже созданы номера 1000 – 1019. У всех номеров задан стандартный пароль регистрации 1234. И если Iptables пропускает SIP и RTP трафик, то на сервере можно сразу зарегистрироваться, используя порт 5060 по умолчанию.
После регистрации на freeswitch с номером 1000 с паролем по умолчанию можно позвонить на номер 5000 и услышать приветствие freeswitch. Здесь так же можно протестировать некоторые возможности freeswitch. При тестировании нужно убедиться, что firewall пропускает трафик! (на время теста firewall можно вообще отключить)
Вход в консоль freeswitch
# fs_cli
Выход из консоли
freeswitch@internal> control-D
Файлы конфигурации
Конфигурация freeswitch лежит здесь
/usr/local/freeswitch/conf/
Структура каталога основных конфигурационных файлов:
autoload_configs – каталог загружаемых при старте системы модулей
dialplan – каталог планов набора. Здесь для каждого плана набора создается xml файл с общим описанием и каталог с детальным описанием планов наборов различных направлений. Планы набора направлений подгружаются по очереди по алфавиту, поэтому лучше планы набора начинать называть цифрами, что бы обеспечить правильную последовательность загрузки.
default
00_in.xml
01_in_supp.xml
default.xml
directory – каталог с описанием абонентских номеров, которые будут подключаться и работать через Freeswitch. Здесь есть файл с общим описанием пользователей и их групп и одноименная папка, содержащая множество файлов. Каждый файл соответствует одному абоненту.
default
1000.xml – описание абонента с номером 1000
1001.xml – описание абонента с номером 1001
….
1019.xml
default.xml
default.xml
sip_profiles – каталог содержащий профили сервера Freeswitch. Главные параметры профиля – это то, IP адрес и порт, на котором работает это SIP профиль. В простейшем случае имеется один профиль, работающий на всех IP адресах сервера и порту 5060. В конфигурации по умолчанию создано два профиля. Первый профиль Internal, работающий на порту 5060, второй профиль external, работающий на порту 5080. Директория, имеющая тоже название, что и имя профиля содержит описание внешних каналов сервера Freeswitch – сущностей gateway.
external
example.xml
external.xml
internal.xml
vars.xml – файл, определяющий ряд глобальных переменных, которые можно использовать при построении конфигурационных файлов.
Допустим необходимо реализовать следующую
И абоненты и внешний стык работают на порту 5060 – поэтому необходим только один профиль SIP. Остальные профили в могут быть удалены в папке sip_profiles (а лучше переименованы для будущего подсматривания), что бы в при загрузке Freeswitch их «не видел». Файлы можно переименовать таким образом, что бы они не имели расширение xml, а имели расширение например такое: xml.removed.
Необходимая структура файлов будет иметь вид:
Исключение ненужных профилей из конфигурации Freeswitch:
# cd /usr/local/freeswitch/conf/sip_profiles
# mv internal-ipv6.xml internal-ipv6.xml.removed
# mv external-ipv6.xml external-ipv6.xml.removed
# mv internal.xml internal.xml.removed
# mv external.xml external.xml.removed
# mv external/example.xml external/example.xml.removed
# mv external-ipv6/example.xml external-ipv6/example.xml.removed
# mv ../directory/default/example.com.xml ../directory/default/example.com.xml.removed
# systemctl restart freeswitch
Убеждаемся, что ни один профиль не загружен:
> sofia status
Name Type Data State
==================================================================================
==================================================================================
0 profiles 0 aliases
Убеждаемся, что не загружен ни один канал - gateway:
> sofia status gateway
Profile::Gateway-Name Data State Ping Time IB Calls(F/T) OB alls(F/T)
==================================================================================
==================================================================================
0 gateways: Inbound(Failed/Total): 0/0,Outbound(Failed/Total):0/0
Исключение прослушивания ненужных портов
Freeswitch по умолчанию прослушивает следующие порты:
После исключения из конфигурации профилей по умолчанию, порты 5060, 5061, 5080, 5081 более не прослушиваются.
Отключаем модуль VERTO, который разрешает работать Freeswitch с телефонами-браузерами по портам 8081, 8082, 1337 с использованием стандарта WEBRTC:
# nano /usr/local/freeswitch/conf /autoload_configs/modules.conf.xml
Комментируем строку:
<load module="mod_verto"/>
Должно получиться:
<!--<load module="mod_verto"/> -->
Настраиваем Freeswitch на работу с системой mod_event_socket на порту 8021. Это необходимо для управления Freeswitch через API. Разрешаем принимать запросы на порту 8021.
# nano /usr/local/freeswitch/conf/autoload_configs/event_socket.conf.xml
Меняем строку
<param name="listen-ip" value="::"/>
на:
<param name="listen-ip" value="0.0.0.0"/>
Открываем порты RTP в диапазоне 8000 – 32768
# nano autoload_configs/switch.conf.xml
Приводим блок RTP port range к виду
<!-- RTP port range -->
<param name="rtp-start-port" value="8000"/>
<param name="rtp-end-port" value="32768"/>
Перезагружаем сервис:
# systemctl restart freeswitch.service
Проверяем порты, которые слушает Freeswitch:
# netstat -ltupn | grep freesw
tcp 0 0 0.0.0.0:8021 0.0.0.0:* LISTEN 16208/freeswitch
Для того, что бы Freeswitch мог работать по сети вносим минимальные правки в iptables. Например, так:
# nano /etc/sysconfig/iptables
-A INPUT -p udp -m udp --dport 5060 -j ACCEPT
-A INPUT -p udp -m udp --dport 8000:32768 -j ACCEPT
# systemctl restart iptables.service
Здесь мы открываем всем порт 5060 для приема SIP сообщений и порты 8000 – 32768 для приема RTP трафика.
Начало конфигурирования
Теперь можно приступить к конфигурированию собственного профиля, каналов и настройке системы Freeswitch
При конфигурировании системы после добавления новых файлов конфигурации необходимо выполнять:
# chown -R freeswitch:freeswitch /usr/local/freeswitch/conf/
# chmod -R 770 /usr/local/freeswitch/conf/
# fs_cli
> reloadxml
или просто
# fs_cli -x "reloadxml"
При глобальный изменения (не просто добавлении нового абонента), нужно рестартовать весь Freeswitch командой:
# systemctl restart freeswitch
Смена пароля клиентам по умолчанию для всех клиентов freeswitch выполняется так:
# cd /usr/local/freeswitch/conf
# nano vars.xml
Меняем пароль 1234 в строке
<X-PRE-PROCESS cmd="set" data="default_password=1234"/>
Например на что-то более суровое:
<X-PRE-PROCESS cmd="set" data="default_password=12345678"/>
Затем применяем изменения в консоли fs выполняем
> reloadxml
> sofia profile restart all
Запись событий (логов) freeswitch в файл:
Подготавливаем лог-файл:
# touch /var/log/freeswitch.log
# chown freeswitch:freeswitch /var/log/freeswitch.log
Правим конфигурацию freeswitch:
# nano /usr/local/freeswitch/conf/autoload_configs/logfile.conf.xml
Ищем строку
<!--<param name="logfile" value="/var/log/freeswitch.log"/>-->
Для записи лог в файл строку нужно раскомментировать, а для этого убрать xml комментарии <!-- и -->. Должно получиться:
<param name="logfile" value="/var/log/freeswitch.log"/>
Раскомментировать и изменить строку с параметром maximum-rotate
<param name="maximum-rotate" value="5"/>
И потом вот эту строчку, определяющую максимальный размер файла::
<param name="rollover" value="10485760"/>
Перезапускаем freeswitch:
# systemctl restart freeswitch.service
Иногда лог-файлы freeswitch переполняются и Freeswitch не может нормально работать. При этом в консоли fs_cli постоянно сыпятся логи:
2016-05-21 19:00:25.931136 [NOTICE] mod_logfile.c:213 New log started.
2016-05-21 19:00:25.931136 [NOTICE] mod_logfile.c:213 New log started.
В этом случае необходимо остановить freeswitch
# systemctl stop freeswitch.service
Затем удалить файл логов и вновь создать его
# rm -f /var/log/freeswitch.log
# touch /var/log/freeswitch.log
# chown freeswitch:freeswitch /var/log/freeswitch.log
Затем запустить Freeswitch заново:
# systemctl restart freeswitch.service
Установка русских звуков в freeswitch
# cd /usr/local/freeswitch/conf
# nano vars.xml
Вставляем строку
<X-PRE-PROCESS cmd="set" data="default_language=ru"/>
В консоли fs выполняем
> reloadxml
Создание нового профиля:
# /usr/local/freeswitch/conf
# touch sip_profiles/supportsvttk.xml
# nano sip_profiles/supportsvttk.xml
Содержимое файла
<aliases>
</aliases>
<gateways>
<X-PRE-PROCESS cmd="include" data="supportsvttk/*.xml"/>
</gateways>
<domains>
<!-- Псевдонимы не создаются, все домены сканируются на предмет подключения gateway -->
<domain name="all" alias="false" parse="true"/>
</domains>
<settings>
<param name="user-agent-string" value="FreeSWITCH TTK"/> <!-- Название SIP-агента-->
<param name="caller-id-type" value="rpid"/> <!-- Remote-Party-ID header -->
<!--Диагностика -->
<param name="debug" value="0"/> <!-- Дебаг отключен -->
<param name="sip-trace" value="no"/> <!-- Трассировка отключена -->
<param name="sip-capture" value="no"/> <!-- Захват SIP трафика отключен -->
<param name="log-auth-failures" value="true"/> <!-- Включаем логи неуспешных попыток авторизации-->
<!-- Параметры DTMF -->
<param name="rfc2833-pt" value="101"/> <!-- Идентификатор DTMF 2833 в трафике RTP-->
<param name="dtmf-duration" value="2000"/>
<param name="dtmf-type" value="rfc2833"/>
<param name=”liberal-dtmf” value=”true”/> <!-- всегда предлагать rfc2833, а принимать и rfc2833, и info dtmf -->
<!-- Параметры WatchDOG (перезапуск сервера, если он вдруг перестал отвечать) - выключен -->
<param name="watchdog-enabled" value="false"/>
<!-- Главные параметры! На каком порту и на каком Ip адресе будет работать профиль-->
<param name="sip-port" value="5060"/>
<param name="sip-ip" value="$${local_ip_v4}"/>
<param name="rtp-ip" value="$${local_ip_v4}"/>
<param name="nonce-ttl" value="60"/> <!-- Параметр TTL-->
<param name="ext-rtp-ip" value="auto-nat"/>
<param name="ext-sip-ip" value="auto-nat"/>
<!-- ACL: Access List -->
<!--<param name="apply-nat-acl" value="nat.auto"/>-->
<!--<param name="local-network-acl" value="localnet.auto"/>-->
<param name="apply-inbound-acl" value="alcgw"/>
<!-- С подсетей указанных в aclgw в файле autoload_configs/acl.conf.xml разрешено совершать звонки без аутентификации -->
<!--<param name="apply-register-acl" value="acluserreg"/>-->
<!--Глобальный ACL для регистрации. Лист нужно создать в autoload_configs/acl.conf.xml-->
<!-- -->
<param name="dialplan" value="XML"/>
<param name="context" value="supportsvttk"/> <!-- Какой dialplan будет включаться при приходе вызова -->
<param name="max-proceeding" value="2000"/><!-- Максимальное количество обрабатываемых диалогов -->
<param name="hold-music" value="$${hold_music}"/><!-- MOH -->
<param name="all-reg-options-ping" value="true"/> <!-- Отправлять периодически параметры OPTION в сторону клиента -->
<param name="nat-options-ping" value="true"/> <!-- Отправлять периодически параметры OPTION в сторону клиента за NAT -->
<param name="unregister-on-options-fail" value="true"/> <!-- Убивать регистрацию, если пакеты OPTION не имеют ответа -->
<param name="sip-options-respond-503-on-busy" value="true"/><!-- Отвечать на SIP OPTION ошибкой 503, если у FS проблема -->
<param name="auth-calls" value="true"/><!--авторизация включена глобально-->
<param name="inbound-reg-force-matching-username" value="true"/> <!-- User и authuser должны совпадать-->
<!-- Кодеки и RTP -->
<param name="inbound-codec-prefs" value="PCMA, PCMU"/>
<param name="outbound-codec-prefs" value="PCMA, PCMU"/>
<param name="disable-transcoding" value="true"/><!-- Отключить перекодироку. FS будет предлагаеть удаленной стороне только кодеки вызывающей стороры-->
<param name=”inbound-codec-negotiation” value="generous"/> <!-- Кто главный в выборе кодека generous - удаленная сторона -->
<param name="inbound-late-negotiation" value="true"/> <!-- Сначала читаем dialplan, потом выбираем кодек -->
<param name="rtp-timer-name" value="soft"/>
<param name="auto-jitterbuffer-msec" value="60"/><!-- Буфер для сглаживания rtp jitterа -->
<param name="rtp-timeout-sec" value="300"/> <!-- Период неактивности RTP, после которого соединение разрывается -->
<param name="rtp-hold-timeout-sec" value="1800"/> <!-- Период неактивности RTP, после которого соединение разрывается -->
<!-- Прочие параметры SIP -->
<param name="enable-timer" value="false"/> <!-- Включить таймеры RFC 4028 SIP Session Timers
Этот механизм определяет и исправляет SIP каналы которые не были закрыты нормальным способом-->
<param name="auth-all-packets" value="false"/> <!-- Не используется аутентификация при получении всех пакетов (только register и invite)-->
<param name="enable-100rel" value="true"/>
<param name="challenge-realm" value="auto_from"/> <!-- Установка realm, используется поле from в качестве значения SIP realm-->
<param name="manage-presence" value="true"/> <!--Для того что бы юзеры могли подписываться на извещение состояния сервера сообщением SUBSCIBE -->
<param name="accept-blind-auth" value="false"/><!-- если установлен в true, то любая аутентификация принимается без проверки -->
<param name="accept-blind-reg" value="false"/><!-- если установлен в true, то любая регистрация принимается без проверки-->
</settings>
</profile>
Создание папки для файлов с описанием каналов – шлюзов – gateway-ев
# mkdir sip_profiles/supportsvttk
Добавляем права на созданные файлы и папки и перезагружаемся:
# systemctl restart freeswitch
Проверяем в консоли Freeswitch и убеждаемся, что наш профиль загрузился:
> sofia status
Name Type Data State
===================================================================================
supportsvttk profile sip:mod_sofia@10.200.16.215:5060 RUNNING (0)
===================================================================================
1 profile 0 aliases
и
> sofia status profile supportsvttk
==================================================================================
Name supportsvttk
Domain Name N/A
Auto-NAT false
DBName sofia_reg_supportsvttk
Pres Hosts
Dialplan XML
Context supportsvttk
Challenge Realm auto_from
RTP-IP 10.200.16.215
SIP-IP 10.200.16.215
URL sip:mod_sofia@10.200.16.215:5060
BIND-URL sip:mod_sofia@10.200.16.215:5060;transport=udp,tcp
HOLD-MUSIC local_stream://moh
OUTBOUND-PROXY N/A
CODECS IN PCMA, PCMU
CODECS OUT PCMA, PCMU
TEL-EVENT 101
DTMF-MODE rfc2833
CNG 13
SESSION-TO 0
MAX-DIALOG 2000
NOMEDIA false
LATE-NEG true
PROXY-MEDIA false
ZRTP-PASSTHRU false
AGGRESSIVENAT false
CALLS-IN 0
FAILED-CALLS-IN 0
CALLS-OUT 0
FAILED-CALLS-OUT 0
REGISTRATIONS 0
Проверяем порты, слушающие Freeswitch:
# netstat -ltupn | grep freeswi
tcp 0 0 0.0.0.0:8021 0.0.0.0:* LISTEN 16146/freeswitch
tcp 0 0 10.200.16.215:5060 0.0.0.0:* LISTEN 16146/freeswitch
udp 0 0 10.200.16.215:5060 0.0.0.0:* 16146/freeswitch
После изменения параметров профиля, его перезагрузку можно выполнить так:
# fs_cli -x "sofia profile supportsvttk killgw samara-ast1" && sleep 30 && fs_cli -x "sofia profile supportsvttk rescan"
Создание описания абонентов
Создадим трех абонентов – 11, 12, 50
# cd /usr/local/freeswitch/conf/directory
Создаем общий файл описания абонентов
# touch supportsvttk.xml
Содержимое файла:
<include>
<domain name="sip.svttk.ru">
<params>
<param name="dial-string" value="{presence_id=${dialed_user}@${dialed_domain}}${sofia_contact(${dialed_user}@${dialed_domain})}"/>
</params>
<variables>
<variable name="record_stereo" value="true"/>
</variables>
<groups>
<group name=" sip.svttk.ru ">
<users>
<X-PRE-PROCESS cmd="include" data="supportsvttk/*.xml"/>
</users>
</group>
</groups>
</domain>
</include>
Домен sip.svttk.ru должен быть прописан в DNS. В нашем случае на Ip 10.200.16.215
Далее создаем папку, где для каждого абонента будет создаваться отдельный файл с его описанием:
# mkdir supportsvttk
Наконец файлы абонентов создаем по шаблону:
# touch supportsvttk/11.xml
# nano supportsvttk/11.xml
Содержимое файла:
<include>
<user id="12"> <!-- Номер и логин -->
<params>
<!-- Пароль для регистрации. Если его не будет - авторизация будет идти по IP адресу-->
<param name="password" value="12345xyz"/>
<!-- IP адрес с которого можно авторизовываться. Если его не будет, то авторизовываться можно с любого ip -->
<param name="auth-acl" value="10.10.0.0/16,192.168.1.0/24"/>
</params>
<variables>
<variable name="dtmf-type" value="rfc2833"/> <!-- режим DTMF -->
<variable name="user_context" value="supportsvttk"/> <!-- контекст номера -->
<!--Можно задать имя и номер, которое будут подставляться при всех исх вызовах с номера-->
<!--<variable name="effective_caller_id_name" value="2057553"/>-->
<!--<variable name="effective_caller_id_number" value="2057553"/>-->
<variable name="sip-force-expires" value="3600"/> <!-- период перерегистрации -->
</variables>
</user>
</include>
Аналогично создаются и другие файлы 12.xml и 50.xml
Пробуем зарегистрироваться на сервере 10.200.16.215 на порту 5060 с логином 11, 12 или 50 и паролем 12345xyz.
Настройки ZoyPer:
Регистрация прошла успешно.
При регистрации в консоли будет писаться:
2016-05-15 18:27:39.192559 [WARNING] sofia_reg.c:1775 SIP auth challenge (REGISTER) on sofia profile 'supportsvttk' for [11@sip.svttk.ru] from ip 10.10.69.141
2016-05-15 18:27:39.212547 [DEBUG] sofia_reg.c:3002 IP [10.10.69.141] passed ACL check [10.10.69.0/24,192.168.1.0/24]
Проверка статуса регистрации абонентов
Для всех абонентов:
> sofia status profile supportsvttk reg
Для конкретного абонента
> sofia status profile supportsvttk reg 11
Или для конкретного абонента можно посмотреть и так
> sofia status profile supportsvttk reg 11@10.10.69.141
Registrations:
==================================================================================
Call-ID: Mzk2ZDQyNThiMDhmNmU1MjAxZmVlMDJhODcyMTZiYzc.
User: 11@sip.svttk.ru
Contact: "11" <sip:11@10.10.69.141:5060;rinstance=e4f819a88eee6403;transport=UDP>
Agent: Zoiper for Windows 2.38 rev.16635
Status: Registered(UDP)(unknown) EXP(2016-05-15 19:28:39) EXPSECS(3170)
Ping-Status: Reachable
Ping-Time: 9.57
Host: kvs.svttk.ru
IP: 10.10.69.141
Port: 5060
Auth-User: 11
Auth-Realm: sip.svttk.ru
MWI-Account: 11@sip.svttk.ru
Total items returned: 1
==================================================================================
Обновить регистрацию конкретного абонента
> sofia profile supportsvttk flush_inbound_reg 11@10.10.69.141 reboot
Если не написать, кого сбрасываем, то обнуляться все регистрации.
> sofia profile supportsvttk flush_inbound_reg reboot
Диалог SUBSCRIBE и NOTIFY.
В описанной настройке не используется диалог SUBSCRIBE и NOTIFY. Этот диалог разрешает пользователю подписаться на события сервера и получать периодически уведомления о его состоянии. Включение этого диалога выполняется на
- SIP клиенте. В ZoyPer «Subscribe for MWI»=«both»
- На сервере freeswitch в sip профиле параметр <param name="manage-presence" value="true"/>
Диалог SUBSCRIBE и NOTIFY выглядит так, как показано ниже. При этом проверка состояния клиента запросами OPTION не производиться.
Другие варианты диалога, при выключенной возможности на Freeswitch и при выключенной возможности на стороне клиента:
В последнем случае Freeswitch в текущей конфигурации будет проверять состояние клиента запросами OPTION.
Создание внутреннего плана набора
Создадим базовую конфигурацию dialplan и дадим возможность абонентам звонить друг другу.
# cd /usr/local/freeswitch/conf
# touch dialplan/supportsvttk.xml
# nano dialplan/supportsvttk.xml
Содержимое файла:
<include>
<context name="supportsvttk">
<!-- Модуль защиты от закольцовывания звонков-->
<extension name="unloop">
<condition field="${unroll_loops}" expression="^true$"/>
<condition field="${sip_looped_call}" expression="^true$">
<action application="deflect" data="${destination_number}"/>
</condition>
</extension>
<X-PRE-PROCESS cmd="include" data="supportsvttk/*.xml"/>
</context>
</include>
Этот файл описывает правила обработки и предотвращения петель.
Далее создаем папку, где будут храниться правила набора:
# mkdir dialplan/supportsvttk
# touch dialplan/supportsvttk/01_internal.xml
# nano dialplan/supportsvttk/01_internal.xml
Содержимое файла:
<include>
<extension name="call_internal">
<condition field="destination_number" expression="^(1[12])$|^(50)$">
<!-- Звоним -->
<action application="bridge" data="user/$1@sip.svttk.ru"/>
<!-- Кладем трубку -->
<action application="hangup"/>
</condition>
</extension>
</include>
Меняем права на созданные файлы и рестартуемся.
Теперь абоненты 11,12 и 50 могут позвонить друг другу по коротким номерам. Вызываемый абонент увидит в АОН короткий номер вызывающего абонента.
Исходящая и входящая связь. Asterisk.
Связь с внешним миром (с ТфОП) будет обеспечиваться через сервер Asterisk и станцию Si3000 ISKRATEL.
Соединение с Asterisk происходит с помощью номера 2057553
Входящие вызовы на 2057553 направляются на внутренний номер 12.
Конфигурация Asterisk:
Файл /etc/asterisk/extensions.conf:
[test-2057553]
exten => _XXXXXXX,1,Dial(${OUTTRUNKSI}/${EXTEN},120,t)
exten => _XXXXXXX,n,Hangup()
exten => _8XXXXXXXXXX,1,Dial(${OUTTRUNKSI}/${EXTEN},120,t)
exten => _8XXXXXXXXXX,n,Hangup()
;Во входящем контексте со стороны Si3000:
exten => 2057553,1,Dial(SIP/2057553gw/${EXTEN},120,t)
exten => 2057553,n,Hangup()
Файл /etc/asterisk/extensions.conf:
[2057553gw] ; тест Freeswitch
type=peer
host=10.200.16.215
port=5060
context=test-2057553
dtmfmode=rfc2833
deny=0.0.0.0/0.0.0.0
permit=10.200.16.215/255.255.255.255
insecure=port,invite
qualify=yes
disallow=all
allow=ulaw
allow=alaw
Создаем файл конфигурации шлюза на Freeswitch на номер 2057553.
# touch sip_profiles/supportsvttk/gw2057553.xml
# nano sip_profiles/supportsvttk/gw2057553.xml
Содержимое файла описание каналов - gateways:
<gateway name="samara-ast1">
<param name="username" value="xxx"/><!--Можно указать любое имя, главное, что бы оно было-->
<param name="password" value="yyy"/><!--Можно указать любой пароль, главное, что бы он был-->
<param name="register" value="false"/>
<param name="realm" value="10.200.104.12"/>
<param name="from-domain" value="sip.svttk.ru"/>
<!-- дополнительные параметры, если на удаленном сервере нужно регистрироваться -->
<!-- При это нужно выставить name="register" value="true" -->
<!--<param name="proxy" value="10.200.104.12"/>-->
<!--<param name="register-proxy" value="10.200.104.12"/>-->
<!--<param name="expire-seconds" value="3600"/>--> <!--Период регистрации-->
<!--<param name="retry-seconds" value="30"/>--> <!--Количество сек ожидания перед повторной регистрацией, если регистрация вдруг была неудачной-->
<!--<param name="ping" value="25"/>--> <!--ОТправлять ping каждые 25 сек. При неответе считает шлюз аварийным и регистрацию прерываем -->
<param name="context" value="supportsvttk"/><!-- Контекст для входящих вызовов-->
<param name="caller-id-in-from" value="true"/> <!-- Использовать АОН входящего вызова в поле from исх вызовов через этот шлюз-->
<!--<param name="contact-params" value="tport=tcp"/>--> <!--extra sip params to send in the contact-->
</gateway>
Для того что бы Freeswitch установил соединение с IP удаленного сервера, как видно достаточно указать этот IP адрес в переменной realm. Это возможно потому, что часть переменных, при их отсутствии заменяется вышестоящими. На рисунке показана зависимость значений некоторых параметров друг от друга в описании gateway:
Параметр gateway name – самый главный, его обязательно нужно указывать. Параметр realm, если не указано другое, принимает значение gateway name. Параметр from-domain, если не указано другое, принимает значение realm и т.д.
Для того что бы разрешить Asterisk-у устанавливать соединения с Freeswitch без регистрации необходимо на Freeswitch создать список доступа – ACL, имя которого будет указано в переменной apply-inbound-acl файла sip-профиля sip_profiles/supportsvttk.xml. В созданном ранее sip-профиле имя этого списка доступа alcgw.
<param name="apply-inbound-acl" value="alcgw"/>
Список доступа alcgw создается в файле autoload_configs/acl.conf.xml
# nano autoload_configs/acl.conf.xml
Добавляем между тегами <network-lists> и </network-lists> блок:
<list name="alcgw" default="deny">
<node type="allow" cidr="10.200.104.12/32"/>
</list>
При попадании входящего вызова в ACL авторизация запрашиваться не будет. Это справедливо и для файлов из sip_profiles и для файлов из directory.
Применяем к созданным файлам права пользователя freeswitch и рестартуем сервис Freeswitch.
# chown -R freeswitch:freeswitch /usr/local/freeswitch/conf/
# chmod -R 770 /usr/local/freeswitch/conf/
# systemctl restart freeswitch.service
Проверяем состояние созданного канала:
Статус на Asterisk:
# asterisk -rx "sip show peer 2057553gw"
* Name : 2057553gw
Context : test-korolev-2057553
Transfer mode: open
CallingPres : Presentation Allowed, Not Screened
Expire : -1
Insecure : port,invite
DTMFmode : rfc2833
ToHost : 10.200.16.215
Addr->IP : 10.200.16.215:5060
Defaddr->IP : (null)
Codecs : (ulaw|alaw)
Status : OK (1 ms)
Статус на Freeswitch:
freeswitch@kvs.svttk.ru> sofia status gateway samara-ast1
===================================================================
Name samara-ast1
Profile supportsvttk
Scheme Digest
Realm 10.200.104.12
Username xxx
Password yes
From <sip:xxx@sip.svttk.ru>
Contact <sip:gw+samara-ast1@10.200.16.215:5060;tport=tcp;transport=udp;gw=samara-ast1>
Exten xxx
To sip:xxx@10.200.104.12
Proxy sip:10.200.104.12
Context supportsvttk
Expires 3600
Freq 3600
Ping 0
PingFreq 0
PingTime 0.00
PingState 0/0/0
State NOREG
Status UP
Uptime 1335s
CallsIN 0
CallsOUT 1
FailedCallsIN 0
FailedCallsOUT 0
===================================================================
После изменения параметров описания шлюза (файла gw2057553.xml), его рестарт можно выполнить так:
# fs_cli -x "sofia profile supptechttk stop" && sleep 30 && fs_cli -x "sofia profile supptechttk start"
Создаем файлы описания диалпланов входящей и исходящей связи:
# touch dialplan/supportsvttk/10_in.xml
# touch dialplan/supportsvttk/20_out.xml
# nano dialplan/supportsvttk/10_in.xml
Содержимое файла:
<include>
<extension name="call_in">
<condition field="destination_number" expression="^(2057553)$">
<!-- Звоним -->
<action application="bridge" data="user/12@sip.svttk.ru"/>
<!-- Кладем трубку -->
<action application="hangup"/>
</condition>
</extension>
</include>
# nano dialplan/supportsvttk/20_out.xml
Содержимое файла, разрешающего звонить на 7ми значные номера:
<include>
<extension name="call_out">
<condition field="destination_number" expression="^([2-9][0-9]{6})$">
<action application="set" data="hangup_after_bridge=true"/>
<action application="set" data="continue_on_fail=true"/>
<!--Выставляем номер и имя у вызывающего абонента через данный шлюз-->
<action application="set" data="effective_caller_id_number=2057553"/>
<action application="set" data="effective_caller_id_name=2057553"/>
<action application="bridge" data="sofia/gateway/samara-ast1/$1"/>
<action application="hangup"/>
</condition>
</extension>
</include>
Теперь можно звонить в город по ТфОП и принимать входящие вызовы на номер 2057553 абонентом 12. При выходе в город в качестве АОН будет подставляться номер 2057553.
При установлении вызова от абонента, каждый раз будет проходить процедура авторизации абонента. При этом на Freeswitch для клиента будут иницироваться переменные из профиля пользователя, которым можно в последствии манипулировать. Нормальная процедура авторизации при установлении вызова:
Для трассировки вызовов во Freeswitch существуют команды, включающие трассировки на профиле:
Включение / выключение трассировки в консоли Freeswitch:
> sofia profile supportsvttk siptrace on
> sofia profile supportsvttk siptrace off
При включенной трассировки в консоль будут ввалиться SIP сообщения вместе с основными событиями:
Изменить степень детализации логов консоли можно так:
> console loglevel 7 (режим DEBUG)
> console loglevel 6 (по умолчанию INFO)
> console loglevel – покажет текущий режим консоли
Уровни логирования могут быть такие:
0 "CONSOLE",
1 "ALERT",
2 "CRIT",
3 "ERR",
4 "WARNING",
5 "NOTICE",
6 "INFO",
7 "DEBUG"
Исходящая и входящая связь. Si3000.
# touch sip_profiles/supportsvttk/gw9938103.xml
# nano sip_profiles/supportsvttk/gw9938103.xml
Содержимое файла:
<gateway name="samara-si3000">
<param name="username" value="xxx"/><!--Можно указать любое имя, главное, что бы оно было-->
<param name="password" value="yyy"/><!--Можно указать любой пароль, главное, что бы он был-->
<param name="register" value="false"/>
<param name="realm" value="10.200.101.11"/>
<param name="from-domain" value="sip.svttk.ru"/>
<!-- дополнительные параметры, если на удаленном сервере нужно регистрироваться -->
<!-- При это нужно выставить name="register" value="true" -->
<!--<param name="proxy" value="10.200.101.11"/>-->
<!--<param name="register-proxy" value="10.200.101.11"/>-->
<!--<param name="expire-seconds" value="3600"/>--> <!--Период регистрации-->
<!--<param name="retry-seconds" value="30"/>--> <!--Количество сек ожидания перед повторной регистрацией, если регистрация вдруг была неудачной-->
<!--<param name="ping" value="25"/>--> <!--ОТправлять ping каждые 25 сек. При неответе считает шлюз аварийным и регистрацию прерываем -->
<param name="context" value="supportsvttk"/><!-- Контекст для входящих вызовов-->
<param name="caller-id-in-from" value="true"/> <!-- Использовать АОН входящего вызова в поле from исх вызовов через этот шлюз-->
<!--<param name="contact-params" value="tport=tcp"/>--> <!--extra sip params to send in the contact-->
</gateway>
Добавляем маршрут для входящей связи:
# nano dialplan/supportsvttk/10_in.xml
Приводим файл к виду:
<include>
<extension name="call_in">
<condition field="destination_number" expression="^(2057553)$">
<!-- Звоним -->
<action application="bridge" data="user/12@sip.svttk.ru"/>
<!-- Кладем трубку -->
<action application="hangup"/>
</condition>
</extension>
<extension name="call_in_si3000">
<condition field="destination_number" expression="^(9938103)$">
<!-- Звоним -->
<action application="bridge" data="user/11@sip.svttk.ru"/>
<!-- Кладем трубку -->
<action application="hangup"/>
</condition>
</extension>
</include>
Разрешаем Si3000 соединяться с Freeswitch без регистрации:
# nano autoload_configs/acl.conf.xml
Меняем ACL – alcgw. Добавляем туда IP 10.200.101.11.
<list name="alcgw" default="deny">
<node type="allow" cidr="10.200.104.12/32"/>
<node type="allow" cidr="10.200.101.11/32"/>
</list>
# chown -R freeswitch:freeswitch /usr/local/freeswitch/conf/
# chmod -R 770 /usr/local/freeswitch/conf/
# systemctl restart freeswitch.service
При работе со станцией Si3000 нужно иметь ввиду, что станция SI3000 для обмена сигнальными сообщениями используется один ip адрес (в нашем случае – 10.200.101.11), а для обмена RTP сообщениями – другие IP адреса (в нашем случае – 10.200.101.13). IP адрес 10.200.101.13 не нужно добавлять в ACL alcgw.
В описанной конфигурации RTP сообщения будут проходить через Freeswitch. Используя опцию bypass_media можно разрешить обмен сообщениями RTP между конечными точками напрямую.
Диаграмма работы Freswitch с Si3000 при входящем вызове будет следующей:
Вот и все