Adjusting Meet-Me Conferencing Parameters

Meet-Me conferencing is an easy to use CUCM feature that allows for quick access to a conference bridge via an internal directory number.

To initiate a Meet-Me conference, a user simply goes off-hook, presses the MeetMe softkey and dials one of the internal directory numbers allocated for Meet-Me conference use.

Subsequent users (internal or external) can join the conference by dialing the assigned directory number.

By default, the MeetMe bridge is configured to accept a maximum of four participants.  This can be easily changed in the CUCM admin console.

Open CUCM administration, go to System > Service Parameters.

Select your CUCM server from the Server drop down.

Then select Cisco Call Manager from the Service drop down.

Scroll down and locate the Clusterwide Parameters (Service) section.

From here you can modify the Maximum MeetMe Conference Unicast setting to allow more participants on the conference bridge.

UC560 Platform Reference Guide

Here’s a link to a very helpful reference guide for the UC560.

Cisco Unified Communications 500 Series Model 560 for Small Business: Platform Reference Guide

Some highlights of the UC560;

• Expandable to 104 users
• Two WIC Slots, 4FXO, 4FXS
• No integrated POE switch

Adding analog ports to a UC520

Recently, I’ve been working with a client to design and standardize telephony solutions across their assisted living facilities.  After determining the UC500 platform would suit our needs from a call management standpoint, the next challenge was analog (FXS) port density.

The client wished to provide an analog telephone connection for select patient rooms.   To control costs, the client wanted the numbers delivered on the same PRI that’s servicing the facility instead of installing individual POTS lines for the patient rooms.

On a UC500 you are limited on the maximum number of  FXS ports (depending on the chassis).  To support 24 or more patient rooms I needed another solution.

Turns out the UC500 supports several analog gateways or ATA’s.  The two solutions I was most interested in were the VG224 and SPA8000.

The VG224 supports 24 analog connections, while the SPA8000 supports eight.  Cisco has published two Application Notes providing information on the configuration of each solution and it’s integration with the UC500.

Configuring a Cisco UC500 to Operate with a Linksys SPA8000 Analog Telephone Adapter (ATA)

Configuring a Cisco UC500 to Operate with a Cisco VG224 Voice Gateway

The SPA8000 is a very inexpensive solution, but the UC520 only supports integration of a single 8-port unit.  (note – only one is supported,  the doc doesn’t say the UC500 won’t work with multiple units)

The VG224 is more costly, but will provide a fairly quick ROI when you factor in the cost of individual analog lines vs using the PRI.

Another factor to consider is licensing, each analog port will require a UC license.

I’ll be implementing the VG224 solution in the not-to-distant future, I’ll let you know how it goes.

Onhook Call Transfer

In Call Manager 6.1, supervised call transfers are the default setting.

In a supervised transfer, Caller A has an active call to Caller B and wants to transfer the call to Party C.  Caller A presses the transfer softkey on their phone and dials the number for Party C.  When Party C answers, Caller A is required to press the transfer softkey a second time to complete the transfer.

With On-Hook Transfer (sometimes called a blind transfer), Caller A only needs to press the transfer softkey, dial the number for Party C and hang up.

Enabling On-Hook Transfers is simple and requires the adjustment of one service parameter.

In the CUCM GUI, go to System > Service Parameters.
Select the appropriate call manager from the Server drop down menu.
Select Cisco CallManager from the Service drop down.
Scroll down to Clusterwide Parameters (Device-Phone).

Locate the Transfer On-Hook Enabled parameter.  Change the parameter value to True.
Click Save.

The change should take effect immediately without requiring a reset of the IP phone.

Note that a supervised transfer is still possible with Transfer On-Hook enabled.

UC520 Part Numbers and Descriptions

The UC520 is available in multiple configurations so I’m posting this primarily for my benefit.  You can find a link to the complete ordering guide here.

UC 520 Ordering Information

