Элтекс

Приветствую Вас, многоуважаемый All!

Возник вот такой вопрос: в плане нумерации есть префикс 8, с минимальным числом цифр 11 и максимальным 20 (был в штатной комплектации и мне подходит) этот префикс направляет звонок в поток, где дают М/Г. Еще там категория стоит межгород.

Есть внутренние номера, расположенные на соседней АТС, подключенной по потоку, номера 8ХХХ.

Создаю в плане нумерации еще один префикс 8 с минимальным количеством цифр 4 и максимальным - тоже 4.

В результате получаю конфликт. А как еще разрулить такую ситуацию, если не в плане нумерации? Разные планы нумерации не подходят, людям надо звонить и туда и на межгород. Да и АТСка моя "младшая", хотя и собирается "подрасти", т.е к тем номерам всепривыкли. И как назло 8ХХХ номеров тьма-тьмущая в их планах.

Просто по логике вещей это разные префиксы, поскольку пересечения числа цифр в номере нет никакого.

Попытка создать префиксы 80ХХ-89ХХ приводят к такому же конфликту.

Просто, как мне кажется, если префикс срабатывает после набора первой же цифры, то зачем тогда проверять минимальное количество цифр в номере? Мне казалось, что АТС должна получить весь номер, а потом сличить его с планом чтобы понять куда бы его направить? нет?

Здравствуйте, Антон!
На сколько я понял, у Вас в одном плане нумерации дожно быть 2 префикса, начинающихся на 8...
А маршрутизация вызовов, с номером начинающимся на 8, должна производиться по признаку мин. макс количество цифр?

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

Если у вас все-таки не пересекающиеся номера, а просто короткие, то возможно задать точные префиксы для коротких и остальные номера закрыть на м/г.

Например:
83333 это внутренний номер (или префикс на внутреннее направление).
необходимо закрыть 80-89 (кроме 83), 830-839 (кроме 833), 8330-8339 (кроме 8333) на направление м/г.

Алексей Сергеев писал(а):Разделение номеров по их длинне не предусмотрено.

А зачем тогда в настройках указание длин минимальнй и максимальной длинны номера?

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

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

Алексей Сергеев писал(а):Если у вас все-таки не пересекающиеся номера, а просто короткие, то возможно задать точные префиксы для коротких и остальные номера закрыть на м/г.

Не совсем понятен термин "закрыть". Если не сложно, поясните его значение, чтобы избежать недопониманий.

Алексей Сергеев писал(а):Например:
83333 это внутренний номер (или префикс на внутреннее направление).
необходимо закрыть 80-89 (кроме 83), 830-839 (кроме 833), 8330-8339 (кроме 8333) на направление м/г.

Хм. Я так и сделал. Давайте я поясню конфигурашку.
Есть 3 потока.
PRI1 - выход в город (межоператорский поток)
PRI2 - выход на АТСку, на которой сидит весь комплекс зданий, там нумерация 4х значная от 1000 до 9999 кроме 6200-6599.
PRI3 - TM.IP с выходом на IPPBX того же комплекса с четырехзначными номерами с 6200 до 6599.

Теперь человек снимает трубку и звонит.
Вариант 1. Он набирает номер 8888. Должен угодить на PRI2.
Вариант 2. Он набирает номер 9405555. Должен угодить на PRI1. (городской номер без 8ок и 9ок, я оператор связи и выход через 9ку или 8ку недопустим)
Вариант 3. Он набирает 6399. Должен попасть через ТМ.IP на IPPBX.
Вариант 4. Он набирает 81014045309585838 должен угодить на PRI1 и дозвониться в штаты.

Вариант 2 и 4 можно исключить введением направления "Default".

Как видите, во всех случаях появляется вероятность, что человек, желающий позвонить по внутреннему номеру нарвется на конфликт с 8кой. Также, он сможет получить проблему звонка на любую другую цифру, все они присутствуют в плане нумерации "соседней" станции.

Я понимаю, что если человек должен "жить" как будто он есть абонент той самой станции соседней, то для него нужно делать план нумерации один единственный - отправлять все, что угодно в PRI2. Но и это не совсем ясно как сделать. ПРидется прописать все цифры от 0 до 9 и в плане нумерации "отправить" их на PRI2, что неудобно. Вместо 1 правила - целых 10.

