Вот нашла на меня интеренсная мысль. Во всех умных книгах, хауту и мануалах (как правило буржуйский) под местные, мг\мн , и мобильные звонки используют различных операторов, соответсвенно у них куча outbound routes, каждый из которых ведёт в свой транк. Они пишут жестокие диал паттерны, чтобы отловить звонки и послать их в нужный транк.
Всё красиво, технолочтгно, местами кавайно , а у меня один провайдер, один транк, в который всё и падает кроме внутренних.
Чисто эмпирическим методом подобрал такой паттерн при которм всё работает "XXX.". Т.е. всё что больше 3-х цифр.
Насколько это правильно с точки зрения идеологии *? Или же необходимо всё же фильтровать по префиксам, но всё равно слать в один транк? Головой понимаю, что тот паттерн что работет у меня потенциально крив и даже опасен, но вот чтото в литературе такого не нашёл.

XXX. заменяется просто на
X.
потому что про внутренние трёхзначные * и так прекрасно знает.

Благодарю. Как я понял отлов по префиксам более элемент безопасности?

ну вообще все от вашей конкретно ситуации зависит - смотря чего вы там напрограммировали. если у вас контекст с внутренними экстеншенами включен ПОСЛЕ контекста исходящих, то X. в исходящих перехватит на себя и все внутренние тоже, чего вы врядли хотите.

Если же исходящие подключены после внутренних - не перехватит.

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

dimas
Благодарю)
Развернуто, понятно.

Возник еще один вопрос. Оператор шлет номера в формате АВСХХХХХХХ, без 8, однако принимать делает всё равно с ней. Поэтому, если на телефоне нажать "перезвонить", то слышу это дурное "ол сёркитс а бизи нау", однако ума не приложу, где перехватывать цид и дописывать 8 ..

Это не CID, а DNID (destination)
exten _АВСХХХХХХХ,1,Dial(SIP/operator/8${EXTEN})
(Вы же не запишете АВС буквально так у себя? :)

повторю себя :)
всее очень индивидуально. и миллион способов сделать одно и то же.

У меня, например на всех входящих звонках сразу "нормализация" callerid проводится. Правила вида:
Россия:
1. если длина номера 10 символов - приписать '7' в начеле
2. если длина номера 11 символов и первый '8', отрезать его и вместо него приписать '7'

ну и для америки и англии еще куча правил, еще о '000' позаботится и все такое.

В результате (если все хорошо) все мои callerid это полные E164 номера - country-area-local. и "перезвон" на них работает нормально (при условии, конечно что у вас все исходящие роуты по странам прописаны нормально)

В третий раз повторюсь что все индивидуально - у нас много международных звонков. А если у вас только Россия то вам лишняя семерка в начале только глаза мозолить будет. Ну способ ded'а для вас должен прекрасно работать тогда.

dimas, нормализация - прекрасно! Тебе уже один шаг до локального/глобального CIDlookup. Или он уже сделан? :)
А воопче, тебе при всей нормализайцыи в е164 надо ещё преобразования при коротких наборах делать, не так ли? Например, набираем 7654321 подразумеваем
exten => _ZХХХХХХ,1,Dial(SIP/operator/7495${EXTEN}) ?
Все полностью длинные наборы то долго набирать, верно?

ну да, нужно.
станция в Питере считает валидным семизначный номер и дописывает 7812 в начале. В других городах/странах - другие правила. Но глобальноо мысль в том чтобы роутить полные номера. Типа так проще и системнее.

Что ты под CID lookup подразумеваешь я не совсем понимаю. У меня под этим названием проходит поиск имени в базе сотрудников по CID при входящем звонке чтобы имя подставить. Но ты ведь не это имеешь в виду?

Это-это!
Просто тема CID lookup имеет разное наполнение. Перечислю в порядке глубины:
1. поиск имени в базе (не только сотрудников) по CID (текстовый файл)
2. поиск имени в базе MySQL, Postgre, ODBC (не только сотрудников но и клиентов) по CID
3. поиск имени в enum.org & e164.org

Тип источника:Выберите тип источника. Можно выбрать из:

* Внутренний: используется внутренняя база Астериск в качестве источника данных, используется модуль Телефонная книга для отображения этих данных.
* ENUM: используется сервис ДНС для поиска имён, который, в свою очередь, просматривает специальные зоны ENUM, указанные в файле enum.conf
* HTTP: используются запросы HTTP GET используя номер позвонившего в качестве аргумента для получения его имени.
* MySQL: запросы в базу данных MySQL для получения его имени.