asterisk.ru

alvama писал(а):Конечно можно уйти от рилтайма.

Я не призывал к этому. Можно иметь Aterisk realtime на 10 000 пользователей, с диалпланом в 5 строк. Которые нет смысла засовывать в MySQL.

alvama писал(а): Куда ни глянь все уходят от конфигов в тексте в конфиги в скуль.

Ага, асобенно массово популярные freePBX, Elastix, etc. У которых MySQL всё выгружает как раз в текстовый extensions_additional.conf

alvama писал(а): К тому-же удручает количество строк. Сейчас в таблице extensions около 500 строк, которые относятся к Питерским префиксам сотовых операторов. надо добавить еще около 100 для перебежчиков. И новые префиксы я добавляю в базу не руками, а апачем. .

Ну надо же! Какое-то нове слово в этой технологии?
Правильный же способ - содержать базу префиксов в MySQL в простом виде в двух колонках
Префикс || оператор.
Куда делать при команде Dial один SQL-запрос - префикс=ХХХ а возвращался бы - оператор. Вся строка имела бы однострочный синтаксис ExecIf.

alvama писал(а): при наборе dialplan show rt-panasonic1 идет ругань

Потому, что такого контекста, вероятно, нет.

Вы покажите то, что выводится при команде dialplan show "номер"@"контекст_через_который_происходит_набор".

А то, что использовать - дело сугубо личное, что удобнее в эксплуатации в той или иной ситуации, но не тренды.

fecyt, в модели realtime команды dialplan show не работают.
dialplan show "номер"@"контекст_через_который_происходит_набор" - это только в текстовых конфиг реализациях диалплана проверить можно.

april22 писал(а):скуль умер - ни кто не куда не звонит

А у меня есть odbc функции (разрешение звонков, форварды), без них будет абы что. Даже с текстовым диалпланом .

ded писал(а):в модели realtime команды dialplan show не работают.

Да да, уже проверить сам успел.

Куда делать при команде Dial один SQL-запрос - префикс=ХХХ а возвращался бы - оператор. Вся строка имела бы однострочный синтаксис ExecIf.

Спасибо всем откликнувшимся за помощь. Правильно я понимаю, что вывод такой: рилтайм диалплан не умеет правильно обработать два префикса разной длины и выбрать наиболее длинный, гарантировать порядок строк в селекте нельзя, и поэтому инзертить более короткие префиксы после соответствующих длинных не имеет смысла (да и звучит паршиво), значит рилтайм нам не подходит. Надо уйти от рилтайма на родную ODBC и маршрутизировать своим кодом? Так?

Вот покопался в интернете, нашел инфу, https://www.voip-info.org/wiki/view/Ast ... Extensions - параграф Caveats Так что работать с шаблонами в realtime он должен уметь.

alvama писал(а):Правильно я понимаю, что вывод такой: рилтайм диалплан не умеет правильно обработать два префикса разной длины и выбрать наиболее длинный

Нет! неправильно! не нужно мешать в кучу разные технологии и пытаться отыскать бриллиант в куче гуано. У диалплана нет задачи выбирать короткий или длинный, есть задача построчно обработать конфиг и на основании шаблона выдать false и продолжить, или поймать true - выполнить - прекратить выполнение. Если прям задача стоит сделать проверку в диалплане читаем -https://www.voip-info.org/wiki/view/Asterisk+func+len.

alvama писал(а):гарантировать порядок строк в селекте нельзя

Нет! неправильно! http://www.mysql.ru/docs/maryan/#lenght & http://www.mysql.ru/docs/man/Sorting_rows.html

alvama писал(а):Надо уйти от рилтайма на родную ODBC и маршрутизировать своим кодом? Так?

Нет! Не так! Риалтайм способ хранения конфигурации. ODBC драйвер. Кислое смешать с мягким и получить оранжевый свист.....

В итоге я не смог имея строку с exten = '_89111.' использовать другую строку с exten='_89111234567' и другой appdata.

Кому интересно вопрос решился путем замены в существующих префиксах точки на нужное количество иксов. Недавно вставленная строка exten='_89111234567' проигрывала строке exten = '_89111.' но выигрывает у '_89111XXXXXX'. Всем спасибо за участие.

Хоть бы Вы Книгу читали, там описан порядок приоритетов выбора шаблонов.