Попробовал использовать STEP BACK рероутинг на EURO DID. Не работает. Дока говорит, что работает только на QSIG и MCDN, но форум дает смутные надежды и насчет EURO:
http://bbs.radiolink.ru/forum/showthread.php?t=18702&highlight=rra
RLI:
RLI 10
ENTR 0
LTER NO
ROUT 1
TOD 0 ON 1 ON 2 ON 3 ON
4 ON 5 ON 6 ON 7 ON
CNV NO
EXP NO
FRL 2
DMI 14
FCI 0
FSNI 0
BNE NO
SBOC RRA
COPT 1
CBQ NO
ENTR 1
LTER NO
ROUT 2
TOD 0 ON 1 ON 2 ON 3 ON
4 ON 5 ON 6 ON 7 ON
CNV NO
EXP NO
FRL 2
DMI 14
FCI 0
FSNI 0
BNE NO
SBOC NRR
CBQ NO
ISET 0
NALT 5
MFRL 2
OVLL 0
В D-канале, в зависимости от типа "аварии" 34 или 47 CAUSE:
DCH 13 UIPE_OMSG CC_SETUP_REQ REF 000056CF CH 19 21 TOD 21:47:50 CK 6B53A5D0
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:351xxxxxxx NUM PLAN: E164 TON: NATL
CALLED #:6xxxxxxx NUM PLAN: E164 TON: UNKNOWN
DCH 13 UIPE_IMSG CC_PROCEED_IND REF 000056CF CH 19 21 TOD 21:47:50 CK 6B53A6BB
DCH 13 UIPE_IMSG CC_DISC_IND REF 000056CF CH 19 21 TOD 21:47:50 CK 6B53ABC9
CAUSE: #47 - RESOURCES UNAVAILABLE
DCH 13 UIPE_OMSG CC_RELEASE_REQ REF 000056CF CH 19 21 TOD 21:47:50 CK 6B53ABCA
DCH 13 UIPE_IMSG CC_RELEASE_CONF REF 000056CF CH 19 21 TOD 21:47:50 CK 6B53AC2B
DCH 13 UIPE_OMSG CC_SETUP_REQ REF 000056D4 CH 19 16 TOD 21:51:02 CK 6B597ED0
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:351xxxxxxx NUM PLAN: E164 TON: NATL
CALLED #:6xxxxxxx NUM PLAN: E164 TON: UNKNOWN
DCH 13 UIPE_IMSG CC_RELEASE_IND REF 000056D4 CH 19 16 TOD 21:51:02 CK 6B597FC0
CAUSE: #34 - NO CHANNEL/CIRC AVAIL
DCH 13 UIPE_OMSG CC_RELEASE_RESP REF 000056D4 CH 19 16 TOD 21:51:02 CK 6B597FC1
Release 4.5.
Мн. уважаемые участники форума, подскажите, можно ли на что-то надеяться в данной ситуации?
На 4.5 EuroISDN точно делал.. не помню, что было TIE или DID.
Судя по доке на CAUSE: #47 ни какой реакции быть и не должно.
COPT 1
• cause 34 "No channel / circuit available"
• cause 38 "Network out of order"
• cause 42 "Congestion"
При cause 34, по логике, сработать должно.
Что такое route 2, там включена трассировка d-ch, что то уходит туда при cause 34?
Работает. Стоит COPT 2 для расширения количества cause.
На MCDN эта фича не работает, кстати.
Станция -11С, релиз 4.5.
...Что такое route 2, там включена трассировка d-ch, что то уходит туда при cause 34?
Есс-но трассировка была включена. В роут прописанный в ENTRY1 ничего не уходило.
К сожалению, распечатал не тот RLI, с которым экспериментировал, было:
RLI 11
ENTR 0
LTER NO
ROUT 2
TOD 0 ON 1 ON 2 ON 3 ON
4 ON 5 ON 6 ON 7 ON
CNV NO
EXP NO
FRL 2
DMI 14
FCI 0
FSNI 0
BNE NO
SBOC RRA
COPT 1
CBQ NO
ENTR 1
LTER NO
ROUT 1
TOD 0 ON 1 ON 2 ON 3 ON
4 ON 5 ON 6 ON 7 ON
CNV NO
EXP NO
FRL 2
DMI 14
FCI 0
FSNI 0
BNE NO
SBOC NRR
CBQ NO
ISET 0
NALT 5
MFRL 2
OVLL 0
Т.е. просто основной и альтернативный роут поменялись местами.
Роуты 1 и 2 - это группы транков, созданных на потоках в одно и то же оборудование - М200 МР. В М200 соединения данных роутов также раздельно смаршрутизированы на разных присоединяющих операторов.
Предвижу вопрос, почему я аварийное переключение маршрутов делаю на М61, а не непосредственно на М200? Потому что смена маршрута, отработанная М200 не отразится в биллинге (CDR снимается с М61!).
Работает. Стоит COPT 2 для расширения количества cause.
На MCDN эта фича не работает, кстати.
Станция -11С, релиз 4.5.
Спасибо, COPT подкрутил, следующий эксперимент только вечером (маршруты под нагрузкой). Хотя и с COPT 1 при CAUSE#34 могло бы работать.
Что стоит еще выложить (роут, транк, DCH)? Не может быть причиной проблемы низкий NCOS на DID транке?
Буду еще пытаться крутить М200.
Спасибо, COPT подкрутил, следующий эксперимент только вечером (маршруты под нагрузкой). Хотя и с COPT 1 при CAUSE#34 могло бы работать.
Что стоит еще выложить (роут, транк, DCH)? Не может быть причиной проблемы низкий NCOS на DID транке?
Буду еще пытаться крутить М200.
Я бы для начала убедился, что в данной конфигурации, вызовы на рут, указанный как альтернативный, проходят в принципе. Простейший способ - указать его, как основной.
Я бы для начала убедился, что в данной конфигурации, вызовы на рут, указанный как альтернативный, проходят в принципе. Простейший способ - указать его, как основной.
Не вопрос, оба указанных рута задействованы в рабочей конфигурации.
Через route 1 пропускается около 90% трафика, остальное - через route 2.
Я бы для начала убедился, что в данной конфигурации, вызовы на рут, указанный как альтернативный, проходят в принципе. Простейший способ - указать его, как основной.
Проверил, что перебор ENTR в RLI работает в принципе. Заглушил роут указанный в ENTR 0 через dis dch/disl - вызов честно ушел через ENTR 1.
Т.е. не работает именно SBOC RRA.
Идеологически, если в ENTR включен SBOC RRA, при получении CAUSE#34, якобы должен выполняться рероутинг на шаг назад. Не выполняется, видимо из-за присутствия некоего допусловия.
В поисках данного мешающего допусловия проделал следующие танцы с бубном:
1.попробовал смену транков/роута с DID на TIE в рамках EURO;
2.попробовал перенастроить условие маршрутизации из SPN/SDRR/ARRN в простой SPN;
3.попробовал устранить общий для основного и альтернативного роута DCH (таймслоты одного из потоков были поделены между этими роутами), разделив роуты по границам потоков;
4.попробовал повысить NCOS транков с 0-го до рабочего (выше FRL в RLI).
Результат - нулевой. Не пинайте больно за возможную системную нелогичность данных экспериментов. Кто его знает, какие потемки были в голове Nortel`евских программеров при реализации процедуры SBOC:).
У кого есть еще какие предложения, что покрутить?
Да, есть подозрение, что М200 может иметь некую специфику D-канальных сообщений (типа CAUSE#34 какой-то не такой и через фильтры SBOC не проходит), но ковыряться в форматах D-канала выше моей квалификации, а чтение перечня настроек DSS М200 мыслей не навеяло.
Идеологически, если в ENTR включен SBOC RRA, при получении CAUSE#34, якобы должен выполняться рероутинг на шаг назад.
С чего бы вдруг "шаг назад" ?
С чего бы вдруг "шаг назад" ?
Из коммутационного узла с недоступностью каналов, в узел в котором выполняется алгоритм RLB. Извиняюсь, если термин "Step Back" я воспринял неточно.
Из коммутационного узла с недоступностью каналов, в узел в котором выполняется алгоритм RLB. Извиняюсь, если термин "Step Back" я воспринял неточно.
Вы путаете функции MCDN Alternate Routing и Network Drop Back Busy.
Перечитайте доку.
Вы путаете функции MCDN Alternate Routing и Network Drop Back Busy.
Перечитайте доку.
Вообще-то имелась ввиду функция Step Back on Congestion (SBOC).
Назовите, пожалуйста, номер документа, его ревизии и номер страницы в нем, на которой начинается описание указанной вами функции.
Назовите, пожалуйста, номер документа, его ревизии и номер страницы в нем, на которой начинается описание указанной вами функции.
Jetc, читайте, пожалуйста, ветку с первого поста. Если у Вас есть конструктивная информация, пожалуйста сообщите.
Jetc, читайте, пожалуйста, ветку с первого поста. Если у Вас есть конструктивная информация, пожалуйста сообщите.
Сообщаю конструктивную информацию: судя по вашим высказываниям, вы путаете функции MCDN (или ISDN QSIG) Alternate Routing и Drop Back On Busy.
Приведены названия функций из NTP, описывающей их работу и настройку.
Приведенное вами название - это не название функции, а расшифровка названия поля, используемого в одной из этих функций.
Идеологически, если в ENTR включен SBOC RRA, при получении CAUSE#34, якобы должен выполняться рероутинг на шаг назад.
Как оно в жизни работает (QSIG и EURO):
1. Есть RLI c entry 0 и entry 1. В entry 0 прописано sboc rra copt 1/2.
2. Вызов уходит на entry 0, возвращается с disconnect cause 34 (например).
3. Вызов уходит на entry 1.
Такое поведение ожидается?
Сообщаю конструктивную информацию: судя по вашим высказываниям, вы путаете функции MCDN (или ISDN QSIG) Alternate Routing и Drop Back On Busy.
Приведены названия функций из NTP, описывающей их работу и настройку.
Приведенное вами название - это не название функции, а расшифровка названия поля, используемого в одной из этих функций.
И чего обсуждаем...
Ну прочитайте #1...
При проблеме с включением опции SBOC Alternate Routing, я естественно, сначала сделал поиск по доке, нашел, что интересующая фича позиционирована сугубо для MCDN и QSIG и я скорее всего зря парюсь с запуском ее на EURO. Но следующим отработанным навыком для жителей Meridian конференции является поиск по любимому форуму. И там находится инфа, что исследуемая фича документирована не очень однозначно. Мне нет оснований не доверять участникам уровня Lev Serdukov или Karter. И в данной ветке положительная возможность решения вопроса подтверждена авторитетами в постах например #2 или #3. Далее пытаюсь исследовать чем моя ситуация отличается...
MCDN и QSIG в моем случае неуместны, испытуемые линки - это межоператорские присоединения. В распоряжении только EURO DID, иначе я теряю больше чем приобретаю.
Тему Drop Back On Busy я и не поднимал, у меня и 192 пакаджа, как выяснилось, нет.
Что, будем дальше играть в студента и злого преподавателя?
Как оно в жизни работает (QSIG и EURO):
1. Есть RLI c entry 0 и entry 1. В entry 0 прописано sboc rra copt 1/2.
2. Вызов уходит на entry 0, возвращается с disconnect cause 34 (например).
3. Вызов уходит на entry 1.
Такое поведение ожидается?
Да. Моделировал именно возврат CAUSE#34.
Мне нет оснований не доверять участникам уровня Lev Serdukov или Karter. И в данной ветке положительная возможность решения вопроса подтверждена авторитетами в постах например #2 или #3. Далее пытаюсь исследовать чем моя ситуация отличается...
В таком случае странно, что вы не поднимаете тему релизов ПО, патчей и включенных плагинов.
В таком случае странно, что вы не поднимаете тему релизов ПО, патчей и включенных плагинов.
Релиз указал сразу в первом посту, Ocean сразу подтвердил актуальность фичи на данном релизе (еще раз спрашиваю, читать умеете?). Углубляться на уровень патчей и плагинов ради решения в общем-то второстепенного для меня вопроса не считаю нужным (тем более поиск по форуму не давал подсказок копать патчи/плагины, в отличие от темы DID транзита, которую форум помог мне решить неделю назад).
Ладно jetc, на самом деле наше вчерашнее эмоциональное общение вроде дало некую подсказку;). Вечером проверю, завтра продолжим общение.
"Актуальность фичи на релизе" не означает ее работоспособности на всех вариантах софта и наборах патчей.