Спасибо!

Благодарю.  К сожалению изменение структуры CDR не вариант т.к. повлияет на существующий сетап. Вопрос решился добавлением впереди еще одного extension c continue=true, который срабатывает на ^prefix(number), устанавливает odbc-cdr-ignore-leg=true и переприсваивает destination_number=$1. В итоге имеем что хотели без модификаций остального. Может кому пригодится.

Так это , odbc-cdr-ignore-leg=true (This allows you to selectively ignore channels.) по сути не писать CDR для текущего канала... чет не понял как это должно помочь с destination_number

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

в любом случае в cdr  пишется содержимое переменной destination_number  в конце звонка
так что Ваши махинации с отключением не нужны и не дают никакого профита

Хотите сказать, что значение odbc-cdr-ignore-leg ни на что не повлияет?

да

точнее даже так , назначение ее в true  а потом назад в false  ничего не дает

важно только в каком виде переменная destination_number (или любая другая в конце звонка)
то есть технически вы вначале можете нормализовывать номер , как вы вообщем-то и делаете , отрезая префикс  и фсе  - больше ничего не нужно тогда, если у вас без префикса диалплан работает корректно и ничего не страдает

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

не знаю как уж прям все модули , но odbc_cdr , pg_csv_cdr  и многие другие вызываются по завершению  вызова и только  и просто в таблицу пишут ровно те данные что назначены искомым переменным , не более того. Соответственно , если вы там делали адский ад трансферили  , подрезали обрезали  и вообще изгалялись над destination _number то запишется ее последнее значение

При трансферах, разве не будет генерироваться отдельная запись? В остальном мысль понятна 👍

А с чего вдруг ,

мы возможно о разных трансферах говорим, я о трансфере внутри диалплана, а не о трансфере звонка(как событие)

можно немного оффтопика?
интересно мнение телефонистов, насколько вообще востребованы такие вещи (биллинговые системы, с существующей командой разработчиков и поддержки, способных запилить под нужды)?
https://te-net.ru/products/sistema-irbis-f-oss/
Система стояла у реально крупного оператора связи, насколько реально ее продавать по демпинговой цене в сравнении с монстрами рынка этого класса решений?
Не реклама, просто вроде сейчас направление загибается, думаю, спросить у шефа, насколько он готов поменять концепцию и продавать "почти даром", в сравнении с текущей ценовой политикой.

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

понял, спасибо

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

Для допила/поддержки старой