Toll Bypass-Intercluster Trunk Route List

[mwheinz]

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.

What am I missing here?

[pbarman]

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.

[mwheinz]

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.

Thanks for contributing to the forum!

[pbarman]

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.

Hope this helps!

[mwheinz]

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.

[pbarman]

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.

[mwheinz]

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?

Thanks for your insights!