По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В данной статье будет в общем виде рассмотрен диалплан и его содержимое - контексты и экстеншены в Asterisk.
Формат диалплана
Диалплан в файле extensions.conf структурирован в секции, называемые контекстами. Контекстом называется сущность внутри диалплана, которая позволяет функционировать его различным частям совершенно независимо. Контексты используются для разделения функций, улучшения безопасности между различными частями диалплана, настройкой классов обслуживания для разных пользователей и так далее.
Контексты в диалплане
Синтаксис для контекста точно такой же как и во всех конфигурационных файлах Asterisk (файлах с расширением .conf) Для создания контекста просто необходимо поместить его название в квадратные скобки:
[telephony-users]
Экстеншены в диалплане
Внутри каждого контекста необходимо обозначит один или более экстеншенов. Экстеншен по сути это определенный список действий с определенным названием. После набора номера экстеншена, Астериск последовательно выполняет каждое действие.
Синтаксис у экстешена следующий:
exten => number,priority,application([parameter[,parameter2...]])
К примеру:
exten => 101,1,Dial(PJSIP/celecom, 20)
В данном случае, номер экстеншена – 101, номер приоритета – 1, используемое приложение – Dial(), с параметрами PJSIP/celecom и 20.
Приоритеты
Внутри каждого экстеншена должен быть один или более номеров приоритетов. Приоритет это просто число, от 1 до N. Команда с первым приоритетом будет соответственно исполнена первой, после её завершения будет исполняться команда с приоритетом 2 и так далее.
Обязательно нужно использовать последовательные числа, иначе выполнение сценария будет прервано.
exten => 101,1,выполнить действие
exten => 101,2,выполнить другое действие
exten => 101,5,выполнить еще какое-то действие
В примере выше выполнение сценария прервется после строчки с приоритетом 2, по причине того, что отсутствует приоритет с номером 3.
Кроме того, вместо номера приоритета можно указывать литеру n (next). То есть возможен такой сценарий:
exten => 101,1,выполнить действие
exten => 101,n,выполнить другое действие
exten => 101,n,выполнить еще какое-то действие
Если не хочется постоянно писать номер экстеншена, можно использовать функцию same.
exten => 101,1,NoOp()
same => n(repeat),Verbose("Нужно что-то сделать!")
same => n,Verbose("Нужно сделать что-то другое!")
Порядок обработки диалплана
Порядок считывания экстеншенов внутри контекста идёт сверху вниз, причем вложенные контексты обрабатываются первыми. То есть к примеру у вас есть три контекста – X, Y и Z. Если вы хотите чтобы контекст Z обрабатывался первым, просто сделайте его вложенным контекстом для контекста X.
Порядок поиска таков:
Экстеншены
Экстеншены с масками
Вложенные экстеншены
Переключатели
Сейчас мы докажем, что в FreePBX можно записать вообще всё.
Мы уже рассказывали про логику записи звонка и том на каких фазах мы можем её контролировать. Однако, стандартный функционал записи ограничивается модулем, в рамках которого мы хотим начать запись. Например, если мы включаем запись на внутреннем номере (Extension), то услышим только часть звонка, которая началась, когда абонент данного номера снял трубку.
Но что, если мы хотим записать ещё и ту часть звонка, которая была до этого? Например, как звонящий терпеливо выбирал опции нашего IVR и какие комментарии при этом отпускал? :)
Для этого в FreePBX существует специальный модуль - Call Recording, который позволяет принудительно включить или отключить автоматическую запись звонка на определенном его этапе. Любые другие опции записи, которые были включены до этого, при этом будут проигнорированы. Но самое главное, что записи звонков, сделанные через этот модуль, будут содержать все голосовые приветствия (Announcement), музыку на ожидании (Music On Hold) и другие сообщения, которые проигрывает наша IP-АТС каждому позвонившему абоненту.
Множество модулей во FreePBX, таких как модуль очередей (Queues), входящей маршрутизации (Inbound Routes), групп вызова (Ring Group), позволяют управлять записью звонка напрямую. Для этого в них есть специальные опции – Call Recording, которые можно при необходимости активировать.
Модуль, о котором мы говорим в этой статье, позволяет настроить принудительное начало записи звонка ещё до того, как он отправится на какое-нибудь направление, которое не имеет опции записи. Например на Page группу или IVR.
Настройка
Перед установкой, проверьте какая версия модуля callrecording у вас установлена. Для этого в консоли введите команду: fwconsole ma list | grep callre. Версия модуля должна быть 14.0.5 и выше, поскольку в более ранних версиях, обнаружен баг (FREEPBX-18899 (https://issues.freepbx.org/browse/FREEPBX-18899)) и функционал полной записи работать не будет :(. Если установлена более ранняя версия, то сделайте обновление данного модуля
После этого переходим во вкладку Settins - Advanced Settings и в разделе Call Recording ищем новую опцию, которая должна появиться - Call Recording Option, её значение устанавливаем в No и только после этого переходим к следующему шагу
Для настройки открываем Applications → Call Recording и нажимаем Add Call Recording:
Перед нами открывается меню добавления нового правила записи звонков:
Как видите всё достаточно просто:
Description - Описание данного правила;
Call Recording Mode - Логика записи, подробно описана в нашей статье;
Force и Never заменяют друг друга и имеют высший приоритет чем Yes и No
Yes и No имеют одинаковый приоритет
Когда один и больше Yes или No встречается в call flow, в приоритете всегда будет первое значение.
Последующие опции Yes или No не переопределяют первую.
Force и Never будут всегда переопределять опции, которые установлены ранее.
Force и Never будут всегда заменять друг друга. Например если сначала был установлен Force, а потом встречается Never, то в приоритете будет Never
Force и Never будут всегда заменять предустановленные опции Yes и No
Yes и No никогда не заменять Force и Never
Don’t Care не будет изменять предыдущую опцию.
Destination - Указывает направление куда необходимо отправить звонок после того, как была включена или же отключена запись.
Применение
Давайте представим себе, что у нас есть входящий маршрут (Main_Route), звонки с которого отправляются в IVR (Main_IVR). Но мы хотим слышать что говорит звонящий, находясь в меню IVR и слушая голосовое сообщение, например для последующего анализа и оценки его реакции.
Для этого, мы создадим Call Recording (For_IVR_Recordings), которое будет включать запись и отправлять звонок на тот же самый IVR, а сам Call Recording – повесим на входящий маршрут:
Готово! Теперь мы получим запись звонка, которая будет содержать часть, где звонящий находится в IVR и слушает его сообщение, и, возможно даёт какие-нибудь комментарии. Остальная часть записи будет зависеть от того, какие опции настроены в IVR.
В этой заключительной статье о перераспределении маршрутов мы проверим работу Route redistribution с помощью IPv6 и увидим небольшое отличие в настройке routes redistributed IPv6 от routes redistributed IPv4.
Предыдущие статьи из цикла:
Часть 1. Перераспределение маршрутов (Route redistribution)
Часть 2. Фильтрация маршрутов с помощью карт маршрутов
Часть 3. Перераспределение маршрутов между автономными системами (AS)
Перераспределение подключенных сетей
Во-первых, рассмотрим маршрутизатор, выполняющий маршрутизацию, предположим, что используется протокол OSPF. Кроме того, предположим, что маршрутизатор имеет несколько интерфейсов, которые участвуют в маршрутизации OSPF. Представьте, что на этом же маршрутизаторе мы запускаем другой протокол маршрутизации (скажем, EIGRP), и мы делаем взаимное перераспределение маршрутов.
Вот что удивительно. Если мы делаем перераспределение маршрута на этом маршрутизаторе, сети IPv4, связанные с интерфейсами этого маршрутизатора, участвующими в OSPF в нашем примере, будут перераспределены в EIGRP. Однако сети IPv6, будут вести себя по-другому. В частности, в сетях IPv6 мы должны ввести дополнительный параметр в нашу конфигурацию перераспределения маршрутов, явно указывая, что мы хотим перераспределить подключенные сети. В противном случае эти маршруты IPv6, связанные с непосредственно с подключенными интерфейсами, не перераспределяются.
Логика такого поведения вытекает из понимания того, что для перераспределения маршрута данный маршрут должен появиться в таблице IP-маршрутизации маршрутизатора. Конечно, когда посмотрим таблицу IP-маршрутизации маршрутизатора и увидим непосредственно подключенные сети, эти сети отображаются как подключенные сети, а не сети, которые были изучены с помощью определенного протокола маршрутизации.
В то время как route redistribution для IPv4 понимает, что сеть напрямую подключена, но участвует в процессе маршрутизации и поэтому будет перераспределена, route redistribution для IPv6 не делает такого предположения. В частности, если мы перераспределяем сети IPv6 из одного протокола маршрутизации в другой, эти сети должны отображаться в таблице маршрутизации IPv6 маршрутизатора вместе с указанием, что они были изучены с помощью перераспределяемого протокола маршрутизации. Конечно, мы можем добавить дополнительный параметр к нашей команде redistribute, чтобы заставить эти непосредственно подключенные сети IPv6 (участвующие в распространяемом протоколе) также быть перераспределенными. Эта настройка будет продемонстрирована немного позже.
Перераспределение в OSPF
В прошлой статье мы обсуждали потенциальную проблему, с которой вы можете столкнуться при распространении в OSPF (в зависимости от вашей версии Cisco IOS). Проблема была связана с подсетями. В частности, по умолчанию в более старых версиях Cisco IOS OSPF только перераспределяет классовые сети в OSPF, если мы не добавим параметр subnets к команде redistribute. Добавление этого параметра позволило перераспределить сети в OSPF, даже если у них не было классовой маски. Пожалуйста, имейте в виду, что последние версии Cisco IOS автоматически добавляют параметр подсети, не требуя от вас ручного ввода.
Однако параметр подсети в IPv6 route redistribution отсутствует. Причина в том, что IPv6 не имеет понятия о подсетях.
Пример route redistribution IPv6
Чтобы продемонстрировать перераспределение маршрутов IPv6, рассмотрим следующую топологию:
Протоколы маршрутизации OSPFv3 и EIGRP для IPv6 уже были настроены на всех маршрутизаторах. Теперь давайте перейдем к маршрутизатору CENTR и настроим взаимное route redistribution между этими двумя автономными системами. Убедимся в этом, проверив таблицу маршрутизации IPv6 маршрутизатора CENTR.
Приведенные выше выходные данные показывают, что мы изучили две сети IPv6 через OSPF, две сети IPv6 через EIGRP, а CENTR напрямую подключен к двум сетям IPv6. Далее, давайте настроим взаимное перераспределение маршрутов между OSPFv3 и EIGRP для IPv6.
CENTR # conf term
Enter configuration commands, one per line. End with CNTL/Z.
CENTR (config)# ipv6 router eigrp 1
CENTR (config-rtr) # redistribute ospf 1 metric 1000000 2 255 1 1500?
include-connected Include connected
match Redistribution of OSPF routes
route-map Route map reference
cr
CENTR (config-rtr) #redistribute ospf 1 metric 1000000 2 255 1 1500 include-connected
CENTR (config-rtr) #exit
CENTR (config) # ipv6 router ospf 1
CENTR (config-rtr) #redistribute eigrp 1?
include-connected Include connected
metric Metric f or redistributed routes
metric-type OSPF/IS-IS exterior metric type for redistributed routes
nssa-only Limit redistributed routes to NSSA areas
route-map Route map reference
tag Set tag for routes redistributed into OSPF
cr
CENTR (config-rtr) #redistribute eigrp 1 include-connected
CENTR (config-rtr) #end
CENTR#
Обратите внимание, что конфигурация взаимного перераспределения маршрутов, используемая для маршрутов IPv6, почти идентична нашей предыдущей конфигурации для перераспределения маршрутов IPv4. Однако для обеих команд перераспределения был указан параметр include-connected. Это позволило маршрутизатору CENTR перераспределить сеть 2003::/64 (непосредственно подключенную к интерфейсу Gig0/1 маршрутизатора CENTR и участвующую в OSPF) в EIGRP. Это также позволило маршрутизатору CENTR перераспределить сеть 2004::/64 (непосредственно подключенную к интерфейсу Gig0/2 маршрутизатора CENTR и участвующую в EIGRP) в OSPF.
Чтобы убедиться, что наша конфигурация рабочая, давайте перейдем на оба маршрутизатора OFF1 и OFF2, убедившись, что каждый из них знает, как достичь всех шести сетей IPv6 в нашей топологии.
Вышеприведенные выходные данные подтверждают, что маршрутизаторы OFF1 и OFF2 знают о своих трех непосредственно связанных маршрутах и трех маршрутах, перераспределенных в процессе маршрутизации. Итак, как мы видим, что когда речь заходит о routes redistributed IPv6, то не так уж много нового нужно узнать по сравнению с routes redistributed IPv4.