С межгорода набирают номер ххх - проходит через наш М1 - попадает на М2 там этот номер множественный - звонок состоялся. Секундой позже набирают тот же номер ххх - попадаетна М1 - межгород слышит долгую тишину потом сонгестион тоне- на М2 номер не проходит. оба потока ISDN PRI. Вот трассировка 2-ого вызова на М1.
DCH 11 UIPE_IMSG CC_SETUP_IND REF 00004F96 CH 2 2 TOD 11:34:50
CALLING #:3272505050 NUM PLAN: E164
CALLED #:2021 NUM PLAN: E164
и так много раз больше ничего нету :-). Дело организовано через СДП. В чем может быть дело?

Что при этом видно на М1 на д-канале в сторону M2 ?
Ситуация чем-то отличается, если звонок приходит не из межгорода?

1-ый вызов нормально проходит в каналы другого роута, 2-ой вызов все время крутит сетап на входящем роуте, исходящий роут не занимается. На счет межгорода на самом деле межгород все преобразует и отправляет нам только последние 4-е цифры.

Можешь включить мониторинг обоих д-каналов на транзитном меридиане и показать всю картину целиком, начиная с первого сетапа?

Вот это круто! Собрат по несчятью нашелся... Ломаю голову уже месяца три над аналогичной проблемой. Наверное даже поднимал тему сдесь.

Картина такая: CDP отправляет группу номеров в поток (b), собственно DSC описывает сотню. На М1 несколько потоков. Абонент М1 (А) ставит переадресацию на номер (B) находящийся за потоком (b) и шлюзом в IP телефонию. Все вызовы на аб. А пока проходят и абонент В их принимает.

Абонент В ставит еще одну переадресацию (у себя в IP телефонии) и вот мы получаем проблему аналогичную вашей. первый транзитный вызов проходит абсолютно нормально, все последующие получают "CAUSE: #42 - SWED EQIP CONGESTION" и в поток b вообще ничего не уходит!

Вызовов собственно с М1 все это не касается и если начать редактировать порт А и выйти с сохранением изменений еще один транзитный вызов проходит.

Я ржу и плачу.

Собственно и при непостедственной переадресации на номер В1 куда в первом случае переадресовывался В эффект тот-же.

Сказка какая-то, одним словом.

Вот собственно как выглядит это безобразие, Оба потока QSIG с передачей NCOS. 2248 аб. А, 2576 - аб. В транзитный вызов совершает абонент 1272.

DCH 5 UIPE_IMSG CC_SETUP_IND REF 0000798A CH 2 1 TOD 13:32:18
CALLED #:1002248 NUM PLAN: PRIVATE
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:1272 NUM PLAN: PRIVATE

DCH 6 UIPE_OMSG CC_SETUP_REQ REF 00000272 CH 7 6 TOD 13:32:18
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:1272 NUM PLAN: PRIVATE
CALLED #:1022576 NUM PLAN: PRIVATE

DCH 5 UIPE_OMSG CC_PROCEED_REQ REF 0000F98A CH 2 1 TOD 13:32:18

DCH 5 UIPE_OMSG CC_FAC_REQ REF 0000F98A CH 0 TOD 13:32:18

DCH 6 UIPE_IMSG CC_PROCEED_IND REF 00000272 CH 7 6 TOD 13:32:18

DCH 6 UIPE_IMSG CC_ALERT_IND REF 00000272 CH 7 6 TOD 13:32:18
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 5 UIPE_OMSG CC_ALERT_REQ REF 0000F98A CH 2 1 TOD 13:32:18
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 5 UIPE_IMSG CC_DISC_IND REF 0000798A CH 2 1 TOD 13:32:34
CAUSE: #16 - NORMAL CALL CLEARING

DCH 5 UIPE_OMSG CC_RELEASE_REQ REF 0000F98A CH 2 1 TOD 13:32:34

DCH 6 UIPE_OMSG CC_DISC_REQ REF 00000272 CH 7 6 TOD 13:32:34
CAUSE: #16 - NORMAL CALL CLEARING

DCH 5 UIPE_IMSG CC_RELEASE_CONF REF 0000798A CH 2 1 TOD 13:32:34

DCH 6 UIPE_IMSG CC_RELEASE_IND REF 00000272 CH 7 6 TOD 13:32:36

DCH 6 UIPE_OMSG CC_RELEASE_RESP REF 00000272 CH 7 6 TOD 13:32:36

DCH 5 UIPE_IMSG CC_SETUP_IND REF 00007A0A CH 2 1 TOD 13:32:42
CALLED #:1002248 NUM PLAN: PRIVATE
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:1272 NUM PLAN: PRIVATE

DCH 5 UIPE_OMSG CC_REJECT_REQ REF 0000FA0A CH 2 1 TOD 13:32:42
CAUSE: #42 - SWED EQIP CONGESTION

Хм.. давай на всякий случай посмотрим на NET_DATA ?

Народ всем приношу изв-я, нашел причину. У нас из-за одного косяка закрывали 2 и 17 каналы соответсвенно в сторону межгорода. А межгород этого не сделал и поэтому их 2-ой вызов постоянно тыркался во 2-ой канал. При прозвонке более 3-х звонков, все работали кроме второго. :-) .
В связи с этим появился еще один крайне важный вопрос: 2 и 17 каналы закрывали потому что при исходящей связи от нас в сторону межгорода абонент после набора всех цифр слушал тишину. При замене идентичной 100% рабочей платой та же проблема сохранилась, настройки ISDN PRI абсолютно стандартные по строкам проверял. Плата и та и другая 100% рабочие. В чем может быть дело?

И еще если кому интересно насчет транзита, все делал через СПН в ЛД90 ни фига не идет :-) вот такой казус, только через СДП в ЛД87

Странно это, потому что
DCH 5 UIPE_OMSG CC_REJECT_REQ REF 0000FA0A CH 2 1 TOD 13:32:42
CAUSE: #42 - SWED EQIP CONGESTION
мало похоже на проблему с 2-ым каналом ...

А насчет тишины - надо бы внимательно проверить промежуточное канальное оборудование, нет ли там ошибок с таймслотами.

Удачи

talga2 пишет
И еще если кому интересно насчет транзита, все делал через СПН в ЛД90 ни фига не идет :-) вот такой казус, только через СДП в ЛД87
Скорее всего что-то напутали с цифрами, забыли AC подставить, например.

Crow пишет
Собственно и при непостедственной переадресации на номер В1 куда в первом случае переадресовывался В эффект тот-же.
Сказка какая-то, одним словом.
А может быть сказка называется "Loop Avoidance Feature" ? ;)

2 PhoneMan:
Спасибо, идея свежая. Однако причем здесь петля? поток то свободный..
QSIG в потоках разный, в первом ETSI во втором ISO, что подтверждает предположение.
Есть способ выключить эту фичу не переделывая поток на isgf?

Loop - кроме того, что "петля", ещё и "цикл". Программисты-то они знают :)
Loop avoidance - механизм предотвращения "зацикливания" вызовов по сети, imho живет где-то в NET_DATA.