Как изменить callerid

Настройка модуля Set CID

Перейдём к настройке. Традиционно, для всех примеров, будем использовать FreePBX версии 13. Для того, чтобы попасть в модуль Set CallerID, с главной страницы, переходим по следующему пути: Applications -> Set CallerID. По умолчанию, данная вкладка пустая, нажимаем на кнопку Add

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

Рассмотрим подробнее каждый из пунктов:

• Description — Предлагается ввести описательное название нового CID, которое поможет определить его назначение. Например: “Sales CID”
• CallerID Name — Здесь настраивается на что будет заменено имя звонящего (caller ID name). Если предполагается изменение текущего имени, то необходимо включить соответствующие переменные. Если же оставить данное поле пустым, то имя звонящего останется пустым.
• CallerID Number — Здесь настраивается на что будет заменён номер звонящего (caller ID number). Если предполагается изменение текущего номера, то необходимо включить соответствующие переменные. Если же оставить данное поле пустым, то номер звонящего останется пустым.
• Destination — Здесь выбирается назначение для продолжения звонка. Звонок будет перенаправлен по данному назначению с новыми именем и номером (CallerID Name/ Number)

Пример модификации Caller ID Name

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

Допустим, мы хотим добавить некий префикс к номерам, которые маршрутизируются с нашего IVR. Мы знаем, что на нашем IVR настроен маршрут для соединения с отделом продаж по клавише “3” и хотим, чтобы у всех звонков, отправленных по данному маршруту был префикс “Sales” перед номером.

Для этого, сначала создаём новый шаблон в модуле.

• В поле Description пишем “Sales CID”
• В поле CallerID Name пишем “Sales:” перед $, это действие и добавляет необходимый префикс.
• Поле CallerID Number оставляем без изменений
• Наконец, в поле Destination, выбираем назначение для данного шаблона – внутренний номер менеджера по продажам (7771 Sales Manager)

Не забываем нажимать Submit и Apply Config

Далее, отправляемся в модуль IVR и настраиваем соответствующее правило.

Готово, теперь все абоненты, попавшие на IVR и нажавшие клавишу “3” на телефоне, попадут на менеджера по продажам, но их номера на дисплее телефона менеджера, будут иметь префикс “Sales”, так менеджер поймёт, что звонок поступил с IVR.

Если Вы хотите подробнее ознакомиться с возможностями модуля IVR, прочитайте нашу соответствующую статью о настройке модуля IVR во FreePBX 13.

Пример модификации Caller ID Number

Рассмотрим другой пример. Допустим, наш провайдер отдаёт нам callerID в формате 8ХХХХХХХХХХ. Но звонить в город мы должны через префикс “9”. Если нам придёт звонок с номера 8ХХХХХХХХХХ, мы должны будем сначала набрать “9”, чтобы дозвониться. Данную задачу можно решить с помощью модуля Set CallerID.

Создадим новый шаблон.

• В поле Description пишем “Outbound Prefix 9”
• Поле CallerID Name оставляем без изменений
• В CallerID Number
• Наконец, в поле Destination, выбираем назначение для данного шаблона, например ринг-группа — (4543 Managers)

Готово, теперь, при поступлении внешнего звонка на ринг-группу Managers, к номеру звонящего автоматически будет добавлен необходимый префикс “9”, таким образом, все участники из ринг-группы, смогут очень просто сразу вызвать абонента заново.

Если Вы хотите побольше узнать о группах вызова, прочитайте нашу соответствующую статью о настройке модуля Ring Groups во FreePBX 13.

Синтаксис

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

Базовый курс по Asterisk

Мы собрали концентрат всех must have знаний в одном месте, которые позволяют тебе сделать шаг вперед на пути к экспертному владению Asterisk

Полезно?

Почему?

😪 Мы тщательно прорабатываем каждый фидбек и отвечаем по итогам анализа. Напишите, пожалуйста, как мы сможем улучшить эту статью.

