Связать два freepbx

Обновлено: 28.03.2024

Обратимся к автомобильным кодам регионов.
Тогда дозвон из Самары будет 9-16-.
Из Казани 9-63-.

Для начала советую ознакомиться чем IAX2 лучше по сравнению с SIP для взаимодействия server-2-server.

Не важно имеют ли астериски прямой выход в интернет. Главное — пробросить UDP порт 4569.
В прошлой статье я описал как реализовать связь по SIP. Теперь дошла очередь IAX2. Тем более, что этот протокол для этого и создавался.

Еще один аспект — использование правильного кодека. По личному опыту лучше всего подходит G729. Вы его можете найти в интернете и загрузить в астериск в интерфейсе CLI посредством команды module load codec_g729.so.

iax.conf 1-го (самарского) астериска
[general]
disallow=all
allow=g729
allow=gsm
allow=alaw
allow=ulaw
bindaddr=0.0.0.0
calltokenoptional = 0.0.0.0/0.0.0.0
delayreject=yes

; for incoming
[kazan]
type=friend
qualify=yes
auth=md5
trunk=yes
username=kazan
secret=password4kazan
host=dynamic
context=office_rules

extensions.conf 1-го (самарского) астериска
.
[office]
exten => _916.,1,Set(CALLERID(all) )
exten => _916.,n,NoOp($)
exten => _916.,n,Dial(IAX2/samara:password4samara@kazan/$,60,tT)
exten => _916.,n,HangUp
.

[office_rules]
exten => _[12]XX,1,Dial(SIP/$,60,tT)
exten => _[12]XX,n,HangUp

iax.conf 2-го (казанского) астериска
[general]
disallow=all
allow=g729
allow=gsm
allow=alaw
allow=ulaw
bindaddr=0.0.0.0
calltokenoptional = 0.0.0.0/0.0.0.0
delayreject=yes

; for incoming
[samara]
type=friend
qualify=yes
auth=md5
trunk=yes
username=samara
secret=password4samara
host=dynamic
context=office_rules

extensions.conf 2-го (казанского) астериска
.
[office]
exten => _963.,1,Set(CALLERID(all) )
exten => _963.,n,NoOp($)
exten => _963.,n,Dial(IAX2/kazan:password4kazan@samara/$,60,tT)
exten => _963.,n,HangUp
.

[office_rules]
exten => _[12]XX,1,Dial(SIP/$,60,tT)
exten => _[12]XX,n,HangUp

Несколько комментариев.
1. Очень важно внешним абонентам дать возможность звонить только на внутренние номера.
Контекст office должен быть описан для ваших офисных пользователей, там же вы можете описать звонки в город и по межгороду.
Контекст office_rules используется для внешних абонентов — разрешаем там только звонить на внутренние номера (3-х значные, которые начинаются с 1 или с 2).
2. При звонках используется конструкция:
Dial(IAX2/login:password@iax-account/. )

Суть в том, что мы звоним с авторизацией на сервер, который смог у нас зарегистриваться для учетной записи iax-account. Как и в случае с SIP, можно указывать несколько директив register.
3. В примере внутри офиса используются клиенты, подключенные по SIP.
4. Просмотреть регистрации для IAX2 можно командой iax2 show registry.
5. Для случая, если астериск находится за NAT. Допустим для определения провайдера при исходящем трафике у вас используются отдельные ай-пи адрес (например, 192.168.4.5 — один провайдер, 192.168.14.5 — другой провайдер), а на шлюзе идет проброс на ай-пи адрес исходя из провайдера.

В этом случае, чтобы срабатывала регистрация, нужно в описание пиров на нашем астериске добавить:
sourceaddress=192.168.4.5
sourceaddress=192.168.14.5
Такая конструкция на текущей версии позволяет добиться множественной регистрации одного пира на нескольких провайдерах. Т.е. грубо говоря, имеем возможность несколько раз сказать, что «у нас такой-то IP адрес».
Пример
iax2 show registry:
Host dnsmgr Username Perceived Refresh State
155.15.75.270:4569 N peer1 72.255.69.78:4569 60 Registered
92.14.191.35:4569 N peer1 72.255.69.78:4569 60 Registered

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

