[cisco-voip] Question about Local Route Group feature

[Daniel Pagan]

“If a device pool doesn't have anything setup for Standard Local Route Group, when someone from that pool calls a route pattern referencing this Route List will it just smoothly go to option #2 or is there some gotcha i'm not grasping?”

Yes - CUCM attempts to get information on the SLRG once the call reaches RouteListControl. Once it fails to find the SLRG entry, RouteListCdrc sends the call to members of the next RG without any delay.

Hope this helps.

Dan

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ed Leatherman
Sent: Thursday, August 27, 2015 3:15 PM
To: Cisco VOIP <cisco-voip at puck.nether.net>
Subject: [cisco-voip] Question about Local Route Group feature

Hello!

I actually haven't had to make significant dial plan/gateway changes since local route group feature got introduced, starting to plan some bigger changes and think this might be a good tool for me to use.

Right now i'm thinking migration strategies for moving folks onto SIP trunk from PRI.

If I have a Route List that has:
1. Standard Local Route Group
2. Existing Route Group #1
3. Existing Route Group #2

If a device pool doesn't have anything setup for Standard Local Route Group, when someone from that pool calls a route pattern referencing this Route List will it just smoothly go to option #2 or is there some gotcha i'm not grasping?

My thoughts are to migrate folks by device pool and reuse my existing dial plan with new SIP trunks added using standard local route group feature and placed into existing Route Lists as the first option. Folks that have nothing set for standard local route group just flow through to the existing options.

This way I don't have as many weird transition route patterns/dial plans/etc. Eventually I'd get rid of the legacy route groups referencing PRI's and then i'd be smoothly (mostly) onto local route group paradigm, which appears to be the way to go anyway.


--
Ed Leatherman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20150827/685e8bb9/attachment.html>