Входящий звонок от оператора:

DCH 16 Q931_IMSG SETUP REF 00000380 TN 00001A04 CH 00000001 TOD 11:40:42 CK 4277454F
40 FF 01 00 2C 00 08 02 00 07 05 A1 04 03 80 90 A3 18 03 A9 83 81 6C 0C 21 83 37 30 31 30 30 30 30 30 30 31 70 0B A1 37 37 35 30 39 37 39 39 30 30 00

DCH 16 Q931_OMSG STP_ACK REF 00000380 TN 00001A04 CH 00000001 TOD 11:40:42 CK 427745AA
41 00 01 00 0A 00 08 02 80 07 0D 18 03 A9 83 81

DCH 16 Q931_OMSG CALLPROC REF 00000380 TN 00001A04 CH 00000001 TOD 11:40:42 CK 427745D2
41 00 01 00 06 00 08 02 80 07 02 00

DCH 16 Q931_IMSG STATUS REF 00000380 TN 00001A04 CH 00000001 TOD 11:40:42 CK 427745FB
40 00 01 00 0C 00 08 02 00 07 7D 08 02 82 9F 14 01 06

DCH 16 Q931_OMSG RELEASE REF 00000380 TN 00001A04 CH 00000001 TOD 11:40:42 CK 42774623
41 00 01 00 0A 00 08 02 80 07 4D 08 02 81 E5 00

DCH 16 Q931_IMSG REL_COMP REF 00000380 NCALL TOD 11:40:42 CK 42774673
40 80 01 00 06 00 08 02 00 07 5A 00

Зачем сиэска отправляет SETUP ACKNOWLEDGE, ведь вся необходимая информация уже получена во входящем SETUP-е?

Подтверждение получения SETUP...
А что не так, что то не работает?

