Long post-dial delay between PBXs

[TechDown]

Hello everyone,

Let me expose the problem:

Our CS1K's DN are 4 digits lenght. we have generated some DSCs with lenght of 5 digits, new route, dch, loop, etc, to reach Siemens's DN (5 digit lenght)through QSIG between both PBXs. Both ends can reach the other, RTP, signaling, no problem, but there's an issue when CS1K set (4 lenght) dials Siemens set (5 lenght)... The outgoing calls delays 16 seconds to reach the Siemens telephone... During these seconds there's no ringback in CS1K telephone and the Siemens set doesn't recieve anything. After that time the call reach the destination and once established everything goes fine.
If we add # after the 5 digits, the call reachs the destination without delays. There's no problem adding #

Let me add something, this issue happens with those DSCs and VNR (same RLI and CDPL and UDPL 5). There's no routing problem, call is not delayed searching for the best route, because there's only 1.

Our ESN has NDCP at 4 (all our DNs are 4 lenght)and I suspect this is the problem. I can't change it, so what can I do ? Can I change any parameter to decrease these 16 seconds delay? Users don't want to add # every time they want to call Siemens's Users (you know, such effort).

This problem doesn't happen when Siemens call CS1K.

Thank you guys and excuse my poor and rusty english.

Regards,

 

[bignose21]

and you have the FLEN of the DSC set to 5?
Another way might be to set DCH overlap send/receive or shorten the inter digit timers

 

[TechDown]

Hi bignose21,

Yes, FLEN is set in 5.

could you tell me which parameters are ? I would like to try both options.

 

[bignose21]

in DCH config you have to config both both ends but the prompts in CS1K

OVLR - Overlap Receive yes/no
OVLS - Overlap send yes/no

for interdigit in the TIM_DATA

DIDT xxx yyy zzz supp-9
Dial tone and Interdigit timeout for DTMF
sets.
Where: xxx = 0-(14)-60; yyy = 0-(14)-60; zzz =
0-(14)-60 when International Supplementary
Features (SUPP) package 131 is equipped.
The 1st parameter is the time before first digit
or the dial tone time. The 2nd parameter is the
time between the first and second digits. The
3rd parameter is the time between digits after
the second digit.
Odd entries are rounded down to a valid
multiple of two seconds.

 

[TechDown]

Thank you bignose21 for your help.

OVLS and OVLR are already in YES, OVLT (timer) in 0.

Do you think that EOD timer is what do I need to change? My route has:

TIMR ICF 512
OGF 512
EOD 13952
NRD 10112
DDL 70
ODT 4096
RGV 640
FLH 510
GTO 896
GTI 896
SFB 3
NBS 2048

If I am not wrong, EOD, end of digits, allows you dialing more digits for almost 14 seconds once you dial 5 digits (DSCs FLEN 5 points to this route)? I mean, once u have dialed the 5 digit lenght destination, the call is sending through this route with EOD 13952 to the other End, so, dialing # is it like ignoring eod timer?

Thank you very much.

Regards,

 

[bignose21]

are you sure its a routing problem on the PABX, enable DCH monitor and dial the 5 digits

does it take a ages before you see the outbound setup message, or do you see the setup message go straight away and then the delay?

 

[TechDown]

Hi bignose21,

when I do ld 96 .enl msgo X , I see the outbound message right after dialing the 5 digits, then the delay.

 

[bignose21]

You can stop looking at the cs1k routing then

Can you trace on the receiving end

 

[TechDown]

Hi bignose21,

thank you for ur time.

On monday I will test again. I'll capture on the receiving end while CS1k phone is on that 16 seconds delay after dialing, and by this way we will see if the call is stuck on cs1k or it is not well processed by the other end.

Thanks again !

 

[bignose21]

as soon as the setup is passed to the distant end it is up to that device to process the call. If you see a Large delay between the setup going out and the Alerting (Ringing) coming back then that would be an issue with the far end processing the call.

 

[TechDown]

I understand you, but why if do I add # after the 5 digits this problem doesn't happen? As far as I know, # tells to the CS1K that I am not adding more digits and it can sending the call to the destination, right? And if I am not wrong, the destination end doesn't receive # in the signaling, just the DN from where the call was did.