😍 Полезные IT – статьи от экспертов раз в неделю у вас в почте. Укажите свою дату рождения и мы не забудем поздравить вас.

Источник

Подмена исходящего caller id num

Добрый день. Прошу помощи, помогите разобраться. Установлена сборка freepbx стабильная версия. Облазал весь интернет, но конкретно под свой случай понятный рабочий вариант так найти и не смог, отовсюду нацеплял кусочки, но полной картины не понимаю.

Нужно на определенный sip транк (транк назвал Asterisk1 (в настройках транка context не указан), с исходящим правилом в Outbound routes — назвал также Asterisk1) отдавать на другую атс все внутренние номера с добавлением префикса перед номером, т.е. добавить нужно 5 в начало.

Т.е. помогите понять, каким образом сделать так, чтобы это заработало: exten => _X.,1,Set(CALLERID(num)=5$) ?

Прописать этом могу в freepbx только в extensions_custom.conf, т.к. другие конфиги не правятся во freepbx.

Что пробовал и что вычитал. Пробовал добавлять такой конфиг [from-internal-custom] exten => _X.,1,Set(CALLERID(num)=5$) exten => _X.,2,Goto(outbound-allroutes,$,1)

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

Также вычитал, что чтобы во freepbx использовать свои contexts, то нужно скачать модуль custom contexts, модуль скачал установил, с ним все понятно, но как его применить и сделать так чтобы работало. Создавал в этом модуле контекст, затем в настройках транка прописывал этот context, ну тут явно что-то делаю не так, т.к. не работает.

Также еще вычитал, что во freepbx нужно в extensionsoverridefreepbx прописывать исключения, чтобы использовать контексты, но тут тоже понимания нет.

Источник

VoIP телефония. Asterisk. Нестандартный подход ко всему. Часть 1

Ровно год назад к нам обратились бывшие коллеги, с предложением принять участие в модификации движка VoIP оператора связи. Задача сводилась к полной переделке личного кабинета, обеспечению масштабирования системы, создания системы биллинга, LCR, мониторинга расходов пользователей, контроля длительности разговоров, аналитики по звонкам. История закончилась печально, т.к. заложенный нами расширенный функционал системы якобы не соответствовал ТЗ, никак не формализованному на бумаге и находящемуся только в головах менеджеров оператора. В связи с тем, что за разработанный функционал, который заказчику очень понравился, менеджеры платить не захотели, отношения мы разорвали. NDA и договора у нас не было, поэтому посоветовавшись с коллегами мы решили часть наработок выложить в свободный доступ. Я думаю, что это будет серия статей. И начнём пожалуй с базовых вещей и архитектуры.

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

• Аренда номера у оператора связи. В данном случае пользователю выдаётся личный логин/пароль к которому «привязан» телефонный номер. При использовании связки логин/пароль для подключения к оборудованию оператора, пользователь может принимать звонки на арендованный номер и совершать звонки другим абонентам с этого номера.
• Аренда блока номеров и подключение через SIP Trunk(транк). При подключении через SIP Trunk, оператор связи отправляет на заранее согласованный IP адрес все вызовы, приходящие на арендованные у этого оператора номера. В зависимости от способа организации SIP транка, может использоваться или не использоваться парольная аутентификация. В данном случае установка правильного CallerID, который будет видеть вызываемая сторона при исходящих звонках лежит на плечах администратора IP АТС.
• Покупка DID номеров у операторов связи без покупки исходящего трафика. Оператор просто перенаправляет вызов, пришедший на данный номер, на указанный сервер.
• Покупка исходящего трафика. Есть довольно много операторов связи продающих исходящий трафик. При этом в зависимости от тарифного плана передаваемый вызываемой стороне CallerID может передаваться или теряться при прохождении через цепочку операторов терминирующих(доставляющих до конечного клиента) трафик нужного направления. Довольно часты случаи, когда звонок на московский номер через московского оператора может прийти скажем с лондонского номера или с бельгийского, потому что маршрут был дешевле.

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

