Have two Call Managers running 3.09. We have a remote office with 10 phones and a full T1 connecting them back to our main office. The folks at the remote office all use g729 for all calls outside there building (region). Also I am using locations for admission control where I set it to 768 k. All external calls go out of our main office. Frequently the users at the remote end are getting "Out of Bandwidth" errors when they try to call outside or to other IP Phones in our main office. The T1 is not fully utilized during this time. To test that it was indeed the Call Mananger having the problem, I set my phone up just like a remote phone and called another phone on the same network (100mb) as my phone and got the out of bandwidth error. Is there a bug or issue with how the Call Manager with regards to this?
If you are using RTPm header compression then you will only use 11k per call but Call Mangager does not know this and will use 24k as the bandwidth per call.
This means the WAn link has enough bandwidth for 768/11 = 69 calls but Call Manager thinks 768/24= 32 calls. The only way to get around this is to alter the location in Call Manager. So 69 calls at 24k = 1656(For Call Manager. The URL below also details
I am not using any header compression. So my calls are coming through at 24k/call. I have 10 phones at the site and each phone has two lines. So if all users had 2 calls going at the same time then the usage would only be 480k give or take. I would think that 768k would allow for any conferencing or whatever.
Will the Out of Bandwidth message show up if the actual T1 is getting "hammered" or will the call attempt to go through and just have terrible voice quality?
The Location bandwidth that you entered of 768k has absolutely nothing at all to do with the actual bandwidth to that physical network location. CallManager has no idea of the real bandwidth available to different phones/gateways on the network so the Locations feature is really the only way to provide Call Admission Control in a centralized call processing environment right now.
Most likely what is happening is that you are experiencing a "leak" in the Locations function in CallManager, and it somehow never gave back your bandwidth for different calls over time, eventually resulting in you not having any bandwidth as far as the CallManager is concerned.
Many of the Locations related leaking was resolved in CallManager 3.0(11) so you could upgrade to that. If you want to track down exactly what known problem you may be running into to insure that the upgrade would fix it, you can open a TAC case and be prepared to offer trace files from the CallManager.
Due to "political" issues within our office, I am not able to upgrade for a week or so. So can I just set the location to "None" for the mean time to "band-aid" the issue? We only have 10 users over at this remote site.
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.