I have 2 clusters, CCM 3.3(3)sr4a, and I want to route local calls to the respective cities over the WAN as 1st choice, LD 2nd. I've set up a Route List, ICT as 1st choice, local LD T1 as 2nd. When I call the number to the far end LATA, I get busy. If I take out the ICT Route Group, the call places fine, out the LD T1 locally. The local circuit at the far is not turned up yet, so the call couldn't place out there anyway, but I thought this would be automatic, that if the far-end circuit was down, or busy, the call would route out of my local LD gateway.
Only if the locally registered gateways in the first route group is down (gets unregistered or is out of resources), CallManager will select the next route group in the route list, and route the call through that gateway in the second route group. So, what you are experiencing is correct, I guess! I have tested this and it works the same way. If the remote network is down and I get a busy, thats it, the call cannot be completed through the alternate route.
You're missing the point. If the "far-end" gateway is down, and I can't take advantage of having a gateway at that location, then I want the call to go out my local Long Distance gateway. In my case the call was returning a busy even thought the 2nd route group, the LD local gateway, was available. It turns out that if I build these gateways MGCP, it works fine.
So you have two route groups, RG1 has ICT, and RG2 has LD T1,correct? Both in RL, RG1 first and then RG2.
Since the "far-end" local gateway which is down is not registered to this CallManager, this CCM will think that the path is available (since ICT is up), and send the call through the ICT. The remote CCM cannot route route the call bcuz that local gateway is down, and will send a disconnect with cause code to this CCM. What is the disconnect cause code?
Based on this disconnect cause code, you can configure CCM to route the call to the next device in the Route List.
Check these service parameters:
Stop Routing on Out of Bandwidth Flag -- default flase
Stop Routing on Unallocated Number Flag -- default true
Stop Routing on User Busy Flag -- default true
If your disconnect cause from the remote cluster is not one of these cause codes, then I am not sure if you can have the LD T1 reroute the call.
Thanks, I did not consider Service Parameters in this nor did I discover the cause code involved. I believe you may be on to something. I've converted the far-end gateway to mgcp and it works fine, and you are correct on the topology.
Why it is working with MGCP is because remote CCM has complete knowledge of the gateway and the T1 channels on the gateway if it is a MGCP gateway. Since the local circuit is down (in other words the T1 channels on the mgcp gateway are down), remote CCM knows that the gateway doesn't have resources to route the call, and will reject the call from the first CCM. The first CCM seeing that the call is rejected by the other end of the ICT, will use the next route in route list.
I was considering the case that you have a h323 gateway at the remote side. In that case, the remote CCM doesn't have enough knowledge about the T1 channels on the h323 gateway (in this case that the local circuit has not turned up). It only knows that the h323 gateway is registered to it, and assumes all it fine. So, it will send a ok to the first CCM via the ICT, and ask it to place a call to the h323 gateway. When the call is forwarded to the remote h323 gateway because no T1 channels are available, the call fails.
Since the first route is already available, the first CCM will never use the next route in the route list. If the call were rejected in the first place, it would have used the second route in the route list.
I see you understand exactly what is going on in my situation. Since my original posting, I have turned up the remote gateway but I had to change it to h323 because the DS0's are T1 CAS ground-start. I suppose that my alternate routing is broke again. How do I re-route the calls now? Do you suppose that a far-end trace will yield clues that would help me work around this problem? What would I look for and what would I do with it when I found it?
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...