Итак, исходим из следующих начальных требований:

1. Сервер для приёма вызовов может стоять где угодно
2. Количество серверов не ограничено
3. Количество операторов связи не ограничено
4. Приём вызова может происходить при любом типе аренды номера (логин/пароль или транк)
5. Вызов с определенным CallerID должен происходить только с того сервера и только с той учётной записи, к которой на данный момент привязан этот CallerID, либо через оператора позволяющего менять CallerID
6. Вызовы между соседними серверами должны проходить прозрачно без потери информации о вызываемом абоненте. Например переадресация лондонского номера на внутренний, мобильный или стационарный телефон в другом регионе
7. Для исходящих вызовов, в зависимости от тарифного плана, должен выбираться наиболее дешевый маршрут с резервированием через более дорогие. В целях контроля качества связи необходимо обеспечить мониторинг ABR, ASR(статистические параметры, определяющие качество связи в заданном направлении через определённый узел телефонии)
8. Если есть внешние пользователи использующие систему, они должны видеть в realtime свой текущий баланс и совершаемые на данный момент разговоры
9. При достижении значения текущего баланса менее определенной суммы пользователь должен получать голосовое сообщение об отрицательном балансе с прекращением разговора
10. Пользователь должен иметь возможность совершать звонки через веб браузер(WebRTC)
11. Сервера обработки входящих и исходящих вызовов, а также сервера обслуживающие абонентов могут быть разделены
12. Для аналитики и маршрутизации вызова нужна геолокация входящих и исходящих звонков

Небольшая ремарка: описываемая конфигурация является универсальной, но в большей степени подходит для сервисов имеющих клиенто-ориентированное направление, например call центров, в случаях когда необходима персонализация клиентов и привязка клиента к одному менеджеру или группе менеджеров. Большинство описываемых механизмов универсально и может эффективно использоваться в других конфигурациях.

Требований довольно много, так с чего начать? Принимать и совершать звонки будет Asterisk, подготовкой вызовов будет заниматься Application Server на python, все рабочие данные мы будем хранить в MariaDB, а большинство логики будет реализовано в виде процедур. Это позволит нам максимально дистанцировать логику работы asterisk от лишних правил в диалплане и обеспечить масштабируемость совместно с унификацией конфигурации.

Трафик

Определимся с нашим трафиком. Нам необходимо присутствие скажем на Кипре, Америке, Великобритании и России. С точки зрения Российского трафика выгоднее работать через Российских операторов связи. Например Весткол, IPPort и прочих. Российские(московские) операторы также по довольно приемлемой цене предоставляют в аренду телефонные номера в кодах 495 и 499. Присутствие на Кипре, в Америке и Великобритании мы можем обеспечить себе купив номера у Zadarma, Multilel или кого-то другого. Так как международные вызовы у Российских операторов довольно дороги, то можно купить трафик у зарубежных операторов для примера VoiceBuy или VoxBeam.

При подключении к оператору связи в варианте «логин/пароль» звонки на нашу АТС будут приходить с IP адреса сервера оператора, на котором происходит регистрация. Однако в случае исходящих звонков адрес сервера может быть другим.

При подключении к оператору через SIP транк входящие звонки могут приходить с нескольких серверов из пула оператора, а исходящие звонки осуществляются по единому DNS имени, на котором в большинстве случаев находится несколько IP адресов. Как мы уже определились ранее, оператор может иметь возможность замены CallerID для исходящего вызова, что может регулироваться тарифным планом либо договором. Замена CallerID(подмена номера) в России при исходящих вызовах запрещена. С зарубежными операторами дело обстоит намного проще и замена CallerID вполне себе поддерживается.

Создаём базу данных.

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

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

currency

providers