да, не работает :(

Оператор не ждёт от нас это сообщение и присылает STATUS, далее банальное освобождение канала.

Может я не прав, но обычно STP_ACK принимающая сторона отправляет инициирующей, когда получена не полная информация в SETUP-e, например, номер передаётся в режиме overlap или нет IE Sending complete. Но тут en-block и вся необходимая информация, включая номер канала, Calling, Called, Sending complete имеется. Что ещё нужно?

Информация в SETUP ACKNOWLEDGE расшифрована?

DCH 16 Q931_OMSG STP_ACK REF 00000380 TN 00001A04 CH 00000001 TOD 11:40:42 CK 427745AA

Total Number of Message Octets : 16
41 00 01 00 0A 00 08 02 80 07 0D 18 03 A9 83 81

Q.931 Decoded Message :

41 - Primitive ID : ISDN data Link Outgoing Indication Layer 3 Monitor Debug outgoing Request
00 - Spare
01 - Port 01
00 - Spare
0A - Message Length 10

08 - Protocol Discriminator: Q.931/I.451 user-network call control messages
02 - Call Reference Length
80 07 - To Call Reference : 896

0D - Message Type : SETUP ACKNOWLEDGE

18 - Information Element : Channel identification
03 - IE Length 3
A9 - Interface Id : Interface implicitly identified
- Primary Rate Interface
- Exclusivel Only the indicated channel is acceptable
- The channel identified is not the D Channel
- Selection : As indicated in the following octets
83 - CCITT standardized coding, as described below
- Channel is indicated by the number in the following octet
- B Channel units
81 - Channel ID : 1

Думаю, дело не в SETUP ACKNOWLEDGE. Спросить у противоположной строны о причине - Cause : Normal, Unspecified.

Может я не прав, но обычно STP_ACK принимающая сторона отправляет инициирующей, когда получена не полная информация в SETUP....

Может я тоже не прав, но то, что вы написали совершенно не обязательно. Это подтверждение получение SETUP и доп. информация МОЖЕТ быть, а МОЖЕТ и нет.
Приаттачил файл на эту тему полезный (Приказ об утверждении правил применения оконечного оборудования, выполняющего функции систем коммутации).

Думаю, дело не в SETUP ACKNOWLEDGE. Спросить у противоположной строны о причине - Cause : Normal, Unspecified.
Разбирались с оператором, переключали поток на другое оборудование и выяснили, что если SETUP ACKNOWLEDGE отсутствует*, то соединение устанавливается. По словам оператора, их оборудование формирует STATUS, потому что от нас получено сообщение, которое они не ждут, поскольку всю необходимую информацию они передали в сообщении SETUP.

* переключение делали на Meridian 1 Option 11C mini, с точно такими же настройками d-канала, маршрута и транков, как на сиэске!

Разбирались с оператором, переключали поток на другое оборудование и выяснили, что если SETUP ACKNOWLEDGE отсутствует*, то соединение устанавливается. По словам оператора, их оборудование формирует STATUS, потому что от нас получено сообщение, которое они не ждут, поскольку всю необходимую информацию они передали в сообщении SETUP.

* переключение делали на Meridian 1 Option 11C mini, с точно такими же настройками d-канала, маршрута и транков, как на сиэске!

Настройки D-канала покажите.

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

Спасибо за документик, но при беглом поиске я не нашёл в нём информации о том, должно ли быть полученное сообщение SETUP подтверждено ответом SETUP ACKNOWLEDGE или не должно.

В спецификации ITU-T Q.931 сказано так: "SETUP ACKNOWLEDGE. This message is sent by the network to the calling user, or by the called user to the network, to indicate that call establishment has been initiated, but additional information may be required.". :confused:

Настройки D-канала покажите.
ADAN DCH 16
CTYP MSDL
MG_CARD 000 0 07
PORT 1
DES KCELL_LOOP26
USR PRI
DCHL 26
OTBF 32
PARM RS422 DTE
DRAT 64KC
CLOK EXT
IFC EURO
CNTY ETSI
PINX_CUST 0
ISDN_MCNT 300
CLID OPT1
PROG NCHG
CO_TYPE STD
SIDE USR
CNEG 1
RLS ID **
RCAP
MBGA NO
OVLR YES
DIDD 0
OVLS NO
T310 120
INC_T306 120
OUT_T306 120
T200 3
T203 10
N200 3
N201 260
K 7

Ключевая фраза "...may be required..." не MUST, а именно may be!

Выдержка из приаттаченого документа:

5) Передающая сторона информирует принимающую сторону о начале установления соединения в сообщении "установка" (далее - Setup).
6) Принимающая сторона подтверждает готовность начать установление соединения сообщением "подтверждение установки" (далее - Setup Acknowledge).

В этом документе описывается процедура установления соединения, и наличие Setup Acknowledge допустимо, а может и даже необходимо по мнению Министерства информационных технологий и связи Российской Федерации. :)

Дополнительная информация для размышления: на этой же сиэске есть подключение к основному оператору, вот настройки d-канала и трейс:
ADAN DCH 11
CTYP MSDL
MG_CARD 000 0 02
PORT 1
DES CSC
USR PRI
DCHL 21
OTBF 32
PARM RS422 DTE
DRAT 64KC
CLOK EXT
IFC EURO
CNTY ETSI
PINX_CUST 0
ISDN_MCNT 300
CLID OPT1
PROG NCHG
CO_TYPE STD
SIDE USR
CNEG 1
RLS ID **
RCAP
MBGA NO
OVLR YES
DIDD 0
OVLS NO
T310 120
INC_T306 120
OUT_T306 120
T200 3
T203 10
N200 3
N201 260
K 7

DCH 11 Q931_IMSG SETUP REF 00001D4B TN 000015C4 CH 00000019 TOD 9:46:17 CK 2D06FC1D
40 00 01 00 2C 00 08 02 4B 3A 05 04 03 80 90 A3 18 03 A9 83 99 1E 02 81 83 6C 0C 21 80 37 31 37 32 39 37 37 37 35 35 70 07 81 39 37 39 39 39 30 A1 00

DCH 11 Q931_OMSG CALLPROC REF 00001D4B TN 000015E0 CH 00000018 TOD 9:46:17 CK 2D06FCE8
41 00 01 00 0A 00 08 02 CB 3A 02 18 03 A9 83 99