Самым удобным решение будет использование протокола IAX2. Он работает через один порт (по умолчанию 4569) и обеспечивает более надежное соединение, особенно если сервера находятся за NAT. Так же, обычно, он расходует меньше трафика за счет исключения сервисных заголовков.

Описание имеющейся инфраструктуры

Имеем два сервера в Москве и Санкт-Петербурге. Оба видят друг друга через интернет и имеют статические адреса:

192.168.0.100 — Москва (внутренние номера 100-199)

192.168.0.200 — Санкт-Петербург (внутренние номера 200-299)

Между серверами проброшена шифрованная VPN сеть (поэтому адреса внутренние) для обеспечения безопасности соединений. Конечно можно и без неё, но тогда все наши звонки потенциально могут быть перехвачены.

Настройка серверов

Оба сервера настраиваются одинаково. Меняется только ip адрес и название контекста транка. Создадим новый транк на сервере в Москве


Создание нового IAX2 транка

В первом окне оставляем все по умолчанию, вводим только любое удобное название транка.

Далее переходим к самой ответственной части. На кладке «iax Общие настроки» нужно прописать конфигурацию для входящих и исходящих соединений. Различаться она будет только названием контекста. В параметре host указываем ip адрес сервера в Санкт-Петербурге.

Первый сервер настроен, на сервере в Санкт-Петербугре прописывает все аналогичным образом, только меняем host на 192.168.0.100.

Если все сделано правильно, то на обоих серверах если в консоли прописать «iax2 show peers» увидим по два (входящий и исходящий) соединения со статусом OK.

Так как мы объединяем два сервера с фиксированными статическими ip адресами, то можно настроить аутентификацию по адресу. Если адрес одной или обеих машин не фиксированы, то можно настроить аутентификацию через логин и пароль. Тогда настройка будет такой и на втором сервере надо будет прописать строку регистрации

Настройка строки регистрации:

Настройка маршрутизации звонков

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

На московском сервере настроим маршрутизацию звонков для номеров 200 (2XX) в наш новый настроенный транк. Для этого во вкладке «Подключения» выберем пункт «Исходящая маршрутизация»


Кнопка настройка исходящей маршрутизации

На открывшейся странице нажимаем кнопку «Добавить маршрут». Необходимо заполнить поле «Название маршрута» любым удобным названием. Выбрать тип маршрута — «Внутрикорпоративный» и в пункте » Последовательность транков для совпавших маршрутов» выбрать наш настроенный транк. Все остальное оставляем по-умолчанию.


Создание нового исходящего маршрута

Далее переходим на вкладку Правила набора. В поле «совпадение шаблона» вбиваем шаблон номеров второго сервера — это 200-299. В качестве шаблона он будет выглядеть как 2XX, где X будет определяться как любая цифра.


Шаблон транка

Создаем новый маршрут и на общей странице исходящей маршрутизации переместим его на самый верх чтобы он проверялся раньше других. Теперь все запросы на номера 2XX будут отправляться в транк to_spb и пересылаться на соответствующий сервер.

Связь трех и более серверов

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

Первый вариант — линейное объединение, когда сервера связываются последовательно и вызов проходит через все сервера пока не найдет нужного абонента. При этом трафик звонка так же будет идти через все сервера, что может создать большую задержку при их большом количестве. Сервер один связывается по протоколу IAX2 с сервером два, сервер два с сервером 3 и так далее. Настройками маршрутизации выбирается связанный сервер и вызов по цепочке передается пока не найдет нужного абонента.

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

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

Хочу рассмотреть простейший способ соединить две АТС на базе популярнейшей системы FreePBX. А чтобы нас не слушало ни АНБ, ни ФСБ — добавим шифрование.

