msgua
16.05.2008, 17:26
Здравствуйте

Подскажите, пожалуйста, есть ли возможность делать переход с ENTR0 (ROUT1) на ENTR1(ROUT2) при протоколе EuroISDN и получении сообщений по ROUT1 типа:
NO USER RESPONDING
или
INVALID NUMBER FORMAT

В ENTR0 маршрут объединяющий Меридиан с Cisca. В ENTR1 маршрут на город.

Комбинировал все возможные варианты SBOC и IDBB и никакого результата, переход на город не происходит.

Как я понимаю, это возможно только при работе по протоколу QSIG (параметр COPT), или с его помощью тоже нельзя этого добиться?

За ранее, спасибо.

AlexandrD
17.05.2008, 05:09
Вы бы мухи от котлет отделили для начала.
Сообщения вида
NO USER RESPONDING
INVALID NUMBER FORMAT
переводятся с инглиша легко и никакого отношения к руту не имеют.И QSIG к этому не имеет никакое отношение.
Смотрите маршрутизацию внешних вызовов.

AlexandrD
17.05.2008, 05:21
[QUOTE]msgua пишет
[iКак я понимаю, это возможно только при работе по протоколу QSIG (параметр COPT), или с его помощью тоже нельзя этого добиться?

Совершенно не правильно понимаете.Делайте выход наружу через SPN/CDP и в RLB выставляйте свои ENTRY.

Old Chap
17.05.2008, 20:34
AlexandrD пишет
Совершенно не правильно понимаете.Делайте выход наружу через SPN/CDP и в RLB выставляйте свои ENTRY.
И что, при указанных причинах дисконнекта будет переход на следующий ENTRY?

Ocean
18.05.2008, 02:44
AlexandrD пишет
[QUOTE]msgua пишет
[iКак я понимаю, это возможно только при работе по протоколу QSIG (параметр COPT), или с его помощью тоже нельзя этого добиться?

Совершенно не правильно понимаете.Делайте выход наружу через SPN/CDP и в RLB выставляйте свои ENTRY.

Это работает и по EDSS1 (EuroISDN).
Но CAUSE должны быть (при COPT 2 в Ld 86 RLB):

— Cause 27, "Destination is Out of Service"
— Cause 34, "No Channel/Circuit Available"
— Cause 38, "Network Out of Order"
— Cause 42, "Congestion"

В любых других случаях, на следующий ENTRY не переходит!

AlexandrD
18.05.2008, 18:42
Ну конечно, надо сначала разобраться с этими сообщениями.Иначе никакого бэкапа не будет.

msgua
19.05.2008, 13:25
Спасибо за помощь.

Проблема была частично решена со стороны маршрутизатора, при обрыве соединения с устройствами после маршрутизатора он начал выдавать "нужные" сообщения:

DCH 13 UIPE_IMSG CC_DISC_IND REF 000000B7 CH 3 4 TOD 10:38:40
CAUSE: #38 - NETWORK OUT OF ORDER (до этого выдавал CAUSE: #18 - NO USER RESPONDING)

И как описано в документации, что переходы возможны по следующим причинам:
QSIG альтернативная маршрутизация поддерживается в следующих случаях:
· В случае 3 " Нет маршрута к пункту назначения "
· В случае 27 " Пункт назначение вне обслуживания "
· В случае 34 " Нет доступного канала / цепи "
· В случае 38 " Сеть неисправна "
· В случае 41 "Временный отказ"
· В случае 42 "Занятость"

по CAUSE: #38 происходит переход на другой маршрут.

Но вот возникла другая ситуация. За маршрутизатором стоит оборудование (Samsung SMG-400), которое ограничено одним соединением с маршрутизатором. При занятии этого соединения и новом звонке АТС получает:

DCH 13 UIPE_OMSG CC_SETUP_REQ REF 000000D3 CH 3 6 TOD 11:35:28
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:444367319 NUM PLAN: E164 TON: NATL
CALLED #:83 NUM PLAN: E164 TON: LOCL
(83 - это просто проверочный TSC код выхода на блок RLB, в котором объеденены ранее описанные маршруты )

DCH 13 UIPE_IMSG CC_PROCEED_IND REF 000000D3 CH 3 6 TOD 11:35:28

DCH 13 UIPE_IMSG CC_DISC_IND REF 000000D3 CH 3 6 TOD 11:35:28
CAUSE: #17 - USER BUSY

DCH 13 UIPE_OMSG CC_RELEASE_REQ REF 000000D3 CH 3 6 TOD 11:35:28

DCH 13 UIPE_IMSG CC_RELEASE_CONF REF 000000D3 CH 3 6 TOD 11:35:28

Т.е. CAUSE: #17 - USER BUSY и соответственно переход на другой маршрут не происходит, а просто получаем сигнал занято.

По сути логично что по CAUSE: #17 переход не нужен, но возможно как-то принудительно сделать все же переход на следующий ENTR при таком CAUSE?
(Т.е. нужно чтобы при ситуации когда нельзя позвонить через маршрутизатор, звонок пошол через городскую сеть)

Также маршрутизатор может просто вернуть звонок обратно, но тогда нужно по каким-то дополнительным кодам его обрабатывать и маршрутизировать в нужном направлении, корректно ли так делать?

Может кто-то сталкивался с такой ситуацией и имеет опыт как её можно разрулить?

msgua
22.05.2008, 18:38
частично решили проблему и опять со стороны кошки. командой

isdn network-failure-cause xxx (где ххх - номер ошибки)

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

Т.к. эту тему только осваиваем, опыта почти нет по стыковке с кошкой, может опытные знают ещё какие-то решения задачи, не такое тупое как описал выше?