PSTN calls over ICT Trunk drops at exactly 10 mins 20 secs.

Unanswered Question
Jan 14th, 2010
User Badges:

We have two clusters -cluster with MGCP gateway PRI is 7.1.3.31900-1 (Cluster A) and our cluster handling our contact center is 5.1.3.7000-5 (Cluster B).  1 in 4 calls going outbound from Cluster B through non-gatekeeper ICT to Cluster A disconnects with a fast busy immediately and exactly at after 10 minutes and 20 seconds.  This is a consistent pattern.  This only happens with outbound calls through the PRI.  Inbound and outbound calls between the cluster is unaffected.  When I do a packet capture off the phone, I can see that as soon as the my would disconnect with a fast busy (7961), there is still an RTP connection with the mgcp gateway but only 1 channel.  The PSTN phone on the other end is apparently still retaining the channel and finally drops off after 5 minutes.


This is what I've done and the results are still the same:

a. Made both ICT trunks use MTP.

b. Changed route pattern call classification as OnNet and OffNet

c. Upgraded firmware on the phone.


Situation still remains the same.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (1 ratings)
Loading.
christopher.con... Fri, 01/15/2010 - 09:21
User Badges:

Try looking under service parameters for a timer that is set to 620 seconds. Then change it and see if the call drops at the new time you set. If it does you can then start troubleshooting whatever that timer does as a starting point for your issue.

Ming Yuan Chiu Fri, 01/15/2010 - 10:00
User Badges:

I tried that too, but it there are no settings with that parameter.  Here is a debug off the router if this helps..



callref =  0x65D3

024635: Jan 14  18:18:31.021: ISDN Se0/1/0:23 Q931: TX -> SETUP pd = 8  callref = 0x65D3

             Bearer Capability i = 0x8090A2

                         Standard = CCITT

                         Transfer Capability = Speech 

                         Transfer Mode = Circuit

                         Transfer Rate = 64 kbit/s

             Channel ID i = 0xA98392

                         Exclusive, Channel 18

             Calling Party Number i = 0x2183, 'XXXXXXXXXX'

                         Plan:ISDN, Type:National

             Called Party Number i = 0xA1, 'XXXXXXXXXX'

                         Plan:ISDN, Type:National

024671: Jan 14  18:18:34.225: ISDN Se0/1/0:23 Q931: TX -> CONNECT_ACK pd = 8  callref =  0x65D3

---  After 10 minutes and 20 seconds --

028114: Jan 14 18:28:57.707: ISDN Se0/1/0:23 Q931:  TX -> STATUS pd = 8  callref = 0x65D3

            Cause i  = 0x829E - Response to STATUS ENQUIRY or number unassigned

            Call  State i = 0x0A

--  my 7961 already dropped the call but called party is still on the line for 5  minutes until… --

029719: Jan 14  18:33:34.197: ISDN Se0/1/0:23 Q931: TX -> DISCONNECT pd = 8  callref = 0x65D3

            Cause i = 0x829B - Destination out  of order

James Hawkins Tue, 03/01/2011 - 02:23
User Badges:
  • Gold, 750 points or more

Hi,


Did you ever resolve this issue? - one of my customers has a similar issue where calls across an ICT trunk drop after 620 seconds.

Ming Yuan Chiu Tue, 03/01/2011 - 13:18
User Badges:

Wow, this was a really old problem but I did figure it out eventually.  It was simply that the ICT Trunk's "Remote Server IP Configuration" was not set identically to it's remote ICT device pool. Most people run into this problem when they have two clusters with 3+ subscribers.  Example:


Side A - Registered with Device Pool set for CM: 10.1.1.1 & 10.1.1.2

Remote Server 1: 11.1.1.1

Remote Server 2: 11.1.1.3


Side B - Registered with Device Pool set for CM: 11.1.1.1 & 11.1.1.2

Remote Server 1: 10.1.1.1

Remote Server 2: 10.1.1.4


Correct the remote server ip address configuration in the ICT trunk and reset the to have it register again and you should no longer encounter dropped calls or intermittent fast busies.

James Hawkins Tue, 03/01/2011 - 16:08
User Badges:
  • Gold, 750 points or more

Ming,


Thanks for responding to my question. I will see if this fix works for my customer

Actions

This Discussion