DCH 11 Q931_OMSG ALERT REF 00001D4B TN 000015E0 CH 00000018 TOD 9:46:17 CK 2D06FD10
41 00 01 00 0A 00 08 02 CB 3A 01 1E 02 81 82 00

DCH 11 Q931_IMSG DISC REF 00001D4B TN 000015E0 CH 00000018 TOD 9:46:19 CK 2D07035D
40 00 01 00 0A 00 08 02 4B 3A 45 08 02 81 90 00

DCH 11 Q931_OMSG RELEASE REF 00001D4B TN 000015E0 CH 00000018 TOD 9:46:19 CK 2D0703CA
41 00 01 00 06 00 08 02 CB 3A 4D 00

DCH 11 Q931_IMSG REL_COMP REF 00001D4B TN 000015E0 CH 00000018 TOD 9:46:19 CK 2D070402
40 00 01 00 06 00 08 02 4B 3A 5A 00
Почему здесь никогда нет сообщения SETUP ACKNOWLEDGE?

ADAN DCH 16
CTYP MSDL
MG_CARD 000 0 07
PORT 1
DES KCELL_LOOP26
USR PRI
DCHL 26
OTBF 32
PARM RS422 DTE
DRAT 64KC
CLOK EXT
IFC EURO
CNTY ETSI
PINX_CUST 0
ISDN_MCNT 300
CLID OPT1
PROG NCHG
CO_TYPE STD
SIDE USR
CNEG 1
RLS ID **
RCAP
MBGA NO
OVLR YES
DIDD 0
OVLS NO
T310 120
INC_T306 120
OUT_T306 120
T200 3
T203 10
N200 3
N201 260
K 7


Оверлап нужен?

оверлап по приёму нужен, так как настроены DID-транки и используется таблица IDC на маршруте

Выдержка из приаттаченого документа:

5) Передающая сторона информирует принимающую сторону о начале установления соединения в сообщении "установка" (далее - Setup).
6) Принимающая сторона подтверждает готовность начать установление соединения сообщением "подтверждение установки" (далее - Setup Acknowledge).
Я видел эти пункты, но они относятся к подразделу "3. Если в коммутационном оборудовании поддерживается сигнализация H.225, то выполняются следующие требования к реализации данного протокола:" раздела "ТРЕБОВАНИЯ К ПАРАМЕТРАМ ПРОТОКОЛА ПЕРЕДАЧИ ПАКЕТОВ МУЛЬТИМЕДИЙНОЙ ИНФОРМАЦИИ (ПРОТОКОЛА H.323)".

Я видел эти пункты, но они относятся к подразделу "3. Если в коммутационном оборудовании поддерживается сигнализация H.225, то выполняются следующие требования к реализации данного протокола:" раздела "ТРЕБОВАНИЯ К ПАРАМЕТРАМ ПРОТОКОЛА ПЕРЕДАЧИ ПАКЕТОВ МУЛЬТИМЕДИЙНОЙ ИНФОРМАЦИИ (ПРОТОКОЛА H.323)".

да, значит я поспешил.... но в любом случае "SETUP ACKNOWLEDGE - Подтверждение установления соединения"
Ни где не написано, что обязательно должна быть доп. информация при наличии данного сообщения.

P.S. Так что на счет оверлапа?

оверлап по приёму нужен, так как настроены DID-транки и используется таблица IDC на маршруте

ответил выше

ответил выше

Если временно отключить и проверить?

Ему низя это менять т.к будет невозможно принимать более 4 цифр.

Интересно всё-таки какая коза у оператора появляется и какая у них АТС

Ему низя это менять т.к будет невозможно принимать более 4 цифр.

Интересно всё-таки какая коза у оператора появляется и какая у них АТС

А я и не предлагал отключить на совсем... только на время проверки.

При OVLR=NO сценарий звонка другой, так как наша станция не находит у себя Called номер и "отбивает" с причиной Unassigned (unallocated) number.

оверлап по приёму нужен, так как настроены DID-транки и используется таблица IDC на маршруте