В этом примере соединяем Москву и Питер. В Москве у нас номера вида 1XX, в Питере вида 2XX.

1. В Москве создаём новый IAX2 транк

Trunk name: spb
Outbound Caller ID: не важен
Trunk name (повторно): spb

Подставьте свои пароль (подлиннее) и host (имя а лучше адрес удалённого сервера).
В теге allow замените кодек на тот, который вам нравится. Я рекомендую Speex и iLBC как современные и свободные кодеки с хорошим качеством звука и хорошим сжатием.
Если сеть плохая, можно добавить jitterbuffer=yes обязательно в комплекте с trunktimestamps=yes

Всё! Здесь больше ничего не нужно заполнять.

2. В Питере делаем всё то же самое, но немного наоборот — где в пункте один spb, там пишем msk, а где msk, пишем spb.

3. Создаём outbound route. Ставим галочку intra-company, а в поле match pattern в Москве пишем 2XX, в Питере 1XX.

4. Если нужно — открываете/пробрасываете UDP порт 4569

5. В консоли (или в меню tools) команда iax2 show peers должна показать что-то вроде:

Всё в порядке, теперь можно звонить напрямую, просто набрав внутренний номер офиса в другом городе.

Разумно проектируйте план набора для каждого сервера, чтобы было сразу понятно, какому из серверов принадлежит тот или иной экстеншен, при наборе номера на любом из серверов. Например, используйте номера 3xxx для сервера A, 4xxx - для сервера B и 5xxx - для номеров экстеншенов, подключенных к серверу C.

Используйте директиву «switch», для того, чтобы сервер A искал на сервере B те екстеншены, которые не известны на сервера A (оба сервера должны всегда быть в рабочем состоянии и доступны, иначе у Вас будут присутствовать большие задержки между моментом набором номера и какой-либо реакции на это действие!)

Метод с использованием SIP протокола.

Когда мы рассматриваем файл sip.conf, то возможно стоит начать с указания типа клиента, как type=friend, на обоих серверах, и, если при этом все начнет нормально работать, Вам, возможно, захочется разделить эту запись по типам: peer - для исходящих вызовов и user - для входящих вызовов. Также, стоит обратить внимание в файле sip.conf на параметры «insecure=very» («insecure=port,invite» в версии 1.4) и, возможно, на параметр: «autocreatepeer=yes».

Сервер A - имеет статический IP адрес, сервер B - динамический IP адрес: Тогда для сервера B нужно прописать строку регистрации на сервере A в sip.conf.

Настройка IAX канала.

Настройте Asterisk сервера с обеих сторон в файле конфигурации in iax.conf, один, как peer, а другой - как user.

Настройте план набора в файле extensions.conf для сервера с пользователем типом user так, чтобы можно было принимать вызовы с другова сервера от пользователя с типом peer.

Не обязательно, зарегистрируйте пользователя с типом peer, на сервере с пользователем типом user (для случаев, когда, например, сервер с пользователем типа peer имеет динамический ip адрес, который неизвестен второй стороне.)

Повторите вышеуказанные шаги, поменяв местами сервер A и B (добавив пользователей, поменяв местами тип peer и user), если вы хотите совершать вызовы в обоих направлениях.

Определение пользователя IAX2 типа user.

Пользователь, типа user - принимает вызовы. Следующие параметры необходимо указать в файле iax.conf на машине с пользователем типа user для проверки (авторизации) перед тем, как позволить ему нас вызвать.

Параметр «context» - очень важен, он устанавливает имя локального контекста, куда будут попадать входящие вызовы от пользователей (Смотри описание файла: extensions.conf ).

Эта настройка позволяет удаленному пользователю зарегистрироваться на Вашем сервере с любого адреса. Если Вы хотите ограничить доступ по IP адресам или хостам, добавьте параметры: permit или deny, в описание Ваших пользователей в файле iax.conf.

