[cisco-voip] Local Route Route Group Design

[Justin Steinberg]

UCM 10 has changes in store to address this local route group limitation.


On Fri, Nov 15, 2013 at 11:35 AM, paul dial <dialp at ucar.edu> wrote:

>  Yes, CER could be an issue.   I think you would have the same issue with
> redundancy in the RL - maybe break those patterns out separately?
>
> FWIW,  I'm also interested in your original question,  "Has there been any
> thought of a Local Route List feature in addition or replacing the local
> route group option?"   I don't understand why Local Route Groups were
> chosen and not Local Route lists?
>
> --paul
>
>
>
>
> On 11/15/2013 8:29 AM, Heim, Dennis wrote:
>
>  Thanks for the reply. I think the only issue with that, is if CER is in
> play from a failover/redundancy perspective.
>
>
>
> *Dennis Heim | Solution Architect (Collaboration)*
>
> World Wide Technology, Inc. | 314-212-1814
>
>
>
> *PS Engineering: ** Innovate & Ignite.*
>
>
>
>
>
> *From:* cisco-voip [mailto:cisco-voip-bounces at puck.nether.net<cisco-voip-bounces at puck.nether.net>]
> *On Behalf Of *paul dial
> *Sent:* Friday, November 15, 2013 10:14 AM
> *To:* cisco-voip at puck.nether.net
> *Subject:* Re: [cisco-voip] Local Route Route Group Design
>
>
>
> Hi Dennis,
>
> I ran into a similar situation and ended up moving the backup from the RL
> to the RG.  For example, our Local Route Group is defined in the Device
> Pool (DP).  So DP SFO would point to RG_SFO.   RG_SFO would contain the
> primary destination for SFO and also a secondary location (in some cases we
> have more than two members in the RG).  Likewise DP NYC would point to
> RG_NYC which would contain the primary destination for NYC and any back up
> locations.
>
> I believe that will allow you to keep just a single RP for \+! and your RL
> would look like RL_LocalCalls  and just have the  Standard Local Route
> Group as a member and uses the RG that is defined by the DP.   Not sure if
> this is the best way of doing it or what the exact implications are of
> moving the redundancy from the RL to the RG.
>
> --paul
>
>  On 11/15/2013 5:45 AM, Heim, Dennis wrote:
>
> 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.*
>
>
>
>
>
>
>
>
>  _______________________________________________
>
> cisco-voip mailing list
>
> cisco-voip at puck.nether.net
>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20131116/9e7b5d84/attachment.html>