Почитайте внимательно ITU когда может формироваться SETUP ACKNOWLEDGE и Normal Unspecified. Cо своими реалиями соотнесите. В том числе, и оверлапом. Проанализируйте различия в формировании каналов связи при использовании 000 0 07 и 000 0 02 (обрудование - конвертация TDM - IP и пр...)

Интересно всё-таки какая коза у оператора появляется и какая у них АТС
Ericsson AXE-810

Почитайте внимательно ITU когда может формироваться SETUP ACKNOWLEDGE
читал несколько раз, вот что там сказано:

5.1.5 Call proceeding
5.1.5.1 Call proceeding, en-bloc sending
If en-bloc sending is used, (i.e. the network can determine that the SETUP message contains all the information required from the user to establish the call) and if the network can determine that access to the requested service is authorized and available, the network shal send a CALL PROCEEDING message to the user. This acknowledges the SETUP message, and indicates that the call is being processed. The network will then enter the Outgoing Call Proceeding state. When the user receives the CALL PROCEEDING message, the user shall also enter the Outgoing Call Proceeding state.

Проанализируйте различия в формировании каналов связи при использовании 000 0 07 и 000 0 02 (обрудование - конвертация TDM - IP и пр...)

000 0 02 - подкл. к основному оператору через RAD Optimux 4E1, Nortel TN-4XE (SDH) --> Meridian 1 Option 81C
000 0 07 - подкл. к альтернативному оператору через РРЛ --> Ericsson AXE-810

читал несколько раз, вот что там сказано:

5.1.5 Call proceeding
5.1.5.1 Call proceeding, en-bloc sending
If en-bloc sending is used, (i.e. the network can determine that the SETUP message contains all the information required from the user to establish the call) and if the network can determine that access to the requested service is authorized and available, the network shal send a CALL PROCEEDING message to the user. This acknowledges the SETUP message, and indicates that the call is being processed. The network will then enter the Outgoing Call Proceeding state. When the user receives the CALL PROCEEDING message, the user shall also enter the Outgoing Call Proceeding state.

5.2.4 Overlap receiving

Включение в настройках D-канала OVLR означает, что информация о Called-номере при входящем запросе на установление соединения может передаваться как в режиме en-block, так и в overlap. Это подтверждено тестовыми звонками!

А поскольку оператор присылает весь Called-номер и IE Sending complete, то звонок обрабатывается по процедуре en-block.

p.s. тоже самое относится и к параметру OVLS для исходящих звонков

...оператор присылает весь Called-номер и IE Sending complete, то звонок обрабатывается по процедуре en-block.


Вполне. Согласен. Читаем ITU дальше.

То-же думаю, что трансмиссия. Был случай когда по EURO подключил клиента через RAD IPMUX-11. Не шел транзит на оператора №1, а на оператора №2 -отлично. Настройки операторов идентичны. Ситуация горела и переделал клиента на ESIG и всё Ok!

PS. RAD IPMUX-11, дрянь редкосная да ещё Eth канал склеивался из двух операторов.

Вполне. Согласен. Читаем ITU дальше.
Кстати, оператор у себя всё проверил, утверждает, что его оборудование работает корректно, а для решения проблемы нам нужно "... выполнить настройки станции таким образом, чтоб сообщение SETUP ACK на нашу сеть не направлялось"

То-же думаю, что трансмиссия. Был случай когда по EURO подключил клиента через RAD IPMUX-11. Не шел транзит на оператора №1, а на оператора №2 -отлично. Настройки операторов идентичны. Ситуация горела и переделал клиента на ESIG и всё Ok!

PS. RAD IPMUX-11, дрянь редкосная да ещё Eth канал склеивался из двух операторов.
у нас не используются IPMUX-ы

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

LD 22
PSWV


А провайдер жжОт...

При OVLR=NO сценарий звонка другой, так как наша станция не находит у себя Called номер и "отбивает" с причиной Unassigned (unallocated) number.
FAQ 21

LD 22
PSWV
распечатка во вложении

