Unresolved - 6608 Conference Bridge
Tried to initiate 3-person ad-hoc conference between HQ and SiteA with HQ phones having 6608 as conference bridge resource and received message stating that the conference could not be created. Unsure why.
Tried to initiate 3-person ad-hoc conference between HQ and SiteA with HQ phones having 6608 as conference bridge resource and received message stating that the conference could not be created. Unsure why.
Could not find National or International Number Prefix sections to prefix PSTN codes upon redial.
Callmanager Express > B-ACD and Tcl Call-Handling Applications > Cisco Unified CME Basic Automatic Call Distribution and Auto-Attendant Service (B-ACD)
Copy and paste code into notepad from approximately 3/4 the way down the page. This will configure the “aa” service as well as the “queue”. Include the voip dial-peer for local dialing from CME phones, otherwise reference the pots dial-peer for inbound PSTN call handling.
I sometimes get confused as to which order to have the channel selection when configuring a PRI, be it MGCP 6608 or otherwise.
TOP_DOWN (first to last) or BOTTOM_UP (last to first). If you are not sure which port order to use, choose TOP_DOWN.
ASCENDING order (channel 1 to channel 23) or DESCENDING order (channel 23 to channel 1).
TOP_DOWN = ASCENDING
BOTTOM_UP = DESCENDING
To minimize glare conditions on the Telco circuit it is almost always recommended to configure the gateway opposite of what the telco is passing.
To control multicast MoH, be sure on what is required. Determine whether multicast MoH is required from the Callmanager MoH servers to a remote branch or instead multicast MoH from the remote branch’s flash. This will determine what number you set the “hops” setting to under the MoH server definition under Callmanager. For streaming locally from remote branch flash, the hop count should be set to 1. If streaming from Callmanager in the HQ, the hop count should be set higher, such as 4.
Additionally, use separate regions/device pools to control what codec is used for the MoH if streaming from Callmanager. If streaming locally using say G.729, ensure that the correct multicast IP address or port is specified in the local “call-manager-fallback” configuration.
Ie. If using G.729 for mcast MoH from the remote branch’s flash, the IP address would be 239.1.1.3 port 16384, or if using Port increments, 239.1.1.1 port 16386.
When integrating Unity with both Callmanager and Callmanager Express (Two Clusters under one Callmanager Configuration in the UTIM), it is known that MWI broadcasts go out on both clusters, however it is undetermined on how you can control regular outdial and avoid outdial to the wrong cluster.
Those that have configured CUE know that it sometimes responds erratically to changes. For example, when the IP address is changed. Often times you will find phones dialing into the pilot number and disconnecting quickly or simply hearing dead air. Usually this means you need a reset of the CUE module, but I have witnessed situations where it has required two reloads of the module. The best command I have found to help isolate the problem is the “show call active voice” command. It will show you all the call legs as well as the target/destination IP addressing for the voip legs. This information can easily help you determine what IP address CME or CM is using when accessing the CUE module. Make sure you keep the “dead air” call up to CUE when you issue this command otherwise you will not see the desired information.
As you can see I am fortunate enough to have everything needed for the CCIE Voice lab. Ebay is a wonderful thing and also I’ve been able to take advantage of partner NFR pricing as well. It is still a significant investment but like any geek out there, being able to tinker and play with whatever scenario you want is an awesome way to learn. There is another APC 1500 going in shortly so I can evenly distribute the power load. When the entire rack is running it draws about 1100watts which isn’t too terrible considering everything running. Also where I live in Canada the power rates aren’t too ridiculous. I’ve got everything remotely accessible via VPN through the ASA5505 firewall. This allows me to remotely control power to every device through the NPS at the top of the rack. I have found this feature to come in very handy depending on what type of lab I am working on. For example, if I am working on CUE, I can just have the specific router, switch and terminal server running. As you can also likely guess, everything that has to do with Callmanager, Unity, IPCC Express, and many other Cisco software products are all running in VMWare ESX 3.0 on the server in the bottom of the rack. This box is a dual Opteron 2.0ghz with 16GB of ram, 3 Broadcom Gigabit NICs, and 1TB of SATAII and SATA disks.