Настройка DUNDi в Asterisk, под управлением FreePBX

  • Tutorial
Опытным администраторам VoIP эта статья будет мало интересна, адресована она админам малых IP-телефонных серверов для маленьких офисов.

DUNDI — что это и зачем нужно


DUNDi — протокол динамической маршрутизации для IP-телефонии. Позволяет автоматически находить сервер, обслуживающий конкретный номер.

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

Практика


Статей по настройке можно найти много, но они обычно не раскрывают особенности настройки DUNDi в связке с FreePBX (он поддерживает настройку DUNDi в полу ручном режиме).

Итак, нам потребуется:

  1. Создать пару приватный\публичный ключ для каждого сервера, подключенного к DUNDi маршрутизации
  2. Выбрать сервера, которые будут корневыми для работы DUNDi (можно сделать и простую звезду или связать всех со всеми)
  3. Создать контекст в котором будем искать внутренние номера (можно и не создавать, и прицепиться к существующему)
  4. Создать DUNDi конфигурацию
  5. Создать транк, через который будет происходить вызов (в этом случае я использую IAX2)
  6. Создать DUNDi транк, на который навесить исходящую маршрутизацию

Ключи DUNDi


Заходим на сервера по ssh и:

cd /var/lib/asterisk/keys
astgenkey -n <понятное нам имя сервера>

Файл *.pub надо передать на другие сервера, которые будут в прямой связи с этим сервером

Контекст поиска внутренних номеров


файл: /etc/asterisk/extensions_custom.conf


[dundi-extens]
include => ext-local
include => ext-intercom-users
include => ext-meetme

Конфигурация DUNDi


Файл: /etc/asterisk/dundi.conf


[general]
; Заполнять переменные ниже не обязательно, смысл как и у сертификатов
department=VoIP
organization=*******
locality=Moscow
stateprov=Moscow
country=RU
email=******
; А далее, уже надо
port=4520
entityid=FE:7E:15:DC:**:** ; Идентификатор этого сервера, обычно MAC сетевого интерфейса
cachetime=600 ; Время кэширования записей, выбирайте сами, сообразно тому, как часто меняется у вас нумерация
ttl=32 ; Тоже самое, что и для сетевых пакетов, как глубока может быть цепочка разрешения номера
autokill=yes

[mappings]
; Задаем соответствие между контекстом DUNDi, найденными номерами и вызывающим транком
; dundi_inter, как раз наш IAX2 транк, через который вызов будет совершен
; dundi-extens - контекст, в котором мы ищем номера
; dundi_context - собственно, контекст DUNDi
; ${IPADDR} - на некоторых версиях Asterisk дает глюк, и постоянно возвращает 127.0.0.1 в запросах. Если у вас такая проблема, поменяйте на IP этого сервера
dundi_context => dundi-extens,0,IAX2,dundi_inter:${SECRET}@${IPADDR}/${NUMBER},nopartial

; Секции DUNDi пиров, тут впишем всех, с кем мы имеем прямую связь по DUNDi
[FE:A0:79:26:52:65] ; ID пира, обычно MAC интерфейса
model = symmetric
host = *.*.*.* ; IP пира, можно указать и fqdn
inkey = <имя файла публичного ключа пира, без суффикса pub>
outkey = <имя файла приватного ключа этого сервера, без суффикса key>
include = dundi_context ; Тут указываем контекст DUNDi пира, в котором мы ищем номера
permit = dundi_context ; А тут разрешаем этому пиру искать в контексте этого сервера
qualify = yes
dynamic=yes

Транк для совершения вызова


Название транка в этой вкладе — просто отображаемое имя



А в этой, уже то, что использует Asterisk, секцию Incoming мы вообще не используем



Секция Outgoing
type=user
dbsecret=dundi/secret
context=dundi-extens



Перезагрузить конфигурацию DUNDi можно так:
module reload pbx_dundi.so

Перезагрузить ключи можно так:
module reload res_crypto.so


DUNDi транк и маршрутизация


Название транка в этой вкладе — просто отображаемое имя