Вот ещё дополнительная информация:
.stat msdl 0 0 2 full
MSDL 000 0 2 ENBL
DCH 11 OPER PORT 1
CARDID: NTBK51AA00
BOOTLOAD FW VERSION: 002
BASECODE VERSION: 073
STATE: ENABLED
ACTIVATED: 04/14/11 22:18
APPLICATIONS:
NAME: PRIE
VERSION: 086
STATE: ENABLED
ACTIVATED: 04/15/11 1:04
NAME: ETSI DATA FILE
VERSION: 048
STATE: ENABLED
ACTIVATED: 04/14/11 22:18


.stat msdl 0 0 7 full
MSDL 000 0 7 ENBL
DCH 16 OPER PORT 1
CARDID: NTDW79AAE5
BOOTLOAD FW VERSION: 002
BASECODE VERSION: 073
STATE: INACTIVE
APPLICATIONS:
NAME: PRIE
VERSION: 086
STATE: ENABLED
ACTIVATED: 04/15/11 16:41
NAME: ETSI DATA FILE
VERSION: 048
STATE: ENABLED
ACTIVATED: 04/15/11 1:59
Карточки разные, стоят в одном MG, версии firmware совпадают, почему же они тогда отрабатывают один и тот же сценарий не одинаково? :confused:

Карточки разные, стоят в одном MG, версии firmware совпадают, почему же они тогда отрабатывают один и тот же сценарий не одинаково? :confused:

Так как насчет проверки отключения оверлапа, ситуация меняется?
Не забываем что выше написал Gluker!

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

Нашёл у производителя... :) Конечно, не конкретно по CS. Но тем не менее...

Document Id: KB01084431Last Modified Date: 11-09-2009Support Goal(s): Telephony and Data NetworkAccess Level: External EntitledDescription (Problem Clarification)
https://support.avaya.com/selfservice/img/sp.gifhttps://support.avaya.com/selfservice/img/viewdoc_tab.gifhttps://support.avaya.com/selfservice/img/sp.gif


Information about ISDN: It includes D-Channel Messages, ISDN D-channel Call Clearing Messages, ISDN D-channel Call Establishment Message, ISDN D-channel Maintenance Messages and ISDN D-channel Miscellaneous Messages.

https://support.avaya.com/selfservice/img/sp.gif Resolution Plan
https://support.avaya.com/selfservice/img/sp.gifhttps://support.avaya.com/selfservice/img/viewdoc_tab.gifhttps://support.avaya.com/selfservice/img/sp.gif
D-channel messages establish and manage ISDN calls in much the same way supervision signals and call progress tones handle non-ISDN calls. Actions such as seizing a circuit or going on-hook are represented by D-channel messages such as SETUP and DISCONNECT.
Most D-channel messages include additional information needed for call processing, such as the calling party number, called party number, and channel ID. These data, referred to as information elements (IEs), varies depending on the message, action being performed, and connected equipment. Mandatory and optional IEs for D-channel messages are defined in ITU-T Q.931.
Other D-channel messages are part of the standard ISDN message set. These messages allow complete control over call establishment and clearing, network maintenance, and the passing of other call-related information between switches.
502 11:25:21.840 60 09003e17 ==> SETUP crv 0_18e3 506 11:25:21.840 62 09003e17 <-- CALL_PROC crv 1_18e3 561 11:25:21.840 62 09003e17 <-- ALERT crv 1_18e3 846 11:25:21.900 62 09003e17 <-- CONN crv 1_18e3 864 11:25:21.940 60 09003e17 ==> CONN_ACK crv 0_18e3 2346 11:26:02.040 60 09003e17 ==> DISC crv 0_18e3 2357 11:26:02.040 62 09003e17 <-- REL crv 1_18e3 2391 11:26:02.100 60 09003e17 ==> REL_COM crv 0_18e3ISDN D-channel Call Clearing Messages

