I am currently having an issue with one of our sites recieveing incoming calls. We are running a h.323 gateway with 4 FXO ports for recieving calls from the PSTN. I ran some debugs and verified that the ports are recieving a signal when a call is coming in. I then ran a debuig voip ccapi inout to see if I could see anything but I am a bit new to this and can't quite understand the debug. I have attached a debug that is working for us and the one that is not. Can anybody see what the issue looks like?
Solved! Go to Solution.
Is this an intermittent issue for that site? I mean you have working and non working debugs from the same gateway? The working debugs are incomplete. As for the non working debugs, here is what I see:
// Ringback signalled on both call legs //
Dec 19 06:11:05.990: //284/B512CC6982BA/CCAPI/cc_api_call_alert:
Interface=0x2B7FF6B4, Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
Dec 19 06:11:05.990: //283/B512CC6982BA/CCAPI/ccCallAlert:
Progress Indication=NULL(0), Signal Indication=SIGNAL RINGBACK(1)
// PSTN call leg disconnects with cause value 16 which is normal call clearing //
Dec 19 06:11:41.750: //283/B512CC6982BA/CCAPI/cc_api_call_disconnected:
Cause Value=16, Interface=0x2BBA9F48, Call Id=283
I would suggest verifying if all 4 FXO lines are working fine or not. Have someone at the site plug each of the 4 analog lines into an analog phone and test incoming calls. That should help narrow things down hopefully.
Is it typical for a inbouind call to match to an outbound dial-peer?
here is dial peer 104 on my router:
dial-peer voice 104 pots
description Outbound 10-Digit Dial Peer
progress_ind alert enable 8
This dialpeer got matched because the call was coming in on port 0/0/0. That is one of the rules of dialpeer matching:
Is the issue consistently happening for the same port?
It's on all ports.
This issue began after we powered on a secondary CUCM after taking it down for a move. I then went in and removed the gateway and phones from even seeing the secondary CM and am still having the issue.
We cuurently have the FXO ports setup PLAR to extension 1209 which is a hunt pilot. I thought that may have been the issue but when I forward port 0/0/0 to my extension in the office, It still does not ring through. I did a debug vpm signal and did a sh voice call sum and stat when I call the port and am seeing the port recieving it.
Thanks for the info. In that case, let's look at the H323 debugs to see what's going on with the VOIP leg of the call:
debug voip ccapi inout
debug vpm signal
debug h225 asn1
debug h245 asn1
Place one incoming call and capture the debugs to a file. Upload it here for further review. BTW, do you see anything wrong with the replication? Any alarms in RTMT? Can you post the gateway config as well along with the UCM version?
UCM version 18.104.22.168
Now that you said something, I am seeing a replication error in RTMT.
On Wed Dec 19 10:42:54 EST 2012; alert DBReplicationFailure has occured. Counter Replicate_State of Number of Replicates Created and State of Replication(ReplicateCount) on node 10.122.1.201 has state value of 3. ReasonCode: Replication data transfer is bad in the cluster.
Would this cause just one out of many sites to have an issue? How would I look deeper into this?
Sorry, I am reletively new.
Thanks for your help.
The debugs are not complete. Can you capture them again from beginning till end? Also, the UCM version you gave is not valid. You can find out what version you are using by logging into the UCM admin page and it should display it right there.
As for replication error, yes, there is definitely a problem there which could be a contributing factor to this issue. Log into the CLI of the Publisher and post the output of "utils dbreplication runtimestate". Also, log into the Unified Reporting Tool GUI page and run the following reports:
Unified CM Cluster Overview
Unified CM Database Status
Upload those for me to review as well.
So after posting a few things, I realized that the outgoing dial peer that was being matched (1000) was the dial peer directed to the the subscriber CM. Since we were having replication issues with the Publisher and the subscriber, it was just not working.
As soon as I shut down that dial peer, I was able to get through.
Now that I have them up, I have to work on getting replication fixed. We have a feeling it may be ACL related on the router.
Thanks for all your help!!
Glad to hear that Jason, here are a couple of replication related docs (one of my own) which should help:
HTH. Please mark this post as answered.