Обычно у зарубежных операторов 2-3 тарифа по которым они доставляют трафик до вызываемого абонента. Про различия CLI и NonCLI техник можно прочитать здесь.

Для выбора тарифного плана обычно используется префикс (noncli_prefix, cli_prefix, premcli_prefix) указываемый перед вызываемым номером в процессе формирования строки вызова.

• providername — наименование оператора
• currency_id — валюта оператора
• noncli_prefix — тариф без поддержки CLI
• cli_prefix — тариф с поддержкой CLI
• premcli_prefix — тариф премиального уровня
• cli_allowed — указывает на то, что оператор позволяет менять CLI для исходящих вызовов
• dynamic_calls — указывает, что оператор позволяет осуществлять звонки по любым направлениям с любым CLI.
• append_plus — добавлять или не добавлять «+» перед вызываемым номером. Часть операторов требует «+», часть нет.
• dynamic_calls_caller_id — CID для оператора по умолчанию.

В случае с WestCall и другими операторами предоставляющими подключение через SIP транк, вы покупаете пул номеров и осуществляя вызовы можете менять исходящий номер на любой номер из данного пула. IPPort как и прочие операторы, при использовании схемы логин/пароль с единственным купленным номером, не позволяют менять исходящий номер. Операторы VoxBeam и VoiceBuy используются для исходящих звонков для любых направлений и позволяют менять исходящий номер на любой другой. Правда здесь есть одно но! И заключается оно в том, что конечные операторы связи доставляющие звонок до вызываемого абонента, могут отклонить вызов или поменять номер вызывающего абонента на свой, если вызывающий номер соответствует внутреннему номеру страны или местности. Т.е. скажем при звонке из России в Украину(Киев) мы меняем CallerID на украинский номер в Киеве и оператор связи через которого идёт вызов может данный звонок просто «отбить», т.к. он не соответствует внутренней политике обработки звонков «Звонок через внешний входящий международный транк не может содержать внутренних номеров». Операторы Zadarma и Multitel у нас будут использоваться в качестве поставщиков номеров и исходящий трафик мы через них отправлять не будем, хотя при желании могли бы.

Важным аспектом обработки вызова является безопасность. Довольно часто встречаются ситуации, когда неверно настроенный сервер IP телефонии позволяет пропускать сквозь себя чужие звонки. Для обеспечения безопасности контуров обрабатывающих входящие и исходящие звонки, дополнительно к разделению операторов по различным контекстам, стоит создать базу IP адресов операторов связи предоставляющих нам услуги связи. Во первых это позволит настроить экспорт адресов в firewall и убрать лишние попытки «прозвона» через нас, во вторых даст более полную информацию о способах подключения к операторам связи.

providers_ips

• provider_id указывает привязку адреса к оператору из таблицы providers
• ipaddress является Int представлением fqdn адреса сервера оператора для конвертации при помощи встроенной функции INET_NTOA.
• domainname указывает fqdn имя сервера оператора осуществляющего обработку вызова.
• direction указывает направление вызова для указанного IP адреса(OUT только на выход, IN только на вход, IN/OUT и на вход и на выход)
• proto указывает протокол по которому происходит взаимодействие с оператором связи(SIP/IAX2/H323)

Таким образом связка оператора и адресов будет выглядеть следующим образом.

vw_providers

Для чего это нужно ?

1. Входящий вызов на номер телефона, арендованного нами у конкретного оператора, должен приходить из пула IP адресов серверов этого оператора. Поэтому в момент входящего вызова стоит проверить номер привязанный к оператору с таблицей IP адресов оператора
2. Оператор может иметь несколько серверов обрабатывающих исходящие вызовы от нашего сервера, поэтому это нужно учесть при формировании очереди дозвона
3. Данная схема позволяет мгновенно получать строку вызова. При этом замена domainname на имя транка определенного в sip.conf или iax.conf не нарушает работу системы
4. Номера могут быть «размазаны» по нескольким серверам для отказоустойчивости, а могут быть жёстко закреплены за каждым сервером. Нет смысла обслуживать вызов на сервере, к которому этот номер не прикреплён.

