I have a user who has mentioned that when he dials certain types of calls (long distance in this case) he gets disconnected after 5 minutes of call time. I have been looking in a number of places with no answers that fit my situation.
Phone: 7965 w/ SCCP45.9-2-3S
CUCM: 188.8.131.5200-9 (Pub w/2 subs)
Network Backbone: Juniper 4200/3200 series switches (please don't get me started, it was not my choice)
Gateway: (2) Cisco 3845 ISRs w/ a total of 4 T1 trunks to a Nortel SL100 PBX which has a trunk to the Long Distance carrier
Calls VoIP to VoIP test fine and do not disconnect.
Calls VoIP to SL100 test find and do not disconnect.
Calls VoIP to Long Distance drop after 5 minutes.
When calling Long Distance with other VoIP phones in the office, the call does not drop.
Currently the issue is isolated to two physical phones with one shared line.
There are zero firewalls between the phones, CUCM servers, or the gateway routers.
Because of the test calls, I feel I can safely rule out the backbone infrastructure.
I haven't rulled out a setting in CUCM yet, but I didn't see any differences between my personal phone and the phone in question. I don't have this issue with my phone. My phone is registered with a different subscriber, but the other phones tested in the office with the phone in question are registered on the same subscriber as said phone.
I've rulled out the routing and gateways as if it was an issue with them this problem should apply to everyone instead of just one user.
Any thoughts or ideas will be considered.
Can you attach the configuration on the gateway you are using and that is in the path of the call disconnects. and produce some signalling debugs?
Is it exactly 300 seconds and can you reproduce?
Please remember to rate useful posts, by clicking on the stars below.
The call was 305 to 306 seconds.
I did some additional troubleshooting on Tuesday by assigning the line (6366) to my desk phone and was able to reproduce the error. I did not get a chance to dig for logs. The basic logging in the gateways didn't reveal anything either.
The gateways are both MGCP configured and has just enough VoIP configuration for that feature. Otherwise, we have OSPF and a SSH access list.
Also, I found out on Tuesday that we have a device called a Telewall that goes between our SL100 and the long distance carrier. Therefore, my SL100 switch tech was to spend today looking into that device and speaking with the indvidual(s) who control said device.
For some education on my part, what are some debugging commands to enable on the gateways for specifically tracing this problem? I'm not keen on turning on all debugging on production devices.
We JUST started having a VERY similar problem at one of our satellite offices. All calls in or out via the PRI end at "5 minutes" (the log shows 299 seconds). We are really mystified on this (so far). I tried replacing one soft-phone (CIPC) with SIP instead of SCCP – no change. All the rest of the phones in the environment are SCCP 7940’s.
I opened a ticket with the carrier (TWTeleCom) and they confirmed the call ending at 5 minutes with a “Network out of order” message, which is what I see as well. I see the messages below at the end of every call (the message is verbatim except I replaced my calling number with ##########).
Nov 26 09:04:23.308 est: %ISDN-6-DISCONNECT: Interface Serial0/3/0:0 disconnected from ##########, call lasted 299 seconds
Nov 26 09:04:23.308 est: ISDN Se0/3/0:23 Q931: TX -> DISCONNECT pd = 8 callref = 0xA08B
Cause i = 0x80A6 - Network out of order
Am debugging currently on the router with:
debug ccm-manager backhaul packets
debug mgcp packets
debug isdn q931
debug voip vtsp session
debug voip ccapi inout
debug cch323 all
debug ip tcp transaction
In my situation, the probem was the TeleWall that I mentioned. In this device it has the capability to see the caller number (because of caller ID) and based on that number, it can limit the length of the call based on the type of signaling.
In our case, the number was flagged as a modem and voice (analog) calls would get cut off at 300 seconds while digital calls would be allowed to continue. We had to talk to the office that controled this device and fix the issue.
One recurring suggestion I've seen (and hopefully you've seen as well) is that people with firewalls in the path of the signal flow would run into this similar issue.
One idea is possibly to run a BERT (Bit Error Rate Test) with the telco and make sure you aren't facing any sort of signal loss.