По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В данной статье будет в общем виде рассмотрен диалплан и его содержимое - контексты и экстеншены в 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.
Порядок поиска таков:
Экстеншены
Экстеншены с масками
Вложенные экстеншены
Переключатели
Cisco CUBE (Cisco Unified Border Element) - контролер граничных сессий (SBC) от компании Cisco. В статье мы поговорим о том, как настроить так называемый SIP Forking, который позволяет отправить SIP сигнализацию на несколько устройств сразу.
В примере мы покажем, как настроить SIP Forking на CUBE для записи видео – звонков, например, для последующего анализа системой записи.
Что мы имеем
Интегрированное приложение Cisco Unified Border Element (далее CUBE) является частью программного обеспечения маршрутизатора CISCO2911, параметры которого приведены ниже:
Cisco CISCO2911/K9 (revision 1.0) with 483328K/40960K bytes of memory.
Processor board ID ABCDEFAAAAA
3 Gigabit Ethernet interfaces
6 Serial interfaces
1 terminal line
2 Channelized E1/PRI ports
1 Virtual Private Network (VPN) Module
DRAM configuration is 64 bits wide with parity enabled.
255K bytes of non-volatile configuration memory.
32K bytes of USB token usbtoken0 (Read/Write)
255744K bytes of ATA System CompactFlash 0 (Read/Write)
Prerequisites
Перед началом нужно выполнить следующие условия:
маршрутизатор сконфигурирован в качестве CUBE;
версия Cisco IOS 15.2(1) или выше;
видео – звонок устанавливается по схеме SIP-to-SIP;
используется адресация версии IPv4;
ключевые составляющие вызова проходят через CUBE, включая SIP – сигнализацию и медиа - потоки;
в рамках устанавливаемого видео – вызова не происходит транскодирования с высокой нагрузкой;
не используется SRTP (Secure Real-time Transport Protocol);
Схема следующая:
Настройка
Для настройки CUBE необходимо подключится к серверу по протоколу Telnet и ввести следующие логин и пароль:
UserName: merionet
Password: ******
Переходим в режим конфигурации:
enable
configure terminal
У нас 192.168.0.2 – IP – адрес системы записи, а 192.168.0.3 - адрес CUCM. В разделе voice service voip, необходимо добавить IP – адрес системы записи и CUCM в список «доверенных» IP – адресов и указать прочие опции, как указано ниже:
voice service voip
ip address trusted list
ipv4 192.168.0.2 255.255.255.255
ipv4 192.168.0.3 255.255.255.255
address-hiding
mode border-element
media flow-around
allow-connections sip to sip
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
sip
asymmetric payload full
early-offer forced
midcall-signaling passthru
g729 annexb-all
video screening
Создаем media profile recorder, в котором необходимо указать тэг dial – peer, который смотрит в сторону системы записи. Помимо этого, необходимо создать профиль для записи видео с опциями, которые указаны ниже. Оба профиля записи указываются в настройке media class:
media profile recorder 100
media-recording 114
!
media profile video 455
monitor-ref-frames
h264-packetization-mode 0
ref-frame-req rtcp retransmit-interval 50 retransmit-count 4
ref-frame-req sip-info
!
media class 3
recorder profile 100
video profile 455
Теперь, на входящем и исходящем dial – peer указываем созданный ранее media class:
dial-peer voice 123 voip
destination-pattern 114
rtp payload-type cisco-codec-video-h264 112
session protocol sipv2
session target ipv4:192.168.0.2
voice-class sip options-keepalive
voice-class codec 1 offer-all
media-class 3
dtmf-relay rtp-nte
no vad
!
dial-peer voice 124 voip
destination-pattern 1402$ // маршрут в сторону PBX
rtp payload-type cisco-codec-video-h264 112
session protocol sipv2
session target ipv4:192.168.0.3
session transport tcp
voice-class codec 1 offer-all
voice-class sip options-keepalive up-interval 100 down-interval 50 retry 6
voice-class sip bind control source-interface GigabitEthernet0/1
voice-class sip bind media source-interface GigabitEthernet0/1
media-class 3
dtmf-relay rtp-nte
no vad
Сохраняем конфигурацию:
copy running-config startup-config
В сегодняшней статье расскажем о том, как проверить скачанные или добавленные модули в графическом интерфейсе FreePBX 13.
/p>
C недавних пор FreePBX имеет встроенную систему проверки подписи для всех официальных модулей. Это было сделано для того, чтобы конечный пользователь или администратор системы могли без проблем определить, подвергался ли модуль изменениям (например, из-за уязвимости системы безопасности, или же модуль вовсе вредоносный).
Неподписанные модули после обновления
Если после обновления с FreePBX 2.11 до FreePBX версии 12 или 13, на главной странице появляются информационные сообщения о неподписанных модулях (Unsigned Modules) это может означать, что Вы не завершили последнюю часть обновления. Для того, чтобы её корректно завершить требуется подключиться к вашей IP-АТС по ssh или через консоль и ввести следующий ряд команд:
amportal chown
amportal a ma refreshsignatures
amportal a reload
Эти команды запустят внутреннюю проверку модулей, а также проверку того, что все файлы имеют правильные разрешения. Если будут обнаружены модули, которые не имеют подписи, то система загрузит их заново и перезапустится. После этого, все предупреждения и ошибки должны исчезнуть.
Сообщения о неподписанных модулях на главной странице
Уведомления о подписи модулей были введены в FreePBX 12 как сообщения, которые появляются на главной панели (Dashboard) при обнаружении каких-либо проблем. Выглядит это примерно так:
Вы можете детально узнать подробности этих информационных уведомлений, нажав кнопку Details. Откроется анализ того, что не удалось корректно выполнить в процессе проверки целостности.
В качестве альтернативы можно также скрыть эти сообщения безопасности, нажав X в правом верхнем углу. Таким образом, уведомления будут скрыты до тех пор, пока не появится новый неподписанный модуль. Эти уведомления будут также отображаться на панели управления, в разделе System Overview и приходить по электронной почте в следующем виде:
Желтые уведомления безопасности являются общими предупреждениями. В то время как красные сообщения, означают, что файл был изменен по сравнению с тем, каким он первоначально был во FreePBX. Например:
Вы можете отключить все уведомления о недействительной подписи в меню Advanced Settings, установив Enable Module Signature Checking в положение False.
Настоятельно не рекомендуем выставлять флаг Enable Module Signature Checking в положение False в системах, которые работают в продакшене, поскольку данное действие отключает несколько уровней системной защиты.
Типы предупреждений
Существует два типа предупреждений о подписи модуля, их описание ниже:
Unsigned - неподписанные модули. Это модули, которые не были санкционированы командой разработчиков FreePBX. Они потенциально могут иметь вредоносный код, который может угрожать вашей системе. Установка этих модулей на свой страх и риск.
Altered - изменённые модули. Это модули, имеющие файлы, которые были модифицированы по сравнению с их первоначальной версией. Рекомендуется повторно загрузить эти модули, чтобы предотвратить возможные проблемы с вашей АТС.