Не отображается при входящей связи номер транка.
В чем может быть причина?

DCH 21 UIPE_IMSG CC_SETUP_IND REF 0000618C CH 0 TOD 15:01:58
CALLING #:9165552483 NUM PLAN: E164
CALLED #:7951569 NUM PLAN: E164

Не отображается при входящей связи номер транка.
В чем может быть причина?

DCH 21 UIPE_IMSG CC_SETUP_IND REF 0000618C CH 0 TOD 15:01:58
CALLING #:9165552483 NUM PLAN: E164
CALLED #:7951569 NUM PLAN: E164



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

Вы это имели ввиду?

08.06.2012 10:04
ACTIVE TN 024 1 09 11
ORIG 021 16 DID RMBR 22 16
TERM 024 1 09 11 MARP 0 4868989 500
TDTN 30 SLOT 14 PTY SLOT 20
DIAL DN 4868989
MAIN_PM RING AUX_PM
TALKSLOT ORIG 20 TERM 82
EES_DATA:
NONE
QUEU CAD
CALL ID 0 9175

---- ISDN PRA CALL (ORIG) ----
CALL REF # = 25625
BEARER CAP = VOICE
HLC =
CALL STATE = 7 CALL RCV
CALLING NO = 4967953999
CALLED NO = 7951321

.10:04:54 08/06/2012
ACTIVE TN 024 1 09 11
ORIG 021 16 DID RMBR 22 16
TERM 024 1 09 11 MARP 0 4868989 500
DIAL DN 4868989
MAIN_PM ESTD
TALKSLOT ORIG 20 TERM 82
EES_DATA:
NONE
QUEU NONE
CALL ID 0 9175


---- ISDN PRA CALL (ORIG) ----
CALL REF # = 25625
BEARER CAP = VOICE
HLC =
CALL STATE = 10 ACTIVE
CALLING NO = 4967953999
CALLED NO = 7951321


.10:04:56 08/06/2012
ACTIVE TN 024 1 09 11
ORIG 021 16 DID RMBR 22 16
TERM 024 1 09 11 MARP 0 4868989 500
DIAL DN 4868989
MAIN_PM ESTD
TALKSLOT ORIG 20 TERM 82
EES_DATA:
NONE
QUEU NONE
CALL ID 0 9175


---- ISDN PRA CALL (ORIG) ----
CALL REF # = 25625
BEARER CAP = VOICE
HLC =
CALL STATE = 10 ACTIVE
CALLING NO = 4967953999
CALLED NO = 7951321

.10:04:58 08/06/2012
IDLE TN 024 1 09 11

Или это:

DCH 22 UIPE_IMSG CC_SETUP_IND REF 0000101A CH 0 TOD 9:41:40
PRIM HDR: 2F 00 00 00 5C 00
MSG HDR: 08 02 1A 20 2E 00
SNCMP: 23 00
BCAP: 01 07 13 00 81 90 00 00 A3
CHID: 09 09 0D 00 A1 00 83 00 01 00 01
GFFAC: 37 1A 11 00 91 00 01 00 A1 12 02 01 B6 02 01 0F
30 0A 02 01 01 0A 01 00 A1 02 81 00
CLG#: 05 10 07 00 21 83 0A 00 09 0A 05 02 0A 04 0A 09
0A 0A
CAD#: 03 0D 03 00 A1 00 07 00 07 09 05 01 05 03 03

Q931 что показывает?

Показывает следующее:
DCH 21 UIPE_IMSG CC_SETUP_IND REF 0000688D CH 0 TOD 14:11:34
CALLING #:4967953999 NUM PLAN: E164
CALLED #:7951321 NUM PLAN: E164

DCH 21 UIPE_OMSG CC_PROCEED_REQ REF 0000E88D CH 21 1 TOD 14:11:34

DCH 21 UIPE_OMSG CC_ALERT_REQ REF 0000E88D CH 21 1 TOD 14:11:34
PROGRESS: TERMINATING END IS NOT ISDN

DCH 21 UIPE_OMSG CC_SETUP_RESP REF 0000E88D CH 21 1 TOD 14:11:36
PROGRESS: TERMINATING END IS NOT ISDN

DCH 21 UIPE_IMSG CC_SETUPCOMP_IND REF 0000688D CH 21 1 TOD 14:11:36

DCH 21 UIPE_OMSG CC_DISC_REQ REF 0000E88D CH 21 1 TOD 14:11:38
CAUSE: #16 - NORMAL CALL CLEARING

DCH 21 UIPE_IMSG CC_RELEASE_IND REF 0000688D CH 21 1 TOD 14:11:38

DCH 21 UIPE_OMSG CC_RELEASE_RESP REF 0000E88D CH 21 1 TOD 14:11:38




DCH 21 UIPE_IMSG CC_SETUP_IND REF 0000408C CH 0 TOD 14:17:46
CALLING #:4967953999 NUM PLAN: E164
CALLED #:7951321 NUM PLAN: E164

DCH 21 UIPE_OMSG CC_PROCEED_REQ REF 0000C08C CH 21 5 TOD 14:17:46

