Имеем: основная полка (АСТ) R8.0.1-g1.503-17-b-ru-c7s2. От нее вынос по INTIP-2, без PCS. Кроме того, полки соединены потоком для реализации собственно overflow.
Все хорошо функционирует в плане того, что при наборе соответствующих городских номеров звонок успешно перетекает на внутренние IP-каналы.
Вопрос: При простом наборе внутреннего номера с одной полки на другую при всех занятых IP-каналах overflow на поток не происходит, все равно пытается ходить через IP. В ARS первым выбором, само собой, локальный роут, вторым - внешний поток. Где косяк?

Давайте по порядку - расшифруем для начала как звоним.
Т.е. если набирается "внутренний номер" (номер абонента?) - при чем тогда ARS?

Звоним по-всякому :-) . ARS для того, чтобы набранный DDI-номер абонента с другой полки ушел именно внутренним набором, а не занимал городской поток. Это работа схемы "в другую сторону".

А вопрос фактически сводится к простому - должен ли переход на внешний транк работать при перегрузке канала, или только при Out of Service?



Редактировано 1 раз. Последний раз 14.07.2009 21:42 пользователем Seller_V.

Вы помоему слегка заблудились (насчет перетекания паблик и приват).
Эта фигня нужна между УЗЛАМИ сети и там по категории абонента указывается - перетекания при занятости или при выходе из строя.
Вы же говорите о выносе, в общем случае линк (INTOF, INTIP и пр) дял нас вещь абсолютно прозрачная.
Например у нас в 0-м кристалле есть TG1 (город) и TG2 (на 1-й кристалл), в 1-м кристалле есть TG3 (на 0-й кристалл). Когда вы говорите о вашем перетекании - вы имеете в виду что вы указываете в ARS сначала TG1, потом TG3 и при звонках абонентов 1-го кристалла (при занятости INT-IP) не переходит на TG3?
Или как то о другом разговор.

косяк наверное как тут http://forum.intersyst.ru/read.php?7,12422

В документации рассмотрен пример как раз системы из одного узла, но там был вынос MG, резервированный PCS. И перетекание происходило в случае умирания IP-линка. MG в этом случае работал, так как есть PCS. У меня это не прокатит, так как вынос нерезервированный. При умирании линка вынос, само собой, отпадет. А вот при переполнении?

Почитав ссылку error, я так понял, что занятость не является резоном для перехода?

Т.е. на вопрос об КОНКРЕТНОЙ организации звонков и поведении (как в предыдущем посту спрашивал) говорить не будем?

Организация такова:
На выносной полке есть номер, скажем, 2000. На него приходит из города 9332000. В дискриминаторе главной полки набор 9332000 направлен на ARS лист, в котором два роута. Первый локальный, Trunk Group -1, откусываем 3 цифры, второй - поток, цифры не меняем. Также этот набор описан в Network DID трансляторе.
Ну, короче, прямо по доке делал. Причем первый ARS-роут (локальный) уже пробовал сделать с источником транк-группы IP-domain для того, чтобы ограничить кол-во разговоров по INTIP (указывается в домене max voice connections). Соответственно, главная и выносная полки в разных доменах.

По идее нормально, непонятно зачем network translator.
Т.е. в ARS попали - с отрезанием цифр и локальным рутом?
Соответственно второе направление - в транковую группу - туда уходит или нет? По t3 ничего нет?
Не забыли в рутах прописать качество и телефонию и факс (иногда при внешних звонках бывают нюансы если не указываете факс - в bearer приходит иногда 80 90 а3, иногда 90 90 а3).
В time based route list - один лист с двумя рутами, а не два листа 8-)?
как при звонках внутренних абонентов (из основного ящика абонент набрал 93332000 или что-то такое)?
А если юзается собственно перетекание (это обычно было между узлами) - то для внешних звонков есть в System - Incoming DID overflow private->public.
Это у абонентов есть телефонная категория с перетеканием по занятости или не работе.

