Уважаемые дамы и господа! Для вас сохранен старый форум по адресу http://forum.intersyst.ru

Страницы: 1
RSS
приходит setup без calling_number и called_number
 
стоит у клиента Alcatel OXE R11.1-l1.301-23-j-ru-c7

от провайдера приходит 5 isdn-pri, на OXE все эти потоки объедены в одну TG

в обеденный перерыв приключилось "сие чудо" - отвалились входящие звонки. связист (который у клиента) физически передернул все платы NPRAE которые идут в сторону прова, легче на стало.
исходящие звонки ходят как ни в чем не бывало.

звоню провайдеру и объясняю что setup приходит абсолютно "голый", проверяет и говорит что по трассировки звонка setup уходит полный (есть нью-анс - это показывает на логическом уровне). что там реально происходит на транке (у прова) знает только "анализатор isdn" (который в данный момент был в другом месте) и "сам бог"

продолжалось это безобразие где-то 40 минут и само все рассосалось, провайдер притащил анализатор isdn но так и не успел "заглянуть в душу транка" чтобы посмотреть что там происходит

кусок трассы одного звонка отправил провайдеру, но он захотел в бинарном ввиде. ну я естественно не сообразил трассировку в бинарном виде снять.

есть несколько вопросов:
1. кому нибудь такое "сие чудо" встречалось?
2. насколько можно верить "t3" и "t3 -data" т.е. возможно ли расхождения (тобишь в "t3 -data" данные одни, а выхлоп в "t3" другой)

вот и сама трассировка "сие чуда"

| (482066:000002) Concatenated-Physical-Event :
| long: 40  desti: 0  source: 0  cryst: 0  cpl: 3  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : SETUP [05]    Call ref :  7f 82
|____________________________________________________________­__________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3)  a9 83 94 -> T2 : B channel 20 exclusive
| IE:[1e] PROGRESS_ID (l=2) 82 81
| IE:[29] DATE (l=5)  ->  date :  01 / 02 / 18   12:03
| [a1] Sending complete
|____________________________________________________________­__________________

____________________________________________________________­__________________
| (482066:000003) 940: Send_IO1 (link-nbr=3, sapi=0, tei=0) :
| long: 26  desti: 0  source: 15  cryst: 0  cpl: 3  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : STATUS [7d]    Call ref :  ff 82
|____________________________________________________________­__________________
|
| IE:[08] CAUSE (l=3) 81 e3 29 -> [e3]
|    INFORMATION ELEMENT NON-EXISTENT OR NOT IMPLEMENTED
| IE:[14] CALL_STATE (l=1) 06
|____________________________________________________________­__________________

____________________________________________________________­__________________
| (482066:000004) 940: Send_IO1 (link-nbr=3, sapi=0, tei=0) :
| long: 26  desti: 0  source: 15  cryst: 0  cpl: 3  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : DISCONNECT [45]  Call ref :  ff 82
|____________________________________________________________­__________________
|
| IE:[08] CAUSE (l=2) 81 9c -> [9c] INVALID NUMBER FORMAT
| IE:[1e] PROGRESS_ID (l=2) 81 81
|____________________________________________________________­__________________

____________________________________________________________­__________________
| (482066:000005) Concatenated-Physical-Event :
| long: 18  desti: 0  source: 0  cryst: 0  cpl: 3  us: 0  term: 0  type a5
| tei: 0  >>>>  message received : RELEASE [4d]   Call ref :  7f 82
|____________________________________________________________­__________________

____________________________________________________________­__________________
| (482066:000006) 940: Send_IO1 (link-nbr=3, sapi=0, tei=0) :
| long: 22  desti: 0  source: 15  cryst: 0  cpl: 3  us: 8  term: 0  type a5
| tei: 0  <<<<  message sent : REL COMP [5a]  Call ref :  ff 82
|____________________________________________________________­__________________
|
| IE:[08] CAUSE (l=2) 81 90 -> [90] NORMAL CALL CLEARING
|____________________________________________________________­__________________
Пути IP-пакета неисповедимы
 
прям точно такого не было, было следующее пару-тройку лет назад )) вроде ковырялся с NPD у ТГ из 6 потоков, все сделал, все работало как нужно, на след.день делал баскул, а из-за разбежки баз процов видимо применился старый NPD. Исход работал при этом нормально, а входа не было, или на оборот. Свова подправил и сделал мастеркопи после этого.
 
Был случай, когдв setup приходил, но длина поля CALLING NUMBER была указана больше, чем реально было. Поэтому в нем часть цифр от CALLED Number была, а само поле CALLED NUMBER не находилось, т.к. его начало было на другом месте, отличном от ожидаемого. Удалось выяснить анализом шестнадцатиричного кода от тестера протоколов. У провайдера была станция, где длина полей вручную задавалась. У заказчика была не ОХЕ, а ipoffice.
Страницы: 1
Читают тему