Part Number	Description
UC520-8U-4FXO-K9	• 8-user configuration with 4 PSTN trunks (FXO), 4 analog ports (FXS), 8 PoE ports, 1 VIC slot for expansion • Feature licenses for call control, voicemail and Cisco Unified IP Phones
UC520W-8U-4FXO-K9	• 8-user configuration with 4 PSTN trunks (FXO), 4 analog ports (FXS), 8 PoE ports, 1 VIC slot for expansion, Integrated Wireless • Feature licenses for call control, voicemail and Cisco Unified IP Phones
UC520-8U-2BRI-K9	• 8-user configuration with 2 BRI trunks (BRI), 4 analog ports (FXS), 8 PoE ports, 1 VIC slot for expansion • Feature licenses for call control, voicemail and Cisco Unified IP Phones
UC520W-8U-2BRI-K9	• 8-user configuration with 2 BRI trunks (BRI), 4 analog ports (FXS), 8 PoE ports, 1 VIC slot for expansion, integrated wireless • Feature licenses for call control, voicemail, and Cisco Unified IP Phones
UC520-16U-4FXO-K9	• 16-user configuration with 4 PSTN trunks (FXO), 4 analog ports (FXS), 8 PoE ports, 1 VIC slot for expansion • Feature licenses for call control, voicemail, and Cisco Unified IP Phones Note: requires an 8-port Cisco Catalyst Express 520 switch
UC520W-16U-4FXO-K9	• 16-user configuration with 4 PSTN trunks (FXO), 4 analog ports (FXS), 8 PoE ports, 1 VIC slot for expansion, integrated wireless • Feature licenses for call control, voicemail, and Cisco Unified IP Phones Note: requires an 8-port Cisco Catalyst Express 520 switch
UC520-16U-2BRI-K9	• 16-user configuration with 2 BRI trunks (BRI), 4 analog ports (FXS), 8 PoE ports, 1 VIC slot for expansion • Feature licenses for call control, voicemail, and Cisco Unified IP Phones Note: requires an 8-port Cisco Catalyst Express 520 switch
UC520W-16U-2BRI-K9	• 16-user configuration with 2 BRI trunks (BRI), 4 analog ports (FXS), 8 PoE ports, 1 VIC slot for expansion, integrated wireless • Feature licenses for call control, voicemail, and Cisco Unified IP Phones Note: requires an 8-port Cisco Catalyst Express 520 switch
UC520-24U-8FXO-K9	• 24-user configuration with 8 PSTN (FXO), 4 analog ports (FXS), 8 PoE ports, 1 VIC slot for expansion • Feature licenses for user configurations of call control, voicemail, and Cisco Unified IP Phones Note: requires a 24-port Cisco Catalyst Express 520 switch
UC520-24U-4BRI-K9	• 24-user configuration with 4 BRI trunks (BRI), 4 analog ports (FXS), 8 PoE ports, 1 VIC slot for expansion • Feature licenses for call control, voicemail, and Cisco Unified IP Phones Note: requires a 24-port Cisco Catalyst Express 520 switch
UC520-32U-8FXO-K9	• 32-user configuration with 8 PSTN trunks (FXO), 4 analog ports (FXS), 8 PoE ports, 1 VIC slot for expansion • Feature licenses for user configurations of call control, voicemail, and Cisco Unified IP Phones Note: requires a 24-port Cisco Catalyst Express 520 switch
UC520-32U-4BRI-K9	• 32-user configuration with 4 BRI trunks (BRI), 4 analog ports (FXS), 8 PoE ports, 1 VIC slot for expansion • Feature licenses for call control, voicemail, and Cisco Unified IP Phones Note: requires a 24-port Cisco Catalyst Express 520 switch
UC520-48U-12FXO-K9	• 48-user configuration with 12 PSTN trunks (FXO), 4 analog ports (FXS), 8 PoE ports • Feature licenses for user configurations of call control, voicemail, and Cisco Unified IP Phones Note: requires two 24-port Cisco Catalyst Express 520 switches
UC520-48U-6BRI-K9	• 48-user configuration with 6 BRI trunks (BRI), 4 Analog ports (FXS), 8 PoE ports • Feature licenses for call control, voicemail and Cisco Unified IP Phones Note: requires two twenty-four (24) port Cisco Catalyst Express 520 switch
UC520-48U-T/E/F-K9	• 48-user configuration with a T1/E1 interface, 4 additional PSTN trunk ports (FXO), 4 analog ports (FXS), 8 PoE ports, 1 VIC slot for expansion • Feature licenses for user configurations of call control, voicemail, and Cisco Unified IP Phones Note: requires two 24-port Cisco Catalyst Express 520 switches
UC520-48U-T/E/B-K9	• 48-user configuration with a T1/E1 interface, 2 additional BRI trunk ports, 4 analog ports (FXS), 8 PoE ports, 1 VIC slot for expansion • Feature licenses for user configurations of call control, voicemail, and Cisco Unified IP Phones Note: requires two 24-port Cisco Catalyst Express 520 switches

Cisco Unity Virtualization

Earlier this year Cisco released a document outlining design guidance for running Unity 7.0(2) on VMware ESX sever 3.5 or later.

At first glance it’s exciting to see Cisco officially support components of the UC infrastructure in a virtual environment.  However, there are some important design restrictions to consider, some of which may render a virtualized Unity solution impractical for many environments.

Unity virtualization is only supported on Intel platforms.  More specifically, the CPU must be from the Intel Xeon E5400, E5500, L5400 series, or a W5580.

Fibre channel storage is required.  Fibre channel HBA’s and FCoE converged adapters are supported.

NAS/NFS, iSCSI and local storage are not supported.

