Outbound calls disconnect after 30 seconds on their own

[SherWat]

CS1000 7.6
Calling to an external number directly from a desk phone works.
Calling to an external number from a SIP endpoint disconnects after 30 seconds after called party answers.
I set up DCH outbound message capture

enl msgo 14
OUTPUT TARGETS: TTY
.
DCH 14 OMSG SETUP REF 00000007 CH 21 7 TOD 12:53:33
CALLING #:7057257025 NUM PLAN: E164/NATIONAL / NPA
CALLED #:7057304744 NUM PLAN: E164/NATIONAL / NPA

DCH 14 OMSG CONN ACK REF 00000007 CH 21 7 TOD 12:53:37

DCH 14 OMSG DISC REF 00000007 CH 21 7 TOD 12:53:41
CAUSE :NORMAL CALL CLEARING

DCH 14 OMSG REL COMP REF 00000007 CH 21 7 TOD 12:53:41
****************************************************************
DCH 14 OMSG SETUP REF 00000006 CH 21 6 TOD 12:53:49
CALLING #:7057257025 NUM PLAN: NUM UNKNOWN/UNKNOWN (UNKNOWN)
CALLED #:7057304744 NUM PLAN: E164/NATIONAL / NPA

DCH 14 OMSG CONN ACK REF 00000006 CH 21 6 TOD 12:53:53

DCH 14 OMSG DISC REF 00000008 CH 21 8 TOD 12:54:11
CAUSE :NORMAL UNSPECIFIED

DCH 14 OMSG REL COMP REF 00000008 CH 21 8 TOD 12:54:11
​

The difference is shown in RED.
I am not sure if I need to change something in the route, the trunks or within NRS.

Thanks.

 

[bignose21]

In 7.6 you can alter the calling number using LD 86 and the CMDB, can then add that table to RLI or RDB etc.

You could say do the following if I don't mention a prompt just press enter

REQ new
CUST 0
FEAT cmdb
TBNO xxx (you set the table number)
RLNO 0 (Rule number 0-15)
MNUM clng
MID 705
MTON ukwn
RNPI e164
RTON natl

In an RLI or an RDB you set the table number against the CTBL prompt

 

[SherWat]

Thanks for this suggestion. I did this, but it made no change.
What I find odd is that the connection goes through so I don't understand why it would just disconnect after a successful connection.

 

[SherWat]

The call also disconnects when calling a 4 digit extension - see call trace below:

ORIG VTN 148 0 00 00 VTRK IPTI RMBR 2 1 INCOMING VOIP GW CALL
FAR-END SIP SIGNALLING IP: 10.35.51.103
FAR-END MEDIA ENDPOINT IP: 10.35.51.10 PORT: 21436
FAR-END VendorID: Tangerine-oSIP-UA/1.06
TERM VTN 248 0 03 04 KEY 5 SCR MARP CUST 0 DN 2215 TYPE 1230
SIGNALLING ENCRYPTION: INSEC
FAR-END H.323 SIGNALLING IP: 10.35.1.15
FAR-END MEDIA ENDPOINT IP: 10.35.5.149 PORT: 5200
FAR-END H.323 SIGNALLING IP: 10.35.1.15
FAR-END MEDIA ENDPOINT IP: 10.35.5.149 PORT: 5200
MEDIA PROFILE: CODEC G.711 MU-LAW PAYLOAD 20 ms VAD OFF
RFC2833: RXPT 101 TXPT 101 DIAL DN 2215
MAIN_PM ESTD
TALKSLOT ORIG 19 TERM 24 JUNCTOR ORIG0 TERM0
QUEU NONE
CALL ID 300 30512


---- ISDN ISL CALL (ORIG) ----
CALL REF # = 385
BEARER CAP = VOICE
HLC =
CALL STATE = 10 ACTIVE
CALLING NO = 7057257025 NUM_PLAN:UNKNOWN TON:UNKNOWN ESN:UNKNOWN
CALLED NO = 1072215 NUM_PLAN:UNKNOWN TON:UNKNOWN ESN:UNKNOWN

​

 

[kyle555]

You need a SIP trace.

30/32 seconds is a telltale sign of some signaling message not getting back.

Like a ACK to the 200OK never happened for example

 

[SherWat]

Are there any timer settings within the CS1000 / NRS / Sig Server that would cause this to happen?

 

[bignose21]

I would tend to agree with SherWat about looking at the SIP leg or at least include the Incoming and outgoing Messages for both the ISDN and the SIP in your post

 

[SherWat]

I have attached a wireshark capture.

 

[bignose21]

So to me it looks like the 200 Ok is sent out to IP address ending .103 but it doesn't send an ACK back, so the IP Address ending .15 keeps sending the 200 Ok every 4 secs or so and gives up at 32 secs after original 200 OK and sends a BYE.