Mitel Forums - The Unofficial Source
Mitel Forums => MiVoice Office 250/Mitel 5000 => Topic started by: Heritage02Rider on March 18, 2014, 11:02:42 AM
-
We are a fairly new MITEL 5000 shop. We have about 50 users with about the same number of IP phones (5360's) phones with 1 GbE switches in them. Our network is running 1 GbE over HP ProCurve A5120's. We are converged, but the phones are on a separate VLAN from the data traffic. On a few phones, mostly the same ones, we are randomly getting a message on the phone itself (not on the 5000) indicating INSUFF BANDWITH and the phone gets a busy signal. After a few moments the call returns.
I have replaced the patch wires at both ends with no noticeable change. The issue cannot be recreated at will. We tried hammering the network connection at the same time we are on a call and the call is perfect. Not even a flutter.
Aside from replacing the wire from the server room to the end user, is there anything else I can/should be looking at? Could replacing the phones be worth a shot? If so, will MITEL actually replace them if I no longer get the issue? How would I prove it and is there a log somewhere of this actually occurring.
Any ideas are welcome.
-
I'd check switch logs for Tx/Rx errors. Try moving cable to new switch port. Also make sure QoS is enabled and prioritized for voice. Most of the time I see insufficient bandwidth alarms on non-VLANed networks and most of the time it's negligible. If you're actually having service impacting issues as a result, I'd take a look at your network infrastructure as a whole. Check for patterns on time of day, people effected, etc.
-
Insufficient Bandwidth is a system alarm, you will get that on phones with the Administrator flag, it doesn't display on the phones causing the issue you would have to check the system logs to see which ones are the cause. If it is one phone, it could be a bad patch cable or something connected to the PC port of the phone as well.
If you are not having any call issues and cannot find a cause, another solution is to go into the system flags and turn off the Insufficient Bandwidth alarm... sometimes this can be a false condition.
-
Insufficient Bandwidth is a system alarm, you will get that on phones with the Administrator flag, it doesn't display on the phones causing the issue you would have to check the system logs to see which ones are the cause. If it is one phone, it could be a bad patch cable or something connected to the PC port of the phone as well.
If you are not having any call issues and cannot find a cause, another solution is to go into the system flags and turn off the Insufficient Bandwidth alarm... sometimes this can be a false condition.
I have to correct you on this one. The phone that is having the issue at the time IS the phone indicating the message. The phone screen displays INSUFF BANDWIDTH (sp may not be exact) and the user gets a busy signal and the third party gets silence. After a moment or three, the phone returns to normal and the phone call continues.
I have checked the logs on the 5000 and cannot find any reference to this happening. Perhaps I have not checked in the correct places, but I did check the seemingly obvious places. Also, there is no alarms being registered on the 5000.
The issue is at the phone.
-
I'd check switch logs for Tx/Rx errors. Try moving cable to new switch port. Also make sure QoS is enabled and prioritized for voice. Most of the time I see insufficient bandwidth alarms on non-VLANed networks and most of the time it's negligible. If you're actually having service impacting issues as a result, I'd take a look at your network infrastructure as a whole. Check for patterns on time of day, people effected, etc.
Last night I checked and you may be correct. The engineer who setup my switch stack may not have enabled the qos properly. I noticed that all my ports were untrusted. So I set the "qos trust dscp" on each port requiring a phone and will see how this affects the users having the issue. Obviously I will have to wait a few days to see if it comes back. Will write back when I have more information.
-
Heritage02Rider,
First off that only comes into play if you are giving the phones and controller DSCP values. If you are that is great! On the phone system though it will show up under the IP Connections settings instead of IP Settings for the System.
System > Devices and Feature Codes > IP Connections > P6xxx >
Audio RTP Type of Service 184
Data Type of Service 184
The phones will get this either through LLDP or you manually set them when you bring up the phone and those will be 46 in case you needed to know.
As for the Alarm 032 Insufficient Bandwidth you are correct that it will show at the phone that is having the problem. Have you looked at your Network Diagnostics Log yet to see what it is saying?
Here is the description of the Alarm just for future reference of readers to this post.
Alarm 032 indicates that the IP network does not currently have enough bandwidth to support the IP call that is connected. This alarm is generated if the IPRC/IPRA detects that the audio-receive timer has expired without receiving the first audio packet or that the Average In Time Frame Percentage has fallen below the threshold specified in Database Programming. When this alarm is generated, a transient message is displayed on the affected IP phone. In addition, the administrator station displays SYS ALARM #32 X INSUF BANDWIDTH where x is the extension number of the affected device.
NOTE: This alarm is displayed only if the Insufficient Bandwidth Alarm flag is enabled in Database Programming (System\Flags). If generated, this alarm indicates a network problem, which may result in packet loss which may affect audio quality. Make sure the affected device is not behind a firewall or NAT.
Message Print Manual Descriptive:
A032 ALARM Ext. <eeeee> Received Insufficient Bandwidth
FIELDS: eeeee The extension number of the device that received the insufficient bandwidth message.
CAUSE: The system detected that the IP endpoint's audio-receive timer has expired without receiving the first audio packet or the average-in-time-frame percentage has fallen below the threshold specified in the Voice Audio Session Configure Command.
ACTION: This indicates a network problem. Poor network condition could cause packet loss or a firewall prevents the callers from receiving audio packets. Dump the network diagnostics file for more information.
NOTE There is a system flag that can disable this alarm.
Thanks,
TE
-
TE - Thanks. That is very detailed.
I did not have the Insufficient Bandwidth Alarm enabled, so I never saw the message on my phone. Also, I assume this prevents the log from show it as well. I have now enabled this feature.
As for the DSCP, I am not a qos expert, so let me ask a question here.
My settings for Type of Service are set as you have indicated: 184/184.
You mentioned that 'if you are giving the phone and controller DSCP values'; I guess I assumed that having these set along with the standard MITEL DHCP option 125 with dscp=46v46s26 has set the DSCP accordingly and the phones are tagging 46. Is there anyway to prove that the packets are tagged? Will Wireshark show this?
Basically, how do I know if I am tagging properly.
-Karl
-
Follow-up - I did a WireShark and got the following:
Src (phone) = 192.168.200.x
Dst (5000) = 192.168.200.x
Differentiated Services Field: 0xb8 (DSCP 0x2e: Expedited Forwarding; ...)
Src (5000)
Dst (phone)
Differentiated Services Field: 0x00 (DSCP 0x00: Expedited Forwarding; ...)
Appears the phones are using qos and the switch is not.
modified...
Src (5000-PEC)
Dst (phone)
Differentiated Services Field: 0xb8 (DSCP 0x2e: Expedited Forwarding; ...)
Apparently the PEC card is doing qos since the UDP packets emanate from there.
-
Heritage02Rider,
Enabling the Insufficient Bandwidth Alarm will only post the alarm to the phones that are set as Administrators and has nothing to do with it showing up in the Error Logs/Message Print.
As for your setup just make sure that both the base and the PEC have 184 setup on their IP Connection, but that only comes into play at certain times, it is the phones that you want to make sure are using it and they are; which is good. Nice to see there is someone else who knows how to use Wireshark and when!
Did you look at your Network Diagnostics Log yet? If you don't know where to find it let me know and I will explain it to you. Well I will just go ahead and explain as it isn't that hard to find.
Download your Error Logs by going through Tools > Error Logs. It is easier to just download everything so do that. Once it is done if you open up the compressed folder you will find a log that should start with an E{MMDD}A.ndl or something like that; the main point is the .ndl which stands for Network Diagnostics Log.
Thanks,
TE
-
Thanks for the information and all your help. I am much smarter now.
However either my system is different or I am an idiot. Not find the "Tools>Error Logs", I did find the "Operations>Error Information...". So I was only able to get the Exxxxxxx.ndl via a Freeze. The regular logs, of which I downloaded all of them, did not have this file. Ran into a few things I never saw before, but successfully recovered. (Once frozen I was unable to unfreeze until I figured out how to turn off Automatic Diagnostics Delivery - good thing this was before the NCAA tourney!)
So it appears the log file is cutoff. I starts mid-stream in a message and only goes back a couple days. (13K) But there was good information there. I believe the "qos trust" has solved the local issue. That was my main focus. My phones that are remote (i.e. Mexico) are still getting the Insufficient Bandwidth. I am now focusing on my VPN to do qos, however I am smart enough to be dangerous with Cisco. I may utilize my SmartNet for this one. That's why I pay for it after-all.
The message below was before my change to the switches:
Insufficient Bandwidth: 03-18-2014 at 09:10 AM
IP Station Extension: '2191' at IP Address 192.168.200.22 on Board 7
VoIP Configuration Information:
N/A
IP Audio Quality Snapshot Values:
Reporting ICP IP address: 192.168.200.201
Reporting IP Address: 192.168.200.22
Reporting Signalling Port: 6921
Reporting Voice Port: 50030
Far End IP Address: 192.168.200.203
Far End IP Port: 6728
RX Codex: 1
Delay: 0
Jitter Instant: 0
Jitter Average: 0
Jitter Buffer Overflow: 0
Jitter Buffer Underflow: 0
Jitter Buffer Average Depth: 20
Jitter Buffer Max Depth: 20
Snapshot Packets Lost: 0
Packet Loss Max Burst: 0
Packets Out of Order: 0
IP Audio Quality History:
Packets Lost: 11
Packets Received Total: 177739
Jitter Buffer Histogram:
10-19ms: 0
20-39ms: 0
40-59ms: 0
60-99ms: 0
100-200ms: 0
200+ms: 0
Packet Loss Histogram: consecutive packets
1: 11
2: 0
3-5: 0
6-10: 0
10+: 0
Audio Samplings:
Rec: Time Jitter Pck Lst Pck Rx InTime%
1 5 0 0 250 100
2 5 0 0 250 100
3 5 5 0 250 100
4 5 5 0 250 100
5 5 0 0 250 100
6 5 0 0 250 100
7 5 5 0 250 100
8 5 5 0 250 100
9 5 5 0 250 100
10 5 5 0 250 100
11 5 5 0 250 100
12 5 0 0 250 100
As for my remote phones, this is all they print out:
Insufficient Bandwidth: 03-19-2014 at 04:44 PM
IP Station Extension: '2196' at IP Address 10.52.66.45 on Board 7
VoIP Configuration Information (Audio Session 10):
VoIP DSP Number: 10
Audio Frames Per Packet: 2
In-Time Frame Percentage Threshold: 60%
In-Time Frame Timeout: 5 secs
Audio TX IP Address/Port: 10.52.66.45:50160
Speech Vocoder Type: G711 Mu-Law
Speech RTP Payload: G711 MU-Law
Other Device System Echo Canceller Profile: No Echo
Echo Suppression: FALSE
Echo Saturation: TRUE
Echo Suppression Sensitivity Level: 0
Conn Dir: Two-Way; Call Session: 2196 (GW) 2619
-
Heritage02Rider,
That will teach me to try and explain from memory, especially since I am not getting any younger, and you are correct it is Operations not Tools to get to the error logs; at least you found them and that is what matters.
Now, I don't know what kind of pipe you have at both ends between the US and Mexico, but let's just try a little experiment with your codecs before you start changing a lot of stuff around.
According to your Network Diagnostics File you are running G.711 for your remote phones so let's knock that down to G.729 and see if the frequency at which this happens either lessens or goes away all together; I will bet on it being reduced with some instances still occuring.
Go to System > IP-Related Information > IP Connections > Remote {or whatever your Mexico Phones are using}
Now, that I look at your Diagnostics again it looks as though you may have you Mexico Phones as local phones since it is showing 2 audio frames per packet. Hmm, you may just want to change your Mexico Phones over to the Remote IP Configuration or at least seperate them from the Local ones so you can change the Codec without affecting all the local phones as well. If you need help with this let me know and I can walk you through it.
Thanks,
TE
-
Tech Electronics,
I have been reading this thread with interest becaused I am having the same issue with one branch location (other 8x work fine).
I would appreciate your assistance in changing the phones in this hunt group to the Remote IP Configuration you suggested. Thank you,
-R
-
Rombrigs,
If you believe that is what your problem is then sure I can tell you how to do it, but first you must gather some information for me so I can be a little more sure that it is the solution for you.
1. Do all the phones at this branch go across an external network to reach the phone system they are programmed on?
2. Look at the programming of one of those phones. System > Devices and Feature Codes > Phones > Ext nnnn > IP Settings, what number is next to Call Configuration
3. Also look at NAT Address Type and determine if it is Native or NAT
By default there are two Call Configurations:
1. Local
2. Remote
We want to ensure that Remote is what they are using if they are indeed Remote Phones. The differences between the two are an increase amount of Audio Frames per IP Packet which will increase latency but reduce Jitter and most of Network Congestion. Then you have an increase in minimum playback time which will also increase latency, but also reduce jitter. Now, there is the major difference of Codecs used to compress DTMF and Audio. With Local we use G.711 for both which does not compress the audio enough for the human ear to really notice. With the Remote however by default we change DTMF to RFC 2833 and Audio to G.729 and the audio can go down to G.729B (VAD) which uses silence suppression to reduce packet size and traffic. These however will provide a noticeable difference in what most humans perceive as quality of audio, especially G.729B (VAD) which messes with the comfort noise they like to hear.
Thanks,
TE
-
1. Yes, they go across a MPLS QOS enabled converged network via a T1
2. 1
3. Native
Thank you! -R
-
Rombrigs,
I am surprised you are having issues with an MPLS circuit and since the phones are showing up as Native then it is considered one network. Do you have QoS set up on the local network at that branch and if so is it the same as all the other sites? Have you checked the metrics on that MPLS circuit to make sure there are no issues?
It could be that the data cable the phone is on is having some problems, the patch cord could be faulty, the port they are attached to could be faulty, the programming of the switch could be wrong. What all have you done to figure out the problem and what were your results?
If you want to continue on with the changes then the only thing I would do, without some actually testing on the network, would be to change the Call Configuration of the phones that have the problem the most to 2 and see if it continues. Just keep in mind that your users may think that the audio difference is an new issue so you will have to let them know there will be a noticeable difference in the quality of the audio.
Thanks,
TE
-
There is definitely an underlying issue that has not been identified. I requested performance metrics from the service provider this morning, I have a feeling packet loss is occuring.
Cables to the phones was the first thing checked, they all passed. Programming of the switch is correct; I rebooted last night. QOS settings are good and frankly there is not enough traffic to cause the symptoms they are experiencing. All settings have been triple checked and are identical to other sites that have no problems. I may do a firmware upgrade and reset to factory defaults of the switch over the weekend.
I would like to try modifying the call configuration on a few phones, for test purposes and to see if it alleviates the disconnected/poor quality calls until I can diagnose the real problem.
Unfortunately, my Mitel vendor is competent enough to get the system running and do basic programming, but anything out of the box is "we will contact Mitel support" and nothing gets done.
Thanks again for your time.
-
Rombrigs,
Hopefully you get your issue resolved soon, but if you need any more information than just post your question back here.
Heritage02Rider,
Are you still on the straight and narrow or do you need some help still with your issue?
Thanks,
TE
-
Heritage02Rider,
That will teach me to try and explain from memory, especially since I am not getting any younger, and you are correct it is Operations not Tools to get to the error logs; at least you found them and that is what matters.
Now, I don't know what kind of pipe you have at both ends between the US and Mexico, but let's just try a little experiment with your codecs before you start changing a lot of stuff around.
According to your Network Diagnostics File you are running G.711 for your remote phones so let's knock that down to G.729 and see if the frequency at which this happens either lessens or goes away all together; I will bet on it being reduced with some instances still occuring.
Go to System > IP-Related Information > IP Connections > Remote {or whatever your Mexico Phones are using}
Now, that I look at your Diagnostics again it looks as though you may have you Mexico Phones as local phones since it is showing 2 audio frames per packet. Hmm, you may just want to change your Mexico Phones over to the Remote IP Configuration or at least seperate them from the Local ones so you can change the Codec without affecting all the local phones as well. If you need help with this let me know and I can walk you through it.
Thanks,
TE
I did have them set as local.
I have moved them to the Remote and G.729.
I will monitor and get right back. I literally got a insufficient from the remote phone a moment before I changed the setting. So I will probably know today.
-
Heritage02Rider,
That will teach me to try and explain from memory, especially since I am not getting any younger, and you are correct it is Operations not Tools to get to the error logs; at least you found them and that is what matters.
Now, I don't know what kind of pipe you have at both ends between the US and Mexico, but let's just try a little experiment with your codecs before you start changing a lot of stuff around.
According to your Network Diagnostics File you are running G.711 for your remote phones so let's knock that down to G.729 and see if the frequency at which this happens either lessens or goes away all together; I will bet on it being reduced with some instances still occuring.
Go to System > IP-Related Information > IP Connections > Remote {or whatever your Mexico Phones are using}
Now, that I look at your Diagnostics again it looks as though you may have you Mexico Phones as local phones since it is showing 2 audio frames per packet. Hmm, you may just want to change your Mexico Phones over to the Remote IP Configuration or at least seperate them from the Local ones so you can change the Codec without affecting all the local phones as well. If you need help with this let me know and I can walk you through it.
Thanks,
TE
You are correct - all my phones were listed as Local. I did move the affected phones to the Remote configuration. They should now be doing G.729. The lower bandwidth requirement should provide less dropouts. I will see if the call quality suffers, but I will assume it will be negligible.
This one is obviously a wait and see, so I will post back next week after we let it sit for a while.
As for the local - still have not see an INSUFF BANDWIDTH show up since the change to the switches.
Thank you for all the help! It has been detailed and informative.
Karl
-
Heritage02Rider,
Well I hope your problem with this issue is solved, but we will see. Anyway, I was glad to help out where I could.
Thanks,
TE
-
Still having problems, so to change these phones to remote/G729 is it as simple as changing the call configuration to "2" or is there more to it?
Thanks! -R
-
Rombrigs,
No, that is all there is to it for your setup.
Thanks,
TE
-
Follow up reply:
RE: Remote phones
Have not gotten a notice about bandwidth from the remote phone yesterday or today, but it appears they only made two calls. I will call them to see what is up - and perhaps a lengthy enough call to determine if we get a drop.
RE: Local phones
The INSUFF BANDWIDTH has been aggressive yesterday and today. Two phones today at exactly the same time today. So I checked the log and they were both receiving incoming calls. (not talking to each other) I am perplexed here. I cannot imagine that they are really having not enough bandwidth for a call. The one phone, which has had several since Friday had one occur at 5:17 pm. Basically 3/4 of the people had gone for the day. No possible bandwidth issue should be occurring.
To add to the frustration, I received an Insufficient Bandwidth notice from our SIP trunk as well. SO I decided to monitor the link and another occurred. We were utilizing about 1% of a 20 Mbps Ethernet MPLS circuit at the time the notice went out.
So... is it possible that the messages are phantom? The users are complaining that they get a brief busy signal, so something real is happening.
I will be contacting my phone vendor, but I already assume they will say its my network and that I need to call in someone else. I just cannot believe that it is the HP switches that are the weak link.
For reference - yesterdays Freeze - I see nothing indicating a problem:
Insufficient Bandwidth: 03-24-2014 at 11:45 AM
IP Station Extension: '2167' at IP Address 192.168.200.21 on Board 7
VoIP Configuration Information (Audio Session 110):
VoIP DSP Number: 110
Audio Frames Per Packet: 2
In-Time Frame Percentage Threshold: 60%
In-Time Frame Timeout: 5 secs
Audio TX IP Address/Port: 192.168.200.21:50228
Speech Vocoder Type: G711 Mu-Law
Speech RTP Payload: G711 MU-Law
Other Device System Echo Canceller Profile: No Echo
Echo Suppression: FALSE
Echo Saturation: TRUE
Echo Suppression Sensitivity Level: 0
Conn Dir: Two-Way; Call Session: 2167 (GW) 94072
IP Audio Quality Snapshot Values:
Reporting ICP IP address: 192.168.200.201
Reporting IP Address: 192.168.200.21
Reporting Signalling Port: 6993
Reporting Voice Port: 50228
Far End IP Address: 192.168.200.203
Far End IP Port: 6824
RX Codex: 1
Delay: 0
Jitter Instant: 0
Jitter Average: 0
Jitter Buffer Overflow: 0
Jitter Buffer Underflow: 0
Jitter Buffer Average Depth: 20
Jitter Buffer Max Depth: 20
Snapshot Packets Lost: 0
Packet Loss Max Burst: 0
Packets Out of Order: 0
IP Audio Quality History:
Packets Lost: 0
Packets Received Total: 18250
Jitter Buffer Histogram:
10-19ms: 0
20-39ms: 0
40-59ms: 0
60-99ms: 0
100-200ms: 0
200+ms: 0
Packet Loss Histogram: consecutive packets
1: 0
2: 0
3-5: 0
6-10: 0
10+: 0
Audio Samplings:
Rec: Time Jitter Pck Lst Pck Rx InTime%
1 5 0 0 250 100
2 5 0 0 250 100
3 5 0 0 250 100
4 5 0 0 250 100
5 5 0 0 250 100
6 5 0 0 250 100
7 5 0 0 250 100
8 5 0 0 250 100
9 5 0 0 250 100
10 5 0 0 250 100
11 5 0 0 250 100
12 5 0 0 250 100
-
Heritage02Rider,
According to this it is not the phone that is having the issue as it is showing no lost packets or drops in service, but is 192.168.200.203 your SIP trunks?
Not to be nosey, but if your switch is an A-series 5120 are you sure that you set up QoS properly for your Voice VLAN?
Thanks,
TE
-
Well, I am not going to discount that. I am not an HP expert, but I follow instructions fairly well. After pondering just that same idea, I can say that we have not had the problems prior to implementation of our SIP trunk. (Freud says that 'sometimes a cigar is just a cigar')
Regarding the connection between the MPLS and the core switches, I will investigate the QoS. To the end-user I believe it to be correct.
I am thinking if it were solely the SIP trunk to be the issue, I should be getting the insufficient bandwidth message at the MITEL switch rather than the end-user and it should be the connection to the SIP trunk in the alert; correct? I have had these messages, but they are never (or rarely) coincidental.
-
Heritage02Rider,
Since you do not have the Insufficient Bandwidth Alarm enabled on the System Flags it will not show at the switch it will always show at the phone where the issue is currently happening whether it is the phone or not.
At this point I would be looking at the SIP Trunk Configuration and downloading Error Logs to see if there is anything going on. Prior to that though I would make sure that the Expanded Message Print was turned on.
Turn on Online Monitor View > Online Monitor hit ok when it tells you to not do this.
Then go into the Maintenance and turn on Expanded Message Print. System > Maintenance > Message Print > Print Expanded Message Print > YES.
Now, turn off Online Monitor View > Online Monitor.
Now download Error Logs Operations > Error Information select both history and message print.
This is all the same stuff you have been downloading except instead of just looking at the .ndl file we want to look at the Message Print File.
Thanks,
TE
-
Hi,
I don't wish to hijack this thread and will be happy to start a new one if asked, but have been reading with interest. I noticed this problem happens at our site rarely, but enough to bother me. We are 60 users, one site, using Mitel 5000 for a few years. Having just looked at the ndl logs we have had a number of 'insufficient bandwidth' issues affecting users over the past few months. This is not happening frequnetly enough that users are reporting it, but I am aware it's going on and would prefer to reduce this as much as possible.
Phones operate in their own VLAN (5).
I checked our network settings, which are:
DHCP
We are using option 43 only id:ipphone.mitel.com;sw_tftp=192.168.50.10;call_srv=192.168.50.10;vlan=5;l2p=6;dscp=46
We are not using option 125
Switches
Using Netgear FS728TP (hopefully being replaced soon). Under QOS menu...
QOS is enabled and using trust mode DSCP
COS (cost of service?) interface config shows each port as using a default COS of 0 (the options are 0-7)
Queue = strict priority (alternative option is WRR)
COS to Queue Mapping...
0 Low
1 Lowest
2 Lowest
3 Low
4 Normal
5 Normal
6 High
7 High
DSCP to Queue Mapping...
See attachment.
Mitel 5000
IP Connections...
P6000 = Audio RTP = 0, Data Type = 0
P6001 = Audio RTP = 0, Data Type = 0
From reading through this thread, the first thing I notice is my IP Connections settings are incorrect. Is it sufficient to just set this to 184 for both values? and for both P6000 and P6001?
Also, I'm confused about our Netgear switches. If DSCP is set to 46, but no 46 exists in the switch DSCP table, should I change the DSCP value the phones receive? If so, can I choose any number which has a DSCP value of 'high' (such as 63)?
Thanks in advance.
-
WallIT,
Your switch and phones are using DSCP which is a high priority, but your Class of Service should be either a 6 or 7; normally 6.
Option 34 and 125 are the same in this instance for your case as they provide the same information for the phones.
Thanks,
TE
-
Thanks TE
Your switch and phones are using DSCP which is a high priority, but your Class of Service should be either a 6 or 7; normally 6.
Isn't it one or the other? In my switch, under the QOS menu, I have QOS mode set to enabled, and beneath that, trust mode = DSCP. The other choice is CoS, suggesting I need to use one or the other.
Also, should update my Mitel IP Settings as mention in my previous post? Or leave as is (both set to 0)?
Thanks. Much appreciated.
-
WallIT,
Since I do not know your switch I am not sure why it wouldn't allow for both since DSCP is normally for data packets leaving the switch and WAN side queueing. The CoS is for internal routing priority on the individual switch ports on that switch.
As for the setting for the P6000 and P6001 that is for the Controller talking on the WAN (DSCP), but if you want to set it then it will not hurt anything on your system.
Think CoS is Layer 2 and DSCP is more Layer 3, not a good analogy but it works in this instance.
Thanks,
TE
-
If anyone is still following this post, my current situation is this; MITEL has been engaged as well as the telco SIP carrier. The carrier has shown no drops and since the user is receiving a fast busy, they have said there is no way for them to provide a busy signal during a call. They are on standby if needed. MITEL has reviewed my logs and freezes and have now sent them to engineering for further review. I have not heard back from them in over a week. Apparently they are perplexed as well. As I find out more information and/or resolution I will post. :D
The odd part of the whole issue is that the problem did not exist for the previous 8 months we had the 5000. Only changes to the system were the addition of a SIP trunk and an MBG for UCA/MiNet support (not SIP trunking - SIP is direct).
Thanks for everyone's support. Stay tuned.
:D
-
Any updates on this? Mine just randomly started doing it last week. Nothing has changed in our setup either. Some days I get 5-10 others it's 1-2 every few minuets. All remote phones.
-
Unfortunately no. Mitel, as well as HP and Windstream had no answer. However, I have an idea, but I have to talk with my vendor first. The only things that changed when this started was in the adding of the SIP trunks and an MBG. The MBG actually does not filter the SIP trunk due to the Windstream configuration. So we use the MBG for simply doing MiNet and SIP phones (UCA app).
The default route of the Mitel 5000 had to be changed to point to the Windstream router to allow calls to be forwarded to Windstream. So now our default route, which was our HP stack becomes a secondary route on the Windstream router. So, I am guessing that the DHCP on the Mitel 5000 has also changed the default route from the HP stack to the Windstream router. So when a phone call is initiated, it has to bounce off the Windstream router before getting back to the Mitel switch. In reality, this should not be an issue, but as for what I am seeing, the insufficient bandwidth mostly appears (I say mostly since I have no hard facts to say all) when a phone is using a SIP trunk (i.e. inbound/outbound call). I can make a "internal" call to our plant 3000- miles away and talk for 30 minutes and never get a insufficient bandwidth message. If they receive an inbound call, they may get it in a a minute or so.
This leads me to still center my attention to the network configuration of the Windstream router and the Mitel switch. However, I do not know how to reprogram the phones to point to the internal HP stack as the default route. (the phones do not need to the Windstream router to be their default route)
Option 6 in the IP Settings >DHCP Server Settings > Options is Option ID 3 (router default gateway) but my configuration reads as follows:
Scope = IP Address Range and points to IP Settings >DHCP Server Settings > IP Address Ranges > 1
Format = Mitel Automatic (can I change this to IP address??? and force the local stack...)
-
Heritagerider02,
Most likely the phones are going back to the 5000 and then out to the trunking. You could check and see if Peer-2-Peer is set up in its Network Group if those trunks are SIP that is.
Thanks,
TE
-
Follow up - I believe the problem to be solved. Turns out that it may have been a setting in the switches as it pertains to spanning tree. Ultimately I made a lot of changes. Found some incorrect configurations on some ports. I modified and tweaked everything until it was how it should look. I was still getting random "INSUFFICIENT BANDWIDTH" messages. Then I came along a document, simply but enlightening.
In case I had not mentioned earlier, I am using HP A5120's setup in a stack of four.
HP A-Series Switches - How to Troubleshoot Spanning-Tree Problems
http://h20565.www2.hp.com/portal/site/hpsc/template.PAGE/public/kb/docDisplay?javax.portlet.begCacheTok=com.vignette.cachetoken&javax.portlet.endCacheTok=com.vignette.cachetoken&javax.portlet.prp_ba847bafb2a2d782fcbb0710b053ce0 1=wsrp-navigationalState%3DdocId%253Demr_na-c03661144-2%257CdocLocale%253D%257CcalledBy%253D&javax.portlet.tpst=ba847bafb2a2d782fcbb0710b053ce01&ac.admitted=1415983014553.876444892.492883150
Using the "display stp tc", "display stp brief" and the "display stp root" commands, I realized my stack was not defined as the root. It was changing to other ports connected to other remote switches and Wi-Fi access points.
Ultimately, I added the following command:
stp instance 0 priority 0
And I am now (for the most part) free of the "INSUFFICIENT BANDWIDTH" issue. I do get a message every once in a while from my remote phones, but they are 3000 to 5000 miles away and I can live with a few random bandwidth issues.
So, I guess we can now mark this as solved. Thanks for everyone's input on this subject.