Женя писал(а):Здравствуйте, Антон!
На сколько я понял, у Вас в одном плане нумерации дожно быть 2 префикса, начинающихся на 8...
А маршрутизация вызовов, с номером начинающимся на 8, должна производиться по признаку мин. макс количество цифр?

Приветствую Вас, Евгений!
Совершенно справедливо!
Суть такого подхода в том, что человеку не требуется знания никаких мегапрефиксов для выхода в любую сеть. Просто есть пара тысяч абонентов, которые не должны заметить того, что пересели с одной АТС на другую.
Я думал, что это противоречие решается прописыванием Виртуальных абонентов, но Вы, Евгений, меня в этом разубедили в предыдущей нашей переписке.

> А зачем тогда в настройках указание длин минимальнй и максимальной длинны номера?
- чтобы откинуть не до конца набранное
- чтобы начинать занятие на исходящее направление с достаточным количеством цифр
- чтобы перестать ожидать цифры и сразу пойти пакетом по достижении максимальной длины номера.

> Согласен, что не все протоколы это поддерживют, но станция ведь поддерживает.
Я просто пояснил исторически сложившуюся ситуацию с маршрутизацией. На ВСС Вас не поймут. Есть требования к нумерации и они удовлетворены.

Простой пример. транзит декады. пока накопится полный номер и заново оттранслируется в исходящий канал пройдет много времени.

> Не совсем понятен термин "закрыть". Если не сложно, поясните его значение, чтобы избежать недопониманий.
Создать недостающие номера префиксов и направить на одно направление. В админе есть функция закрытия всех свободных номеров на одно направление.

> Хм. Я так и сделал. Давайте я поясню конфигурашку.
Прописывать 8ХХХ префиксы надо? надо.
- прописываем все 8ХХХ номера (порты или префиксы)
- прописываем 6ХХХ номера
- вызываем функцию закрытия на направление. автоматически генерируется набор префиксов "закрывающих" дырки в нумерации на транк группу.
- удаляем лишнее (по обстоятельствам, попавшие дырки по 6ХХХ например)

Если меняется состав 8ХХХ номеров. удаляем автоматические префиксы (они одним сплошным списком с идентичным названием)
модифицируем префиксы 8ХХХ, повторяем закрытие.

В Вашем варианте есть требования различения номеров 8101 и 81014045330... ?

Также и про одно правило против 10.
Вызовом одной функции закрываем все дырки (неназначенные) в нумерации на одно направление.

Алексей Сергеев писал(а):[color=green]
В Вашем варианте есть требования различения номеров 8101 и 81014045330... ?

Также и про одно правило против 10.
Вызовом одной функции закрываем все дырки (неназначенные) в нумерации на одно направление.

Приветствую Вас, Алексей!
Еще раз прошу меня простить.
Я делаю сейчас вот что.
Префикс 6 мин длинна 5, макс - 4 - отправляем в VoIP
Префикс 6410013, мин длинна 7, макс 7 - туда же.
И ступор у станции "линия перегружена".

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

В разделе модификаторы набора именно так и сделано. Т.е. все, что не соответствует ничему ранее описанному - делай вот так. Что описано - то по описанию.

Антон Никифоров писал(а):..Приветствую Вас, Сергей!..

Обратите внимание, не Сергей, а Алексей Сергеев

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

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

Женя писал(а):

Антон Никифоров писал(а):..Приветствую Вас, Сергей!..

Обратите внимание, не Сергей, а Алексей Сергеев

1000 извинений, Алексей. Простите. Исправился.

Алексей Сергеев писал(а):

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

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

Хорошо, а 10 тысяч правил человеком как воспринимаются? Человек должен думать, а машина считать, но не наоборот.
Простите. Остановлюсь лишь на том конфликте номеров, который уже описан.

Можно сократить пример до минимума.
Если я прописываю пир 6410013, то я теряю возможность прописать любой из следующих более коротких номеров:
6, 64, 641, 6410, 64100, 641001. При попытке добавления возникает конфликт.
Соответственно, я не могу их никак использовать, что недопустимо в моей ситуации. Да и куда они пойдут - тоже неясно. Туда же куда и 6410013? или куда? И это 7мизнак.