DISCONNECT The DISCONNECT message clears a connection. The expected response to a DISCONNECT is RELEASE. A received DISCONNECT message starts timer T305 (4 seconds) by default. A received DISCONNECT message that also has a progress indicator IE descriptor of 8, starts timer T306 (60 seconds). Timer T306 is used when the network wishes to provide in-band tones and announcements when disconnecting the call. RELEASE The RELEASE message clears a connection. A RELEASE message is sent to acknowledge the DISCONNECT message and clear the connection. The expected response to a RELEASE is RELEASE COMPLETE. RELEASE COMPLETE The RELEASE COMPLETE message acknowledges receipt of a RELEASE message and is the final step in clearing a connection. No response is expected. RESTART The RESTART message requests a restart (set to idle) for the D-channel, or individual B-channel, specified. Response to a successful request is the RESTART ACKNOWLEDGE message. For a D-channel RESTART message a status report is generated indicating the ICC ISDN span has been reset. When this processing has completed, a RESTART ACKNOWLEDGE is returned. For a B-channel RESTART message, the call on that channel is cleared and the port is set to idle and a RESTART ACKNOWLEDGE is returned. RESTART ACKNOWLEDGE The RESTART ACKNOWLEDGE message indicates that a previous RESTART has been performed. ISDN D-channel Call Establishment Message

ALERTING The ALERTING message indicates that called-user alerting has been initiated. CALL PROCEEDING The CALL PROCEEDING message indicates that the call establishment requested by a SETUP message has been accepted and that no further call establishment messages will be accepted. CONNECT The CONNECT message indicates the call has been accepted and should be connected. CONNECT ACKNOWLEDGE The CONNECT ACKNOWLEDGE message indicates that the call connection has been established. CONNECT ACKNOWLEDGE is automatically transmitted in response to a received CONNECT message. PROGRESS The PROGRESS message provides additional information required for call establishment. SETUP The SETUP message initiates call establishment. When a new call originates, the system generates a D-channel SETUP message. When a system receives a SETUP message with acceptable parameters (CHAN ID, CD NUM, BEARER IEs, etc.), the system must generate a CALL PROCEEDING message and send it to the network. The correct message to reject a call establishment request is a RELEASE COMPLETE with a cause IE of NETWORK CONGESTION. NOTE: For Communication Manager A SETUP ACKnowledge message is also a valid first response message. When it is received, channel negotiation and channel cut-thru shall be the same as is done for a CALL PROCeeding message. Receipt of this message should stop Timer T303 and start T304
NOTE: Communication Manager will never originate a SETUP ACKnowledge message.
ISDN D-channel Maintenance Messages

SERVICE The SERVICE message is supported in only the 4ESS, 5ESS, and NTI ISDN protocols. This message changes the current status of the channel to in-service, out-of-service, or maintenance. Response to a successful request is the SERVICE ACKNOWLEDGE message. SERVICE ACKNOWLEDGE The SERVICE ACKNOWLEDGE message indicates that a received SERVICE message has been processed. ISDN D-channel Miscellaneous Messages

CONGESTION CONTROL The CONGESTION CONTROL message indicates the establishment or termination of flow control. FACILITY The FACILITY message requests a specific facility or service. The expected response to a FACILITY message is either a FACILITY ACKNOWLEDGE message (facility request accepted) or a FACILITY REJECT message (facility request rejected). FACILITY ACKNOWLEDGE The FACILITY ACKNOWLEDGE message accepts a FACILITY request. FACILITY REJECT The FACILITY REJECT message rejects a FACILITY request. NOTIFY The NOTIFY message conveys information pertaining to a call across the interface. The NOTIFY message is sent by the called user to the network or by the network to the calling user. STATUS The STATUS message responds to a STATUS ENQUIRY message. The current call state is reported. STATUS ENQUIRY The STATUS ENQUIRY message requests a STATUS message from a peer Layer 3 entity. Response to a successful request is STATUS.

Так как насчет проверки отключения оверлапа, ситуация меняется?
Не забываем что выше написал Gluker!
Прописал номер в LDN0, отключил IDC на маршруте, выкл. OVLR - звонки пошли:
DCH 16 Q931_IMSG SETUP REF 00002980 TN 00001A04 CH 00000001 TOD 12:07:46 CK 8AD3BF6A
40 FB 01 00 2C 00 08 02 00 53 05 A1 04 03 80 90 A3 18 03 A9 83 81 6C 0C 21 83 37 30 31 30 30 30 30 30 30 31 70 0B A1 37 37 35 30 39 37 39 39 39 30 00

