asterisk.ru

Возможно, решение не стандартное, но оно работает

ОНО работает до того момента, когда диалплан перестает быть нормально читабельным из-за обилия вариантов. Потом же сами будете за голову хвататься и лопатить.
Пример, который указал tоl_iwan тоже неплох при жонглировании кучей исходящих номеров-каналов.

Wapo писал(а):ОНО работает до того момента, когда диалплан перестает быть нормально читабельным из-за обилия вариантов. Потом же сами будете за голову хвататься и лопатить.

Обилие вариантов в любом случае не способствует удобочитаемости. ИМХО, в плане удобочитаемоести мой вариант с одним контекстом и сопоставлением CID проще в восприятии, чем куча контекстов с инклудами. Хотя, как говорится, на вкус и цвет...

сопоставлением CID проще в восприятии,

Вот и подходим к самому главному - планирование внутренней нумерации. Пример: отдел продаж 200-299, отдел закупок 300-399, руководство 101-199. Кто и как выйдет в город - понятно сразу по тому же _X.,/_[1]XX или уж инклуды, когда для руководства надо отключить запись или же дать продажникам функционал дополнительных фишек (клиента послать подальше и т.д.). Всяко глупо городить конструкцию серии

exten => _X./201,1,Set(CALLERID(num)=3000101)
exten => _X./202,1,Set(CALLERID(num)=3450101)

можно использовать astdb
пример в самом простом варианте
;
DB(peers/101)=TRUNK1
DB(peers/201)=TRUNK2
;
exten => _X.,1,Dial(${DB(peers/${CALLERID(num)})}/${EXTEN})
;