Определение пользователя IAX2 типа peer.

Пользователь, типа peer совершает вызовы. Следующие параметры необходимо указать в файле iax.conf на машине с пользователем типа peer для своей идентификации (авторизации) на машине с пользователем типа user, перед тем, как совершить вызов.

Обратите внимание:

Использование типа «type=friend» делает жизнь проще, но не долго. Если вы добавите одновременно: «type=friend» и «host=hostname@domain.ext», то этим вы ограничите одним хостом, число тех серверов, с которых эта учетная запись может принять вызов на обработку, что, возможно, совсем не то, что Вам нужно.

Для инструкций по поводу использования директивы «auth=rsa», см: Asterisk IAX RSA авторизация?.

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

Соединение планов набора.

Пример 1

Пример 2

В некоторых случаях, параметры serverA и serverB, должны содержать имя пользователя сервера.

Пример 3

С помощью объекта Switch в файле extensions.conf Вы можете соединить два сервера Asterisk и план набора другова сервера. В данном случае, наш «server C» или соединяется с «server A» или с «server B»:

Замечания: Вы не можете установить замкнутую цепочку, используя switch с serverA на serverB и с serverB на serverA! Также, обратите внимание на (новую) установку в файле iax.conf «autokill=», которая предотвращает длительное зависание, если удаленный сервер не работает или отсоединился.

Пример 4

В файле extensions.conf (на master):

В файле iax.conf (на master):

В файле extensions.conf (на slave):

Команда register.

Когда ip адрес клиента типа user неизвестен, пользователь типа peer не знает, куда совершать вызов (например, при вызове из офиса сотрудника, который работает на дому, когда у него имеется только динамически назначаемый ip адрес или он находиться за NAT .) Для решения этой задачи, домашний работник активно регистрируется на сервере в офисе, предоставляя свои данные и местоположение в сети.

Для включения регистрации, в секции [general] файла iax.conf, добавьте директиву для регистрации:

При этом непрерывно, через некоторые интервалы, будет обновляться информация о пользователе, и сервер всегда будет знать, как вызвать пользователя, даже если его IP адрес будет меняться.

Директива «register» работает только, если вы хотите соединить свой сервер с динамическим IP адресом c сервером, который имеет статический (реальный) IP адрес, т.е. для пользователя, на котором производиться регистрация, Вы должны добавить директиву «host=dynamic» в файле iax.conf. Если оба сервера имеют известные статические IP адреса, то в этом случае нет никакой нужды в регистрации, просто используйте директиву host=hostname на обоих серверах.

freepbx13-sip-trunk-general

Определяет основные параметры SIP транка:

Trunk name

Имя транка для веб интерфейса. Сугубо описательное значение, для идентификации транка в веб интерфейсе FreePBX. Не используется непосредственно для вызовов. Назначьте удобное для вас имя, для легкого распознавания среди других транков.

Hide CallerID

Не сообщать удаленной стороне исходящий CallerID.
В большинстве случаев требуется передавать CallerID, но если вдруг понадобиться…
Yes No

Outbound CallerID

Задайте исходящий CallerID для данного транка. Во FreePBX Outbound CallerID может быть задан или модифицирован, в нескольких местах по пути обработки исходящего вызова.

Outbound CallerID екстеншена. Когда внутренний номер инициирует вызов, если задан параметр Outbound CallerID для этого екстеншена, он используется как исходящий CID.

Далее вызов обрабатывается в Outbound Routes. Если параметр Override Extension = No (по умолчанию), исходящий CID ектеншена, используется и далее.

Затем вызов попадает в транк, если CID Options = Allow Any CID, то Outbound CalleID екстеншена, используется для данного вызова, через транк.

CID Options

Но если выбрано другое значение CID Options, то Outbound CallerID внутреннего номера, или переназначенный в Outbound Routes, может быть модифицирован одним из перечисленных ниже значений в настройках транка.

