Incoming call blocking sometimes and cause #44 appears..!!

[Optman]

Hi all

we have some problems with incoming call over PRI trunk runing under CS1000 system..sometimes we got this issue that can take about 5 minutes then it reload automatically and we got normal service.

Under DCH monitoring and during the issue we got lot of messages with cause #44..

DCH 10 UIPE_OMSG CC_REJECT_REQ REF 0000AD80 CH 0 TOD 13:37:36 CK 87125C81
CAUSE: #44 - REQ CIRC/CHAN NOT AVAILABLE

Now my customer wants to have raisons of this issue and what can cause it ?

I don't know if we can suspect CO Provider or CS1000 system ?

I see the cause #44 means that there is no channel available but what is the responsible of this ?

Let me know

Thanks

 

[Firebird Scrambler]

Not sure what release your system is,
but a patch mplr27770 X21 4.50W was issued to cure the following fault that had cause 44.

Problem Scenario :
QSIG EGF4 PRI link using DPRI NT5D97AD and MSDL d/bd NTBK51AA to a third-party IVR system
A real-time monitoring utility on the IVR system causes an application to crash and calls are then rejected with cause 44 (requested channel not available). At this point the M1 puts the B-channel into LCKO and tries all other channels in turn, until all are in a LCKO state. The DCH is still enabled and active.
.............Now reboot the IVR system (or disconnect the PRI cable).

Expected Response:
M1 to continue call processing normally

Actual Response :
Lots of PRI358 messages produced and Call Registers quickly disappear from the Idle queue until all are used up (this takes less than 2 minutes) and call processing stops

Recovery Process :
1) Disable the DCH on the M1 (if you are quick enough) or, if not
2) Manual INI of the M1


Patch 27770_1 written to fix the problem

FULL PROBLEM DESCRIPTION:
Loads of PRI358 message is causing the switch to eat away the Call registers, this issue is triggered on site and happens 100 % under the following conditions.

Meridain Swith connected directly to an IVR system over a Qsig PRI connection. Under certain condition the IVR system fails to respond to an i/c SETUP message due to faulty conditions of the IVR. In response it will send an 0_CC_REJECT message with cause of 44 (.PRA_NO_REQ_CH). Once the Meridian receives this message it will put the channel into lock-out as normal. When all 24 B’channels have been locked out, if the PRI cable is disconnected or IVR server rebooted, then the switch will print loads of PRI358 messages on the TTY.
We have the CRSTART logs following on from the problem that shows loads of Callregisters stuck in MAINPM( .SPECIAL) and AUXPM (.DCH_MAINT).

Set-up
1) Node A: Meridian Switch OPT (61) running x210450w, pp4.
a) Receives i/c pstn call to IVR.
b) Qsig pri connection directly to an IVR system.

2) IVR system to handle i/c call connected to Node A over a Qsig (pri) connection.

ACTION
1) Assume the IVR system has a fault and is unable to respond to a call.

2) Make any type of call to reach the IVR from Node A.

3) Once all B channels are locked-out, due to receiving a O_CC_REJECT message with Cause (44). Disconnect the PRI cable or Re-boot the IVR.

EXPECTED RESULTS:
1) Print loads of PRI358 messages on the TTY, But no Callregisters should be stuck!!

ACTUAL RESULTS:
1) Print loads of PRI358 messages on the TTY and loads of Callregisters are stuck in
MAINPM( .SPECIAL) and AUXPM (.DCH_MAINT).
This causes the switch to slow down and will eventually halt. The only way out is to re-boot the switch.

IMPACT OF PROBLEM: Loss of service

SYMPTOMS EXHIBITED:

DCH 24 UIPE_OMSG CC_SETUP_REQ REF 0000065F CH 24 22 TOD 12:27:43 CK 5BD8FB19
PROGRESS: INTERWORKING WITH A PUBLIC NETWORK
PROGRESS: CALL IS NOT END TO END ISDN
CALLED #:1225 NUM PLAN: PRIVATE TON: ESN CDP

DCH 24 UIPE_IMSG CC_REJECT_IND REF 0000065F CH 24 22 TOD 12:27:43 CK
5BD8FBCC
CAUSE: #44 - REQ CIRC/CHAN NOT AVAILABLE

ERR9032 24 22 12:27:43 23/01/2009

PRI cable is disconnected or IVR server rebooted,

DTA203 24 4 2
DTA203 24 4 1

PRI358 24 124014709 24 124014709
PRI358 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 12401470o9
PRI358 24 124014709 24 124014709
PRI358 24 124014709 24 124014709
PRI358 24 124014709


All the best

Firebird Scrambler
Meridian 1 / Succession and BCM / Norstar Programmer in the UK

http://www.linkedin.com/in/davidbromley

If it's working, then leave it alone!.

 

[Optman]

many thanks for your reply, but I have system runing Rls 7.0 and we don't have the same issue that you have describe (IVR, QSIG..etc)

and we didn't got PRI358 messages.

The PRI (NTBK50) is connected directly to the CO Provider and the problem is intermittant..

my question is what can cause this issue CO Provider or CS1000 ?

 

[Optman]

Hi all

Please the problem is very critical, we have never met the same kind of problem.

so it is intermittant issue, each day the incoming calls was blocking and we receive a lot of "cause: #44" it take about 15 minutes then it come up automatically.

DCH 10 UIPE_IMSG CC_SETUP_IND REF 00000C80 CH 60 1 TOD 15:54:38 CK BB99DA0A
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:2xxxxxxxxxxx NUM PLAN: UNKNOWN TON: UNKNOWN
CALLED #:5430 NUM PLAN: UNKNOWN TON: UNKNOWN