Seller_V Написал:
-------------------------------------------------------
> Организация такова:
> На выносной полке есть номер, скажем, 2000. На
> него приходит из города 9332000. В дискриминаторе
> главной полки набор 9332000 направлен на ARS лист,
> в котором два роута. Первый локальный, Trunk Group
> -1, откусываем 3 цифры, второй - поток, цифры не
> меняем. Также этот набор описан в Network DID
> трансляторе.
> Ну, короче, прямо по доке делал. Причем первый
> ARS-роут (локальный) уже пробовал сделать с
> источником транк-группы IP-domain для того, чтобы
> ограничить кол-во разговоров по INTIP (указывается
> в домене max voice connections). Соответственно,
> главная и выносная полки в разных доменах.

нда ужж... смешались люди и кони в кучу....

теперь я тут вообще не понимаю

из всего что понял так это:
пришел звонок на номер 9332000 по Pri главной полки ну и как положено начинаем его роутить на внутреннего абонента при условии что ip-линки свободные, теперь допускаем такую ситуацию что ip-линки все заняты и по правилу ars выкидывается обратно в к прову. вот тут самое интересное - куда должен прийти этот звонок????? и как ни странно на то же самое правило ars

для интереса такую ситуацию сможешь смодурировать сам - берем внутренний номер телефона который имеет прямой городской номер т.е. к примеру гор.номер 9332000 приходит только к абоненту 2000, вот теперь возьми и позвони с номера 2000 на городской номер 9332000 и интересно станет сможеш ли ты принять звонок в разговор?????

VAD
- в рутах и факс и голос
- один лист с двумя рутами
- в системе и категориях все выставлено
- с основной полки набор 9332000 через обычное занятие транк-группы проходит нормально.
- а вот через ARS на второй роут не уходит. Трасса чистая. Похоже, недостаток каналов не является резоном для перехода.

error
Задача немного не в том. У каждой полки свой PRI со своими городскими. А задачи две. Первая - при наборе городского номера другой полки вызов уходит внутренним номером (это работает). Второе - при переполнении IP внутренний вызов должен уходить на другую полку городским номером (это не работает)

согласно доки по ars
1.для начала надо определить класс ars на каждом транке (по дефолту класс ars равен 31 тобишь самый высокий приоритет), т.е. класс ars на TG ISDN ставим 30 либо значение меньше
2. добавляем в ars route - route под номером 1 со всеми причендалами для формирования звонка (это у вас работает), туда же добавляем route под номером 2 который будет звонить через внещную сеть т.е. через городской номер
3. в этом ars route есть time-based route list, создаем там только одну единственную строку time-based route list ID под номером 1,содержание в нем (route number 1, waiting cost limit -1, stoping cost limit -1)
4. затем через mgr time-based route list ID под номером 1 добавляем содержание (route number 2, waiting cost limit -1, stoping cost limit -1)
5. в этоге у тебя в time-based route list ID под номером 1 должны быть две строчки под route number 1 и route number 2


когда делал такую настройку я в поле качество прописал полный фарш (все кроме out servise на всякий случай)



Редактировано 1 раз. Последний раз 16.07.2009 17:10 пользователем error.

Ну, собственно, все заработало. А косяк обидный - после создания IP-доменов рестарт не провел вовремя. Итого, кол-во разговоров в домене выставил 1, первый вызов идет по внутреннему IP, второй уже рулится на внешний DDI. Красота.

VAD, error, огромное вам спасибо за помощь...

Кстати, без Node Access Prefix эта штука не работает.



Редактировано 1 раз. Последний раз 16.07.2009 19:23 пользователем Seller_V.

Первое правило Алкатель - если что-то не работает - рестарт, если не помогло (что в 99 % и происходит), тогда разбираемся с проблемой.

8-)

Просто иногда вылазят глюки (установка OPS, смена адреса TFTP сервера, первое создание SIP транковой группы), когда бьешся головой об стену, а нужен был рестарт.