Ситуация следующая:
1. Для выхода в город используется "9"
2. Есть два PRI потока
3. Один (1) освоенный, второй (1) новый.
4. Нужно постепенно переводить номера (всего около 500 штук) с одного (1) потока на второй (2), при этом что бы переведнные звонили только через (2) поток и принимали звонки и с (1) и с (2) так как городские индексы будут меняться
5. Поток (1) будет еще существовать некоторое время для приема входящих на старые городские индексы.

Как это лучше всего сделать, что бы после постепенного перевода в конце все было нормально настроено?

Зависит от того, как сейчас разруливается 9-ка..
Как настроена маршрутизация исходящих?

Для начала в
ld 20
prt
dn
9

REQ: prt
TYPE: dn
TYPE DNB
CUST 0
DN 9
DATE
PAGE
DES

DN 9
TYPE CDP
STCD TSC

Зависит от того, как сейчас разруливается 9-ка..
Как настроена маршрутизация исходящих?

"9" прикрутили так. Теперь получается что при наборе девятки все звонки автоматом заворачивает на ROUT 1. А нужно группами заворачивать на ROUT 2

ld 86
REQ new
CUST 0
FEAT dgt
DMI 4 Создать новый DMI
DEL 1
INST 7701 - код доступа к руту


REQ new
CUST 0
FEAT rlb
RLI 3 создать новый RLI
ENTR 0
LTER yes
ROUT 1
DMI 4
OVLL 3

ld 87
REQ new
CUST 0
FEAT cdp
TYPE tsc
TSC 9 9-ка выход в город
FLEN 8
RLI 3

INST 7701 - код доступа к руту

Зачем это???

REQ new
CUST 0
FEAT rlb
RLI 3 создать новый RLI
ENTR 0
LTER yes
ROUT 1
DMI 4
OVLL 3

Бррр... Ненадо никаких LTER.
В существующий RLI добавляете ещё один выбор - ENTRY 1, в котором прописан выход на рут второго оператора. В самих рутах и на абонентах прописываете TARG/TGAR, и каждый попадает на тот рут, на который ему нужно и можно.

Бррр... Ненадо никаких LTER.
В существующий RLI добавляете ещё один выбор - ENTRY 1, в котором прописан выход на рут второго оператора. В самих рутах и на абонентах прописываете TARG/TGAR, и каждый попадает на тот рут, на который ему нужно и можно.

А можно чуть более подробно. Я не совсем давно работаю с этой АТС

А можно чуть более подробно. Я не совсем давно работаю с этой АТС
Ваша 9-ка - это TSC. TSC привязан к RLI, т.е. к списку рутов.
Включите в RLI оба ваших рута: ENTRY 0 = ROUT 1, ENTRY 1 = ROUT 2 (подробности см. в доке по ESN).
Ограничения кому какой рут можно/нельзя использовать для выхода через этот RLI прописаваются через связку параметров TGAR абонента и TARG в руте (подробности см. в доке по Access Restrictions).

Бррр... Ненадо никаких LTER.
В существующий RLI добавляете ещё один выбор - ENTRY 1, в котором прописан выход на рут второго оператора. В самих рутах и на абонентах прописываете TARG/TGAR, и каждый попадает на тот рут, на который ему нужно и можно.

Где именно прописывать TARG/TGAR для рута? У абонента вроде как знаю.

Ваша 9-ка - это TSC. TSC привязан к RLI, т.е. к списку рутов.
Включите в RLI оба ваших рута: ENTRY 0 = ROUT 1, ENTRY 1 = ROUT 2 (подробности см. в доке по ESN).


Это уже получилось :) Огромное спасибо


Ограничения кому какой рут можно/нельзя использовать для выхода через этот RLI прописаваются через связку параметров TGAR абонента и TARG в руте (подробности см. в доке по Access Restrictions).

А это щас буду искать

Где именно прописывать TARG/TGAR для рута? У абонента вроде как знаю.
TGAR - у абонента, TARG в руте.
Если TARG == TGAR, то рут не выбирается, проверяется следующий рут.

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

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

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

