Comments 9
А будет возможность использовать PHP-AGI скрипты в исходящей маршрутизации? Сейчас можно только во входящих правилах использовать.
Это и сейчас разрешено, можно описать custom-контекст и выполнить произвольный AGI скрипт, не важно SHELL / PHP / GO, на чем на пишете ))
Пример описан тут wiki.mikopbx.com/faq:specific_provider
О кастомизации опишу отдельную статью.
Из минусов — это скрипт придется залить на станцию вручную по SFTP, положить можно к примеру на
Пример описан тут wiki.mikopbx.com/faq:specific_provider
О кастомизации опишу отдельную статью.
Из минусов — это скрипт придется залить на станцию вручную по SFTP, положить можно к примеру на
/storage/usbdisk1
Далее следует либо 35 либо 26
Это настолько редкий кейс, что городить ради него костыли в виде REGEXP — ну такое… Чаще всего это означает что у вас что-то не так в планировании Dialplan, либо же требуется DB со всеми префиксами из реестра Россвязи. Все остальные условия решаются стандартным Pattern Matching.
В целом — да, кейс редкий. Часто достаточно направить вызовы через одного, единственного провайдера (60% внедрений).
На примере нашей компании — используем GSM шлюз с 4 сим картами от разных провайдеров.
распределяем звонки используя эти правила.
На примере нашей компании — используем GSM шлюз с 4 сим картами от разных провайдеров.
распределяем звонки используя эти правила.
И как вы решаете вопрос с миграцией между операторами абонентов?
Миграцию сейчас никак не учитываем. Но есть нюансы. К примеру звонки на городские номера с Мегафон оплачиваются отдельно, сверх пакета минут, а вот если звонить через Yota, то в пакет минут выходят все исходящие не важно на какой номер.
Есть тонкости в «Домашнем регионе», не все операторы связи включают в пакет минут номера из чужих регионов.
Так и работаем. То есть принадлежность номера к определенному провайдеру на текущий момент не важна. А вот звонить на городские через tele2 или yota выгоднее чем через мегафон.
Есть тонкости в «Домашнем регионе», не все операторы связи включают в пакет минут номера из чужих регионов.
Так и работаем. То есть принадлежность номера к определенному провайдеру на текущий момент не важна. А вот звонить на городские через tele2 или yota выгоднее чем через мегафон.
Гдето я такое уже видел.
Правда, там это сделали для исходящих правил.
Штука в том, что когда у вас таких правил 20+, у вас просто обычный звонок без всяких изысков нагружает ядро asterisk. Фишка в том, что в таком варианте самый сложный по CPU звонок — неправильный набор. Что очень плохо.
Ну про мусор в логах и говорить нечего.
Вот не помню где. Толи в сангомовском облачном решении, толи еще где.
А еще это потом очень тяжело расширать/менять(поскольку вы не можете просто вставить custom правило используя asterisk-way).
Точно помню, что это было убрано из всех продакшн новых версий по причине " у нас 100% cpu и почти нет звонков".
Ребята, проанализируйте существующие решения. Вы наступаете на грабли, которые все прошли 10-15 лет назад.
Правда, там это сделали для исходящих правил.
Штука в том, что когда у вас таких правил 20+, у вас просто обычный звонок без всяких изысков нагружает ядро asterisk. Фишка в том, что в таком варианте самый сложный по CPU звонок — неправильный набор. Что очень плохо.
Ну про мусор в логах и говорить нечего.
Вот не помню где. Толи в сангомовском облачном решении, толи еще где.
А еще это потом очень тяжело расширать/менять(поскольку вы не можете просто вставить custom правило используя asterisk-way).
Точно помню, что это было убрано из всех продакшн новых версий по причине " у нас 100% cpu и почти нет звонков".
Ребята, проанализируйте существующие решения. Вы наступаете на грабли, которые все прошли 10-15 лет назад.
А вообще у вас очень много анти-паттернов даже в предоставленном кусочке кода
Кусочек с транками можно сильно проще переписать вот так
Почему именно так? Так если вы хотите добавить интеграцию, вы это просто меняете в статическом файле, а не лезете куда в ваш код и ищите где генеряться конфиги.
Ну вот к примеру вы решите не перезванивать если не только ANSWER, но и BUSY.
зы правильное еще и флаги для транка описать вне диалпана в переменных, но это усложняет понимание данного кусочка.
- использовано execif->gosub вместо gosub-if
- Hangup в средине диалплана(хотя тут очевидно проще было execif->return). Тут же остутсвие возврата из gosub в одном из случаев.
- множественные gotoif вырождающиеся потенциально с сотни переходов.
- повторение одинаковых контекстов отличающихся по сути двумя переменными.
- CDR могут не отражать попытки неуспешного звонка на некоторые транки(хотя в новых версиях астериск это побороли в ядре, есть настройки).
- Неправильное использование функции REGEX. Она собственно возвращает 1 для того, чтоб можно было сразу написать
GosubIf($[ ${REGEX("^[0-9]{6}$" ${EXTEN})} ]?SIP-PR-2-out,${EXTEN},1)
Кусочек с транками можно сильно проще переписать вот так
[call-trunk]
exten => _X!,1,ExecIf($["${number}x" == "x"]?Hangup())
exten => _X!,2,Noop(placeholder)
exten => _X!,3,ExecIf($["${DIALSTATUS}" != "ANSWER"]?Return())
same => n,Hangup
[SIP-PR-1]
include => call-trunk
exten => _X!,2,Dial(SIP/PR-1/${EXTEN},600,TeK))
[SIP-PR-2]
include => call-trunk
exten => _X!,2,Dial(SIP/PR-2/${EXTEN},600,TeK))
Почему именно так? Так если вы хотите добавить интеграцию, вы это просто меняете в статическом файле, а не лезете куда в ваш код и ищите где генеряться конфиги.
Ну вот к примеру вы решите не перезванивать если не только ANSWER, но и BUSY.
зы правильное еще и флаги для транка описать вне диалпана в переменных, но это усложняет понимание данного кусочка.
Sign up to leave a comment.
Asterisk. Dialplan Askozia 6. Исходящие звонки