Can you change names of Route List, Route Groups etc...

[wilson_1234_2]

Can you change the names of componenets in the dial plan without disturbing the associations within the config?

For example if I have:

Branch Route Group

     Test Route List

          Branch Route Pattern

Can I change the name of Test Route List to Branch Route List without disturbing the memberships, or does Branch Route List have to be created sperately and added to everything, then remove Test Route List?

I am thinking the latter is true.

[Chris Deren]

Yes, the updated name change will propagate in database and all depended entities will reflect it.

Chris

[wilson_1234_2]

Thanks Deren,

I have some follow up questions along these same lines. Our dial plan is a mess, a result of having a third party manage the system. Each person has named CSS and paritions differently, grouped things differently and it is growing into a bigger and bigger problem. It is harder to follow call paths with the way it is now.

We have a hub site with seven branches. Some branches have route lists named for the branch, others are grouped together in a global RL, some things are in several different places.

I have all of the route patterns\lists\groups documented and I would like to get this more into a best practice plan.

My first question is, if there is a route list that does not have a route pattern or route group associated to it, would this be the only place a potential link could exist to it?

Is it ok to delete the RL if it does not have a route pattern in it, or not tied to a route group ?

[Chris Deren]

If route list is not referenced by a route pattern it is not in use then and can be deleted, also if it does not point to any roue group(s) it does nothing.

Chris

[wilson_1234_2]

Thanks again Chris,

As I mentioned, our route plan is a mess and I would like to organize it to make everything easier to follow.

We have a SIP implementation with two CUBE routers, one in HQ site, one in DR site. All calls for all branches are inbound and outbound via Round Robin through the CUBE router, then routed across MPLS to the respective branch.

It was not originally this way, each branch originally had their own respective PRI, so each site (HQ and DR included) each had their own separate Route Group. When we migrated over to the SIP, depending on the engineer that worked on it, had a different scheme, so this is how it has gotten unorganized.

We have several route groups names with the two CUBE routers. Route list names are not consistent per branch and partitions are a mess as well.

I believe it should be relatively easy to organize it without too much interruption.

Is there a rule of thumb or best practice for this type of config from the organization standpoint?

For example, there are several route group names that have the same gateways in them (the two CUBE routers)

Since everyone is using the same two gateways, is there any benefit to keeping a per branch Route Group, or is it better to have a single Route Group name and have everyone use the same RG?

Question two, once the RG is determined, if a change is made to a branch RL, RG or RP, does the gateway need to be reset?

[chrisnoon11]

Hi wilson,

What I did when faced with this transition from local PRI's to centralized CUBE GW's, was to start using a single RG but keep separate RL and RP.  This way you can cut down on unnessary RG's, but still maintain flexiblity when it comes to digit translations, prepending, etc for different branch offices. 

And no, changes to RL RG and RP's do not require resets of the individual gateways.  The only exception I can think of might be if you have a RP pointing directly at a GW (instead of a RL)... that might automatically reset the GW, but I'm not sure.  But as far as I know, you should not need to manually reset a GW under these circumstances.

Hope that helps,

Chris

[Chris Deren]

Right, if there are 2 SIP trunks and they are to be load balanced then all you will need to access them from any location is single Route Group and Route List. There should be no reason to have site specific RG, RL if they ultimately point to the same centralized trunks.  Delete all site specific route lists and route groups that point to these trunks and point the route patterns to the central RL.  Simple as that.

Chris