Thanks for your answers, I appreciate it.

Regards,

 

[jose.marti]

Let us see test call LD 96 MSGI and MSGO

 

[TechDown]

I will post them next monday.

Thank you all.

 

[TechDown]

Good morning,

I've made the test calls.

Nortel calling Siemens without #:

DCH 9 UIPE_OMSG CC_SETUP_REQ REF 000000B8 CH 29 23 TOD 9:23:35 CK 8E374413
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:2633 NUM PLAN: E164 TON: UNKNOWN
CALLED #:14561 NUM PLAN: E164 TON: UNKNOWN

DCH 9 UIPE_IMSG CC_MORE_INFO_IND REF 000000B8 CH 29 23 TOD 9:23:35 CK 8E3744C5
PROGRESS: TERMINATING END IS NOT ISDN

DCH 9 UIPE_IMSG CC_PROCEED_IND REF 000000B8 CH 29 23 TOD 9:23:51 CK 8E37BF72

DCH 9 UIPE_IMSG CC_ALERT_IND REF 000000B8 CH 29 23 TOD 9:23:51 CK 8E37C704
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 9 UIPE_IMSG CC_SETUP_CONF REF 000000B8 CH 29 23 TOD 9:23:55 CK 8E37D9EE
PROGRESS: TERMINATING END IS NOT ISDN

DCH 9 UIPE_IMSG CC_DISC_IND REF 000000B8 CH 29 23 TOD 9:24:13 CK 8E386DC9
CAUSE: #16 - NORMAL CALL CLEARING

DCH 9 UIPE_OMSG CC_RELEASE_REQ REF 000000B8 CH 29 23 TOD 9:24:13 CK 8E386DCA

DCH 9 UIPE_IMSG CC_RELEASE_CONF REF 000000B8 CH 29 23 TOD 9:24:13 CK 8E386E26
CAUSE: #16 - NORMAL CALL CLEARING

================================================================================

Nortel calling Siemens with #:

DCH 9 UIPE_OMSG CC_SETUP_REQ REF 000000B9 CH 29 22 TOD 9:27:01 CK 8E3D92ED
PROGRESS: ORIGINATING END IS NOT ISDN
CALLING #:2633 NUM PLAN: E164 TON: UNKNOWN
CALLED #:14561 NUM PLAN: E164 TON: UNKNOWN

DCH 9 UIPE_IMSG CC_MORE_INFO_IND REF 000000B9 CH 29 22 TOD 9:27:01 CK 8E3D93A0
PROGRESS: TERMINATING END IS NOT ISDN

DCH 9 UIPE_OMSG CC_INFO_REQ REF 000000B9 CH 29 22 TOD 9:27:03 CK 8E3D9A57

DCH 9 UIPE_IMSG CC_PROCEED_IND REF 000000B9 CH 29 22 TOD 9:27:03 CK 8E3D9ABC

DCH 9 UIPE_IMSG CC_ALERT_IND REF 000000B9 CH 29 22 TOD 9:27:03 CK 8E3D9DF8
PROGRESS: INBAND INFO OR PATTERN IS AVAIL

DCH 9 UIPE_IMSG CC_SETUP_CONF REF 000000B9 CH 29 22 TOD 9:27:07 CK 8E3DBEF4
PROGRESS: TERMINATING END IS NOT ISDN

DCH 9 UIPE_IMSG CC_DISC_IND REF 000000B9 CH 29 22 TOD 9:27:13 CK 8E3DED0D
CAUSE: #16 - NORMAL CALL CLEARING

DCH 9 UIPE_OMSG CC_RELEASE_REQ REF 000000B9 CH 29 22 TOD 9:27:13 CK 8E3DED0E

DCH 9 UIPE_IMSG CC_RELEASE_CONF REF 000000B9 CH 29 22 TOD 9:27:13 CK 8E3DED68
CAUSE: #16 - NORMAL CALL CLEARING
======================================================

As you can see, without #, there's a 16 seconds delay, during that time I've been capturing in the destination end and there's no traffic.
With # the call reachs the destination without delays.

