[cisco-voip] Local Route Route Group Design

[Heim, Dennis]

Has there been any thought of a Local Route List feature in addition or replacing the local route group option?

Here is my use case, if I am missing something, please let me know...

Dial Plan is E.164. We have translation patterns that normalize the Called number. From there the calls match at \+.! Route pattern the sends the call to the gateway.  The route list assigned to that route pattern includes the following members: (1) Standard Local Route Group (2) HQ-PSTN-RG.

The use case is this, what happens when we have regional or different secondary destinations? If we had some sites in the western US, that if their local circuits were unavailable we wanted the calls to go through a San Francisco regional site (SFO-PSTN-RG). At the same time, we had some sites in the eastern US, that if their local circuits were available we wanted the call to go through a New York regional site (NYC-PSTN-RG).

As it is with local route group's, we would need to have multiple route pattern's \+.! Placed in different partitions, and assigned a different route list. For our example we would have the following:

*         Route List 1 (SFO)

o   Standard Local Route Group

o   SFO-PSTN-RG

*         Route List 2 (NYC)

o   Standard Local Route Group

o   NYC-PSTN-RG

In order to feed the local route group's, we would need  separate PSTN translation patterns (9.@), with separate partitions and calling search spaces to feed  the different \+.! Route pattern. Is that how others are handing this scenario?

If we had a local route list instead of local route group, then that could be specified on the device pool, and we could have one set of patterns and be able to easily manage multiple failure path's.

Thoughts?

Dennis Heim | Solution Architect (Collaboration)
World Wide Technology, Inc. | 314-212-1814

PS Engineering:  Innovate & Ignite.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20131115/e3ebfdaf/attachment.html>