Тема: h.323 контроль транка
Да чё конфиг? Я проще открытым текстом. В ку-дэ галка, в набираемом 807 (при условии, что 8 - это доступ к тэ-гэ, а 07 - это аш323-я группа.. но у вот в моей “интертрепации” это чаще *807, если 7-я группа), а в “равенстве” ставь что угодно. Я пробовал по-разному, вплоть до.. хоть в и-цэ-дэ кидай, в которой о-гэ-эм, мол, “сейчас пока не связи нет, но мы над этим работает”. Проверь, просто направив “в пустое место” (то есть на айпи, где нет АТС). А потом можешь попробовать в существующую, у которой будут заняты все транки (то бишь о чём начал Игорь). Мне почему-то кажется, что 2-й эксперимент будет неудачным.
Саш, я ж писал:
1. если выдернуть LAN шнур из собственной станции - работает.
2. если вывести плату в оус - работает.
3. если переполнение каналов - работает.
4. если направлять в пустоту - не работает.
Этой херней я уж точно заморачивался и даже в БЗ по этому поводу писал. Специально делал несуществующий адрес и посылал на него... - не работает хоть тресни.
Мне сейчас проверять не на чем... так, что если кто то ещ скажет, что оно так работает - остается поверить...
mich5843, у меня работало... значит ты что-то забыл и не учёл.
mich5843, у меня работало... значит ты что-то забыл и не учёл.
Саш, первый пост Тебе в помощь.
Подскажи коллеге (он же не с улицы) - ему можно и помочь.
Он сделает... отпишется, что все равботает... и вопрос на этом закроем моим недоумением-недоделыванием. ОК.
а главное, что он, как сторона нейтральная, с Твоей помощью сделает вывод о работоспособности...
Миш, Игорь хочет немного другого.
Тэээээкс. Моя эксперимента удалася.
Если вызов отправляется в группу шлюзов, и первый шлюз в данной группе недоступен (из АТС был выдернут шнурок), вызов перенаправляется на второй шлюз.
Сейчас буду проверить Ку-Дэ рероутинг без кодов АТС...
Игорь, ты же хотел немного другого.. как мне ка-а-ацца.. Не чтобы был недоступен именно шлюз, а чтобы через ДОСТУПНУЮ АТС не было доступа. И чтобы в ЭТОМ случае рероутилось. Разве не так?
А с ГРУППОЙ шлюзов не особо интересно.
Саша, как раз-таки нет.
Мне надо было отправить вызов на одну АТС, если она отвалилась по какой-то причине, чтоб этот вызов шел через вторую АТС... И тут, собственно, мой склероз привел к появлению этой темы - про гв-группы запамятовал.
Теперь по QD-reroute.
Все отрабатывает замечтательно, однако, не без особенностей.
Вкратце:
NS500 - 3xx
NCP500 - 4xx
На NS цифра 4 и в азерах (в TIE без кодов), и в QD с галкою. Из доступных павликов только петля CO-Ext, поэтому QD выглядит так: 4=9301.
Вытаскиваем LAN из NCP, звоним с 302 на 4хх - получаем вызов на 301, НО!!! на дисплее 302 видим 301хх
DP не спасает (ибо аналог), поэтому ежели набрать, например, 440 или даже 404, то на 301 дозвониться не получится, пока месседж вейт не прибьешь 😊
Обнаружил еще одну интересную особенность: связь между АТС есть, однако если попытаться позвонить на неподключенный СТ соседней АТС или даже на любой номер соседней АТС, порт которого в аусе - получаем не отказ в обслуживании (как внутри этой АТС), а отрабатывает рероутинг.
Из доступных павликов только петля CO-Ext, поэтому QD выглядит так: 4=9301.
Вытаскиваем LAN из NCP, звоним с 302 на 4хх - получаем вызов на 301, НО!!! на дисплее 302 видим 301хх
DP не спасает (ибо аналог), поэтому ежели набрать, например, 440 или даже 404, то на 301 дозвониться не получится, пока месседж вейт не прибьешь 😊
QD
401=9301
402=9302
...?
Юра, да вообще-то это несмертельно.
Я обратил на это внимание чисто случайно, именно благодаря тому, что звонил на 404 и получил месседжвейт на петле. А расписывать в QD всех абонентов соседней АТС смысла не вижу. Ибо если город аналоговый - лишние цифры оператор просто проигнорит (а диза если и есть, то трубку снять не успеет). Если город - цифра - DP нам в помощь. К тому же общее число абонентов в сети может существенно превышать 1000.
Обнаружил еще одну интересную особенность: связь между АТС есть, однако если попытаться позвонить на неподключенный СТ соседней АТС или даже на любой номер соседней АТС, порт которого в аусе - получаем не отказ в обслуживании (как внутри этой АТС), а отрабатывает рероутинг.
Допустим, у тебя IP-CT не нашёл Primary АТС и подключился к другой. Расширенные функции есть, номер один и тот же. Вполне логично, что вызов через вторую АТС (в той же группе гв) дойдёт до этого IP-CT.
Обнаружил еще одну интересную особенность: связь между АТС есть, однако если попытаться позвонить на неподключенный СТ соседней АТС или даже на любой номер соседней АТС, порт которого в аусе - получаем не отказ в обслуживании (как внутри этой АТС), а отрабатывает рероутинг.
Ага, значит внедрённое однажды с “занятыми СО на другой АТС” (при транзите) тоже (чисто теоретически) может возвращать в QD.. Кому не лень, попробуете?
ЗЫ. Хотя, если верить презенташке с официального сайта, так и должно происходить. Там ведь, насколько мне помнится, не была указана ПРИЧИНА, по которой вызов не может быть совершён.
Обнаружил еще одну интересную особенность: связь между АТС есть, однако если попытаться позвонить на неподключенный СТ соседней АТС или даже на любой номер соседней АТС, порт которого в аусе - получаем не отказ в обслуживании (как внутри этой АТС), а отрабатывает рероутинг.
Допустим, у тебя IP-CT не нашёл Primary АТС и подключился к другой. Расширенные функции есть, номер один и тот же. Вполне логично, что вызов через вторую АТС (в той же группе гв) дойдёт до этого IP-CT.
Алексей, привет!!! Не совсем понял, как это связано с рероутингом на павлика через QD…
ПыСы: ЛС глянь 😊
