Runt post: A little VG224, MGCP annoyance…

While I am not a fan of MGCP for general gateway setup, I agree that it’s a good protocol to go with when setting up a VG224 device.  For those not familiar, you can use a VG224 device to connect multiple analog devices to your VoIP network.  Keep in mind that each analog device you add to your IP network makes a baby cry, but if you’re going to do it anyway and have quite a few analog stations, these devices make sense.

Up until recently, I had never had the privilege of configuring one of these guys from scratch.  Like adding any MCGP gateway, though, its a pretty straight forward process, so imagine my surprise when my VG224 wouldn’t register with call manager.

I saw the Unregistered status in Call Manager, and I also saw this on the gateway when I did a #show ccm-manager from the CLI. The status stayed in Registering toward the primary, then would occasionally swap to Registering toward the secondary. What had I forgotten?  Most commonly the mistake is to forget to use the fully qualified domain name as the device name in Call Manager. If “ip domain name” is set on the router, be sure to include the domain name as part of your device name when adding your VG224 to CUCM.  (Pro tip: You can see what the FQDN name should be in the #show ccm-manager output.)

This wasn’t my mistake though.  My “mistake” was simply this – I was trying to get the VG224 to register, but I hadn’t added any configuration to the ports.  My thought was “let’s get this thing registered, then I’ll go back in and add the directory numbers to the ports” – the VG224’s thought, however, was “I’m not registering until this chick defines some ports.”

Alas, after about 20 minutes of checking the configuration against known good configurations, I decided to proceed with adding the directory number information to the ports and worry about the registration at the end.  After I configured the first port, though, the VG224 starting showing as Registered in Call Manager and I proceeded to kick myself for wasting my own time.

Here’s what you *should* see in the output of a properly registered VG224 using MGCP, notice the Domain Name, this is what needs to be added in Call Manager for the device name:

My_VG224_#show ccm-manager
MGCP Domain Name: My_VG_224_my.lab.com
Priority        Status                   Host
============================================================
Primary         Registered               10.10.10.1
First Backup    Backup Ready             10.10.10.2
Second Backup   None                     

Current active Call Manager:    10.10.10.1
Backhaul/Redundant link port:   2428
Failover Interval:              30 seconds
Keepalive Interval:             15 seconds
Last keepalive sent:            14:12:27 CDT Apr 25 2002 (elapsed time: 00:00:14)
Last MGCP traffic time:         14:12:27 CDT Apr 25 2002 (elapsed time: 00:00:14)
Last failover time:             15:33:26 CDT Apr 11 2002 from (10.10.10.2)
Last switchback time:           15:35:01 CDT Apr 11 2002 from (10.10.10.1)
Switchback mode:                Graceful
MGCP Fallback mode:             Not Selected
Last MGCP Fallback start time:  None
Last MGCP Fallback end time:    None
MGCP Download Tones:            Disabled
TFTP retry count to shut Ports: 2

Ways Contact Center Makes Me Cry – chapter 1

One of the fun yet often excruciating parts of working in voice is the opportunity to troubleshooting a wide variety of devices and applications.  For me personally, Cisco Unified Contact Center (UCCX) proves to be one of the more challenging pieces of the software I encounter. This is probably because I started out in voice completely unfamiliar with the product- and also because the application developers may or may not have been smoking crack.  Alas, I jest with that last part- UCCX (formally IPCC) does what it does well. When something goes wrong, however, that box is like a wounded wild animal – there’s a very good chance it will bite your hand off when you try to help it.

Let me relay just one of many anecdotes I have accumulated that illustrate my point.

Executing a simple assignment: to change out the memory in an elderly IPCC server so that it will be ready for its upcoming upgrade to new, snazzy Linux-based UCCX goodness.  For those not aware, starting with version 8 of UCCX, the operating system changes from Windows Server to a Red Hat version of Linux. And there was much rejoicing.

Back to the story though- I gracefully take down the secondary server and pull out 2 sticks of 1 gig memory and put in 2 sticks of 2 gig memory. We’re not talking rocket science here, just your basic hardware swap, expected to be so simple and quick I’ve left the car engine running.

When I power on the what-should-be-happier server, however, I am woefully disappointed when all is not right in Whoville.  I’m greeted with this message of awesomeness:

c:\program files\wfavvid\ClusterData\profile.ini cannot be found and you won’t be making out of here on time tonight, if ever.

That last part doesn’t come standard with this error, but it should.

The effect of a profile.ini file gone missing – the server loses all willingness to be social.  It refuses to join in the UCCX game the other server is playing and instead pouts in the corner.  At this point I’m left with no other options but to figure out what it going to take to reconcile this sullen server with its former BFF.

