Frustration with Manager - Incoming call route wildcards on any version IP Office

[zakabog]

According to the help documentation for every IP Office version I've seen, "X" is a valid option as an incoming number, and "#" is a valid destination.

A # matches all X wildcards in the Incoming Number field. For example, if the Incoming Number was -91XXXXXXXXXXX, the Destination of "#" would match XXXXXXXXXXX.

That works fine, and you can do 123# as a destination and it will send it to the correct extension, except Manager ALWAYS throws an error.

The Incoming Call Route destination is invalid. If a # or . is specified then these characters can only occur on their own or within quotes.

Does anyone know WHY it's like this and if there's anything I should be worried about when doing this? I have some customers where they have 100 DIDs, let's say 3300-3399 and instead of doing XXXX I want to narrow it down so anyone looking at Manager can guess the range based on the incoming call routes but Manager will throw this error which means every time I make any changes Manager will ask if I'm sure I want to save a configuration that contains errors.

Anyway, if it's something I just have to deal with then I can accept that, I was just hoping to see if anyone knew the logic behind this error (with "." it makes sense since that will return the entire number anyway and not just the wildcard portion)

[thiel2]

I've never used # in an ICR, but if the purpose is to make things clearer for those that come after you, why not just put the entire incoming DID number in the incoming number field? If I only see a hundred entries ranging from 3300 to 3399, that doesn't tell me what the area code and office code is. I'd rather see all 100 DID's listed as 2135553300, 2135553301, etc. For unassigned numbers, set the destination to AVAILABLE, and make a short code AVAILABLE to send the call to the operator, or to the automated attendant, or whatever. Now you can see the actual numbers, and what hasn't been assigned, and if a call comes to an unassigned number, it ends up somewhere that it can be answered. Last bonus is if the telephone service is a PRI, and the ARS table doesn't specify to send a number on outgoing, the system will send the DID number associated with the extension making the call.

[zakabog]

I was using 33XX as an example, I always write out the whole number. So the incoming call route would be

21255533XX and the destination would be 33# with a fallback of the operator/auto attendant/main group.

That way, if there's an extension that's available in the 3300-3399 range I know it's an available DID. If there's no extension built for a number it automatically falls back somewhere, I can easily change the time profile for EVERY number in an office since it's one incoming call route instead of 100. This also works to set the outgoing caller ID on PRIs without a specified outgoing caller ID.

This also has the advantage of reducing the number of incoming call routes that need to be built, instead of having 100 incoming call routes for that range I only have 1. If I want to block a specific number from calling in, all I need to do is add one more incoming call route instead of 100 (we have a customer with 500 incoming call routes, 250 for DIDs and 250 for blocking one number from calling.) If I want to add a backup trunk with another 100 DIDs, it's simply 1 more incoming call route instead of 100. Plus I could easily copy the one incoming call route If someone wants to be outside of the normal range (3350 should go to 2345) I can just build one incoming call route and I can easily tell who has a specific DID outside of the usual range. I can also glance at the incoming call route table and since there are only 5 or 6 routes for a company with 100+ numbers I can easily tell what special case numbers they might have, like a voicemail backdoor or a meet me conference.

It's a really great option when used correctly but I'm just wondering if Avaya will "fix" it one day where you MUST use # by itself in the destination rather than 1234#.

[combsk]

Destination wildcard

I know this is an old thread, but wanted to post in case anyone else ran across it... you can enter 33XX in the destination and that would work, too.

[zakabog]

Great! Just tried now and didn't see any error but I haven't attempted to do a test call (was working on an offline configuration.) I'll have to give that a go and see if it works.

[combsk]

Good deal - hope your test calls were successful.