Translation pattern for incoming calls to external pilot numbers

[dan.letkeman]

Hello,

I have a scenario where I would like to translate all calls from our internal locations going to our external pilot numbers back to our internal hunt groups.

eg. internal user from location a calls the pilot number for location b instead of calling the internal extension for location b.

I have setup a translation pattern for one location so when they call an external number of a certain building that it translates to the internal hunt group and all is working well.  For example

Location A(5551111) calls the pilot number for Location B(5552222)

Translation pattern is as follows

Translation pattern: 95552222

Partion: location_a_phones_pt

calling search space: location_a_phones_css

called party transformation mask: 8200 (hunt group for location b)

So with this, when location a calls location b's external pilot number, it does not route out the pri and back into the pri.

So my problem is that I don't want to have to create a translation pattern for each location (there are 15 of them) to each location.  That would be hundreds of translation patterns.  What type of calling search space / partitions or translation patterns would you suggest to minimize this?

Thanks,

Dan.

[Gajanan Pande]

Dan,

I agree with you about creating 15*14 = 210 Translation pattern to meet this requirement but few points here from my side..

1. Does all the sites need to dial all other 14 site numbers ? If not, then it can reduce the number of translation patterns.

2. Why cant users be educated to dial internal numbers ( instead of external ) for inter-site pilot numbers ? May be printed dial-list at each user's desk can ease the job.

3. If above are not the options, then I am affraid there is no escape from the admin overhead.

GP.

Pls rate helpful posts by clicking on stars below the post !!

[dan.letkeman]

1.  Yes they all dial the other 14 numbers at some point, some more than others.

2.  They can and will be educated to dial internal numbers, but the nature of the staff is to always do what they remember.  Change is always hard and for people that don't call alot, they will and have been dialing pilot numbers.  This is still even if they have a printed list.  I won't go into this anymore as it is never ending and there is no logical solution for it.

3.There has to be a way, I'm sure I am not the only one who has converted 15 buildings to a unified system......

Perhaps something on the gateway, re-routing the call back to call manager?  That way calling search spaces and partitions would not be a limitation....?

[Jaime Valencia]

If they're all unique DNs within your organization can't you just create one TP for each and place them all in a common partition anyone can reach??

HTH

java

If this helps, please rate

www.cisco.com/go/pdihelpdesk

[dan.letkeman]

That is what I was wondering....So create a partition, add that partition to the css of each location,then create the TP and put it in that newly created partition?

[Jaime Valencia · Accepted solution]

Yeah, if they all dial the same DNs in all locations, and they will reach the same internal DN via the TP, I don't see why you would need to create 14 TPs for each location if they're all going to do the same thing but just differ in the fact they will be in a local partition.

One unique TP for each DN, all in a global partition anyone can reach, and you still retain control of who they will end up calling via the called party transformation pattern and the TP CSS.

HTH

java

If this helps, please rate

www.cisco.com/go/pdihelpdesk

[dan.letkeman]

Ok, this is where I run into a problem.  I have tried this, but when I do, the call cannot be completed.

Here is what I think the problem is

The caller from location a is calling location b.  dials, 9, gets the outside dialtone and then dials 5552222.  The TP I have might be wrong but is as follows:

Translation pattern: 95552222

Partion: location_a_phones_pt

calling search space: location_a_phones_css

called party transformation mask: 8200 (hunt group for location b)

I think there is an issue with the outside dial tone number being in the mix.

It all works fine if I just have the pilot number not including the "9"  eg  5552222.  But as soon as I add the 9 then the call cannot be completed becuase it over laps with the 9 being used for outside dialtone for every other outgoing call.

This is why I was thinking that something on the gateway where the PRI resides might be a better solution.  This way I could match the number exactly and then point it back to CUCM.

[dan.letkeman]

Ok, so I tried adding something on the gateway and that did not work either.  Anyone else have any ideas on what to do in this situation?

Seems like a simple problem, but the solution is becoming complex.

[Dennis Mink]

Dan,

I am with Java on this one. In fact I have deployed a similar setup in the past, to force calls Onnet for external number ranges. In that particular case, I have used Translation patterns.

have you used the Dialed Number analyzer at all, to see what patterns get hit when 95552222 is dialed. I would advise you to do this.

personally I would not do any digit manipulation on your gateways, because this way what you will essentially be doing is hairpinning the call, on your gateways,  which is unnecessary. 

I you can, please provided us with the output of the dialed number analyzer

[dan.letkeman]

Figured out it was the order of my partitions that was causing the issue.  Now creating one TP per number in a partition that everyone has access to solves the problem.