Таким образом, должен быть доступен один из вариантов фильтрации дайлплана и добавления всех этих пиров:
1. Проверка длинны (Вы уже сказали что она не производится)
2. Проверка последовательности написания пиров (у меня это не вышло)
3. Установка приоритета пира.
Даже смена типа с "общий" на "служебный" ничего не дала, станция все-равно при проверке плана нумерации говорит, что префикс 64 конфликтует с префиксом 6410013 (ровно как и просто 6 и все остальные усечения номера).

И даже, если упростить схему до минимума. То я не понимаю, как сделать так, чтобы любой звонок от пользователя уходил в определенный отдельно взятый поток. Прописать префиксы 0-9 и направить их в этот поток?

Можно, коенчно, зарулить все звонки на систему с более мощным фильтром и вернуть оттуда звонки по другому потоку. Но, как я понимаю, если исходящие порты на плате TM.IP указать можно, то для входящих, разделить мои 128 голосовых каналов на группы, чтобы им впоследствии присвоить разные планы нумерации - невозможно. А использовать для таких целей потоки - дюже дорогое удовольствие.

Из чего я делаю вывод, что наверняка это как-то решено в Вашей станции. Не могли Вы это упустить. Это я что-то упустил. И я очень Вас прошу помочь мне разрешить сей конфликт.

P.S. Функции "закрыть направление" я почему-то не обнаружил, подскажите как ее найти, пожалуйста.

Меню "Конфигурация" / "Префиксы" / "Закрыть номера на направление".
Все что вы описали - конфликты в нумерации.
Помочь избежать конфликтов и не писать много префиксов вручную помогает функция "закрытия напрвления". Я уже описал принцип использования.

Если у вас ситуация с номерами что вы вынуждены расписывать семизнаки, то придется мириться с большим количеством префиксов.

для совместного использования 6 и 6410013
необходимо:
1 префикс 6410013
и 54 префикса закрывающих остальные номера на 6.

Приветствую Вас, Алексей!
То, что Вы описали - я понял. Даже в прошлый раз. Не нашел только функции "закрытия" в меню. Спасибо за подсказку.

Меня больше беспокоит вопрос того, как сделать префикс 64 при наличии префикса 6410013.
Иными словами, в моих планах нумерации есть номер 6410013 и номер 6410. Как быть именно с этими двумя номерами?
Теперь я сделал "закрытие" и обнаружил, что 6410 не существует в закрытом направлении.

... в моих планах нумерации есть номер 6410013 и номер 6410. Как быть именно с этими двумя номерами?

К сожалению никак. Текущий механизм обработки вызовов не позволяет одновременно иметь два таких номера в одном плане нумерации.

Алексей Сергеев писал(а):

... в моих планах нумерации есть номер 6410013 и номер 6410. Как быть именно с этими двумя номерами?

К сожалению никак. Текущий механизм обработки вызовов не позволяет одновременно иметь два таких номера в одном плане нумерации.

И нет никакой возможности сделать "виртуального" пользователя или еще как-то поступить обойдя это ограничение? Ведь обязан же существовать обход подобных ситуаций. Наверняка уже не первый раз Вы с таким сталкиваетесь.

Те варианты, что доступны моему пониманию:
Отправить ВСЕ без исключения звонки на Asterisk (Definity или Siemens, лишь бы там была функция построения планов по регулярному выражению или хотябы подстановки), а оттуда вернуть по-направлениям расставленные в другие планы.
Т.е. человек локальный снял трубку. и набрал 6410. Звонок идет по PRI0 на астериск, а оттуда возвращяется уже через другой поток и в другой план нумерации и уходит куда нужно.
Недостатки очевидны:
1. Лишняя точка отказа
2. Лишние потоки (кстати, если бы TM.IP позволяла разбивать ее на "части" и позволяла бы писать дайлпланы по-хитрее - было бы куда проще сделать это через нее, скажем сделав ей несколько IP адресов, чтобы можно было каждый из них привязать к своему плану нумерации при входе звонка от него в станцию)

И я обнаружил что при "закрытии направления" значение максимальной и минимальной длинны номера имеют значение.
Т.е. если стоит префикс 6410013 с длинной в 4/4 - он не проходит и станция выдает "неправильно набран номер".

Также в трейсах встречаются:

MC240 писал(а):(49:02:21.955)[00/01:00] CMD: 'QUERY NEXT DIGIT'
(49:02:22.515)[00/01:00] Port msg: 'Digit': 13.
(49:02:22.515)[00/01:00] Dial In (in=01, need rm=0): {3} (flg=next)
Digit in buf: 07. Sended: 00
(49:02:22.515)[00/01:00] Dial Proc (plan 00): x{6}{4}{1}{0}{0}{1}{3} <Next Digit enabled>
In-Dial: link to index, num len 7
(49:02:22.515)[00/01:00] LinkIdx: type=PREFIX, idx=01. Access code 0
(49:02:22.515)[00/01:00] Link Prefix 01: type 'TRUNK.GRP', idx=1
User access code=00, pwd label 00
TG access need CID=mandatory, 'Quered CID'=y, 'Have CID'=y
(49:02:22.515)[00/01:00] 'Trunk Group': Link, idx=1
TG 01. Digit proceed=7, in buf=7 (need del=0)
Prefix modify num: use prefix, del 0
TG modify num: dial buf <{6}{4}{1}{0}{0}{1}{3}> (need del 0)
TG modify num: insert dial <>, need del 0

Не это ли выбор транка после получения всех цифр?

MC240 писал(а):(49:02:22.515)[00/01:00] 'Trunk Group': called dir type 0, called nature=1
Dial buf: x{6}{4}{1}{0}{0}{1}{3}
Select order: FIRST
(49:02:22.515)[00/01:00] 'Trunk Group': Link VoIP on slot=00/00
(49:02:22.515)[00/01:00] Set link to IP, slot 00
chan limit: 128
(49:02:22.515)[00/00:76] State: 'OutUse'
(49:02:22.515)[00/00:76] V-chan alloc, line type '8M-Trunk.' (02). Shelf 0, line 255
Search for mode 'Line8M-Common'
Found free v-chan: 05:00
(49:02:22.515)[00/00:76] Voice off, v-chan 05:00
(49:02:22.515)[SWITCH] Off 5,0
(for sip-t) ss7 category: e3 (227)
(for sip-t) SS7 Transmit medium req: 0x03
(for sip-t) SS7 Nature Of connection: 0x10
calling set from linked: clg_type 1, calling_present_screen 13
calling number: type <SUBSCRIBER>, present/screen: 13, len 4, number: 6.3.0.1.
called number type: <SUBSCRIBER>
(for sip-t) Hop Counter: default = 31
(for sip-t) Prop delay: default = 0
(49:02:22.515)[00/00:76] Link VoIP: next wait digit
(49:02:22.515)[00/00:76] Post link for setting TG param (incoming 00/01:00) - TG 1, digit min=7/max=7/t-out=10 (next digit=y)
(49:02:22.515)[00/01:00] Go dial to ext.port 00/00:76
(49:02:22.515)[00/01:00] State: 'InUse'
(49:02:22.515)[00/01:00] CMD: 'INFO: SHOW INFO' Parent=00/00:76.
(49:02:22.515)[00/01:00] CMD: 'GO USE (WITH OUTGOING DIAL)' Parent=00/00:76.
(49:02:22.515)[00/01:00] Next Digit: 16. Dial from buffer, send=0, len=7, need rm=0
(49:02:22.515)[00/00:76] CMD: 'DIAL DIGIT' Parent=00/01:00. Param=0x00000016
(49:02:22.515)[00/00:76] Enblock: Called number <6>
(49:02:22.515)[00/01:00] Next Digit: 14. Dial from buffer, send=1, len=7, need rm=0
(49:02:22.515)[00/00:76] CMD: 'DIAL DIGIT' Parent=00/01:00. Param=0x00000014
(49:02:22.515)[00/00:76] Enblock: Called number <64>
(49:02:22.515)[00/01:00] Next Digit: 11. Dial from buffer, send=2, len=7, need rm=0
(49:02:22.515)[00/00:76] CMD: 'DIAL DIGIT' Parent=00/01:00. Param=0x00000011
(49:02:22.515)[00/00:76] Enblock: Called number <641>
(49:02:22.515)[00/01:00] Next Digit: 1A. Dial from buffer, send=3, len=7, need rm=0
(49:02:22.515)[00/00:76] CMD: 'DIAL DIGIT' Parent=00/01:00. Param=0x0000001a
(49:02:22.515)[00/00:76] Enblock: Called number <6410>
(49:02:22.515)[00/01:00] Next Digit: 1A. Dial from buffer, send=4, len=7, need rm=0
(49:02:22.515)[00/00:76] CMD: 'DIAL DIGIT' Parent=00/01:00. Param=0x0000001a
(49:02:22.515)[00/00:76] Enblock: Called number <64100>
(49:02:22.515)[00/01:00] Next Digit: 11. Dial from buffer, send=5, len=7, need rm=0
(49:02:22.515)[00/00:76] CMD: 'DIAL DIGIT' Parent=00/01:00. Param=0x00000011
(49:02:22.515)[00/00:76] Enblock: Called number <641001>
(49:02:22.515)[00/01:00] Next Digit: 13. Dial from buffer, send=6, len=7, need rm=0
(49:02:22.515)[00/00:76] CMD: 'DIAL DIGIT' Parent=00/01:00. Param=0x00000013
(49:02:22.515)[00/00:76] Enblock: Called number <6410013>