CPU affinity is required, processor cores must be dedicated to Cisco Unity.  This rules out the ability to use Vmotion and DRS.

A memory reservation of 4096 MB is required.  A memory reservation in VMware means that the virtual machine is guaranteed that amount of physical RAM from the host.

Snapshots and VMware consolidated backup features are supported.

So, with all of these restrictions (there are actually more, I just touched on some of the highlights), why would you want to virtualize your Unity server?  From my point of view, the biggest benefit may come from the ability to implement the fail-over / standby features of Unity in a mixed  physical/ virtual server configuration.  Using VMware to support a warm-standby server recovery scenario could also be a viable option.

A link to the Design Guide for Cisco Unity Virtualization pdf can be found here.

Cell Phone Ringtone RANT

I was on a pre-sales call yesterday.  In these economic times, getting a chance  to be in front of a good qualified opportunity is as valuable as gold.

All of the right players were at the table, the IT manager and the CFO.  We brought along two manufacturer reps.  It was a great appointment.

So, in a situation like this, why wouldn’t you MUTE YOUR CELL PHONE RINGER??

It happened twice in this particular meeting, two different people, both coworkers.  Both with annoying, loud ring tones.

IMO, one of the most unprofessional things you can do during a pre-sales engagement is take a cell phone call.  Second only to your annoying ring tone.  No one cares that you have the latest Nickelback hit as your ring tone.

What a waste of technology and money….

When I first started in this business we didn’t have cell phones.  When I did get one, it was married to my vehicle.  It was called a “Car Phone”.

Yes I know that’s hard for some of you younger folks to comprehend but we actually conducted business without a cell phone glued to our ear, or constantly texting friends, or updating Facebook status.

We sat across from the client and listened.   We took notes and asked open ended questions.  We focused all of our attention on the client.  It’s a lost art, folks just don’t know how to listen and pay attention anymore.

There’s  too much digital noise, most of it unnecessary, at least for a business environment.

CUP Install – CUCM AXL Integration

Cisco Unified Presence obtains user, device and licensing information from CUCM via the AXL API.  The AXL username and password much be specified during the install of Presence.  Typically this account is associated with a user that has the Standard AXL API role assignment in CUCM.

You can verify AXL is running on your CUCM publisher and your specified user account has the proper privileges by using the following procedure:

Open a browser and enter http://<<CUCM Hostname or IP Address>>/axl.
When prompted, enter the user name and password for the associated AXL account.

If everything is functioning correctly you’ll receive this message in the browser window:

Cisco CallManager: AXL Web Service

The AXL Web Service is working and accepting requests. Use HTTP POST to send a request.

If you receive an error message, make sure the Cisco AXL Web Service is activated in CUCM.  (Cisco Unified Serviceability>Tools>Service Activation).  Also, verify the username and password for the account are correct.

Route Pattern Config – 7-digit and 10-digit dialing

In large metro areas, telco providers have eliminated 7-digit dialing from their dial plans.  That’s nice because it simplifies the route pattern config in CUCM.

If you’re lucky, (like me) and your telco still allows 7-digit dialing, you’ll need to make some modifications to the dial plan.  Otherwise, when a user places a 7-digit call, they’ll find themselves waiting for the inter-digit timeout to expire.  (if they even wait that long before calling the help desk)

So, my basic route patterns looked like this. (minus the 911 patterns and patterns added to prevent toll fraud)  It works, but if you make a 7-digit call, you wait for the inter-digit timeout to expire before the call is connected.

9.[2-9]xx[2-9]xxxxxx
9.1[2-9]xx[2-9]xxxxxx

All 10-digit calls using our provider have to be prefixed with the area code (479), otherwise, it’s a long distance call. Using that information, I made a couple of changes to the route patterns.

9.[2-9]xxxxxx
9.479xxxxxxx
9.1[2-9]xx[2-9]xxxxxx

The addition of a 7-digit pattern allows CUCM to match that pattern and immediately connect the call.
Modifying the 10-digit pattern with the area code provides a quick pattern match for 10-digit calls.
The 11-digit long distance pattern remained unchanged.

CiscoLIVE! – Not this year….

Regretfully, I’ve had decline the trip to CiscoLive in San Fran.  Even with the free pass, the cost was escalating rapidly, approaching $2,000 by the time I figured in air fare, hotel and misc expenses.  I’ve decided to focus my attention (and $$) on completing the CCNP in the next few months.

In retrospect, I don’t think Cisco could have picked a more expensive place to have their event. (maybe New York) I know San Fran is their back yard, but come on!  Not everyone can afford a $230/night hotel room.

Suggestion to Cisco, pick some place less expensive in the middle of the country, Dallas, KC, Chicago, St. Louis.  Even Denver or Las Vegas would be a better choice.