Better way to reroute an internal call?

[Tommer Catlin]

I have one way to do reroutes with h323 gateways.  Its kind of a pain, but it works.

Customer has a cluster, but with some remote locations that are h323 gateways.  I have a pattern that says:

450XXXX  go out this H323 gateway.

But if the h323 gateway is down, I need to reroute this call to the PSTN locally.

I create a route group/list.   Priortized the list to first hit the H323 gateway.  If its not available, the call goes to the next on the list, which is then manipulated at the RL/RG setting to change to the PSTN 5551212XXXX and dials out.

Is there a better way to do this?   

CUCM 6.1.4

[asandborgh]

From your description what you are doing makes sense.

  Curious though, where is the pain?

HTH,

Art

[Tommer Catlin]

The problem is amount of work it is to create this.

30 remote sites.

30 different route route rl/rgs to accomplish this

Site A:

IP phone dials Site B  450XXXX   connects to h323 gateway

If H323 is down, it will then need to reroute to PSTN to complete the call (its local gateway)

I have 30 sites.

451XXXX

452XXXX

etc.

[asandborgh]

After your answer you should definitely look at AAR.  It was ma

de specifically for this functionality.

Cheers!

Art

[asandborgh]

One more question - the title of this post indicates you want to re-route an internal call, but your description indicates TEHO with local PSTN fallback (I think).  Does the call in the first case stay inside your CUG or hop off to the PSTN at a remote office?  If it is a true internal reroute then you might want to use AAR.

[Tommer Catlin]

AAR only works with CAC and you cant use CAC with h323.  Only with Gatekeepers

[asandborgh]

If you have a true hub and spoke network where your cluster is the hub you can still use CCM CAC, but considering most are

MPLS you are very likely correct.

Good catch!

Art

[asandborgh]

Actually though my last post was not right either - AAR is bandwidth based and NOT for a full failure of the WAN where the branch would be in SRST, only oversubscription of the bandwidth.  Your solution is the correct one for the scenario.

Thanks again,

Art