We have an AT&T Opteman (10MB) circuit connecting two of our buildings. A 5200 PBX is the only thing using this circuit at the moment. We've yet to move our operations. There are nine phones in our main building programmed to this switch. I will occasionally receive an insufficient bandwidth error. All nine phones are dropped.
I want to say it is the Opteman circuit, but I'm having trouble proving it. Any ideas?
9 phones couldn't use 10MB's if they tried. All phones dropping at the same time means call control was choked out (TCP 5566).
What type of phones are at the local site w/ the 5000?
EXACTLY! We're using 8622Ps and 8622s on a 5200. We've now found that AT&T wants us to use Packet Shaping. Bandwidth tests show our 10M pipe is actually running at 1.5M. An IP call is still a grain of sand in an ocean at that bandwidth. Our Canadian office is connected with a 1.5M T1 service. That pipe handles phones, terminal services and a variety of other tasks without a hiccup. I have a feeling the dropped lines with the aforementioned system is an indicator of another problem. Unrelated to the phone system. If so, I'm glad we're finding it before we move our operations into that facility.
if you have access to the router - I would start there - see if there are errors on the span
you can get the error logs from the system for some more clues and maybe find a pattern
Mark this in your calendars. AT&T admitted there was something wrong. That means the Chiefs will come back and win the Super Bowl!
Whomever admitted fault at AT&T must have been new and hadn't gone through the corporate training program yet.
Well, I have to revive this thread. The AT&T issue has been resolved. We're now getting our full 10M throughput. I've gotten "insufficient bandwidth" errors two days in a row.
Today
-02:249- 13:00 11-25 A032 ALARM '1026' Received Insufficient Bandwidth
-02:250- 13:00 11-25 A032 ALARM '1165' Received Insufficient Bandwidth
-02:251- 13:00 11-25 A032 ALARM '1194' Received Insufficient Bandwidth
-02:252- 13:00 11-25 A032 ALARM '1091' Received Insufficient Bandwidth
-02:253- 13:00 11-25 A032 ALARM '1196' Received Insufficient Bandwidth
-02:254- 13:00 11-25 A032 ALARM '1198' Received Insufficient Bandwidth
-02:255- 13:00 11-25 A032 ALARM '1224' Received Insufficient Bandwidth
-02:256- 13:00 11-25 A032 ALARM '1019' Received Insufficient Bandwidth
-02:257- 13:01 11-25 *** offhook_idle_sts_t::enter - voice channel resources are not idle for ID(2:'1019')
-02:258- 13:01 11-25 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:259- 13:01 11-25 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1019')
-02:260- 13:01 11-25 *** offhook_idle_sts_t::enter - voice channel resources are not idle for ID(2:'1019')
-02:261- 13:01 11-25 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:262- 13:01 11-25 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1019')
-02:263- 13:01 11-25 *** offhook_idle_sts_t::enter - voice channel resources are not idle for ID(2:'1019')
-02:264- 13:01 11-25 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:265- 13:01 11-25 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1019')
-02:266- 13:03 11-25 *** offhook_idle_sts_t::enter - voice channel resources are not idle for ID(2:'1019')
-02:267- 13:03 11-25 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:268- 13:03 11-25 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1019')
-02:269- 13:03 11-25 *** offhook_idle_sts_t::enter - voice channel resources are not idle for ID(2:'1019')
-02:270- 13:03 11-25 *** DEALLOCATE_VOICE_CHANNEL FAILURE - Connection ID Invalid.
-02:271- 13:03 11-25 *** Connection ID - '@03@5'
-02:272- 13:03 11-25 *** Voice Channel - 1-0x01.0x30 [2.16.1] [7.77.1] 1 0-0x00.0x00 1-0x04.0x4D [7.0.0] '@03X9'
-02:273- 13:03 11-25 *** offhook_idle_sts_t::enter - voice channel resources are not idle for ID(2:'1019')
-02:274- 13:03 11-25 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1019')
-02:275- 13:04 11-25 *** Voice channel already allocated. Disconnecting voice path and re-allocating.
-02:276- 13:04 11-25 *** Connection ID - '@03@#'
-02:277- 13:04 11-25 *** Voice Channel - 1-0x01.0x30 [2.16.1] [7.77.1] 1 0-0x00.0x00 1-0x04.0x4D [7.0.0] '@03X9'
-02:278- 13:04 11-25 M8027 SVR HW SS [7.0.0]: Illegal Data Byte Sent To Board: [C8,07,19,06,4D,4D]
-02:279- 13:04 11-25 M8027 SVR HW SS [7.0.0]: Illegal Data Byte Sent To Board: [C8,07,19,00,4D]
Yesterday
-02:294- 11:55 11-24 A032 ALARM '1026' Received Insufficient Bandwidth
-02:295- 11:55 11-24 A032 ALARM '1165' Received Insufficient Bandwidth
-02:296- 11:55 11-24 A032 ALARM '1194' Received Insufficient Bandwidth
-02:297- 11:55 11-24 A032 ALARM '1091' Received Insufficient Bandwidth
-02:298- 11:55 11-24 A032 ALARM '1196' Received Insufficient Bandwidth
-02:299- 11:55 11-24 A032 ALARM '1198' Received Insufficient Bandwidth
-02:300- 11:55 11-24 A032 ALARM '1224' Received Insufficient Bandwidth
-02:301- 11:55 11-24 A032 ALARM '1019' Received Insufficient Bandwidth
-02:302- 12:03 11-24 A001 ALARM Alarm Manually Cleared By '1262'
-02:303- 12:03 11-24 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:304- 12:03 11-24 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1262')
-02:305- 12:03 11-24 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:306- 12:03 11-24 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1262')
-02:307- 12:03 11-24 A001 ALARM Alarm Manually Cleared By '1262'
-02:308- 12:03 11-24 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:309- 12:03 11-24 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1262')
-02:310- 12:03 11-24 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:311- 12:03 11-24 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1262')
-02:312- 12:03 11-24 A001 ALARM Alarm Manually Cleared By '1262'
-02:313- 12:03 11-24 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:314- 12:03 11-24 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1262')
-02:315- 12:03 11-24 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:316- 12:03 11-24 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1262')
-02:317- 12:03 11-24 A001 ALARM Alarm Manually Cleared By '1262'
-02:318- 12:03 11-24 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:319- 12:03 11-24 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1262')
-02:320- 12:03 11-24 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:321- 12:03 11-24 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1262')
-02:322- 12:03 11-24 A001 ALARM Alarm Manually Cleared By '1262'
-02:323- 12:03 11-24 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:324- 12:03 11-24 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1262')
-02:325- 12:03 11-24 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:326- 12:03 11-24 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1262')
-02:327- 12:03 11-24 A001 ALARM Alarm Manually Cleared By '1262'
-02:328- 12:03 11-24 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:329- 12:03 11-24 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1262')
-02:330- 12:03 11-24 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:331- 12:03 11-24 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1262')
-02:332- 12:04 11-24 A001 ALARM Alarm Manually Cleared By '1262'
-02:333- 12:04 11-24 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:334- 12:04 11-24 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1262')
-02:335- 12:04 11-24 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:336- 12:04 11-24 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1262')
-02:337- 12:04 11-24 A001 ALARM Alarm Manually Cleared By '1262'
-02:338- 12:04 11-24 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:339- 12:04 11-24 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1262')
-02:340- 12:04 11-24 *** ui_keyset_t::present_idle returning UI_STATUS_FAILURE
-02:341- 12:04 11-24 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1262')
-02:342- 12:07 11-24 *** offhook_idle_sts_t::enter - voice channel resources are not idle for ID(2:'1019')
-02:343- 12:07 11-24 *** idle_sts_t::enter - voice channel resources are not idle for ID(2:'1019')
-02:344- 12:08 11-24 *** offhook_idle_sts_t::enter - voice channel resources are not idle for ID(2:'1019')
-02:345- 12:08 11-24 *** Voice channel already allocated. Disconnecting voice path and re-allocating.
-02:346- 12:08 11-24 *** Connection ID - '@0944'
-02:347- 12:08 11-24 *** Voice Channel - 1-0x01.0x23 [2.3.1] [7.63.1] 1 0-0x00.0x00 1-0x04.0x3F [7.0.0] '@0928'
-02:348- 12:08 11-24 M8027 SVR HW SS [7.0.0]: Illegal Data Byte Sent To Board: [C8,07,19,06,3F,3F]
-02:349- 12:08 11-24 M8027 SVR HW SS [7.0.0]: Illegal Data Byte Sent To Board: [C8,07,19,00,3F]
This concerns me as well
-02:350- 13:14 11-24 *** Voice channel already allocated. Disconnecting voice path and re-allocating.
-02:351- 13:14 11-24 *** Connection ID - '@099#'
-02:352- 13:14 11-24 *** Voice Channel - 1-0x01.0x9B [1.59.1] [7.55.1] 1 0-0x00.0x00 1-0x04.0x37 [7.0.0] '@0918'
By default, the 5000 has to detect less than 60% of the frames arriving in time AND this has to be sustained for over 5 seconds to generate alarm 32. So, basically less than 60% of what you put on the wire made it to the other end in time. Not good. Latency all the way to me.
Who manages the routers? Do you have access? What are you doing for QoS?
Here's the response from our network admin.
"We have Class of Service options from the phone company. This relates directly to the question I had a while back about which DSCP setting Inter-Tel marks on
packets. AT&T likes to use DSCP markings for class of service."
Inter-Tel marks no DSCP settings by default. You have to program ToS values on each endpoint plus the P6xxx interfaces in the 5000. Usually this is set to ToS 184, which translates to EF or DSCP 46.
Fantastic information. Our network guy is on it.
Will this need to be done on all nodes and IP endpoints?
There is also a software bug that I have ran into between a 5000 and an Axxess. It may or may not relate to this situation but I posted the notes I have:
The Axxess IPRC has an unsupported fax pass-through mode for IP private networking. In this mode, the IPRC detects a fax tone and switches the encoding to G.711. The IT-5000 uses T.38 for fax-transmission for IP private networking. These methods are not compatible. Attempting to use them together will result in Insufficient Bandwidth Alarms and one-way or no audio.
There is also a bug in some Axxess versions that sets the Fax Detection Sensitivity to 1 when it is programmed to 0 (off, the default) in the database. This causes frequent erroneous Insufficient Bandwidth alarms to occur.
In Axxess, the settings are in OLM mode under Node IP Connection Groups-P8xxx-IP Call Configuration.
There is a chance of false fax detection when the Fax Detection Sensitivity level is set to a low value. It seems common for the sensitivity level to be set to 1 (10 ms) which will result in frequent false detections.
When networking Axxess and IT-5000 nodes, both sides should have fax detection maximized - As a precaution to avoid the known Axxess bug, set the Fax Detection Sensitivity to a value of 100 (100 is maximum) on all Node IP Connection Groups (P8xxx) on both the Axxess and IT-5000 nodes.
NOTE - IT5000 to IT-5000 or Axxess to Axxess, this does not need to be set.
Examine the Network Diagnostics Log (.ndl) on both systems for a good indication that this is happening. This log shows Insufficient Bandwidth Alarms. If one system has the majority of the alarms, there is a good chance that the opposite node has incorrect fax settings.
This only applies to IP private networking calls with a combination of IPRCs and IT-5000s. Insufficient Bandwidth Alarms on IP endpoint, Axxess-only, or IT-5000-only calls probably have another cause.
Awesome post! This is why I subscribe to this group. The Axxess was already set to 100. The two 5000s were set to 0. I'm only having this problem with one of the nodes. It happened over the weekend and this morning. I've made the changes. Hopefully it will take care of the issue.
So far, so good. No drops to report.
Two more weeks have gone by with no problems. Thank you.
I know this is an old post but just wondering how or where you generated those reports? We just had a insufficient bandwidth message on one of our phones.
Appear to be from 'System Freeze' logs, 'Message Print'.
I've been having similar problems with Insufficient Bandwidth alarms that we can't explain, so I'm willing to try the fax detection settings.
Does anyone know if calls will be dropped when the values are changed? I know that IPRCs sometimes reset during programming.
I'm revisiting this problem DND did you try this and did it help? dfleschute? problems never came back?
Changing the fax detection settings seems to have corrected the problem.
It's very rare that I see an alarm.