DCH 10 UIPE_OMSG CC_REJECT_REQ REF 00008C80 CH 0 TOD 15:54:38 CK BB99DA0A
CAUSE: #44 - REQ CIRC/CHAN NOT AVAILABLE

thanks

 

[trvlr1]

When you get this error, have you stat the circuit in LD 60 to see if you have channels available?

 

[RickyPone]

Five days later? How critical can it be?

 

[Optman]

when I stat the loop through (LD 60) I see that there is channels idle...!!

yes five days later, I have opened critical case within avaya/support but it is still on investiguation.

Thanks

 

[SL1M1]

Is your PRI a full 30 channel availability from your provider
This looks like an order/span problem ?

Cheers!!

 

[Optman]

yes all 30 channel are available from the CO Provider..

we have see that the LED of CC on NTBK50 card flash sometimes then it come fix...!!

may be this can also cause the issue...!!!

Thanks

 

[SL1M1]

So how many members are configured in that route, print it out and see...Just curious ?

LD 21
REQ LTM
CUST X
ROUT X

Cheers!!

 

[Optman]

thanks, I have create 30 members on that route:

TYPE TLST
TKTP DID
ROUT 23
DES PRI
TN 060 01 MBER 1 DID
TN 060 02 MBER 2 DID
TN 060 03 MBER 3 DID
TN 060 04 MBER 4 DID
TN 060 05 MBER 5 DID
TN 060 06 MBER 6 DID
TN 060 07 MBER 7 DID
TN 060 08 MBER 8 DID
TN 060 09 MBER 9 DID
TN 060 10 MBER 10 DID
TN 060 11 MBER 11 DID
TN 060 12 MBER 12 DID
TN 060 13 MBER 13 DID
TN 060 14 MBER 14 DID
TN 060 15 MBER 15 DID
TN 060 16 MBER 16 DID
TN 060 17 MBER 17 DID
TN 060 18 MBER 18 DID
TN 060 19 MBER 19 DID
TN 060 20 MBER 20 DID
TN 060 21 MBER 21 DID
TN 060 22 MBER 22 DID
TN 060 23 MBER 23 DID
TN 060 24 MBER 24 DID
TN 060 25 MBER 25 DID
TN 060 26 MBER 26 DID
TN 060 27 MBER 27 DID
TN 060 28 MBER 28 DID
TN 060 29 MBER 29 DID
TN 060 30 MBER 30 DID

when I print the clock SSCK:

SSCK 4 1

ENBL
CLOCK ACTIVE
CLOCK CONTROLLER - DTI062
PREF - 1
SREF -
AUTO SWREF CLK - ENBL
DTI055

 

[trvlr1]

Do you have any other routes/circuits or is this the only one?
You might want to consider asking the telephone company to do a busy study on the circuit. They can see the state of all the channels at all times and let you know if you are getting all channels busy or not. Your stat in LD 60 may not be quick enough to capture the moment when all the channels are actually busy.

 

[Optman]

thanks,

yes we have another route (PRI2) that is stable (with no issue) on the same system.

the CO Provider are already make channel by channel test, and they see that all channels are good...!!

 

[cmassjohn]

Are you in the UK (as you're on E1 I'm assuming Europe...) and if so who is the telco?

Is is only with calls to one particular DN, a range or all?

As an aside... I've seen cause 44 on OUTBOUND calls because the alternative carrier couldn't route a single number properly and CS1k got cause 44 back from an upstream carrier switch. Once we routed that number out via BT circuit it work, so we get customer to play hard ball with carrier who eventually admitted they had a routing issue with that particular number.




Senior Engineer, cmass

http://www.cmass-ni.com

 

[Optman]

no, Im not in UK.

this system is installed in Morroco.

 

[cmassjohn]

Is problem only with calls to one particular DN, a range or all?

Has the problem only started recently or was always there?

What variant of ISDN are you using (can you print the ADAN DCH in LD22)



Senior Engineer, cmass

http://www.cmass-ni.com

 

[Optman]

thanks for your reply, yes the problem is with all DN (all incoming calls on that PRI) and the issue was always there..

DCH printout:

ADAN DCH 10
CTYP MSDL
MG_CARD 004 1 01



PAGE 002

PORT 1
DES
USR PRI
DCHL 60
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 COLP
MBGA NO
OVLR NO
OVLS NO
T310 120
INC_T306 120
OUT_T306 120
T200 3
T203 10
N200 3
N201 260
K 7

 

[cmassjohn]

Can you print DCH for the working link too? Best to compare the DCH and a few trunks between the 2 routes.

If that checks out it could be a DSP issue or similar where no resources are available for the bearer channels, but we'll go one small step at a time...


Senior Engineer, cmass

http://www.cmass-ni.com

 

[Optman]

thanks cmassjohn for your reply..
this is the DCH working:
ADAN DCH 61
CTYP MSDL
MG_CARD 008 0 02
PORT 1
DES PSTNRABAT
USR PRI
DCHL 61
OTBF 32
PARM RS422 DTE
DRAT 64KC
CLOK EXT
IFC EURO
CNTY FRA
PINX_CUST 0
ISDN_MCNT 300
CLID OPT1
PROG NCHG
CO_TYPE STD
SIDE USR
CNEG 2
RLS ID **
RCAP
MBGA NO
OVLR NO
OVLS NO
T310 120
INC_T306 120
OUT_T306 120
T200 3
T203 10
N200 3
N201 260
K 7

you see that this issue can caused by DSP channels not CO Provider...what we need to check the DSPs..??

Thanks