[cisco-voip] running into the 128 voice translation-rule limit

Tue Jul 20 14:40:40 EDT 2010

Ed,
   Doing this in CUCM isn't going to make your life easier - it's
going to give you an even bigger dialing maze to deal/cope with.
You're really going to be best served by figuring out how to make
peoples extensions coincide with their DIDs, as opposed to continuing
down the path you're going now. There's no good solution to the mess
that's being created as you add more and more extensions, and your
configuration already sounds unmanageable.
    On one hand, yes your users might have to deal with having their
numbers changed, but on the other, won't they be happy when they no
longer have to remember different extensions from their DIDs? Wont
_YOU_ be happier? Troubleshooting will certainly be easier.

-Peter


On Tue, Jul 20, 2010 at 11:31 AM, Nick Matthews <matthnick at gmail.com> wrote:
> I wouldn't count on the 128 limit being raised.  Some people have hit
> this limit, but generally there is a 'better' way to to these types of
> things.  The main factor to take into account is that by increasing
> the limit you are increasing the PDD for every call ever made through
> a cisco gateway.  Thus, care is taken to make sure that the algorithms
> for dial plan searching is minimal to reduce delay.
>
> -nick
>
> On Tue, Jul 20, 2010 at 8:35 AM, Edward Beheler
> <ebeheler at tippecanoe.in.gov> wrote:
>> Several interesting ways of approaching the issue.  Looks like if I need for it to be easily manageable, I'll be doing this in CUCM.  I was hoping to keep it on the router, to have one less point of failure to worry about.  Maybe someday the 128 limit will be raised or removed.
>>
>> -----Original Message-----
>> From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Nick Matthews
>> Sent: Monday, July 19, 2010 7:10 PM
>> To: Ted Nugent
>> Cc: cisco-voip at puck.nether.net
>> Subject: Re: [cisco-voip] running into the 128 voice translation-rule limit
>>
>> As said, there is no easy way.  You can nest these so you get 128*16.
>>
>> Example (not exact commands)
>>
>> translation rule 1
>> rule 1 /1/ /2/
>> ..
>> rule 16 /16/ /2000/
>>
>> translation rule 2
>> rule 1 /17/ /2001/
>> ..
>> rule 16 /32/ /2002/
>>
>> translation profile 1
>> translate incoming 1
>>
>> translation profile 2
>> translate incoming 2
>>
>> dial-peer voice x pots
>> translation-profile 1
>> incoming called-number 1
>>
>> dial-peer voice y pots
>> translation-profile 1
>> incoming called-number 16
>>
>>
>> In this manner you map 16 incoming called numbers to a single
>> translation pattern, sharing it.  It sucks to configure but it buys
>> you a workaround.  This is where something like a gatekeeper,
>> centralized manager of some sort (CUCM), or sip proxy would do a good
>> job.
>>
>> As well, number expansion cuts at 512.
>>
>> -nick
>>
>> On Mon, Jul 19, 2010 at 5:25 PM, Ted Nugent <tednugent73 at gmail.com> wrote:
>>> Be careful with num-exp since as Shawn mentioned its global and does
>>> not discriminate. Num-exp 2123 5556611 could turn a simple call that
>>> included 2123 to something you did not intend.
>>> If a user were to dial for instance 918002123555 it would be turned
>>> into 918005556611555... I does work well for longer to shorter translations
>>> though like you mentioned in your original post (num-exp 4239761 8761) would
>>> be fine since there's an unlikely event that that pattern would
>>> be inadvertently altered
>>> However if this is CUCM rather then CME I would have CM handle
>>> the translations
>>>
>>>
>>> On Mon, Jul 19, 2010 at 5:00 PM, Shawn Wilson <macwired at gmail.com> wrote:
>>>>
>>>> Hi Ed
>>>> I have used the number-expansion feature on the router to get around
>>>> this.  You have to remember it is global on the router and cannot be
>>>> assigned to dial-peers or voice ports, so it doesn't work in all cases.  I
>>>> have never run into a limit though.
>>>>
>>>> The command looks like
>>>>
>>>> num-exp 2123 5556611
>>>>
>>>> Shawn
>>>>
>>>> On Mon, Jul 19, 2010 at 10:06 AM, Edward Beheler
>>>> <ebeheler at tippecanoe.in.gov> wrote:
>>>>>
>>>>> I am at a site where the DID's don't align with the extensions, and I am
>>>>> looking for suggestions how to handle when we reach the limit of 128 voice
>>>>> translation rules.  We currently have several hundred lines that look like:
>>>>>
>>>>> voice translation-rule 765423976
>>>>> rule 1 /^4239761/ /8761/
>>>>> rule 2 /^4239762/ /4705/
>>>>> rule 3 /^4239763/ /4703/
>>>>> rule 4 /^4239764/ /1424/
>>>>> rule 5 /^4239765/ /1307/
>>>>> rule 6 /^4239766/ /4225/
>>>>> rule 7 /^4239767/ /2203/
>>>>> rule 8 /^4239768/ /4985/
>>>>> rule 9 /^4239769/ /2309/
>>>>> rule 10 /^4239760/ /1624/
>>>>> rule 15 /.*/ /8101/
>>>>>
>>>>> Just about everything I'm finding deals with people trying to put more
>>>>> than 15 rules under a translation rule.
>>>>>
>>>>>
>>>>>
>>>>> Ed Beheler
>>>>> Network Administrator
>>>>> Tippecanoe County MITS
>>>>> 765-423-9762 / x4705
>>>>> www.tippecanoe.in.gov
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> cisco-voip mailing list
>>>>> cisco-voip at puck.nether.net
>>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> cisco-voip mailing list
>>>> cisco-voip at puck.nether.net
>>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>>
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>