Browsing to the aforementioned folder, I find that this server has overstated it’s case just a bit in that the file is most certainly there.  But it’s blank. Just a bunch of whitespace with no clues whatsoever as to what dark magical incantations used to abide there. Since 5 minutes ago I didn’t know this now vacant profile.ini file existed and my maintenance window was closing fast, I determined it was time to call up my buddies at TAC and let them enlighten me on this peculiar set of circumstances.

Sure enough, the engineer knew exactly what to do.  If at the time I had been a little more familiar with IPCC on a Windows platform, I likely would have guessed the solution as well since it oozes simplicity. Just copy the contents from the same named file located in the same named directory on the primary server into the now blank file on the secondary server.  Yep, that’s it! Just reboot, and voilà!  Two joyfully reunited IPCC servers strolling hand in hand down the boardwalk. Wonder if I qualify for a Nobel Peace Prize or something…

As a bonus for listening to this tale of woe, here’s what the profile.ini file generally looks like: (ip addresses have been changed to protect the innocent)

#Tue Oct 18 18:05:25 CDT 2011
port=1099
clusterProfile=default
ipAddress=172.10.10.10;172.10.10.1
latestUpdateTimeStamp=1318979125096
Completed=true

Note: In case you were wondering, this particular server was MCS-7825-H3-CCX1-DL380, the version of IPCC was 7 with the latest SUs.

Simplicity

Urban sprawl – New York city is the quintessential example of this phenomena. Why do I bring it up?  One, because I’m currently writing this from a not-so-cushy chair in the bloggers lounge of Interop, hosted in New York.  Two, because it’s the image that for a couple reasons comes to mind while processing all of the information that have been dumped into my overly saturated brain this week.

Reason one this comes mind: network sprawl. Networks just keep growing and growing, constantly bombarded with changes that risk the comforting hierarchal design allowing us OCD geeks to sleep at night.  Every time we wake someone else is demanding we modify our rock solid architecture to incorporate some new fangled something or other.  We grudgingly graft these new devices/endpoints/services into our designs but at a cost. In not too long, our once pristine work of art starts to strongly resemble the monster in Shelley’s Frankenstein – and frankly, we as geeks resent it.

Reason two this comes to mind: networking company sprawl.  Sounds odd, I know, but it’s an apt description when pondering the large, big name, been-around-forever, companies that we’re all familiar with in the networking community. These large companies are all faced with an exigent need to be innovative and encumbered by the weight of supporting past business decisions.  The sheer extent of the empire often results in a series of disjointed business units, complex product lines, incomprehensible licensing models, isolated pools of talent, and a customer base sitting on the edge of their chairs waiting anxiously to see how it all falls out. For the record, we geeks intensely resent this as well.

So when companies like HP Networking announce they are simplifying their product names, I perk up. It’s an immediate sign that someone, somewhere realized that sprawl has gone unchecked for too long and monster creation needs to be mitigated. Hints of such recognition have also been made by other big players, including Cisco, and every time I hear it I get giddy.  I dream of a world with simplified licensing models, BOMs that don’t take a PhD to comprehend, and companies with clearly articulated, streamlined direction. In a word, focus.

I’ve only seen hints though.  I want to see more.  Simplifying product names represents an awesome step in the right direction.  Now how about eliminating confusing redundant products? Cisco’s stance on getting back to core competencies sets my heart a flutter, now how about eliminating cripplingly complexities in the licensing models?

I love that HP Networks invited myself and other front line engineers to their briefings and honest feedback was both requested and given.  I’m sure they are not the only company doing so and for good reason. Listening to the folks doing the implementations can only help in the attempts to narrow focus and reclaim simplicity in the business.

Letting geeks in on company direction is a total win as well.  As geeks we know that change is constant, technology is always in flux, and everyone is just guessing at the next big thing.  We can handle that.  What we can’t abide is a lack of direction, goals, a sense of purpose in all the chaos.  In the words of Douglas Adams “we demand rigidly defined areas of doubt and uncertainty.” So bring us in, spill the beans, and we’ll be more than happy to help you sort through it all.  It’s what we do every day, it’s in our nature, and the results are a windfall for those who seek us out. Leave us in the dark, make us guess, send mixed messages and we’ll drop you like a bad habit. It’s what we do.

For some more great coverage of HP and Interop, check out these bloggers whom I had the great honor of meeting this week as well. I can confirm they are all fabulously awesome in meatspace too:

Aaron Paxson http://teneo.wordpress.com

Andrew VonNagy http://revolutionwifi.blogspot.com/

Brad Casemore http://nerdtwilight.wordpress.com/

Ethan Banks  http://packetpushers.net formerly at http://packetattack.org/

Matthew Norwood http://insearchoftech.com

Stu Miniman http://blogstu.wordpress.com

*A special thanks to @hp_networking who took excellent care of us bloggers, always keeping us fed and in constant supply of caffeine.