Я так понимаю, имеется ввиду переписать в RLI entry новый маршрут вместо старого...
Clid'ы у всех переписать разом как-то напряжно, если много абонентов. А вообще да...
Да, сейчас сообразил, что если у товарища DIDN YES в CLID`е не получается, то плохо ему...
Но он, наверное, до этого ньюанса еще не дошел.

To TIMOS:
Опишите раскладку своего внутреннего DN диапазона на городскую сетку:
1.как было
2.как будет

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

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

А что бы сменить CLID у абонента, его нужно сначала вывести из GHT которых тоже насчитывается около 90 штук

А что бы сменить CLID у абонента, его нужно сначала вывести из GHT которых тоже насчитывается около 90 штук

А зачем менять у абонента? Лучше в самой таблице CLID сменить формируемый городской номер.

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

А что бы сменить CLID у абонента, его нужно сначала вывести из GHT которых тоже насчитывается около 90 штук
??? это как?
GHT-сервис обработки входящих вызовов, CLID-исходящих. Вроде никак не связано.
Про CLID смотрите
LD21
REQ prt
TYPE clid
.
.
Хоть кусочек этой таблицы здесь распечатайте. Основной массив абонентов настроен через DIDN YES или DIDN NO в CLID ENTRY?

Большое всем спасибо :) У меня получилось это сатварить.
Звонки уже ходят так как нужно.

Теперь возникла новая проблема. При звонке на номера нового потока номер на экране отображается без первых двух цифер.
Где указывается что отрезать?

Про CLID смотрите
LD21
REQ prt
TYPE clid
.
.
Хоть кусочек этой таблицы здесь распечатайте. Основной массив абонентов настроен через DIDN YES или DIDN NO в CLID ENTRY?

Все однообразные

ENTRY 122
HNTN
ESA_HLCL
ESA_INHN NO
ESA_APDN YES
HLCL ХХХХХХХ
DIDN NO
HLOC
LSC
CLASS_FMT DN

Большое всем спасибо :) У меня получилось это сатварить.
Звонки уже ходят так как нужно.

Теперь возникла новая проблема. При звонке на номера нового потока номер на экране отображается без первых двух цифер.
Где указывается что отрезать?

Нигде. Какой номер вам оператор присылает, его и покажет телефон, его же можно увидеть в трассировке.

Нигде. Какой номер вам оператор присылает, его и покажет телефон, его же можно увидеть в трассировке.

Тоесть это оператор высылает номер
44ХХХХХХХ
вместо
8044ХХХХХХХ ?

Нигде. Какой номер вам оператор присылает, его и покажет телефон, его же можно увидеть в трассировке.

И еще я кучу раз тут читал про ТРАСИРОВКУ
Как ее делать?

И еще я кучу раз тут читал про ТРАСИРОВКУ
Как ее делать?
LD96
enl msgi NN
enl msgo NN

здесь NN - номер D-канала исследуемого потока

Речь сейчас не о трассировке, а о мониторинге D-канала.
Перед этой процедурой подключите CAPTURE FILE в вашей терминальной программе. Данные будут бежать быстро.
Главное потом сумейте отключить это.
LD96
dis msgi NN
dis msgo NN

Лучше, когда вы работаете на одном терминале, а вывод мониторинга идет на другом. Для работы на "бегущем" терминале требуется определенный навык.

Кстати, если вы не правили
LD15
REQ CHG
TYPE CLID

то исходящие вызовы в новом потоке у вас идут со старыми CLID`ами.
Вижу это по присланному вами
.
ENTRY 122
HNTN
ESA_HLCL
ESA_INHN NO
ESA_APDN YES
HLCL ХХХХХХХ
DIDN NO
HLOC
LSC
CLASS_FMT DN
.
Или вы и старому и новому провайдеру должны отдавать одни и те же 7 цифр в CLID?

LD96
Кстати, если вы не правили
LD15
REQ CHG
TYPE CLID

то исходящие вызовы в новом потоке у вас идут со старыми CLID`ами.
Вижу это по присланному вами
.
ENTRY 122
HNTN
ESA_HLCL
ESA_INHN NO
ESA_APDN YES
HLCL ХХХХХХХ
DIDN NO
HLOC
LSC
CLASS_FMT DN
.
Или вы и старому и новому провайдеру должны отдавать одни и те же 7 цифр в CLID?

Для нового провайдера создаю новіе клиді, что не путаться. Теже 7 цифирок.
Ну всмісле не теже, а уже номера предоставленіе им. Тоесть меняю клид с номеров єтого провайдера

Попробуйте договориться с новым провайдером, что если A-номер от вас будет идти неправильный, то пусть провайдер подменяет его на пилотный (один из диапазона выданных вам номеров). А потом постепенно правьте номера в таблице CLID в ld 15, а не у абонентов! Если номера идут подряд, то скриптом это вообще можно сделать за несколько минут.

Попробуйте договориться с новым провайдером, что если A-номер от вас будет идти неправильный, то пусть провайдер подменяет его на пилотный (один из диапазона выданных вам номеров). А потом постепенно правьте номера в таблице CLID в ld 15, а не у абонентов! Если номера идут подряд, то скриптом это вообще можно сделать за несколько минут.

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

Провайдер уже дает такую услугу. Но вся проблема в том, что основная деятельность фирмы - торговля.
И поэтому иногда идут звонки в обратную сторону, мол нам звонили с этого номера. Так что пилотный номер отпадает :(
Сегодня, что четверг? Уясняешь для себя сейчас все вопросы на подготовительном уровне. Идешь отдыхать до пятницы 17.00 (или конкретно до последнего часа работы фирмы на неделе). Дальше все время до утра понедельника - твое. Обычный режим аврала корпоративного связиста. Даже если скриптов нет. В понедельник фирма работает по новой схеме связи.

Для нового провайдера создаю новіе клиді, что не путаться. Теже 7 цифирок.
Ну всмісле не теже, а уже номера предоставленіе им. Тоесть меняю клид с номеров єтого провайдера
Т.е. новые CLID Entry создаете? Двойная работа, потом еще номера CLID Entry в абонентских профилях корректировать. Проще HLCL в существующих записях CLID Entry поправить, на это как раз несколько часов ночного времени хватит, даже без скрипта.