Opposite of standard local route group?

[carlnewton]

Guys,

We all know about standard local route group - It allows you to create a single \+.! Route pattern, and make this accessible from the device calling search space to route all outgoing calls.  You set your route lists at a device pool level and the device automatically selects the "Standard locel route group" depending on whats configured in its device pool.  

This means anyone can log in anywhere and get a line out of their current local gateway.

I want the opposite.  I want users to ALWAYS use their home gateway - no matter where they log in.

Ideally I'd like a "standard local route group" setting on the users "User Device Profile" itself, but I'm not aware of anything like this existing.

The only way I can think to do it is to create a \+.! route pattern for every site, and make this accessible from the users LINE calling search space.

Any more elegant solutions out there?

[Vivek Batra]

Hi,

When you are saying 'anyone can login', I assume that you meant to say EM. Since in case of EM, LRG will be selected from device pool which is assigned to device, not to UDP, hence I believe that what you already mentioned is the most suitable option viz to keep that RP in separate partition and allign it with line level CSS. 

- Vivek

[carlnewton]

Hmm yes, thats what i was afraid of!

Its a bit of a pain creating a new calling search space and route pattern for every site.  It is what it is, I guess!

[Vivek Batra]

Hi dear,

Since our requirement is also opposite to what everyone like to have, hence this may result in bit more configuration.

Anyway I really appreciate that you have put your requirement in very clear and concise manner. This leads me to think that if we can have 'device pool' setting available on UDP as well and takes precedence over 'Device' (/device pool) settings to get the LRG configuration. If this configuration is available, user can have two device pool viz one assigned to UDP (applicable only during EM) and other device pool assigned to phone. LRG in UDP device pool will be users home gateway and in devices device pool, will be local gateway in reference to local phone.

When user roaming to another office and login to any phone using EM, device pool of UDP can be checked first (if configured) to get the LRG which will be referenced to users home gateway and all calls will be routed via home gateway instead of local gateway.

Doing so, we can have only one pattern \+.! accessible to all CSS and LRG can be selected either on the basis of UDP Device Pool (in case of EM) or devices device pool (without EM).

I will try to create this as an idea in community forum.

- Vivek

[carlnewton]

Hi Vivek, good idea! however i think having a device pool under the user device profile is not the best implementation.

this could lead to problems with things like location bandwidth manager, and the mobility function.

I think the ideal implementation is to have a new field under a users device profile to simply say:

-Default Standard Local Route Group

---Device pool controlled

---RG_A

---RG_B

---_RG_C

and so on.

That would certainly fix my issue!

[Vivek Batra]

Hi,

Thanks for sharing your inputs. I am going to add this as a feedback to Cisco community forum and will update this thread if there is any outcome.

- Vivek

[Ayodeji Okanlawon]

Carl, 

The reason why SLG was designed was to counter the similar thing you are asking for. While your scenario may be unique, this feature would not be beneficial to many. 

Think of a global company with sites all over the continent where users move between locations. Imagine if they have to use their local gateway for calls. 

In the says of CUCM 4.x we had to Configure route pattern per site etc and point to the local gateway. This was very cumbersome. 

SLG cane to make our lives easier.. But like I said you may have reasons why you want to do this and I am sure these are not users in different countries.. 

[carlnewton]

the users are in different countries actually.  And we have a requirement to maintain the correct calling number ID, so the call must always go out of the users home gateway no matter what site the call originates from (Since we are still using E1/T1 and we don't want to make any changes with the carrier)

Standard local route grooup wouldnt work for us in this scenario, so we will have to just make lots of route patterns as you say.

Thanks anyway for the input.