Incoming call routes and remote locations 1

[573dawn]

Hi All, while getting ready for tonight's upgrade to 4.0.7, I was saving configs and noticed that I have piles of warnings related to incoming call routes stating:

"Incoming call route destination does not target Voicemail or match any known RAS, Users, Groups, or Short Codes."

This is on our main site DS for extensions at remote locations, and when looking at the remote DS units, there are something like 3-4 incoming routes each, none of which are specific to single user extensions, but which are things like HGs, or fax extensions.

SO, what are incoming call routes, should I be worried about this, and could it contribute to my dropped call issues?

Thanks, Dawn

 

[ProviderReborn]

An incoming call route is a way to point a line group or mutiple numbers from the line group to specific locations or rather more phones/groups/shortcodes/vm functions.

The errors from the top of my head are given when you have DDI's or Incoming Line group ID's pointing to VM:Shortcode name or shortcodes.

As long as your routes and DDI's are functioning correctly you have nothing to worry about.

Unless your drop issues are happening when the call very first hits your IP Office then NO I do not think this is related.

 

[573dawn]

TheProvider, thanks. So I guess I can ignore the errors? The drops ususally occur in the first 2-3 minutes of a call that is transferred to the trouble site, with some folks being dropped multiple times because they are transferred to direct extensions within the IPO. It has been a constant and unfixable problem for months now. So far nothing has alleviated it, and I've done almost everthing you can think of except have new copper pulled from the POP, and swapping routers from trouble-free locations, though I am going to do that here in the next week.

<sigh>

 

[ronromano]

Hey dawn, I've been watch our posts and My curiosity has grown to the point where I have to ask this. You are an end user right? And you have a vendor who supports you? If the first two are correct, don't you think its time for a new vendor?

 

[573dawn]

ronromano, I am the sole IT person/dept. for my company. So yes, I am an end user in a way. However, I have an extensive IT background and therefore, I now seem to have responsibility for something that is NOT in my background, namely this phone system.

Unfortunately, my boss has this long-term biz relationship with the vendor, and so far won't disrunpt that. If it were up to me we would ahve scrapped the whole thing over a month ago and either gotten a new vendor or a NON IP system.

Thankfully, I have this forum, or it would be twice as bad as it is...

 

[ProviderReborn]

IP Office is a great solution. Yeah it has its bugs but unless their is a specific issue some where I feel your sites are just genuinly unlucky.

Either through poor installation
Network issues
Line provider issues.

Im not just saying that, Im not in sales, I am an engineer. IP Office is still a good solution in my eyes any how.

 

[Gibsonic]

dawn you first five threads are free but we will have to start charing you from here on out

 

[intrigrant]

I agree, about IP Office AND about the support your vendor gives.
Forget about the errors ( are these really errors or just warnings? ) about ICR, just make sure you know the target excists in the remote location.

 

[573dawn]

TheProvider, I would agree whoeheartedly if we could get it to work correctly. I have really weird things like:

An extension that is NOT an HG acts like one and the actual HG doesn't.

Short codes that forward the GMs calls to a salesman, I can only assume the BP set it up because I didn't and no one else knows how.

Voice mail boxes that won't stay set up.

Then there are the drops.

With the assistance of the many generous people here, I have resolved a great many issues already. Suffice it to say that the BP set a number of things up incorrectly.

I know it COULD be great, but I am flying pretty much solo. The BP took some readings from Monitor about a month ago, allegedly sent them to Avaya, haven't heard a thing about them since.

It's YOU guys who I turn to, because no one else seems to care enough not to give up.

 

[intrigrant]

There are some "golden"rules when programming IP Office, if you keep these in mind then there should not be any problem:
[ul]
[li]Any name must be unique, actually the first eight chars must be unique. Names like Administrator1 and Administartor2 can lead to problems with VM Pro ( e-mail boxes not recognized etc.)[/li]
[li]Use only Alphanumeric chars and spaces in names, names may not start with a number or a space and names may not end with a space[/li]
[li]Use only two, three or four digit number plan, do NOT mix two and three digits, IP Office do not like that[/li]
[li]Keep it simple, try to think like a IP Office. A incoming call list for lets say 200 DDI numbers has to be passed everytime a call comes in. Thats a lot of work and i hate work, so does the IP Office. Create one ICR for all DDI numbers as in the docs with XXXs and a # as destination and create only ICRs for the exeptions. Try to do that kind of thinking on all things you program[/li]
[li]Erase all shortcodes which you know they will not be used. No one uses logon or logoff? > delete the short codes.
what is not there cannot create a problem![/li]
[li]Do not go over the top, no more extension/users as the system is designed for, max 1000 Directory entries etc.etc.[/li]
[/ul]

 

[573dawn]

intrigant, thanks. Now if only I knew how to do some of that Can you clarify point number 4? The main site has ICRs for many many extensions, while the remote sites only have maybe 3-4 ICRs at the remote sites.

Well, just got the 4.0.7 upgrade done, I'm headed for home! I will be back tomorrow

 

[intrigrant]

Incoming call routes.