А вот завершение набора в SIP транк.

MC240 писал(а):(49:02:22.515)[00/00:76] Stop Dial, reason 'max digit'
(49:02:22.515)[00/00:76] Voice link up: 00/01:00
(49:02:22.515)[00/00:76] Voice link with 00/01:00 (v-chan 05:00 <-> 04:00)
(49:02:22.515)[SWITCH] Link 5,0 <-> 4,0
(49:02:22.515)[00/01:00] CMD: 'STOP DIAL' Parent=00/00:76. Ptr=<00000000>
(49:02:22.515)[00/01:00] Activate flag 'Stop Dial'

А вот начинается открытие соединения на SIP направление.

MC240 писал(а):(49:02:22.515)[SIP-T/ISUP] <<-- TX. Slot '00' IAM- Initial Address Message:
[optional params]
[end of params]

(49:02:22.520)[00/00:76] Slot cmd: 'Seize' : 01.01.07.16.14.11.1A.1A.11.13.02.06.01.13.06.03.00.01.04.1D.01.10.20.00.E3.03.02.08.06.01.10.46.01.10.F3.0A.04.01.13.36.10.3D.01.1F.31.02.00.00.00.
(49:02:22.520)[00/00:76] Slot cmd: 'V-Chan Connect' : 05.00.
(49:02:22.520)[00/00:76] State: 'Wait ack'
(49:02:22.520)[00/01:00] Go Wait-Ack
(49:02:22.520)[00/01:00] Voice off, v-chan 04:00
(49:02:22.520)[SWITCH] Off 4,0
(49:02:22.520)[00/01:00] State: 'Wait'
(49:02:22.640)[00/00:76] Port msg: 'SeizeAck': 00.
(49:02:22.640)[00/00:76] State: 'OutUse'
(49:02:22.640)[00/01:00] Go dial to ext.port 00/00:76
(49:02:22.640)[00/01:00] State: 'InUse'
(49:02:22.640)[00/01:00] CMD: 'INFO: SHOW INFO' Parent=00/00:76.
(49:02:22.640)[00/01:00] CMD: 'GO USE (WITH OUTGOING DIAL)' Parent=00/00:76.
(49:02:22.640)[00/00:76] Stop Dial, reason 'max digit'
(49:02:22.640)[00/00:76] Voice link up: 00/01:00
(49:02:22.640)[00/00:76] Voice link with 00/01:00 (v-chan 05:00 <-> 04:00)
(49:02:22.640)[SWITCH] Link 5,0 <-> 4,0
(49:02:22.640)[00/01:00] CMD: 'STOP DIAL' Parent=00/00:76. Ptr=<00000000>
(49:02:22.640)[00/00:76] Port msg: 'Call Proceed'
(49:02:22.640)[00/00:76] Message: Call Progress
(49:02:22.640)[00/00:76] Stop Dial, reason 'chan.event'
(49:02:22.640)[00/00:76] Voice link up: 00/01:00
(49:02:22.640)[00/00:76] Voice link with 00/01:00 (v-chan 05:00 <-> 04:00)
(49:02:22.640)[SWITCH] Link 5,0 <-> 4,0
(49:02:22.640)[00/01:00] CMD: 'STOP DIAL' Parent=00/00:76. Ptr=<00000000>
(49:02:23.440)[00/00:76] Port msg: 'Answer'
(49:02:23.440)[00/00:76] Answer from chan in state OutUse
(49:02:23.440)[00/00:76] Voice link up: 00/01:00
(49:02:23.440)[00/00:76] Voice link with 00/01:00 (v-chan 05:00 <-> 04:00)
(49:02:23.440)[SWITCH] Link 5,0 <-> 4,0
(49:02:23.440)[00/00:76] State: 'Talk'
(49:02:23.440)[00/00:76] Set flag 'TALK': 11/06/09 16:59:37 175655.610
(49:02:23.440)[00/01:00] CMD: 'RESPONSE CALL' Parent=00/00:76.
(49:02:23.440)[00/01:00] Voice link up: 00/00:76
(49:02:23.440)[00/01:00] Voice link with 00/00:76 (v-chan 04:00 <-> 05:00)
(49:02:23.440)[SWITCH] Link 4,0 <-> 5,0
(49:02:23.440)[00/01:00] State: 'Talk'
(49:02:23.440)[00/01:00] Set flag 'TALK': 11/06/09 16:59:37 175655.610
(49:02:23.440)[00/01:00] Port cmd: 'Timing' : 00.00.
(49:02:23.440)[00/00:76] Slot cmd: 'V-Chan Connect' : 05.00.
(49:02:25.880)[00/00] Slot msg: 'Dev:Slave Down'
(49:02:32.060)[00/00] Slot msg: 'Dev:Slave Down'
(49:02:32.500)[00/01:00] Port msg: 'PreOnHook'
(49:02:32.680)[00/01:00] Port msg: 'OnHook'
(49:02:32.680)[00/01:00] On-Hook: State 'Talk', LINK=00/00:76, A=none:-1, B=none:-1
(49:02:32.680)[00/01:00] Release linked with cause: state 'Talk', linked port 00/00:76 (cause not set)
(49:02:32.680)[00/00:76] CMD: 'RELEASE' Parent=00/01:00.
(49:02:32.680)[00/00:76] Release port, state Talk, cause Normal call clearing
(49:02:32.680)[00/00:76] Voice off, v-chan 05:00
(49:02:32.680)[SWITCH] Off 5,0
(49:02:32.680)[SWITCH] Off 5,0
(49:02:32.680)[00/00:76] State: 'Release'