Block Foreign CIDs - блокировать любой внешний CallerID. Под внешним подразумевается пришедший извне, из-за пределов системы. Outbound CID абонентов это не затронет.

Maximum Channels

Максимальное количество одновременных соединений через данный транк.

Asterisk Trunk Dial Options

Опции команды Dial для исходящих вызовов, через транк. По умолчанию, значение заданное в Asterisk Dial Options. Переопределяет системные опции, если выбрано override на заданные здесь.
Override System

Continue if Busy

Искать следующий доступный транк, если этот переполнен.
Yes No

Disable Trunk

Выключить, т.е. вывести транк из обслуживания. Обратите внимание, что на Register String этот триггер не распространяется.
Yes No

Dial Number Manipulation Rules

Вариантов может быть масса, но общий принцип, надеюсь ясен.

sip Settings

И, наконец, ключевые наcтройки sip пира. Во FreepBX они разделены на Outgoing и Incoming
Которые отвечают за исходящие type=peer и входящие вызовы type=user, соответственно.
Подробно с настройками sip.conf в Asterisk вы можете ознакомиться по ссылке
Здесь же рассмотрим основные параметры.

Outgoing

freepbx13-sip-trunk-sip-settings-outgoing

Большинство параметров указываются здесь.

username и secret

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

Предполагается, что здесь должно быть peer - набор свойств для исходящих вызовов.
Однако можно написать и friend и не назначать никакие параметры в секции Incoming (кроме register string, которая хоть и расположена во FreePBX в секции incoming настроек транка, прямой связи с ним не имеет и может существовать вообще без sip пира, хоть и нуждается в нем, для аутентификации входящего вызова, как доверенного, а не анонимного).
Так тоже будет работать.

Также здесь могут быть заданы любые параметры, доступные SIP пиру:

context

- контекст обработки входящих вызовов. Стандартный контекст входящих вызовов Freepbx для цифровых транков- from-trunk. Вызовы из него обрабатываются в модуле FreePBX 13 входящая маршрутизация. Но вы можете указать собственный контекст и написать его в extensions_custom.conf. См. также FreePBX custom context

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

Но если несколько углубиться в данный вопрос, можно вспомнить, что для Asterisk, по сути, нет разницы между внутренним номером и транком. Когда внешняя система вызывает некий номер, она является sip устройством, которое совершает исходящий вызов через контекст, назначенный транку, так же, как телефон совершает исходящий вызов через контекст, назначенный пиру. Поэтому, как нет разницы между sip транком и внутренним номером, так нет разницы и между использованием контекстов, им назначенных.

insecure

insecure=invite - практически обязательное условие, для приема входящих вызовов.

disallow

- запретить использование кодеков, чтобы назначить разрешенные в параметром allow.

allow

- разрешить перечисленные через запятую кодеки.

- задать свойства использования rport , media при работе за nat. Если не указано, будут использованы настройки из модуля FreePBX Asterisk SIP Settings.

qualify

- Посылать запросы Options = yes/no

qualifyfreq

- частота запросов в секундах. и тд.

Incoming

Данная секция должна иметь уникальное название, т.к. является, в некотором роде, независимым объектом, не пиром, но часовым пира, который требует пароль (secret) и указывает путь (context), если проверка пройдена. Не отображается в консоли, при вводе команды sip show peers, так как type=user. Как и следует из названия, отвечает за входящие вызовы. Основные параметры: context и secret те же, что указаны в outgoing.

freepbx13-sip-trunk-sip-settings-incoming.jpg

Здесь же задается строка регистрации, которая в чистом Asterisk, вынесена в категорию sip.conf - [general].
Это очень важный параметр, отвечающий за посылку Register SIP серверу регистраций. Если вы подключаетесь к SIP серверу провайдера и требуется получать входящие вызовы, в большинстве случаев, надо посылать Register.

Register String

authuser - необязательное имя пользователя для авторизации на SIP сервере (authuser). Обычно то же, что и 'user'.

Читайте также: