Call Manager – Justin On VOIP (and more)

CUCM: The Logout Profile

Good Morning Readers!

Today’s post is quick and dirty. If you work in an environment where Extension Mobility is widely used, the content of this post is probably common knowledge and you can stop reading here if you like.

For those curious about Extension Mobility, there are a ton of resources on the Internet that can show you how to use and configure it as well as how it impacts your CUCM licensing. If you don’t know what CUCM stands for, this probably isn’t the post for you.

I was recently dealing some odd behavior from one of the 7841 IP Phones in my lab. Despite the fact that I had logged out my Extension Mobility (EM) user, their details (their User Device Profile) were still showing up on the physical phone. I reset the phone, checked the cluster for DB errors, and scratched my head a lot. I then proceeded to smack my head when I remembered the logout profile configuration in CUCM.

If you know anything about Unified Communications Manager Express (UCME), you know that the logout profile is very common on this platform. EM cannot exist on UCME without it. In CUCM we get spoiled, we can use existing device configuration details and do not have to specify a logout profile, there is however still a place for one.

In a perfect world a logged out EM configuration (in CUCM) should look like this:

This denotes that when a user logs out of the phone, the phone will use whatever configuration data exists in CUCM.

If however, a logout profile gets set (as shown below), the phone will display that profile upon an EM logout.

This is exceptionally confusing when the profile that was just logged out happens to also be the logout profile!

Obviously this was a misconfiguration on my part. Instead of just checking the box to enable Extension Mobility, I also specified a user profile. This lead to several minutes (a good half hour) of me troubleshooting a problem that inevitably had no problem at all.

Thanks for reading and hopefully you got some enjoyment laughing at my screw-up.

-J

The Upgrade Follies: Communications Manager 9.x to 11.x

If you’ve been in the Cisco voice game for more than a second, you’ve probably done a Call Manager upgrade or two. In my case, I lost count around version 4.1 to 4.3. My record for the longest upgrade that I was a part of is 72 hours…straight! It was painful but such was life back in those days.

With the advent of virtualized Cisco voice and all of its associated parts the upgrades have definitely improved, but that does not mean that the gotchas aren’t still lurking.

For one of my current customer projects I am upgrading a virtualized 9.x environment to 11.x. Unity Connection was upgraded first using CLI. CUC luckily doesn’t have a whole lot of gotchas assuming the engineer that built it originally used an OVA template and followed the correct steps. All you need to do is apply the new “keys” COP file (ciscocm.version3-keys.cop.sgn) and you are good to go. Maybe it isn’t quite that easy, but you get the picture. Communications Manager (Call Manager) is a far different animal. For the sake of automation, I’m doing the CM upgrade using Prime Collaboration Deployment (PCD). PCD is a separate application server that comes with your upgrade order on Cisco’s Product Upgrade Tool (PUT). PCD basically allows you to take a CM cluster (including IM&Presence) and script the upgrade so that you can basically click once and wait. If only it were that easy…

There are a couple gotchas that I’ve learned the hard way. I’ll list them below, hopefully they can help you out during your next upgrade.

Licensing. If you are going to do an upgrade, do your homework. I could write an entire post on licensing but for a 9.x to 11.x upgrade it really just involves doing clean up. If you are getting that ugly little licensing warning from Cisco when you log into your system, clean it up before attempting to upgrade, you’ll save yourself from a lot of pain later.
Disk Space. I get it, hard drive space is cheap, but OVAs are not future proof. The original mid-size build OVA for CM 9.x specified an 80 gig virtual drive. The 80 gig drive model is not not supported by fresh 11.x installs. What bites engineers in the ass is a pesky little storage location known as the common partition. When the 11.x upgrade script first verifies that an upgrade is possible, it checks the amount space available in that common partition, if less than 25 gigs space is available the upgrade will fail. There is an excellent Cisco Support Forums post about this failure here. So what do you do if the above scenario is true?