Any thoughts about this? How could I solve this problem? We need to call without # between PBXs. What do you think about changing EOD timer of this DCH?

Thank you everyone.

 

[jose.marti]

Try OVLS NO

 

[AvayaHE]

Check your Routing script
Guess something wrong

ADAN DCH n
CTYP MSDL
CARD XY
PORT 1
DES uuuuu
USR PRI
DCHL 7
OTBF 32
PARM RS422 DTE
DRAT 64KC
CLOK EXT
IFC ISGF
PINX_CUST 0
ISDN_MCNT 300
CLID OPT0
CO_TYPE STD
SIDE NET
CNEG 1
RLS ID **
QCHID YES
RCAP COLP NDI CCBI CCNI PRI DV3I CTI QMWI
PR_TRIGS DIV 2 3
CNG 2 3
CTR1 2 3
PR_RTN NO
MBGA NO
OVLR NO
OVLS NO
T310 120
T200 3
T203 10
N200 3
N201 260
K 7
********************************************************************************
ROUTE DATA BLOCK CONFIGURATION
********************************************************************************
>LD 21
PT1000
REQ: PRT
TYPE:RDB
CUST 0
ROUT xxx
TYPE RDB
CUST 00
DMOD
ROUT xxx
DES
TKTP TIE
NPID_TBL_NUM 0
ESN NO
CNVT NO
SAT NO
RCLS EXT
VTRK NO
NODE
DTRK YES
BRIP NO
DGTP PRI2
ISDN YES
MODE PRA
IFC ISGF
SBN NO
PNI 00001
NCNA NO
NCRD NO
CTYP UKWN
INAC NO
ISAR NO
CPFXS YES
DAPC NO
INTC NO
DSEL VOD
PTYP DTT
AUTO NO
DNIS NO
DCDR NO
ICOG IAO
SRCH RRB
TRMB YES
STEP
ACOD 207
TCPP NO
TARG 01
CLEN 1
BILN NO
OABS
INST
ANTK
SIGO STD
ICIS YES
TIMR ICF 512
OGF 512
EOD 13952
NRD 10112
DDL 70
ODT 4096
RGV 640
GRD 896
SFB 3
NBS 2048
NBL 4096
IENB 5
TFD 0
VSS 0
PAGE 002
VGD 6
DRNG NO
CDR NO
VRAT NO
MUS NO
FRL 0 0
FRL 1 0
FRL 2 0
FRL 3 0
FRL 4 0
FRL 5 0
FRL 6 0
FRL 7 0
OHQ NO
OHQT 00
CBQ NO
AUTH NO
TTBL 0
ATAN NO
PLEV 2
ALRM NO
ART 0
SGRP 0
AACR NO
********************************************************************************
TRUNK DATA BLOCK CONFIGURATION
********************************************************************************
>LD 20
PT0000
REQ: PRT
TYPE: TNB
TN
7 1
DATE
PAGE
DES
DES
TN ppp 01
TYPE TIE
CDEN SD
CUST 0
TRK PRI2
PDCA 1
PCML A
NCOS 0
RTMB nnn 1
B-CHANNEL SIGNALING
TGAR 0
AST NO
IAPG 0
CLS UNR DTN WTA LPR APN THFD
P10 VNL
TKID
AACR NO
DATE

 

[KCFLHRC]

Try setting FLEN to 0, then it should route immediately

 

[TechDown]

Guys, I could fix the problem.

The issue was in siemens side. I had to set it's overlap options to 5 digits. Now when Nortel dials without # the call reachs Siemens end without delay.

I dont really understand but its ok. Now it works.

I want to thank all of you for ur help and time.

 

[bignose21]

Not sure why you are still suggesting routing changes when he has a flen of 5 call routes instantly you see the setup message. I would say make sure both ends are overlap send/receive set to off so call is passed enblock. Either way the settings for overlap need to agree at both ends so if one is send the other must be receive.

 

[KCFLHRC]

The FLEN of 5 means the Nortel will wait for all 5 digits before routing the call. A Flen of 0 will route the call on the first digit. Just a suggestion, seems he has it fixed anyway.