настройка iax2 транка elastix

Сценарий

Представим, что вы честный системный администратор в компании, занимающейся производством мебели. У компании есть центральный офис в Москве и производство в Новосибирске. На уровне L3 сетевая связность между локальными сетями офисов обеспечена технологией VPN. В Московском офисе мы используем нумерацию 1XX (100-199), а в Новосибирске 2XX (200-299).

Для корректной настройки от нас потребуется создать 2 IAX транка на каждом из филиалов и создать соответствующие маршрута. IP – адресация на нашем стенде следующая:

Настройки Московского филиала

Приступаем к настройке Московского филиала. Переходим в раздел Connectivity → Trunks и добавляем новый IAX транк нажатием +Add Trunk → Add IAX2 Trunk. В поле Trunk Name вкладки Outgoing вводим novosib, а в сегменте PERR Details вносим следующие настройки:

После настройки исходящих параметров, приступаем к настройке входящих для Московского филиала. Открываем вкладку Incoming. В поле User Context укажите moscow, а в разделе следующие настройки:

Нажимаем Submit. Переходим к настройке исходящего маршрута в Московском филиале. Нам нужно будет осуществлять звонки с 1XX на 2XX номера, следовательно, в шаблоне набора мы укажем IP – АТС Asterisk отправлять все вызовы, в которых пользователи набрали трехзначный номер начинающийся с двойки в транк до Новосибирска. Переходим в раздел Connectivity → Outbound Routes и нажимаем + Add Outbound Route:

После указания настроек нажимаем Submit и Apply Config

Настройки Новосибирского филиала

Теперь произведем необходимые настройки для филиала в Новосибирске. Переходим по пути Connectivity → Trunks → +Add Trunk → Add IAX2 Trunk. В Outgoing секции указываем имя moscow и следующие параметры:

Теперь в секции Incoming указываем контекст novosib и следующие опции конфигурации:

Делаем исходящий маршрут для звонков в Москву. Переходим в Connectivity → Outbound Routes и нажимаем + Add Outbound Route:

Нажимаем Submit и Apply Config

Проверка

Для проверки наших настроек, в каждом из филиалов дадим команду iax2 show peers . Как видим, наши транки в статусе OK

Теперь, при звонках с московских внутренних номеров, которые зарегистрированы на московской IP – АТС Asterisk в сторону новосибирского филиала на номера вида 2XX, мы сможем дозвониться, и, что самое главное, на телефонах принимающей стороны будет виден внутренний номер звонящего.

Полезна ли Вам эта статья?

Пожалуйста, расскажите почему?

😪 Нам жаль, что статья не была полезна для вас 🙁 Пожалуйста, если не затруднит, укажите по какой причине? Мы будем очень благодарны за подробный ответ. Спасибо, что помогаете нам стать лучше!

😍 Подпишитесь на нашу еженедельную рассылку, и мы будем присылать самые интересные публикации 🙂 Просто оставьте свои данные в форме ниже.

источник

Полный разбор связи транком по протоколу IAX2 одной и более АТС.

В данной статье будут рассмотрены различные способы соединения одной или более АТС по протоколу IAX2 для того, чтобы иметь возможность иметь внутреннюю связь между дружественными АТС. Итак, конкретно речь пойдёт о: Почему IAX2, а не SIP? Описание лабораторного стенда. Связь 2-х АТС с регистрацией. Связь 2-х АТС без регистрации. Связь 3-х АТС, где 2-е из […]

В данной статье будут рассмотрены различные способы соединения одной или более АТС по протоколу IAX2 для того, чтобы иметь возможность иметь внутреннюю связь между дружественными АТС.

Итак, конкретно речь пойдёт о:

1. Почему IAX2, а не SIP?
2. Описание лабораторного стенда.
3. Связь 2-х АТС с регистрацией.
4. Связь 2-х АТС без регистрации.
5. Связь 3-х АТС, где 2-е из 3-х за одним маршрутизируемым IP.

Почему IAX2, а не SIP?