Lets say you have 100 DDI numbers in the range 12345600 to 12345699.
The extensions are numbered from 600 to 699.

Create one ICR:
LineID = the trunkgroup the calls come in
DDI = 12345XXX
Destination = #

Any DDI coming in will go to the extension were the last three digits match

You can creat anothe ICR for lets say DDI 12345666 which is the sales group.
if the groupnumber is not in the 6xx range then the ICR is like this
LineID as above
DDI = 12345666
Destination = groupnumber

IP Office will first check the DDI from right to left so if it finds a match on 666 it will go to the sales group fi it does not match it will go to the 12345xxx route.

The same can be done with shortcodes.
If you want to call a group on a remote site then you will have to create a SC for each group.
If all the directory numbers on a remote site are in the range 1xx then you only need one shortcode:
SC = 1xx
TN = 1N
Action = dial
LineID = the ip line to the other location
If SCN is enabled then IPO will first search in its internal directory ( including users in the remote sites ), if the number is not found then it will check the shortcodes.
If there are shortcodes for some mobile numbers which are only used by some people then put these shortcodes in the users shortcode list and not in the system shortcode list, it will increase the performance of IPO as it has a shorter system shortcode list.
Directory numbers, in IPO you can have up to 1000 names and numbers. The names may not include spaces or non-alphanumeric values. If there are not allowed names it may cause problems as IPO checks all incoming CLIs against the Directory.
There can be more things which may increase performance, think about it and take a look at the config were improvements can be made.

 

[kwing112000]

Intrigrant,
I have never used this method for the incoming call routes. I usually put all the numbers in. my question is using your method if i have an extension at a remote site will this route the calls over there or would i need additional ICR routes?

Thanks for your help. THis may save a ton of time in the future.

 

[573dawn]

intrigrant, I am trying to follow you here. At my main DS I have 4 POTS lines, 1 PRI, and 3 IP. They are numbered as follows:

1 - Analog Trunk, incoming group Id 1, Outgoing group id 1
2 - Analog Trunk, incoming group Id 2, Outgoing group id 2
3 - Analog Trunk, incoming group Id 3, Outgoing group id 2
4 - Analog Trunk, incoming group Id 4, Outgoing group id 3
5 - PRI 24, all groups under channels set to 0 0
10 - IP, incoming group Id 10, Outgoing group id 10
11 - IP, incoming group Id 11, Outgoing group id 11
12 - IP, incoming group Id 12, Outgoing group id 12

BUT, when looking at the ICRs at the main DS, you will see line group IDs of:

442 pointing at a fax DDI
443 Pointing at a fax DDI
433 pointing at a demo room phone
4 pointing at a fax DDI
3 pointing at a fax DDI
2 pointing at a fax DDI
0 pointing at everything else, which includes every valid extension at every site, many un-setup extensions both fax and voice, and hunt groups at every site.

So the line group IDs in Incoming Routes don't match any of the group IDs set up in Line.

That is the first thing I question, any thoughts? If you can tell me if this matters, I can move on to the next portion of your excellent post.

 

[intrigrant]

I don't see a reason for the 4xx numbers as these are no linegroup numbers, the others make sense. I only miss a ICR for line ID 1, is it used for RemoteManager?

For the IP Lines you do not need a ICR if SCN is enabled, SCN IP Lines do not use ICR.

What do you mean with call drops? In what scenario does it happen?
And about the voicemail boxes, what happens?

 

[573dawn]

intrigrant, I have no idea why the 4xx numbers are there, the extensions that point at the fax lines are 445, 446, 447 & 448, so it makes no sense.

I see no line group for remote manager, either, all I see for that is an IP route of 192.168.99.0 255.255.255.0 0.0.0.0, and frankly I am ready and willing to remove it, if they want in they should have to ASK first.

We are using SCN, too.

As for the drops, they are mainly only at one site, and I have been looking back at the IP routing thinking it was not set up properly, see thread:

http://www.tek-tips.com/viewthread.cfm?qid=1391882&page=1

The VM boxes are weird. You set them up and they default back to original settings for some unknown reason. We did the 4.0.7 upgrade 2 nights ago and I was instructed to remove "enable faststart" in the VOIP setting of the IP lines, per an Avaya bulletin. I don't know yet if any of this has made a difference, but I do know that customers get really angry when a voice mail isn't returned, and I get really angry when I find out the only reason it wasn't checked was because the user didn't know what to do when prompted to "say their name" for the ??? time. (They should call me, but some of them don't, so I play VM police.)

 

[tlpeter]

573dawn

you can leave that ip route in
if you want to block the dial in then change the password for remotemanager
if they want to do dial in change it and give it to them
after the dial in change it back to the one you only know


ACA - Implement IP Office
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[573dawn]

tlpeter, thanks To my knowledge they have never dialed in anyway.

 

[tlpeter]

They are scared i think


ACA - Implement IP Office
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[573dawn]

tlpeter, and they should be! Say, would you look over my thread:

http://www.tek-tips.com/viewthread.cfm?qid=1392699&page=1

There are 3 replies and they are all me, I really want some input on that one, thanks in advance if you can

Dawn