I have users dialing an on-net number to another site and they get the "ring out" message on their phone, but the user gets dead air and the call is not connected. This does not happen every time, only sporadically. Sometimes 10 times in a row, then not for another two days.
This only seems to be happening with remote users calling other sites, or back to the main building over WAN links. The fact that the user is getting the "ring out" tells me that Callmanager is finding a match and routing it accordingly. The Callmanager is at our main site, along with our Unity server and all remote sites have a frame-relay T-1 back to the main site.
Before looking deeper into call tracing, QOS, bandwidth, queuing, device weights, etc. I was wondering if anyone has seen this before and possibly found a quick fix. I have tried to replicate at the main building, but without success. This will be very hard to troubleshoot as it only happens so often, and I am not at a remote site. Possibly an RTP bug?
See if DSPs come back as being ALIVE. In the summary above it will say total on-board DSPs and an amount. The # of ALIVEs should equal the # of on-board DSPs. If these don't match then theres a problem DSP.
But all the DSPs could be alive, and there could still be a DSP issue effecting the calls. A little harder to troubleshoot though. need to place multiple calls and watch what DSPs are active on working calls and keep track of working DSP ids versus non-working ones. (show voice dsp, show voice call summ are useful for this).
Also, turn on logging on the gateway/router or look at existing logs if logging is on to see if there are any errors / warnings. DSP problems might have log entry depending on type of problem.
Not yet. I turned on the Quality Reporting Tool to try and see a trend for when this was happening, but I haven't been able to isolate it. Have you been on the router when trying to call out and see the line go off-hook? I usually do a "sh voice port sum" and a "sh voice call sum" to see the FXO ports and what they're doing. If it's not even getting there it's a gateway issue with the call routing, gateway registration, or possibly even a hardware failure.
My problems weren't exclusive to a specific port, but to any type of calling (on-net, long distance, local, etc.)
If you find anything out, let me know. They may be related. I'll keep plugging away on my end and post if I find out any new news.
Slowly but surely, I am narrowing the issue down. Seems it's only affecting calls that come over the WAN link and go to our PBX for call routing (on-net VOFR system and commerical long distance). The call is going through our 6509 with a WS-X6608-T1 blade (Digital Access Catalyst 6000 T1 VoIP Gateway). We have a single port connected to a T1 card in our Nortel PBX giving us 24 channels for these types of calls.
Does anyone know of any issues with this type of setup or specifics when setting up the gateway in Callmanager? I think there's a disconenct somewhere that flakes out from time to time that I need to contain. I'm going to troubleshoot the T1 port from the network end, and have a telecom guy look at the T1 from teh PBX end and make sure we've got all channels up and everything is good.
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.