Для связи 2-х АТС, находящихся за NAT преимущественно должен использоваться протокол IAX2. Если транковая связь за NAT основана на SIP, зачастую это ведёт к потере голоса в одну или обе стороны, потому что в заголовках SIP-пакетов приходят немаршрутизируемые в интернете IP-адреса. В отличие от SIP, IAX2 очень хорошо проходит NAT без осложнений. IAX2 передаёт сигнализацию в битовых полях, а не текстовых, что позволяет существенно экономить сетевой трафик. Для работы используется один лишь порт 4569, по которому перемещаются как сигнализация, так и медиапоток. Так же протокол позволяет совмещать множество голосовых потоков и передавать их внутри транка, уменьшая расходы, связанные с передачей заголовков IP-пакетов.

Описание лабораторного стенда.

В первых двух примерах используются 2 виртуальных сервера с дистрибутивом VoIP-Voxlink. Для упрощённого представления машине с адресом 192.168.32.67 был присвоен hostname = localhost, а машине с адресом 192.168.32.95 hostname = amotest.

Связь 2-х АТС с регистрацией.

Для того, чтобы связать 2 АТС IAX2 транками с аутентфикацией, необходимо дать некоторую полезную информацию об устройстве данной схемы. Есть 2 сервера Asterisk, 1 из которых является сервером регистрации (сервер регистрирующий на своей стороне, в нашем случае это машина под именем localhost), а другой сервером регистрирующимся (в нашем случае это машина с именем amotest). На сервере регистрирующем необходимо создавать входящий контекст для того, чтобы другой сервер мог на нём зарегистрироваться, а так же исходящий контекст. На сервере регистрирующемся мы указываем только исходящий контекст и строку регистрации.

Для создания транка сервера регистрации, на машине с условным именем хоста – localhost, перейдём Connectivity -> Trunks:

После перехода Вы должны увидеть примерно следующую картину:

Далее добавляем новый iax2 транк. Чтобы добавить новый транк, нажимаем +Add Trunk -> Add IAX2 Trunk:

Перед нами откроется следующее окно:

Всё, что нас интересует во вкладке General – это: Trunk Name и Disable Trunk.

Trunk name – имя транка для отображения в веб-интерфейсе FPBX.

Disable Trunk – включить или отключить транк. Соответственно, Yes – выключить, No – включить.

На деле это будет выглядеть следующим образом:

Следующим шагом создадим исходящий контекст, для этого перейдём во вкладку iax2 settings:

После перехода на вкладку iax2 settings, интерфейс представит нам подраздел исходящего контекста outgoing примерно следующим образом:

В данном случае Trunk Name – это уникальное имя, которое будет использоваться в рамках транкового контекста, а PEER Details – это описание директив для исходящего контекста.

Конфигурация для сервера регистрации будет выглядеть следующим образом:

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

После описания исходящего контекста, создадим входящий контекст для сервера, который будет у нас регистрироваться, в нашем случае – это amotest.

Информер: входящий контекст можно сравнить с учётной записью extension (sip/iax2/virtual/pjsip), т.к. фактически – это учётная запись, которую нужно создать на регистрирующейся стороне.

Переходим в подраздел Incoming:

Увидим, примерно, следующее:

USER Context – фактически является именем пользователя для регистрации.

USER Details – описание директив учётной записи пользователя.

Register String – строка регистрации.

Итак, приступим к заполнению параметров:

Конфигурация будет выглядеть следующим образом:

На стороне сервера регистрации настройка завершена. Сохраним конфигурацию Submit -> Apply Config:

Подключимся по SSH к серверу и проверим состояние пира.

Для проверки состояния пира введите в CLI Asterisk:

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

Траблшутинг:

Если статус будет не OK, а Unmonitored, включите параметр qualify=yes в транке. Если статус останется UNKOWN, проверяйте доступность пира, правильность введённых директив. Если пир вовсе не отображается в списке пиров из CLI, проверяйте наличие директивы type=friend/user/peer в транке.

Переходим к серверу-клиенту, который будет регистрироваться на сервере регистрации, в нашем случае – это amotest.

Переходим в Connectivity -> Trunks. Настройка во вкладке General будет аналогична серверу регистрации:

Переходим в iax Settings, во вкладку Outgoing, затем прописываем те директивы, что указывали во вкладке Incoming сервера регистрации:

После указания исходящего контекста, переходим во вкладку Incoming, прописываем строку регистрации неполного формата для сокращения записи:

Иными словами: user = имя пользователя, указанное в директивах defaultuser/fromuser. Password = пароль пользователя, указанный в директиве secret. Host=DNS-имя или IP адрес сервера регистрации.

