Вопрос по плану нумерации

[Алексей Сергеев]

Мин/макс цифр в префиксе не влияют на выбор:
- отбрасывают не удовлетворительные (был конец набора, но минимум не достигнут)
- по достижении макс цифр идут пакетом без ожидания конца набора.

т.е. пассивные проверки при уже совершенном выборе.

По приведенному логу: занятие в SIP всегда происходят по получению необходимого количества цифр, т.к. протокол такой.
Я про занятие сразу в канал приводил пример CAS+декада.

Про семизначный префикс с параметрами 4/4.
Это просто ошибка конфигурирования. По четырем цифрам сработает таймаут набора (т.к. до самого префикса не доберется). По 7 цифрам не удовлетворит условиям в префиксе.

[Антон Никифоров]

Приветствую Вас, Алексей!

Мин/макс цифр в префиксе не влияют на выбор:
- отбрасывают не удовлетворительные (был конец набора, но минимум не достигнут)
- по достижении макс цифр идут пакетом без ожидания конца набора.

т.е. пассивные проверки при уже совершенном выборе.

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

По приведенному логу: занятие в SIP всегда происходят по получению необходимого количества цифр, т.к. протокол такой.
Я про занятие сразу в канал приводил пример CAS+декада.

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

Очень простой пример для объяснения почему я так настойчив:
Есть городской аплинк. Туда улетает все, что набрал пользователь.
Точно известно, что "соседние" станции обрабатывают определенные номера. Мой вопрос: зачем набирать в город через поток, заведомо зная, что звонок вернется из города обратно этим же потоком, но займет 2 тайм слота, да еще и за исходящее соединение придется заплатить?
Вопрос второй. Зачем пользователю набирать (знать вообще) префиксы, если он помнит 7ми занчный номер и ему по-большому счету наплевать как АТСка его с этим номером соединит.
Пример "из жизни". Есть клиенты, которым мы обслуживаем всю их информационную систему, включая АТС. У их АТС падает городской поток и они хотят звонить нам чтобы об этом сообщить, но не могут (если у них МС240, а я рассчитываю что она у них скоро появится).
Поверьте, Алексей, я не просто так "сочиняю" я только из жизни "необходимостей" могу Вам рассказать тьму-тьмущую.

Про семизначный префикс с параметрами 4/4.
Это просто ошибка конфигурирования. По четырем цифрам сработает таймаут набора (т.к. до самого префикса не доберется). По 7 цифрам не удовлетворит условиям в префиксе.

Простите, я имел ввиду префикс 4 знака 4/4 и префикс 7 знаков 7/7. Т.е. чтобы не пересекались длины совсем.
Мне кажется, что создав, например, префикс для внутренних абонентов 4 знака и ограничение 4/4 и все остальные (например) 20 знаков с длинами 5/20 можно четко и быстро определить направление и в случае 4х знаков (да, тут будет таймаут) и в случае больше чем четырех знаков.

[Алексей Сергеев]

Очень простой пример для объяснения почему я так настойчив:
Есть городской аплинк. Туда улетает все, что набрал пользователь.
Точно известно, что "соседние" станции обрабатывают определенные номера. Мой вопрос: зачем набирать в город через поток, заведомо зная, что звонок вернется из города обратно этим же потоком, но займет 2 тайм слота, да еще и за исходящее соединение придется заплатить?
Вопрос второй. Зачем пользователю набирать (знать вообще) префиксы, если он помнит 7ми занчный номер и ему по-большому счету наплевать как АТСка его с этим номером соединит.

Что-то я Вас перестал понимать. К чему этот пример?
Ведь нет проблемы сделать префиксы на номера соседних АТС ведущие на потоки к этим АТС? Пусть даже семизначные.
Основное направление при этом закрыть функцией закрытия.
Пусть все и набирают 7-ми значные номера.
Проблема, я так понял, только с 4-х значными?

В текущей версии ПО проблема коллизии 4-х и 7-ми знаков в одном плане нумерации не решается.

[Антон Никифоров]

Что-то я Вас перестал понимать. К чему этот пример?

К тому, что если я захочу клиентам поставить МС240, то я "попаду" на такую же проблему.

Ведь нет проблемы сделать префиксы на номера соседних АТС ведущие на потоки к этим АТС? Пусть даже семизначные.
Основное направление при этом закрыть функцией закрытия.
Пусть все и набирают 7-ми значные номера.
Проблема, я так понял, только с 4-х значными?

Проблема с их пересечениями в начале (первые 4 цифры)

В текущей версии ПО проблема коллизии 4-х и 7-ми знаков в одном плане нумерации не решается.

Вот мой вопрос и звучит: когда появится версия, способная обходить это ограничение?