DCH 21 UIPE_OMSG CC_ALERT_REQ REF 0000C08C CH 21 5 TOD 14:17:46
PROGRESS: TERMINATING END IS NOT ISDN

DCH 21 UIPE_OMSG CC_SETUP_RESP REF 0000C08C CH 21 5 TOD 14:17:50
PROGRESS: TERMINATING END IS NOT ISDN

DCH 21 UIPE_IMSG CC_SETUPCOMP_IND REF 0000408C CH 21 5 TOD 14:17:50

DCH 21 UIPE_IMSG CC_DISC_IND REF 0000408C CH 21 5 TOD 14:17:54
CAUSE: #16 - NORMAL CALL CLEARING

DCH 21 UIPE_OMSG CC_RELEASE_REQ REF 0000C08C CH 21 5 TOD 14:17:54

DCH 21 UIPE_IMSG CC_RELEASE_CONF REF 0000408C CH 21 5 TOD 14:17:54

DCH 21 UIPE_OMSG CC_PROCEED_REQ REF 0000D400 CH 21 5 TOD 14:17:58

UIPE и Q931

Об этом речь. Предмет вопроса понятен?

К сожалению. непонятен.

А в чем собственно проблема? Связь не работает? Звонки не ходят?

Выдержка не из документации на M1. Но суть описывает. Подробности команд - в документации.


There are two variants of ISDN messages on Meridian. They are

·
UIPE messages, the proprietary set of messages that are exchanged
between Meridian SL-1 Software and the MSDL Card.
·

Q931 Messages, the messages exchanged between the Meridian and the
external world.

Note : The loadware present on the MSDL card converts the UIPE proprietary
messages into Q931 and vice versa. The two messages are not necessarily the
same.
Currently Meridian supports monitoring of the above two sets of ISDN
messages in Overlay 96 in the form of UIPE and DEBG messages.

Incoming or outgoing UIPE messages can be monitored using the following
command in overlay 96.
NORTEL proprietary UIPE message monitor offers three levels of monitoring.
The method to set the monitor levels for the enabled messages is as shown in
the figure below
Monitor Level 0 - Craft level Monitoring. Certain important ISDN message
contents are decoded and printed in plain English format.
A sample monitor level 0 message is shown in the figure below
Monitor Level 1 - Raw message level Monitoring. The actual message received
is displayed in hexadecimal format.
> ld 96


.enl msgi/msgo <dch>


.set msgi/msgo <dch> mon x
Where x can be 0, 1 or 2

The command to enable the Q931 messages on Meridian is as shown in the
figure below

>ld 96
.enl msgi/msgo <dch> debg

Q931 Message monitoring also supports the three levels of monitoring.

Вы это имели ввиду?
...


Нет, но ниже уже распечатали, то, что надо для понимания.
В SETUP не было номера голосового таймслота. Т.е. вообще не было.
Номер таймслота выбрал Меридиан в следующем сообщении (CC_PROCEED_REQ - CALL PROCEEDING).
Дальше обмен уже пошел с номером. Повторюсь, это вполне нормально. Можете почитать спецификацию ITU-T Q.931, если интересно.

Все работает, звонки проходят.

В силу специфики, мы часто пользуемся командой
ENL MSGI XX MSG STP.
Для "чистоты эксперимента" хотелось бы понять почему нет номера транка.
Как я понял мы его не получаем от встречной АТС?
В спецификацию попытаюсь вникнуть. Спасибо

Все работает, звонки проходят.

В силу специфики, мы часто пользуемся командой
ENL MSGI XX MSG STP.
Для "чистоты эксперимента" хотелось бы понять почему нет номера транка.
Как я понял мы его не получаем от встречной АТС?
В спецификацию попытаюсь вникнуть. Спасибо

Не получаете. И это вполне законно.

Не получаете. И это вполне законно.
Это как?
Сторона NET обязана выдать номер b-канала.

Вопрос в том, правильно ли отображается в UIPE логах трассировка.

По хорошему, надобно бы стать на канал каким-либо сторонним девайсом и сравнить что получается в логах UIPE, Q931 и девайса.

Это как?
Сторона NET обязана выдать номер b-канала.

А кто NET у топикстартера?

А кто NET у топикстартера?

Это несущественная деталь до выяснения правильно ли трассировкой отображаются сообщения.

Был у меня случай, когда оператор не назначал номер б-канала. Меридиан благополучно справлялся с этой проблемой, назначал сам. Другое оборудование работать отказывалось :)

Это как?
Сторона NET обязана выдать номер b-канала.

Вопрос в том, правильно ли отображается в UIPE логах трассировка.

По хорошему, надобно бы стать на канал каким-либо сторонним девайсом и сравнить что получается в логах UIPE, Q931 и девайса.

network обязан.
внутренний путин подсказывает, что это не network.

Встречная АТС - оператор (NET).
Мы USR.

Встречная АТС - оператор (NET).
Мы USR.

Ну тогда можете их попробовать пощекотать документом.
Тут вот коллега не доверяет UIPE трассировке, включите Q931.