Call Disconnects after Recovery Timer Expiry.

[leo]

Hi All,

R9.0 patch 42
Of lately we are facing an issue on a specific service provider's numbers, when dialed.
The calls matures and then disconnects after 30-40 second duration.
On analyzing the t3 trace following are the observations:
1. On receiving the alert message some "Mandatory Information Elements missing" is been seen.
Over this the system asks for status.
2. On non receipt of any answer from the far end for this status query a recovery timer runs and finally the
call is disconnected after its expiry.
We have ignored the React. receiving msg state options and have set " Send Status for IE non-existent" as false with no effect.
Attached is a t3 trace.
Hope some help on this.

TIA
LEO

[vad]

in trace absent SETUP message. What about B-channel number? Usually provider have Network mode=yes and B-channel choice=yes and must replay to your SETUP like this
______________________________________________________________________________
| (006666:000039) Concatenated-Physical-Event :
| long: 20 desti: 0 source: 0 cryst: 1 cpl: 6 us: 0 term: 0 type a5
| tei: 0 >>>> message received : CALL PROC (02) Call ref : 8a
|______________________________________________________________________________
|
| IE:[18] CHANNEL (l=1) 8a -> T0/S0 : B2 channel exclusive <------------------ !!!! LIKE THIS
|______________________________________________________________________________

[leo]

Hello Vad,

Thanks for the reply and Sorry for the earlier incomplete trace. Please find the complete trace with setup message.

regards,
LEO

[vad]

Can you show in addition trace for good call?

[leo]

Hi Vad,

Please find attached trace information obtained on a good call.

LEO

[vad]

About not good calls

______________________________________________________________________________
| (888199:000015) Concatenated-Physical-Event :
| long: 27 desti: 0 source: 0 cryst: 2 cpl: 6 us: 0 term: 0 type a5
| tei: 0 >>>> message received : ALERT (01) Call ref : 81 7e
|______________________________________________________________________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[7d] HLC (l=2) 91 81
|______________________________________________________________________________

I never see before "BEARER_CAPABILITY " and "HLC" messages in ALERT message. I'm look in ISDN standart ETS 300 102-1 - in this standart nothing about presence "BEARER_CAPABILITY " and "HLC" in ALERT message (f.e. in SETUP message this IE described and in your SETUP present).

[ranlp]

Looking at the trace, status message complains of IE [04]
______________________________________________________________________________
| (888199:000015) Concatenated-Physical-Event :
| long: 27 desti: 0 source: 0 cryst: 2 cpl: 6 us: 0 term: 0 type a5
| tei: 0 >>>> message received : ALERT (01) Call ref : 81 7e
|______________________________________________________________________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[7d] HLC (l=2) 91 81
|______________________________________________________________________________

______________________________________________________________________________
| (888199:000016) 1578: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 26 desti: 0 source: 15 cryst: 2 cpl: 6 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : STATUS [7d] Call ref : 01 7e
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=3) 81 e0 04 -> [e0] MANDATORY INFORMATION ELEMENT MISSING
| IE:[14] CALL_STATE (l=1) 03
|______________________________________________________________________________

On the standards (ETS 300 102-1: December 1990), it does not say nothing about including IE Bearer and HLC in Alert Message.

[alex]

On the standards (ETS 300 102-1: December 1990), it does not say nothing about including IE Bearer and HLC in Alert Message.

Actual edition of Q.931 is ETS 300 403-1(1995):

This ETS which is based on ITU-T Recommendation Q.931 (1993) is an extended and updated version of ETS 300 102-1 (1990) which was based on CCITT Recommendation Q.931 (1988). Annex ZA identifies the relevant differences between this ETS and ETS 300 102-1.

From Annex ZA, ETS 300 403-1:

ZA.2 Technical changes
1) The Bearer capability and High layer compatibility information elements may now be included in the ALERTING, CALL PROCEEDING, CONNECT, and PROGRESS messages for support of BC and HLC selection.

So why OXE rejects this ALERT? May be because BC is the same as it was in SETUP - that means there is no need to repeat it. Or may be OXE needs PROGRESS IE included? I can only assume - anyway it's better to create an eSR just to get official explanation from ALU.

[svatc]

Leo.how you solved the problem? I have the same problem
call oxe (send 6 digit 484046) ----->PABX ewsd------>PABX huawei-----PABX

mobile operator-(mobile operator number 484048 or 8xxxx484048) trace

bad(RECOVERY ON TIMER EXPIRY)
call oxe(send 8xxxx484048) ----->PABX ewsd------>PSTN------->PABX mobile

operator 8xxxx484048) trace good

call oxe (send 6 digit 485xxx) ----->PABX ewsd----->PABX huawei(mobile

operator) all good

call oxe(send 6 digit)------->PABX ewsd all good
please help me.
P.S. Привет VADу )

good trace.txt

bad trace.txt

[tot3nkopf]

Did you tried with B channel choice on your side?