[cisco-voip] Local Route Route Group Design

[paul dial]

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] *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.@ <mailto: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 <mailto: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/20131115/f93051cb/attachment.html>