Попробуем получить строку вызова для номера 74957777777.

Запрос строки дозвона

Как мы видим, мы получили готовые данные для дозвона, которые нужно передать приложению Dial сервера Asterisk. На этом пока остановимся.

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

servers

• servername — внутреннее имя сервера
• location — географическая зона в которой находится сервер. В данном случае Россия
• ipaddress — реальный IP адрес сервера
• sip — SIP URL для соединения с сервером
• iax2 — Связка RSA ключа с идентификатором сервера для переадресации звонков между серверами
• iax2control — специальный канал команд для удалённого управления серверами и межсерверного взаимодействия. Длина команды до 80 символов
• protocol — информационное поле для сортировки по типу межсерверной связи

Для чего нужна эта таблица и почему она такая странная? Для межсерверного соединения серверов asterisk удобнее всего использовать протокол IAX. Причин несколько:

1. весь транзитный трафик между серверами можно зашифровать
2. в отличие от SIP протокола — более простое прохождение через Firewall операторов связи(для работы нужен всего 1 UDP порт)
3. невозможность установки соединения злоумышленником с сервером без наличия ключей шифрования
4. возможность передавать данные между серверами. например сессионные переменные. В SIP протоколе можно добавлять данные в заголовки сессионных пакетов, но зачастую лишние заголовки просто «вычищаются» промежуточными серверами из пакетов. В IAX протоколе можно перед установкой соединения передать необходимые переменные в потоке
5. чёткая привязка хоста и связки пользователей/ключей к контексту на сервере

С серверами на начальном этапе разобрались. Теперь необходимо сделать привязку арендуемых номеров к определенному серверу. Это необходимо для корректной маршрутизации вызовов.

CREATE TABLE numbers_pool (
id INT(11) UNSIGNED NOT NULL AUTO_INCREMENT,
number VARCHAR(50) NULL DEFAULT ‘0’ COMMENT ‘Арендуемый номер’ COLLATE ‘utf8mb4_unicode_ci’,
provider_id INT(11) UNSIGNED NOT NULL DEFAULT ‘0’ COMMENT ‘Прикрепление номера к оператору’,
server_id INT(11) UNSIGNED NOT NULL DEFAULT ‘0’ COMMENT ‘Прикрепление номера к серверу’,
enabled BIT(1) NOT NULL DEFAULT b’1′ COMMENT ‘Включение/отключение номера’,
direction ENUM(‘IN’,’OUT’,’IN/OUT’) NULL DEFAULT ‘IN’ COMMENT ‘Направление звонка по умолчанию’ COLLATE ‘utf8mb4_unicode_ci’,
virtualflag BIT(1) NOT NULL DEFAULT b’1′ COMMENT ‘Виртуальный или реальный номер’,
echotest TINYINT(1) UNSIGNED NOT NULL DEFAULT ‘0’ COMMENT ‘Тестирование номера 0/1 — выключено/включено’,
PRIMARY KEY ( id ),
UNIQUE INDEX number ( number ),
INDEX FK_number_assignment_copy_providers ( provider_id ),
INDEX FK_number_assignment_servers ( server_id ),
INDEX number btree ( number ),
CONSTRAINT FK_provider FOREIGN KEY ( provider_id ) REFERENCES providers ( id ),
CONSTRAINT FK_server FOREIGN KEY ( server_id ) REFERENCES servers ( id )
)
COLLATE=’utf8mb4_unicode_ci’
ENGINE=InnoDB
AUTO_INCREMENT=1
;

numbers_pool

• number — номер в международном формате
• provider_id — привязка номера к оператору
• server_id — привязка номера к серверу
• enabled — обслуживать вызовы на данном номере или нет
• direction — обслуживаемые номером направления вызова
• virtualflag — номер является «реальным» или «виртуальным». «Реальные» номера привязаны к диалпирам, «виртуальные» не имеют привязки
• echotest — включение режима тестирования номера. если режим включен, то вызов переадресовывается на приложение Echo() сервера Asterisk