Сохраняем изменения – Submit -> Apply Config.

Проверим статус транка. Для этого переместимся в консоль Asterisk.

Введём следующую последовательность команд:

Если статус OK или Вы намеренно отключили/не описали директиву qualify – Unmonitored, то вводим следующую команду:

Если State = Registered, значит, транк зарегистрирован успешно и можно приступать к тестированию вызовов в обе стороны.

Если State = No Authentication/ Rejected – проверяйте аутентификационные данные и настройки фаервола станции/сетевого оборудования (роутера).

Следующим шагом будет создание исходящего маршрута на обеих АТС, чтобы можно было звонить в одну и другую сторону. Начнём с сервера регистрации – localhost. Для этого переходим в Connectivity – Outbound Routes:

После перехода увидим, примерно, следующее:

Создадим исходящий маршрут на amotest, нажав +Add Outbound Route:

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

Заполним следующие параметры:

Route Name – имя маршрута. Можно задать любое.

Trunk Sequence for Matched Routes – транк, который будет использоваться при совпадении маршрута.

Перейдём в Dial Patterns для составление плана маршрутизации:

Создадим маску для звонка на 100-е номера на АТС amotest:

1ХХ означает – вызывать любой трёхзначный номер, начинающийся на цифру 1. На amotest заведены абоненты с 100-й нумерацией.

Аналогичная настройка производится на сервере amotest:

И маску для совершения исходящих:

Сохраняем, применяем, теперь можно тестировать.

Зайдём в CLI Asterisk на сервере регистрации localhost, совершим вызов в сторону клиентской АТС и позвоним с 201-го на 100-й:

Позвоним с amotest на localhost:

Аналогичным образом вызов прошёл успешно. Связка работает. Перейдём к разбору связи АТС без регистрации.

Связь 2-х АТС без регистрации.

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

На машине localhost заводим транк со следующими параметрами:

1. Вкладка General:

• Вкладка iax Settings, подраздел Outgoing:

Минимально необходимый конфиг для первого пира localhost:

Сохраняем, применяем изменения – Submit -> Apply Config.

Затем переходим в CLI Asterisk для проверки статуса пира:

Первый пир – ОК. Переходим к машине amotest.

Создаём транк, затем во вкладке General описываем параметры:

Переходим на вкладку iax Settings и прописываем исходящий контекст аналогичным образом с localhost с тем лишь отличием, что необходимо указать другой хост:

Сохраняем, затем проверяем в консоли статус пира:

Исходящая проверяется аналогичным образом.

Разберём последний параграф данной статьи.

Связь 3-х АТС, где 2-е из 3-х за одним маршрутизируемым IP.

Может возникнуть неприятная, но в то же время не очень ситуация, когда имеется 3 АТС, 2 из которых в разных локальных подсетях, которые смотрят в интернет через коммутатор с 1-го маршрутизируемого в интернете IP, а 3-я АТС спрятана за своим коммутатором со своим IP. Схема подключения будет реализована следующим образом:

1. АТС №1 и АТС №2 связаны IAX2 транком
2. АТС №2 и АТС №3 связаны IAX2 транком

Схема обзвона будет реализована следующим образом:

Если 301 абонент захочет вызвать, например, 101, то вызов пойдёт через транк между 3 и 2 АТС, а АТС №2 будет искать номер 1ХХ, следуя в транк между 2 и 1 АТС. Все остальные направления аналогичны.

Т.к. АТС №2 имеет абонентов, с которыми может производиться общение, а так же она является транзитной АТС между 3 и 1, то она же будет и точкой отказа, во время падения которой, фактически, перестанет функционировать внутренняя связь между 3-мя АТС. Данное положение можно поправить, если на АТС №1 завести транк в одну сторону до АТС №3, но практически это не имеет большого КПД.
Транки следует заводить без регистрации peer-to-peer. Создание транков производится по аналогии с параграфом 4 данной статьи с той лишь поправкой, что в данном случае между АТС за роутерами 89.192.32.45 и 94.56.44.45 имеется NAT, ставим директиву nat=yes в транке, так же следует добавить директиву canreinvite=no. В директиве, описывающий хост будут фигурировать 89.192.32.45 и 94.56.44.45, соответственно, а АТС №1 и №2 будут коннектиться друг к другу в среде локалнета.

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

источник