DUNDi Mapping соответствует секции mappings из файла /etc/asterisk/dundi.conf



Создаем маршрут:



Так как план нумерации у меня четырехзначный, то и шаблон номера у меня такой



Проверка


После применения изменений, из командной строки asterisk -rv можно:
Посмотреть статус DUNDi пиров:


voip*CLI> dundi show peers
EID                  Host                Port   Model      AvgTime  Status
fe:a0:79:26:**:**    172.16.**.*     (S) 4520   Symmetric  Unavail  OK (9 ms)
1 dundi peers [1 online, 0 offline, 0 unmonitored]

Попробовать разрешить внутренний номер:


voip*CLI> dundi lookup 1000@dundi_context  #Это запрос номера, расположенный на этом-же сервере
DUNDi lookup returned no results.
DUNDi lookup completed in 170 ms
voip*CLI> dundi lookup 1901@dundi_context #Это запрос номера, расположенного на другом сервере
  1.     0 IAX2/dundi_inter:e3ade6Lmkz5GK5l4KBVsfA==@172.16.*.*/1901 (EXISTS)
     from fe:a0:79:26:*:*, expires in 600 s
DUNDi lookup completed in 9 ms
  • +10
  • 6,1k
  • 5
Поделиться публикацией
Похожие публикации
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама
Комментарии 5
  • 0
    И как впечатления от использования? Много ли серверов у вас завязаны на работу с DUNDi? Какие проблемы встречаются? Конечно, понимаю, что это туториал, но разобраться как работает можно и по официальной документации, больше хочется узнать впечатления. Или вы просто собрали на стенде и «вау, работает! напишу-ка инструкцию» ;)
    • 0
      Работать оно работает. Пока серьезных проблем нет. Основная цель — это избавление от единого узла коммутации телефонии. Офисов стало относительно много, и сеть между ними нормально туннелями с OSPF работает (есть два филиала, которые обеспечивают общую связность сети). А вот телефония была заведена на одном из узловых филиалов, и настроена звездой (исторически так получилось). Когда узловой филиал остается без интернета, все филиалы, которые сохранили сетевую связность (спасибо OSPF) теряли связь по телефонии между собой. После перехода, на DUNDi связь сохраняется при сохранение сетевой связности.
      Добавлять новые узлы не сложнее чем при классической схеме, а плюс в том, что нет нужды держать четкие диапазоны для каждого филиала, я могу с легкостью номер перенести на другую АТС, и он останется рабочим (разве что, надо изменить входящую маршрутизацию до него, если такая была).
      • 0
        Меня больше удручало создавать iax каналы при большом количестве малых офисов, в меня их более 20 и если появляется новый, то что бы все могли к нему звонить, надо проверять все сервера всех офисов, когда у тебя 2-5 серверов не критично, но когда из больше 20 начинает раздражать это. В итоге я придумал систему когда каналы создаются на всех серверах сами, тебе надо выполнить один sql запрос :). Касательно DUNDi перенос безболезненный номера на др сервер мне как то не пристает, так как все равно телефон надо перенастраивать, и делать ручками некоторые вещи. Поэтому у меня все же за каждым офисом закреплена нумерация.
        • 0
          В вашей задаче DUNDi тоже может быть удобным. В простом случае строить звезду с одним центральным узлом. Два транка, один маршрут и практически неизменная конфа для каждого узла (примерно так-же как и обычный транк на двух концах настроить). Но, АТС при этом связываются на прямую (номер могут получить и рекурсивно).
          А миграция у меня случилась… Но DUNDi помог мне без массовой остановки работы, в ленивом режиме, объединить (с пропорцией 2/7) планы нумирации двух АТС (офис частично съехал на другую площадку).
          • 0
            ну у меня конфигурация маршрутов, у всех одна и таже, она изменяется только при внешних звонках, разные операторы по разному принимаю нумерацию. А внутренние звонки, обрабатываются одним экстеншином, в котором agi скрипт определяет на какой сервер отправить звонок. надо как-нибудь написать, как у меня все это работает, может кому это и будет интересно.

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