На момент разработки системы количество арендованных номеров было около 400 штук, количество серверов 4. Для тестирования маршрутизации вызовов даже добавляли Мультифон от Мегафона. При использовании «реальных» номеров, привязанных к логину/паролю, необходимо обеспечить осуществление вызова через правильный диалпир. Так как asterisk не может знать через какой диалпир должен маршрутизироваться вызов, необходимо создать таблицу связей.

gates

• numbers_pool_id — идентификатор номера из таблицы numbers_pool
• serverid — привязка гейта к серверу
• gatename — имя гейта
• gatenumber — номер подключенный к гейту
• cid_support — поддерживается ли установка callerid при исходящем вызове
• contextname — контекст на сервере, который обслуживает исходящие вызовы по данному номеру

На этом настройка базы для обслуживания вызовов практически закончена. Я намеренно не рассматриваю сейчас работу тарификатора и систем контроля вызова, так как это очень большая тема, которую стоит вынести в отдельную статью.

В связи с тем, что основная логика обработки и маршрутизации вызова вынесена из Asterisk в Application Server, а процедуры находятся в MariaDB, необходимо обеспечить механизмы отладки и контроля работы процедур. Для этого можно использовать следующую схему.
Для хранения отладочной информации создаём дополнительную базу данных debug и создаём там таблицу debug_records

Для записи в данную таблицу данных создаём процедуру debug

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

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

Настройка Asterisk

Перейдём к настройке Asterisk сервера. Стандартная процедура обработки вызовов попадающих в контекст public, в большинстве существующих конфигураций, выглядит следующим образом

обработка исходящего вызова из контекста dialout выглядит так

В общем кто как привык и кому как нравится. Как мы видим при такой организации исходящих вызовов практически нет информации о состоянии вызова. Мы модифицировали Dialplan обработки звонков и добавили в него сервисные функции

Контекст [service] содержит в себе сервисные функции такие как:

• getip — определение IP адреса входящего сервера
• set_handler — установка обработчиков на текущий исходящий вызов. Данный обработчик вызывается перед осуществлением вызова при создании канала
• outbound_handler — обработчик завершения вызова. Вызывается во всех случаях отбоя со стороны вызываемого абонента
• no_more_paths — используется если исчерпаны все доступные варианты вызова абонента

Контекст [predial] вызывается перед соединением абонентов при успешном поднятии трубки на вызываемой стороне.
В контекст [public] попадают все внешние звонки.
В контекст [redirect] попадают все звонки, которые необходимо переадресовать с сервера на сервер.
Контекст [users_context] является основным контекстом пользователей для подготовки маршрутов для вызовов.
Контекст [make_a_call] является основным контекстом при осуществлении исходящего вызова.

Рассмотрим более подробно процедуру обработки входящего вызова:

1. Вызов поступает с сервера оператора и попадает в контекст [public]
2. Вызывается процедура определения IP адреса сервера с которого пришёл вызов на основе заголовков SIP пакета
3. Вызывается AGI приложение incoming.py осуществляющее начальную обработку входящего вызова.
4. Внутренняя логика приложения подключается к базе данных и отправляет в процедуру проверки подключений начальные имеющиеся параметры: IP адрес сервера, вызываемый номер, идентификатор сервера. Идентификатор сервера является уникальным, соответствует таблице серверов и определяется в файле asterisk.conf.
5. Если с идентификацией номера всё нормально, то производится поиск ранее использованных звонков пользователей звонящему абоненту. В случае успешного поиска вызов переадресовывается на инициатора предыдущего звонка. В случае неуспешного поиска вызов переадресовывается на дежурного оператора. Если с идентификацией номера возникли проблемы, то производится голосовая «отбивка».