There are 3 options…

You can go into your server’s TFTP directory and manually remove old crap that you don’t need. If you happen to remove crap that you do need, bad things WILL happen, so keep that in mind….
You can apply the following COP file ciscocm.free_common_space_v1.3.k3.cop.sgn. This little beauty will remove any software tied to the inactive partition of the system which may include software tied to the common partition, thus giving you your required space. This is a really cool idea/theory, but I’ve had mixed results.
This is the scariest sounding one, but its actually not that bad. There is a second COP file that you can run. The ciscocm.vmware-disk-size-reallocation-1.0.cop.sgn; This file will allow you to resize your virtual disk in VMWare ESXi and make CM ok with it (I tend to expand 80 gig disks to 160 as long as the physical systems allow it). **Changing the size of the disk without the COP file basically guarantees you a rebuild from scratch and possibly a resume` generating event.** As I said, its not that bad, but there is a catch. In a couple of different cases, your results may vary.

1. If your CM system is running on a snapshot within ESXi, your virtual disk size adjustment option will be grayed out, this will inevitably cause you to panic and wonder if a PCD migration is your only option, its not. You can actually delete the snap shot and once you do that you should be able to change your disk space. Once you do this, restart your VM and let it go through its process. It will reboot 2 times during the start-up process as it expands the disk in the “BIOS” and then in the initial CM boot process If you’ve done it correctly you’ll see your partitions aligned and your new disk size in both the CLI and web console.

2. In some cases the allocation of your virtual disk may be as large as the blocks with in the disk controller will allow it to be. If this is the case, you have two options. Option 1 (see option 1 above). Options 2, migrate instead of upgrade using PCD. It will take more time but you and/or your customer’s data should be safe and back where it belongs.

Whew… that was a long post. I hope it helps someone. For those of you new to upgrades, you’re lucky, they keep getting easier. If you have questions, leave a comment and we can have a discussion. Thanks for reading!

-Justin

Cisco Jabber SRV Records: Being a Knowledgeable & Helpful Collaboration Engineer

If you’ve deployed Cisco’s IM & Presence (formerly Cisco Unified Presence or CUPS) and its associated Jabber product line, you know all about DNS SRV records, or at least you should.
If you don’t know about them or if you are a little rusty, Cisco has a good document (link below) that you should get to know intimately…
http://www.cisco.com/c/en/us/td/docs/voice_ip_comm/jabber/Windows/9_7/CJAB_BK_C606D8A9_00_cisco-jabber-dns-configuration-guide.html

SRV records allow servers to advertise service locations within the core of the DNS architecture. For example: _cuplogin._tcp.example.com is an SRV record the Jabber looks for during service discovery and sign-in. The record above points at the IM & Presence service across port 8443 which happens to be what Jabber/IM&P uses for authentication. There are SRV records that Jabber looks for for directory services as well as Collaboration Edge (Cisco Expressway) which is its own animal.

Without SRV records flexible Jabber deployment becomes difficult and Collaboration Edge integration becomes next to impossible.

So we know that SRV records are important, but are they really our problem as Collaboration Engineers? I guess that depends on how broad your IT shop or your customer’s IT shop is. You may have, at your disposal, wonderful Server Engineers who know DNS like you know Call Manager, but not every situation is that clean.

I realize that not every enterprise uses Windows for internal DNS, but since the majority seem to, we’ll cover Windows DNS. My system is a 2008 Server Standard instance.

– What SRV records do we need to add? Cisco gives us a good run down in the document referenced above, I copied the below passage from that document.

The following is an example of the _cisco-uds SRV record:
_cisco-uds._tcp.example.com
priority       = 1
weight         = 5
port           = 8443
svr hostname   = cucm1.example.com

The following is an example of the _cuplogin SRV record:
_cuplogin._tcp.example.com
priority       = 5
weight         = 100
port           = 8443
svr hostname   = cup1.example.com

**There are additional records required for Collaboration Edge**

In the outputs above, you’ll see the SRV record and its priority, weight, port and host the has the service. You’ll notice in the SRV record itself that TCP is called out. If these were UDP SRV records you would of course see UDP in the SRV.

– How does this translate to Windows DNS? Pretty easily actually…

Below is the DNS Manager screen from my server.

You’ll see that under my domain’s Forward Lookup Zones there are several folder entries including _tcp, _udp, and others.

If you right click on the domain (image below) you’ll able to add Other New Records and from here you can select SRV records

Once you select your SRV record type you can begin configuring the SRV record (shown below)

Once you fill in the particulars and click OK, you’ll see your record(s) under the _tcp organizational folder (shown below)

From there, repeat the process to add the other records that you need.

We haven’t really talked about priority and weight and they do exactly what you might expect them to do. Multiple systems can respond to the same SRV record within the same DNS domain. Like anything else, someone has to be first. Assigning a priority and a weight allows you to both build redundancy and load balance across multiple hosts. For instance if you have a CUCM PUB and a SUB, you may be want the SUB to respond first and thus would give it a higher priority for its _cisco-uds record.

In closing, you may never need to know how to add SRV records but if you do, hopefully you’ll remember this post and be successful in your deployment.

-Justin

Configuration Example: Cisco CUBE with FlowRoute

So you’ve decided to step-up and get a “Big Boy” phone system. You’re done with CME and you’ve moved to Call Manager (Cisco can call it whatever it wants, but to many of us it will always be Call Manager). But wait, there is a problem… Call Manager won’t natively peer to your ITSP, so what do you do? While there may be many solutions, the best one that I have found involves using Cisco’s Unified Border Element or CUBE. CUBE, for those of you new to Cisco voice technology is a fancy term for a SIP proxy. The CUBE pairs with your ITSP and routes calls to and from your Call Manager via SIP or H.323 . Below is the topology that I am working with. Yours may look a little different and we’ll get into these differences as we progress.

I mentioned topology differences and the biggest one is probably the firewall (ASA 5505) sitting between my CUBE and my ITSP. In an ideal world I’d give my CUBE router a public address and let it talk directly to the internet, this is not an ideal world. My ISP is small and stingy with their public IP addresses. It took a few fights and some extra cash to get one dedicated public IP on my ASA and getting a second is simply not worth the trouble. I’ve read all of the stories regarding trying to pass SIP through a firewall and while there are some caveats, I’ve made it work.

Connectivity is Everything…

It seems like a simple enough statement, but in terms of building and maintaining voice network connectivity really is everything. I prefer to keep it simple and the simplest way to build my topology was to keep the same protocol throughout. With the exception of the SCCP Phone (Call Manager does just fine translating SCCP to SIP and vice versa) every other connection is SIP.

Call Manager to CUBE & CUBE to Call Manager – SIP
CUBE to ITSP & ITSP to CUBE – SIP

By keeping the majority of my transactions SIP, I take away at least one point of failure. I mentioned earlier that you could configure the CUBE router connection to CM via H.323 and while I know that configuration can work just fine, why make it more complicated than it needs to be? The biggest thing to keep in mind when deciding on connectivity is “Can I troubleshoot it easily when it does not work?” Its a lot easier to look at a straight SIP trace.

Bring on the configs…

We’ll start with the CUBE first (This CUBE is running archaic 12.4 code).

The voice service commands are pretty standard. In the allow-connections section sip to sip is the key portion. Remember to configure your sip registrar settings here as well.

The next piece we’ll look at, are the voice translation rules. The first rule points my DID (I only have one in this scenario) to an extension on my CM. The second rule puts my DID as the number mask for all outgoing calls. Without this second translation, I’d have to do additional configurations in CM, the translation rule is easier.

Now, we’ll look at the dial-peers. I’ve got one for the incoming calls (from the ITSP) (Dial-peer 2) One for outgoing calls (I’m just dealing with LD calls right now) (Dial-peer 10) and one for communication with CM (Dial-Peer 100). Note where I applied my translation rules.

Finally, we’ll look at the SIP-UA (SIP User Agent) configuration. This is the actual heart & soul of CUBE. This is the connection and authentication to the ITSP. You may find that your ITSP we’ll peer with your specific public IP address rather than give you a user-id and/or password. Peering with an IP is in theory much more secure as spoofing an IP end to end is much more difficult. Notice the credentials and authentication sections. They both include a username and password. The credentials line identifies your CUBE to the ITSP and the authentication line gets you through door.

Next, we’ll take a look at the CM trunk configuration (My CM is 9.x)

First the initial configuration of the trunk. You’ll assign your device pool, media resources and things of that nature here…

Now, we’ll look at the incoming calls section of the trunk config. You’ll want to make sure that you direct inbound calls to the Calling Search Space that includes the Directory Numbers that you intend to answer the calls. You can also adjust things like significant digits. Generally speaking, I always want the CUBE/router to send me everything and then I’ll configure CM to pick and choose what it wants.

Finally, we’ll look at the connectivity section of the SIP trunk config. Here you’ll specify the address of your CUBE and your SIP and SIP Security profiles. These are standard profiles from Cisco and no tweaking is required to make this work.

Like most other things that Cisco creates, there are far more options in the trunk configuration than most configurations will require.

Finally, lets take a look at the ASA (This ASA is running 8.4(7) code)

First, we’ll take a look at my network and service objects. For this scenario, I defined the RTP range and SIP protocols. While not necessary, I defined SIP with both UDP and TCP entries.

Next, we’ll take a look at the NAT statements. While the CUBE is not a NAT aware SIP Proxy, the ASA provides some assistance in maintaining the end to end SIP headers required for successful peering and usage.

Finally, we’ll take a look at the access-list portion of the configuration. These are pretty straight forward…

Additional Notes…

The phone & route pattern configurations for this example are not impressive. The phone (7961) is configured with a Directory Number and pointed at a CSS with access to PSTN calling features. The basic route pattern is configured as 9.1XXXXXXXXXX and pointed at the SIP trunk created above. I discard the 9 (pre-dot) and send 11 digits to my ITSP. You don’t need the 9 but it keeps the scenario in line with most business systems.

I’ve struggled to find an ITSP that supports a true integration with the CUBE. There are several ITSPs that work with Asterisk and other open-source IP PBX platforms but CUBE is its own animal and as such these “Asterisk ITSPs” usually don’t work properly or in many cases don’t work at all. When I came across FlowRoute http://www.flowroute.com I was initially skeptical but as I’ve used their service more and more, I’ve become a bigger and bigger fan. The first thing that you’ll notice about FlowRoute is that anyone can try it out. Simply sign up and you’ll get some free time (minutes to place test calls) to peer with them and try your system out. If your system doesn’t work and/or you aren’t happy with the performance, go another direction. If (and this is much more likely) you really enjoy the service. Deposit some money, purchase a DID and keep on going.

Final Thoughts…

I hope this example configuration has helped someone. What I’ve shown is not difficult and is actually quite simple when compared to other voice configurations. That being said, we all need to learn somewhere and hopefully I’ve helped someone do that.

**DISCLAIMER** All information posted in this article was accurate as of the date/time it was posted. Images posted in this article follow the same copyright guidelines as the article itself. Plagiarism is not a gray-area issue, it is wrong and in some cases illegal. If you like this article link to it, do not copy it.

Tag: Call Manager

CUCM: The Logout Profile

The Upgrade Follies: Communications Manager 9.x to 11.x

Cisco Jabber SRV Records: Being a Knowledgeable & Helpful Collaboration Engineer

Configuration Example: Cisco CUBE with FlowRoute

Menu