Mitel Forums - The Unofficial Source
Mitel Forums => MiVoice Office 250/Mitel 5000 => Topic started by: gr8whtd0pe on July 08, 2014, 09:12:28 AM
-
I've been having issues with insufficient bandwidth messages popping up in teleworker phones for the last month. I've talked to my ISP, they swear it isn't them. I've replaced the modem, router, and some switches. Mitel learned the system was hacked and we replaced the flash card and locked down more ports.
Its still happening. I'm at a loss here.
My idea, since we have failover, is to maybe put some of the local to me phones on a different ISP to see if they still have issues. I would have to leave the others like they are however. This will allow me to see if it's the ISP or still something internally.
I've not see a way to do this, but hopefully there is.
-
I get low bandwidth alarms on internal phones on some shoddy CAT5 networks, where we have a system with lots of home workers I'm tempted to turn the low bandwidth alarm off it happens so frequently.
But crucially we very rarely get users complaining of poor quality calls or calls cutting off.
Do your users suffer with call quality or are they just seeing the alarm?
-
I get low bandwidth alarms on internal phones on some shoddy CAT5 networks, where we have a system with lots of home workers I'm tempted to turn the low bandwidth alarm off it happens so frequently.
But crucially we very rarely get users complaining of poor quality calls or calls cutting off.
Do your users suffer with call quality or are they just seeing the alarm?
Office is brand new. All CAT6 inside. It's happening to every single telworker dervice as well, so that rules out a wire on their end being bad. Unless all 43 just went bad at once.
Internal is fine out the PRI.
They are loosing audio and sometimes the calls drop. Its not just the alarm, its legit.
-
Sounds like the Office Internet connection is bad if all external users are having issues, do you see them all go down or start complaining at the same time?
-
Sounds like the Office Internet connection is bad if all external users are having issues, do you see them all go down or start complaining at the same time?
Yup that's my thought (and has been), but the ISP swears it's fine. This is why I want to put some on a different ISP, and leave the others that I can not get to on the current ISP.
Not at the same time. It's random. Remote phones are not used that much, but when they are 99% of the time there is audio loss.
-
Is the ISP connection that the 43 remote users are connected through, also used for something else? If so, is it possible that whatever that other use is, it's overwhelming it and choking those remote phones out?
Also, are they traditional 5000 remote phones, or Mitel Teleworkers through an MBG?
-
Is the ISP connection that the 43 remote users are connected through, also used for something else? If so, is it possible that whatever that other use is, it's overwhelming it and choking those remote phones out?
Also, are they traditional 5000 remote phones, or Mitel Teleworkers through an MBG?
It is used for everything. Exchange, VPN, the works. It has been for the last year and a half. This all just randomly started on Memorial Day weekend.
Traditional. Just set teleworker to the public IP of the ISP.
-
I'm guessing that there is not a way to do this based on the crickets in here. lol
-
Since you're using the traditional method, no, there is not a way to do this that I know of since the controller has to know the WAN address thats mapped to it.
I'm a traditional 3300 guy, so multiple teleworkers can do this however. You would put an MBG on each ISP, and then assign phones to the two MBG external servers. Now that MBG can be used with the 5000, I assume this feature is available here as well, but don't know that for certain.
-
gr8whtd0pe,
Are these teleworkers working from home or an external office with a good amount of bandwidth? The problem may not be with your main office side at all if the user's data connection at their home is having the issue. You can try to lower the amount of bandwidth required if they are not already using G.729 for the remote phones.
Thanks,
TE
-
gr8whtd0pe,
Are these teleworkers working from home or an external office with a good amount of bandwidth? The problem may not be with your main office side at all if the user's data connection at their home is having the issue. You can try to lower the amount of bandwidth required if they are not already using G.729 for the remote phones.
Thanks,
TE
43 different stores, some with useless Frontier, some with Comcast, some with Suddenlink and one on fiber. I've ruled that out because of that.
Phones are already set to G.729, even changed them back to G.711 Mu-Law under Mitel's advice. Thinking it might not timeout so fast.
Wonder why there is 2 settings for IP Connections under System - Device and Feature Codes - IP Connections. Could I set the second one (P6002) that is not set to the second WAN IP? Wouldn't that allow both connections to come into the system?
-
Gr8whtd0pe,
Unfortunately no, the second one is only if you have a PEC-1 card installed in the system and if there was one you would have to have a second public IP address for the phones to work properly. Most likely you see that as P6001 and it had a red X next to it meaning the card is not installed.
Has your vendor set up a VoIP test box between your main site and one that is having problems to determine the issue you are having?
Sorry,
TE
-
Gr8whtd0pe,
Unfortunately no, the second one is only if you have a PEC-1 card installed in the system and if there was one you would have to have a second public IP address for the phones to work properly. Most likely you see that as P6001 and it had a red X next to it meaning the card is not installed.
Has your vendor set up a VoIP test box between your main site and one that is having problems to determine the issue you are having?
Sorry,
TE
No red X. 8)
My vendor is useless. They are the local phone company. I have his admin login and do 99% of the work myself thanks to these forums. He even made the comment that I should take the test and get certified lol.
Only thing they have done is called their NOC, which tries to help, kinda, and then if it gets bad calls Mitel.
-
Gr8whtd0pe,
From what I have noticed everyone, regardless of skill or knowledge passes the certification course if they are able to pass the entrance exam; which is relatively simple.
So, as I am now dumbfounded as to how your system is working properly at all can you go to.
System > IP Settings > Static Expansion Card IP Address
1. Does that line exist, should be under Static Processor Module IP Address?
2. Does it have a red X next to it?
3. Is it on the same network as the Processor Module?
If the answers are Yes, No, Yes then go here and look at this line?
System > Devices and Feature Codes > IP Connections > P6001 Expansion Card > NAT IP Address
Is there something there other than 255.255.255.255 ?
Is this one of your Public IP Addresses?
Are all the correct ports NAT'd from that Public IP to the Static Expansion Card IP Address?
So, basically what I am looking at is that the Base Processor and the Expansion Card have separate Public IP addresses and that the Private IP Addresses are on the same network. If any part of this is not valid than I would be surprised if your remote phones had any audio at all, but I wouldn't be surprised if they were having problems.
Thanks,
TE
-
That line does not exist.
255.255.255.255 is what is listed.
-
Gr8whtd0pe,
Well that makes me feel better, you do not have an expansion card installed, but the installer must have used a default database with that card installed on it.
Anyway, that will do what you want it to do, but at least it is not part of your problem with audio issues.
Thanks,
TE
-
Gr8whtd0pe,
Well that makes me feel better, you do not have an expansion card installed, but the installer must have used a default database with that card installed on it.
Anyway, that will do what you want it to do, but at least it is not part of your problem with audio issues.
Thanks,
TE
So just to verify, I can NAT two different public IPs, right?
-
gr8whtd0pe,
Let me put it this way so hopefully there is no confusion.
IF you have a PEC [Processor Expansion Card] AND you are using remote IP phones then you have to have a Public IP addresss pointed to the PEC that is different than the one pointed to the Base Processor, otherwise you will have audio issues. The IP Phones will never use the Public IP address of the PEC as their Controller IP, it is always the IP of the Base Controller.
So, to answer your question yes you have to have NAT to point to the two different Public IP Addresses of the Controller if there is a PEC installed on the Base Processor, but you cannot point IP Phones to that public IP address and expect it to work properly.
Thanks,
TE
-
Alternative way to test this: put a VPN router in at one of the remote sites, then you don't need to set a handset's 'NAT Address Type' to NAT, and the public IP programmed on the 5000 doesn't matter. It's a bit of overhead, but it's a lot easier [IMO] than deploying an MBG just to try and diagnose an ISP issue.
-
The lack of a red X on the expansion caught my eye. I have a 5000 that was just upgraded to 6.0.10.82 because of an alarm 1007. Now my local IP (LAN) endpoints are getting Insuff Band alarms and resetting intermittently. I also noticed that now my expansion card does not have a red X on it although there is not one installed.
Anyone else upgrade and noticed the red X issue?
-
619Tech,
If you are looking at it in Local Mode it may not have the X on it. Other than that it should if you are in Online Mode.
Thanks,
TE
-
619Tech,
If you are looking at it in Local Mode it may not have the X on it. Other than that it should if you are in Online Mode.
Thanks,
TE
Mine has a red x in both modes. You have to actually click on IP connections to see it.