Все внутренние и внешние исходящие вызовы происходят через контексты [users_context] и [make_a_call].

Рассмотрим подробнее процедуру исходящего вызова:

1. Внутренний абонент набирает номер вызываемого абонента
2. Вызов попадает в контекст [users_context]
3. Исходные данные для осуществления вызова передаются в AGI приложение make_a_route.py, внутренняя логика которого, используя данные базы данных, формирует очередь маршрутов для осуществления вызова. На основе полученного списка маршрутов, который состоит из:
   • оператора через которого происходит вызов
   • исходящего диалпира для осуществления вызова
   • CallerID для исходящего вызова
   • стоимости вызова через оператора
   • …
     приложение make_a_route.py меняет контекст на [make_a_call] или [redirect] и передаёт в них идентификатор сформированной очереди
4. Контекст [redirect] используется в случаях, когда жёстко привязанный к серверу номер, с которого необходимо сделать вызов, находится на другом сервере.
5. Контекст [make_a_call] представляет собой цикл дозвона с мониторингом состояния. В нашей конфигурации мы ограничиваем количество итераций в цикле дозвона до 10 штук. Поэтому при обращении в контекст дозвона, мы устанавливаем в 1 внутреннюю переменную итераций дозвона, действующую только в текущей сессии.
6. Данные очереди полученные из предыдущего контекста и номер текущей итерации дозвона передаются в AGI приложение incoming_dialer.py, которое возвращает сформированный заранее, в AGI приложении make_a_route.py, DialString для осуществления вызова.
7. Для осуществления мониторинга вызова, используются дополнительные опции приложения Dial, а именно U и b. Опция b позволяет вызвать подпрограмму после создания канала связи, но перед самим вызовов. В данном случае эта опция используется для установки AGI приложения, которое будет вызвано при разрыве соединения. Одновременно с вызовом данной опции, в базу данных, заносится информация о текущем осуществляемом вызове. Опция U позволяет вызвать подпрограмму при установлении соединения с абонентом, т.е. в момент поднятия вызываемым абонентом трубки. Это позволяет гарантированно отследить начало разговора и начать отсчёт времени.
8. Если соединение с абонентом не удалось и код возврата не равен 17(Занято), следует новая итерация цикла.
9. Вся информация о завершении соединения через текущий канал связи заносится в базу данных. Что позволяет считать ABR, ASR и прочую аналитику путём обычного запроса к базе данных
10. Если количество циклов дозвона превысило имеющееся в базе данных, то происходит переход в контекст [no_more_paths], который может осуществлять информирование клиента о невозможности соединения с абонентом

На этом логика работы сервера Asterisk заканчивается. Используя данную связку базы данных и приложений, добавление серверов в обслуживающий кластер происходит путём копирования конфигурационной директории сервера Asterisk, сменой имени сервера, генерацией новых RSA ключей для IAX соединений и прописыванием идентификационных данных сервера в одной таблице. Вся остальная логика работы формируется через веб интерфейс путём привязки номеров и операторов к серверам.

Использование AGI приложений на Python обусловлено единообразием среды разработки при проектировании Application сервера. Начальная версия AGI приложений использовала прямое подключение к базе. После запуска системы и отладки работы ядра, AGI приложения были переписаны под использование протокола HTTP и Application Server на uwsgi. Часть операций не требующих проверки условий и вычислений, например проверка категорий номеров, была переписана для скорости на использование CURL в диалплане.

Следующая статья посвящена тарификатору, LCR и определению геопозиции вызываемых или вызывающих абонентов.

Источник

В рамках данной статьи рассмотрим общие принципы доработки, позволяющей изменять свой CallerID (отображаемое имя при звонке) в модуле UCP FreePBX. Также рассмотрим создание режима администратора, позволяющего изменять не только свой CallerID, но также CallerID других пользователей.

Кому может быть полезно

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

Использование функционала