И окончание разговора.
Все мои "изыскания" подтверждаются еще и тем, что первый пакетик от TM.IP к SIP серверу приходит ровно в момент набора последней цифры из 7мизначного номера.
Т.е. слова о том, что выбор направления и транка осуществляется по первой цифре и сразу идет в линию не совсем соответствует действительносити. Разница, как минимум, в технологии дальнейшей передачи.

Может я опять полез куда не следует, Вам лучше знать внутренности Вашего продукта, но сдается мне, что выбор направления осуществляется и по числу набранных цифр тоже. Т.е. алгоритм (по моему мнению) может обрабатывать и одинаковые префиксы при условии указания непересекающихся длинн.
Скажем, если есть четкие указания длинны префикса и длины двух одинаково начинающихся префиксов не пересекаются - то это не будет противоречить Вашему алгоритму ни капельки. Зато такое нововведение откроет почти безграничные возможности по описанию дайлпланов и исключит недоступность некотороых направлений из-за обеспечения исторически сложившихся нумераций.
Пользователь, описав длины префиксов, сам ограничивает себя в скорости исполнения его звонка. Если в плане есть только 9ка и 8ка как выход в город - то пусть все работает пулей, как это у Вас принято. А если в плане есть 4х знаки, то уж простите, придется подождать пользователю пока он не наберет необходимое число цифр.
Есть такой подход у разного роде "ленивых" операторов. Этот подход заключается в том, чтобы все, что набрал пользователь отправлять сначала в МГТС, как "значимому оператору". Пусть он решает подходит ему такой номер или нет. А если не подходит - следующему. Это занимает много времени на соединения и отлупы, но это быстрее ожидания набора нужного числа цифр.

Если он не делает этого (хоть одного из подходов) сейчас, то впорос мой следует перефразировать: когда он сможет? или что сделать чтобы смог?