DCH 16 Q931_OMSG CALLPROC REF 00002980 TN 00001A04 CH 00000001 TOD 12:07:46 CK 8AD3BFC8
41 00 01 00 0A 00 08 02 80 53 02 18 03 A9 83 81

DCH 16 Q931_OMSG ALERT REF 00002980 TN 00001A04 CH 00000001 TOD 12:07:46 CK 8AD3BFF0
41 00 01 00 0A 00 08 02 80 53 01 1E 02 81 82 00

DCH 16 Q931_IMSG DISC REF 00002980 TN 00001A04 CH 00000001 TOD 12:07:52 CK 8AD3EFC9
40 80 01 00 0A 00 08 02 00 53 45 08 02 80 9F 00

DCH 16 Q931_OMSG RELEASE REF 00002980 TN 00001A04 CH 00000001 TOD 12:07:52 CK 8AD3F01C
41 00 01 00 06 00 08 02 80 53 4D 00

DCH 16 Q931_IMSG REL_COMP REF 00002980 TN 00001A04 CH 00000001 TOD 12:07:52 CK 8AD3F044
40 10 01 00 06 00 08 02 00 53 5A 00

Получается, что при вкл. OVLR сиэска игнорирует IE Sending complete в сообщении SETUP, отправляет STP_ACK, но не ждёт INFO с IE Sending complete, а сразу отправляет CALLPROC, что и вводит в заблуждение станцию оператора, которая уже всю необходимую информацию передала в SETUP-е!

Остаётся открытым вопрос:Дополнительная информация для размышления: на этой же сиэске есть подключение к основному оператору... Почему здесь никогда нет сообщения SETUP ACKNOWLEDGE?Ведь настройки одинаковые, разное только железо!

И ещё, когда я только создавал эту тему, мы тестировались с оператором и из множества неуспешных звонков были единичные случаи, где сиэска не отправляла STP_ACK и соединение устанавливалось успешно, вот пример:
DCH 16 Q931_IMSG SETUP REF 00000400 TN 00001A04 CH 00000001 TOD 11:40:48 CK 4277767F
40 00 01 00 2C 00 08 02 00 08 05 A1 04 03 80 90 A3 18 03 A9 83 81 6C 0C 21 83 37 30 31 30 30 30 30 30 30 31 70 0B A1 37 37 35 30 39 37 39 39 39 30 00

DCH 16 Q931_OMSG CALLPROC REF 00000400 TN 00001A04 CH 00000001 TOD 11:40:48 CK 427776EF
41 00 01 00 0A 00 08 02 80 08 02 18 03 A9 83 81

DCH 16 Q931_OMSG ALERT REF 00000400 TN 00001A04 CH 00000001 TOD 11:40:48 CK 42777717
41 00 01 00 0A 00 08 02 80 08 01 1E 02 81 82 00

DCH 16 Q931_IMSG DISC REF 00000400 TN 00001A04 CH 00000001 TOD 11:40:54 CK 42779FAD
40 DF 01 00 0A 00 08 02 00 08 45 08 02 80 9F 00

DCH 16 Q931_OMSG RELEASE REF 00000400 TN 00001A04 CH 00000001 TOD 11:40:54 CK 4277A011
41 00 01 00 06 00 08 02 80 08 4D 00

DCH 16 Q931_IMSG REL_COMP REF 00000400 TN 00001A04 CH 00000001 TOD 11:40:54 CK 4277A03A
40 00 01 00 06 00 08 02 00 08 5A 00
SETUP-ы идентичные, где логика?! :confused:

Добавлю: установка актуального деплиста и лоадварей никак на ситуацию не повлияла, причина столь нелогичного поведения новой карточки выяснена не была.

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

Спасибо всем, кто откликнулся!