В данном разделе рассмотрим основные возможности доработки, а также изменения в веб-интерфейсе.

Для того, чтобы воспользоваться доработанным функционалом необходимо авторизоваться в UCP и открыть панель пользовательских настроек (User Settings). Переход на данную панель находится в левом нижнем углу экрана, а иконка её выглядит следующим образом:

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

Необходимо перейти на вкладку User Details.

Далее рассмотрим два различных функционала: пользователя (доступно изменение только своего имени) и администратора (доступно изменение имён всех внутренних номеров АТС).

Функционал пользователя

Для изменения собственного имени необходимо отредактировать поле Display Name. Чтобы изменения применились в системе необходимо нажать на клавишу ‘Enter’.

Функционал администратора

Кроме изменения собственного имени, администратору системы доступно также изменение имени любого другого внутреннего номера системы. При этом вкладка User Details для администратора имеет вид:

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

Способ изменения имени такой же, как и у пользователей: в поле Display Name вводим новое имя и подтверждаем изменение нажатием клавиши ‘Enter’.

Назначение роли администратора

Для того, чтобы назначить пользователю роль администратора необходимо в FreePBX перейти по следующему пути: Admin -> User Management. В появившемся списке выбираем пользователя, которому собираемся выдать соответствующие права и открываем его для редактирования настроек.

В появившемся окне переходим на вкладку UCP:

В отрывшейся вкладке находим настройку Administrator и выставляем её в Yes.

Чтобы подтвердить выбор необходимо нажать кнопку Submit на этой же странице.

Рассмотрим доработку на примере изменения пользователем своего имени.

Описание доработки

Первым делом необходимо добавить обработчик, реагирующий на изменение поля displayname в настройках UCP. Для этого открываем файл /var/www/html/admin/modules/ucp/htdocs/modules/Settings/assets/js/global.js, находим в нём функцию displaySimpleWidgetSettings и в неё вставляем следующий код:

$("#displayname").change(function() {
	$.post("ajax.php?module=Settings&command=settings", {
    	key: "extrename",
    	displayname: $("#displayname").val()
	}
});

В результате выполнения данного кода отправится AJAX-запрос на ajax.php?module=Settings&command=settings с ключом extrename.

Теперь необходимо написать обработчик этого AJAX-запроса. Делается это в файле /var/www/html/admin/modules/ucp/htdocs/modules/Settings/Settings.class.php. Находим функцию ajaxHandler. В ней находим switch($_POST['key']). Здесь опишем обработчик extrename:

case 'extrename':
	$displayname = htmlentities(strip_tags($_REQUEST['displayname']));
	$ext_num = $user['default_extension'];
	$this->UCP->FreePBX->Core->updateUsername($ext_num, $displayname);
	$this->UCP->FreePBX->Userman->updateUserExtraData ($user['id'], array('displayname' => $displayname));
 
	$ret = array(
    	"status" => true
	);
break;

Также в этом же switch переписываем обработчик case 'displayname' на следующий:

case 'displayname':
	$ret = array(
	    "status" => true
	);
break;

Теперь осталось только реализовать функцию updateUsername в модуле Core, которая будет обновлять имя пользователя. Для этого открываем файл /var/www/html/admin/modules/core/Core.class.php. В него добавляем следующий код:

/**
 * Update username by extension number
 * @param {int} $ext The user extension
 * @param {String} $new_name The new name of extension
 */
public function updateUsername($ext, $new_name)
{
	global $astman;
 
	$sql = "UPDATE users SET name = ? WHERE extension = ?";
	$sth = $this->database->prepare($sql);
	$sth->execute(array($new_name,$ext));
 
	if($astman->connected())
	    $astman->database_put("AMPUSER",$ext."/cidname",$new_name);
	else
	    error_log("Astman not Connected!");
}

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

На это статья-обзор по изменению CallerID разных пользователей в настройках модуля UCP FreePBX завершена.