However, there were a few notable experiences/lessons learned along the way that are worth passing on.  Some of these experiences may be unique to the equipment I worked on. You are welcomed to verify these findings against your own environment.

Configuring SRV Records

A typical CUC SIP integration uses SIP trunks configured in CUCM, one for each Unity Connection server.  Using route groups, you have some control in determining how calls are sent across the trunks.

The “Design Guide for Cisco Unity Connection Release 8.x” refers to SRV records as another legitimate deployment model.  When I read this, I was pleasantly surprised.  It seemed a reasonable way to remain consistent in my design since the CUPS integration was using an SRV.

When integrating with Cisco Unified CM through a SIP trunk, it is possible to balance voice traffic that the Connection cluster server pair handles by using one of the following methods:

• (Recommended) Use a Route List in Cisco Unified CM.
• Use DNS-SRV – RFC 2782.
• Use a SIP gateway DNS-SRV.

Using an SRV record, I could configure a single SIP trunk in CUCM (e.g. cucvm.domain.local), which would point to my Unity Connection servers.  This would reduce the amount of configuration and make it easier for troubleshooting in the future.

Long story short, after opening a ticket with TAC, I found that the Unity Connection team had no idea that Connection could support (allegedly) SRV-based integrations with CUCM.  Though the design guide mentioned SRV records, there was not one reference of this in the configuration or administration guides.

My verdict?

1. Don’t bother with SRV records for Unity Connect right now.  Though SRVs allow for more granular load balancing, a simple route list in CUCM will suffice for most customers.
2. Cisco needs to determine if SRV deployments will be supported or not.  If so, TAC engineers need to be briefed and configuration documents need to be updated.  If not, remove the reference in the design guide to reduce confusion.

CUC 8.6(2) OVA Template

My current environment is running UCS B200 M2 series blades with Intel Xeon E5649 2.53GHz processors.  When deploying the OVA template, it appears that the minimum CPU reservation defined is 6 Mhz higher than what vCenter allows.

The error: Could not power on VM: CPU min outside valid range.

This issue is still outstanding with TAC.  If you are installing Unity Connection 8.6(2a) on a B-Series, I’d be interested to see if you experience the same issue.  The OVA template being used: CUC_8.6.2_vmv7_v1.5.ova

East of Target Field

The past two weeks have been incredibly busy.  I’m working on a UCS B-Series based project that includes CUCM, CUC, CER, CUPS, and CUEAC (what I call The Iron Fist).  I only had nine working days to get the environment to the point where users could train on test phones.

In a perfect world (i.e. non-reality), nine days would be plenty of time.  In a perfect world, the phone system would arrive pre-configured on a pallet.  Position it in the data center, plug it in, and you’re done.  Hmm…welcome to reality.

Let me just say, deploying a unified communications platform is not simple.  It gets easy over time, but that doesn’t simplify the process.

Back on CiscoVoiceGuru.com

After some indecisiveness, I’ve decided to keep my technical posts separated from the rest of my life.  It ended up being more of mental barrier to me than I thought.

The RSS for this blog is: http://feeds.feedburner.com/CiscoVoiceGuru

Upcoming Content

I’m going to shift the focus of this blog back to it’s original purpose; namely, documenting things that I learn through practical experience and studies.  Here are a few posts that I’m working on right now:

• SRV Records in a CUCM-CUPS Integration
• Populating Active Directory user profile pictures in CUPC/Jabber
• Unity Connection Single Inbox with Exchange 2010 Cheat Sheet
• Configuring IPMA the Right Way
• CUPS 8.6(3) Reflections – Bugs and Frustrations

Once I finish a major cutover next week, I’ll start cranking these out.  The content is in Evernote, but I still need to add some screenshots and format them correctly.

Video Walkthroughs

Question: Would anyone be interested in me posting some short video walkthroughs of how to configure different UC features?  I’d like to experiment with using screencasts as blog content, but I’ll only do it if people would find it useful.

I’m becoming increasingly convinced that Cisco UCS product line is going to change the way we view server virtualization.  It’s innovative and brings a tear to this “tech head.”

Integrated server blades, networking and management make UCS a strong contender for fast-growing data centers in this exclusive Network World test.

By Joel Snyder, Network World

December 19, 2011 12:09 AM ET

If you’re tempted to think of Cisco‘s Unified Computing System (UCS) as just another blade server — don’t. In fact, if you just want a bunch of blades for your computer room, don’t call Cisco — Dell, HP, and IBM all offer simpler and more cost-effective options.

But, if you want an integrated compute farm consisting of blade servers and chassis, Ethernet and Fibre Channel interconnects, and a sophisticated management system, then UCS might be for you.

Cisco sees UCS as key cloud building block

When Cisco introduced UCS in 2009, based on a 2006 investment in Nuova Systems, everyone had an opinion about Cisco entering the server business. Now that they’ve had a couple of years to prove their case, we wanted to take a closer look and see whether UCS had lived up to the initial excitement.

We found that for some environments, Cisco has brought a compelling and valuable technology to market. Cisco UCS offers enterprises greater agility and lower deployment and maintenance costs, and is especially attractive in virtualization environments.

While UCS won’t be attractive in some data centers, and won’t be cost effective in others, it does have the potential to make life, and computing, easier fordata center managers.

Under the hood

Cisco UCS has three main components: blade server chassis and blades, a fabric interconnect, which is networking based on Cisco Nexus 5000 switchhardware and software, and a management system resident within the fabric interconnect that controls it all.

The blade server chassis is fairly simple, and there’s a competitive selection of blade CPU and memory options. Networking is integrated, not just within the chassis, but between multiple chassis (up to about 20 within a single management domain today).

But what really makes Cisco UCS worth considering is the integrated hardware and configuration management. In UCS, a single Java application (or CLI) is used to manage the hardware and network configuration for up to 176 blades today, with a doubling of that expected to hit the streets soon.

The management system runs as a software process inside of the (mandatory) UCS 6100- or 6200-series fabric interconnect hardware, and is responsible for configuration of the chassis, the blades, and all networking components.

If you follow Cisco’s advice and use two fabric interconnects, you’ll have high availability for networking, and high availability for UCS management. The management system automatically clusters and runs in an active/passive high-availability mode spread across the two fabric interconnects.

Click to see: Cisco net results

Cisco claims 7,400 UCS customers as of August

The management interface actually takes the form of a documented XML-based API, accessible either via Cisco-provided CLI or GUI tools, or, if you want to write your own tools or buy third-party ones, directly via the API. We used the Java-based UCS Manager software, which is what anyone with a single UCS domain would want to use, in most of our testing.

Because a UCS domain is limited in size today to about 175-ish servers connected to a single pair of UCS fabric interconnects, it’s likely that many customers will have at least two domains for two data centers. In that case, you can manage the two domains separately or buy a third-party “orchestrator” package that lets you work across domains. Cisco actually offers a free open source tool called “UCS Dashboard” that lets you roll up two or more UCS domains into a single read-only view.

There are some limitations to the reach of the management system. For example, if you provision a new server with SAN connections, there’s no way for the management interface to reach over to the SAN to make the linkage and match up Fibre Channel names. The same is true for networking: just because you create a new VLAN using the UCS management system doesn’t mean that the rest of your network will know about it.

UCS management at your service

UCS management is based largely on the concept of “service profiles,” a series of parameters that define every aspect of a single blade server, from BIOS versions, power and disk settings, to network interface card configurations including media access control addresses and storage-area network identifiers.

Once you have created a service profile for a type of server, you use it whenever you want to add servers to your mix. Install the blades, and then apply the service profiles in an “association cycle.” Within a few minutes, a server can be provisioned that matches your requirements.

We can say one thing: you don’t know what you’re missing until you’ve seen UCS management in action. Getting a server from out-of-the-box to ready-to-use is reduced to a bare minimum of effort. This makes UCS ideal for enterprise environments where the number of servers is sizeable and growing continuously.

If you’re not constantly adding new servers, and incurring the pain of configuration and deployment, then an investment in UCS is less compelling.

Digging deeper into UCS servers

Cisco UCS may be all about management, but if the servers that make up UCS don’t make the grade, then there’s no point. We found a solid core of full-featured blades, but also a lot of obsolete and niche UCS products on the web site and price list that had to be cut away to understand what was really important. In both servers, and in networking options, Cisco has a lot of parts that confuse the issue, making things more complicated than they need to be.

Cisco currently offers B-series (blade) and C-series (rack-mount server) options for UCS, although the B-series are all that matters. The B-series are blades that go into an eight-slot chassis (the UCS 5108), and the C-series are standard 1U to 4U rack-mount servers.

The B-series blades have changed over time. Cisco started with an “M1″ series of blades, some of which are still on its price list, and has since gone through an upgrade cycle, offering B200, B230, B250, and B440 M2 blades. Today, the “M2″ series includes two-socket and four-socket offerings based on Intel 5600 and E7 series processors with four to 10 cores per socket, CPU speeds up to 3.46 GHz, and with up to 512GB memory.

Blades come in both single slot and double slot configurations, depending on the number of disk drives and the amount of memory you want. (Cisco confusingly calls these half-slot and full-slot, which means they should have called the 5108 chassis a 5104 chassis, since it really only has four “full slots.”) Most environments will be based on the single slot configuration, giving eight blades per chassis.

Compared to existing 1U servers from traditional vendors, the B-series blades stand up as very competitive offerings from a technology point of view. In fact, with Cisco’s Extended Memory Technology, B200 two-socket servers can have as much as 384GB of memory, beating out traditional rack-mounted Intel Xeon 5500/5600-based servers that top-out at 144G or 288GB (using very expensive and not-very-available 16GB DIMMs). Even if you don’t want that much memory, Cisco’s higher DIMM slot count lets you use less expensive (per gigabyte) DIMMs to achieve the same memory capacity.

Cisco UCS pricing: It’s complicated

As with any blade server, the focus is on network-based storage via SAN rather than local storage. The B-series blades all have the capability to handle two or, in the case of the B440, four drives, but local storage is extremely limited. If more than four drives of local storage on a single system are important, then blade servers are probably not right for you.

The C-series includes six standalone devices, from 1U to 4U and with a storage capacity of between eight and 16 drives. Anyone looking at UCS should focus exclusively on the B-series, for two reasons. First, while the C-series have most of the capabilities of the B-series blades, they aren’t managed and controlled in the same way, although Cisco told us they are working to smooth out the differences.

Secondly, and more importantly, there’s just not a lot of point in buying standalone servers from Cisco. All of the advantages of UCS disappear when you’re talking big servers with lots of local disks. Once you put a lot of disks on something, it’s no good for hypervisor virtualization, and it’s no longer a cog in the machine of the data center.

Cisco competitors downplay new blade server

If you had a big Cisco blade server farm and wanted to throw one or two rack-mount standalone servers in, you could do that for a special purpose, but there’s no good reason to build UCS in your machine room based on rack-mount servers.

Cisco’s blade chassis, the UCS 5108, is also very competitive with other blade chassis on the market. The 6U unit has four power supplies and eight fan trays and is designed for easy maintenance both of the chassis and the blades inside of it. Features such as front-to-back airflow and cabling are all set up for modern data center environments. If you put the UCS 5108 in your data center, you’re not going to be surprised by any poor design choices.

On the other hand, the raw blade servers you get in UCS are not going to stun you with their brilliance either. Now that most servers are being treated as commodity systems using the same chipset, there’s not a lot of room for computing innovation while maintaining compatibility.

If you’ve been buying servers by the dozen from Dell, IBM, and HP, Cisco’s blade server specifications and capabilities aren’t going to be very far afield from what you’re used to.

Networking innovation

UCS is primarily a server product designed to be sold to data center managers, not network managers, but, as you would expect from Cisco, there’s a very strong awareness of the problems of networking in the data center.

For example, a fully configured UCS chassis with eight servers inside will usually only require four power cables, and four data cables to connect to the enterprise network: two 10Gbps ports out of the interconnect card on one side of the chassis and two out of the card on the other side.

That’s not bad for eight servers, which would traditionally require eight times as many patch cords for both storage and networking, and four (or more) times as many power cables.

To understand the networking, you have to see that Cisco has created a distributed switch, extending all the way from the traditional distribution-layer switch down to the NIC in the blade server, and even to virtual NICs in virtual machines running on a blade server.

Cisco UCS includes two critical pieces that make this large-scale distributed switch possible. The first piece is the Fabric Extender, the UCS 2104XP. This card — and you need two of them per blade chassis, unless you are simply building a test system — sits in the UCS 5108 chassis, and aggregates the traffic inside the blade server, including both Ethernet and Fibre Channel, from all eight blades over internal 10Gbps interconnects. These fabric extenders shoot the traffic up to the second critical piece, the Fabric Interconnects, (based on Cisco Nexus 5000 switch hardware) over multiple 10Gbps connections.

The benefit of UCS to the network manager is that everything, from the fabric interconnects down to the Ethernet cards in the blades, is managed as a single entity. There’s no difference between the management of the core switches, the top-of-rack switch configuration, which wires go to what ports, or how VMware networking is configured — it’s all done by one person, the UCS chassis manager, using Cisco’s UCS management tools.

The networking handoffs between a Cisco UCS domain of a hundred or more servers and the rest of the data center occurs at the fabric interconnect, where a few Ethernet and Fibre Channel connections link UCS to the core LAN and Fibre Channel switches. It’s sophisticated networking, but the details are hidden. Remember that UCS is managed by server managers with a minimum of requirement for networking expertise. To set your expectations properly, pretend that it doesn’t say “Cisco” on that nameplate — this is not a network product, but a server product.

Once the configuration is loaded into a blade, the blade’s networking configuration is done and isolated from other devices. That means that when you start to load an operating system on a configured blade, all you see are the Ethernet and Fibre Channel ports configured by the UCS manager.

In a VMware environment, the UCS manager brings virtual ports to each virtual machine. The VMware Vswitch is gone (if you want), because the Vswitch has been replaced by the UCS fabric extenders and fabric interconnect, a true physical switch. There’s no need for the VMware manager to understand VLANs, Vswitches, or anything other than normal LAN and storage interconnections.

These configured ports on blades show up as virtual ports on the fabric interconnect. Every virtual NIC on every VLAN (and every Fibre Channel adapter) available to every blade has become a port on the fabric interconnect, literally thousands of them in some situations.

While the fabric interconnects are based on the same hardware as Cisco’s Nexus 5000-series switches, you don’t get the full IOS configuration capability you might have expected on the Nexus switch. The fabric interconnect switches traffic, but that’s about it, meaning that more powerful Layer 3 switch features, such as routing and access control lists, are not available at this level.

If you’ve gotten used to advanced security features of Cisco’s Nexus 1000V virtual switch in your VMware environment, you won’t find them in Cisco UCS, and you’d have to combine UCS capabilities and the 1000V, losing some of the benefits of UCS.

Cisco goes even further and strongly suggests you run the fabric interconnect in “End Host” mode which disables spanning tree, making the UCS domain connect up to your network as if it were a really, really, big host. UCS then can spread the load of different VLANs across all uplinks from the fabric interconnect to the rest of the network. This advice makes it clear who UCS is designed for: not the network manager, but the server hardware manager.

Strict configuration makes for simplified networking

Networking flow in Cisco UCS is very hierarchical and very constrained. Every blade connects Ethernet data, Fibre Channel data, and some out-of-band management traffic, over two private 10Gbps connections. These two connections are internal within the chassis, one from each blade to the two fabric extenders also within the chassis (in the normal case). The fabric extenders connect upwards, out of the chassis, to the fabric interconnects, typically using two ports per fabric extender for a total of four ports per chassis going to two fabric interconnects.

From the fabric interconnects, Cisco UCS connects to the rest of your Ethernet and Fibre Channel network via separate Fibre Channel and 10Gbps Ethernet connections.

Some variation in networking is possible, but not a lot. Cisco has multiple Ethernet cards available for the blades, but most network managers will use the M81KR adapter, code-named “Palo,” which presents itself as Fibre Channel and Ethernet NICs to the blade, and has two 10Gbps internal uplink ports.

There’s also an Ethernet-only card if you don’t want Fibre Channel, which will save you $300 a blade. However, if you’re not heavily into Fibre Channel storage, all of the networking integration and many of the provisioning advantages of UCS won’t mean anything to you — which suggests that UCS works best in a Fibre Channel environment.

Click to see: Diagram of Cisco UCS

In other words, if you’re using iSCSI or local storage, you’re not a great candidate for seeing the advantages of UCS.

When we looked at UCS last month, the fabric extender was limited to the 2104XP, which has eight internal ports (one for each blade) and four uplink ports to the fiber interconnect, all at 10Gbps. A 2208 model has been announced (along with a matching high-density Ethernet card), with 32 internal ports and eight uplink ports, for the rare environment where 10Gbps is just not enough for a single blade.

The fabric interconnects have also been revised. Cisco originally released the UCS 6120XP and UCS 6140XP, able to handle 20 and 40 chassis ports plus uplink capacity. The current replacement for both is the UCS 6248UP, with a total of 48 ports. Depending on how the rest of your network looks, that would leave you room for 20 to 22 chassis per switch. The unannounced-but-nearly-ready UCS 6296UP would double those numbers, allowing up to 44 chassis, or 352 blades, per UCS domain.

Those maxima are pretty important, because you can’t grow UCS domains (that’s the word Cisco uses for a combination of fabric interconnects and chassis) beyond two peer-connected fabric interconnects.

If you follow best practice recommendations for redundancy, that means you start with two fabric interconnects (which are clustered into a single management unit), and can have up to about 22 chassis, or 176 blade servers, per UCS domain using released hardware. (Double that if you’re willing to wait for the UCS 6296UP to ship.)

All of these configuration guidelines and capabilities make UCS networking a great fit in some environments, but not in others.

If you’ve had networking configuration and management problems with large virtualization environments or even physical environments with lots of servers, Cisco UCS provides a dramatic simplification by creating a flat distributed switch that reaches all the way down to each guest virtual machine.

If you’ve been burned by cable management problems, or if the idea of bundling more than 150 servers or 1,500 virtual systems into four racks with 80 internal patch cables and less 10 external patches seems like a good one, then the network density and rollup of UCS will definitely drop your blood pressure. And reduce the likelihood of patching and configuration error.

Is UCS right for you?

After spending a week looking in-depth at Cisco UCS, as we did, it’s easy to come away excited about the product. The engineering is solid, the software isn’t buggy, and UCS clearly has something to offer to the data center manager.

On the other hand, UCS is not for everyone. If you’ve only got a 100 servers in your data center, or if you’re not growing racks full of servers every few months, you won’t enjoy the management interface, because you’re not feeling the pain of deploying servers.

If you’re worried about single vendor lock-in for hardware and networking, if you run the same application on 10,000 servers, or if capital costs for servers are a major concern, Cisco UCS won’t be very attractive to you.

Cisco UCS is thoroughly modern hardware. The performance (running industry standard benchmarks) in both virtualization and non-virtualization environments is outstanding. Features such as power management, hardware accessibility, and high-speed networking are what you’d want from a server vendor. Although there will always be a lingering concern whether Cisco will stay in the server business, they’ve shown evidence of continuing innovation and development, and solid commitment from customers up to this point.

The use case for UCS boils down to two advantages: agility, and shrinking provisioning and maintenance time.

Agility because UCS treats server blades the way that SANs treat disk drives, as anonymous elements that are brought into play as needed by the load. Whether you’re layering a virtualization workload on top of non-virtualized servers, UCS offers some of the benefits of virtualization at the server hardware layer.

One Cisco staffer called it “VMotion for bare metal.” It’s not exactly that, of course, but the idea is the same: virtual or non-virtual workloads can be moved around computing elements. This makes it easy to upgrade servers, to manage power, to balance loads around data centers, and to maintain hardware in a high-availability world.

The shrinking of provisioning and maintenance time comes from the management interface. All of the little details of bringing a new rack of servers online, from handling Fiber Channel addressing to virtual or physical NICs, to cabling, to power management, to making sure that every little setting is correct — they’re all taken care of by the UCS management layer, either using Cisco’s applications, a multi-domain orchestrator from some third party, or even home-grown tools.

If virtualization is one of the first steps you take to gain a competitive advantage in enterprise computing, then the agility and flexibility that UCS delivers are good second steps.

Snyder, a Network World Test Alliance partner, is a senior partner at Opus One in Tucson, Ariz. He can be reached at Joel.Snyder@opus1.com.

Source: http://www.networkworld.com

Today, I’ve been working on a design document for a customer in Minneapolis.  For this project, we’re rolling out the full Cisco UC 8.6 “iron fist”: CUCM, CUC, CUPS, CER, and CUEAC.

I wanted to define the phone firmware versions for CUCM 8.6(2a), but forgot where to find it.

After 10 minutes of searching, I uncovered the firmware matrix here: Cisco Unified Communications Manager Software Compatibility Matrix.

Search for “Default Loads” (the page itself is length).  Voila.

The matrix shows you the default loads, broken out by CUCM versions. Simple post, but helpful information. Just the way we like it around here!

My Pier One + IKEA Mashup

This post is an update from a previous post last week, after I had reorganized my office to be based on a stand-while-you-work model.  The health benefits to this model are numerous and artistically summarized here.

Last weekend, I did something significant…I reorganized my home office.

This was quite the accomplishment, especially given the fact that the week before I reengineered my border device to run DD-WRT.  Cables were strewn about the floor and unrecognizable power supplies lay hidden like land mines beneath the blue, orange, and yellow Cat5 foliage.  It was chaos!

I reorganized my office so that I would be forced to stand at my desk.  This was done using two IKEA LACK side tables, purchased for $12 apiece last year.  Simple, cheap, and temporary.  I didn’t want to get too financially invested in an idea I wasn’t convinced of.

The Verdict

Between Monday and Friday, I worked from home every day, standing 4-6 hours per day in mostly single stretches.  Here’s the verdict.

• It felt good on my back.  At the end of the day, I was recognizably more tired, but my back wasn’t sore.  I noticed that every 15-30 minutes, I’d do a few standing stretches.  This was done instinctively and, quite frankly, it felt good to have more movement throughout the day.
• My shoulders weren’t sore.  I was concerned about shoulder soreness since I wouldn’t have armrests.  However, I didn’t have issues with this.
• My feet were sore.  I think this was caused by wearing cheap house slippers all day while standing.  This coming week, I’m either going to wear my outside Dr. Martens shoes or go barefoot.  The slippers did not have the support I needed.  My back didn’t suffer, but my feet were crampy.

Take baby steps...

I remember a summer camp that I went to between high school and college – Summit Ministries.  This was a camp for nerds.  We attended lectures on leadership, cultural paradigms, and world religions…heavy stuff, to say the least.

Dr. David Nobel, the leader of the organization, would continually say, “If you want to be a leader, you have to be a reader.”  That was all the impetus I needed back then.  Of course, I was single, carefree, without a job, and with plenty of time on my hands.

How do you make time for reading in the “real world”?  That is, the world of full-time jobs, work deadlines, home obligations, bills to pay, and errands to run?

Robert Bruce, a full-time web writer for Dave Ramsey and a book blogger at 101 Books shares some excellent advice on making time in your schedule for reading. His personal goal is pretty epic.  He is reading Time Magazine‘s Top 100 English-Speaking Novels Since 1923. Check it out!

Read on the go...

Begin article:

“I don’t have time to read.”

When I tell people about my blog, that’s one of the comments I usually hear in response. The implication—or at least the way my possibly oversensitive mind takes it—“You must not have any life to read that many books … loser.”

Of course, I exaggerate. But, really, it’s a tension a lot of people in our overworked and overstressed society deal with. They understand that reading is important—after all, their second grade teacher made that clear. But nobody has the time to read a Dr. Seuss book, much less To Kill A Mockingbird or (gasp!) Infinite Jest.

In the last few years, I’ve dramatically changed my lifestyle. I’ve trained for five half marathons and two full marathons while working a full-time job. I’ve read 30 novels since last September. And, on top of all that, my wife and I had our first child last June. Kids have a slight effect on your schedule. Maybe you’ve heard?

Life is hectic around our house. But I’ve somehow managed to make time to read in the middle of all that. And I say that not to pat myself on the back but to show that, even with a busy life, it is possible (and important) to make time for hobbies you’re passionate about.

Here are a few tips that have helped me:

1. Sacrifice something. You’ve got 24 hours in a day. You spend 8–10 hours (hopefully not much more) working. You spend 6–8 hours sleeping. You’ve got family and friends to spend time with every day. All of this doesn’t leave much time for other interests, like reading. So your golf game, like mine, might take a hit. You might have to turn off the television after 9:00 p.m. But, if reading is a priority, you’ll make time for it. As Jon Acuff puts it: “Be selfish at 5 a.m.”
2. Make a routine. If I say I’m just going to “find time to read,” then it will never happen. I have to make time to read. So here’s what I do: I read during my lunch break, and I read at night, beginning around 8:45, after family time, after the wife and little guy are in bed.
3. Set a goal. You’ve heard this so much that it’s clichéd. But it works. My goal is to read 101 novels. Usually, I would’ve given myself a deadline, but I didn’t want to speed read through the books, so I just chose to read them as they come. At my current pace, I’ll reach my goal in three more years. Maybe you should set a goal to read one book a month. If that seems unlikely, then make it one book every two months. And take it a step further—tell someone about your goal. Or, if you’re crazy like me, start a blog about it. There’s nothing like that extra accountability to keep you moving.
4. Have fun. You don’t have to read a book simply because a friend suggested it, you know? Think about your hobbies, interests, and passions—then go and read about those subjects. I once spent five months reading nothing but casual, behind-the-scenes books about restaurants and chefs. I’m a chef groupie, I guess. Once you’ve read a few “fun” books, then dabble into the more serious, thought-provoking stuff.
5. Mix it up. Once you get into the flow of reading, branch out of your comfort zone. If all you’ve read is nonfiction business books, then relax a little and pick up a novel. If you’ve plowed through Stephen King’s entire catalog in a few years, maybe it’s time to give a leadership or inspirational book a try. The point is: If you read the same style of book over and over, you’ll eventually get burned out and go back to watching two hours of Brady Bunch reruns every day…unless you’re reading 101 books for some crazy blog, of course.

What book are you going to read?

As a result of these basic steps, I’ve dramatically altered my lifestyle over the last year. If I’m not at work or spending time with family or friends, I’m probably reading. At 9:00 every evening, you can probably find me in my “man cave,” in my chair, lights dimmed, reading a book or updating my blog. I wouldn’t have it any other way.

Hopefully, one day, my mind will thank me for the daily exercise. As Dr. Seuss says, “The more that you read, the more things you will know. The more that you learn, the more places you’ll go.”

And who’s going to argue with Dr. Seuss?

XMPP, short for Extensible Messaging and Presence Protocol, is a term every UC (err…collaboration) engineer should become familiar with.  XMPP relates to AIM, GTalk, Lync, CUPS, and iChat (@me.com).

XMPP is maintain by the  XMPP Standards Foundation, which is an independent, nonprofit standards development organization whose primary mission is to define open protocols for presence, instant messaging, and real-time communication and collaboration on top of the IETF’s Extensible Messaging and Presence Protocol (XMPP).

Here’s a brief blurb about XMPP from their website:

The Extensible Messaging and Presence Protocol (XMPP) is an open technology for real-time communication, which powers a wide range of applications including instant messaging, presence, multi-party chat, voice and video calls, collaboration, lightweight middleware, content syndication, and generalized routing of XML data. The technology pages provide more information about the various XMPP “building blocks”. Several books about Jabber/XMPP technologies are available, as well.

The core technology behind XMPP was invented by Jeremie Miller in 1998, refined in the Jabber open-source community in 1999 and 2000, and formalized by the IETF in 2002 and 2003, resulting in publication of the XMPP RFCs in 2004 (see the history page for more details).

Although the core technology is stable, the XMPP community continues to define various XMPP extensions through an open standards process run by the XMPP Standards Foundation. There is also an active community of open-source and commercial developers, who produce a wide variety of XMPP-based software.

If you have any questions about the use or development of XMPP technologies, feel free to participate in one of the open discussion venues hosted by the XMPP Standards Foundation.

With the emergence of Customer Voice Portal (CVP), contact center engineers were forced to educate themselves at the CLI level.  No more RDP or web GUIs on this side of town!  Welcome to the world of dial-peers, SIP trunks, and additional MTP resource allocation.  Enjoy!

CVP is a powerful technology. If you work with Cisco UC on a regular basis, it would behoove you to skim through the SRND.  Know the basics.  If you want a job that’s in high demand, master CVP.  (Aside: Most of the recruiters who contact me want CVP gurus and are willing to pay $150k+/year).

This week, I needed a refresher on the SIP call flow for CVP.  I’m including this information from the CVP 8.x SRND for review:

Comprehensive

This functional deployment model provides organizations with a mechanism to route and transfer calls across a VoIP network, to offer IVR services, and to queue calls before being routed to a selected agent.The most common usage scenario for this functional deployment model is for organizations wanting a pure IP-based contact center.

Callers are provided IVR services initially and then, upon request, are provided queue treatment and are transferred to a selected Unified CCE agent. Upon request, callers can also be transferred between Unified CCE agents.

In this functional deployment model, Unified CVP and Unified ICM can also pass call data between these endpoints and provide cradle-to-grave reporting for all calls.

This functional deployment model provides all the capabilities of the Standalone Unified CVPVXML Server and Call Director functional deployment models, plus the ability to route and queue calls to Unified CCE agents.

Callers can access Unified CVP via either local, long distance, or toll-free numbers terminating at the Unified CVP ingress voice gateways. Callers can also access Unified CVP from VoIP endpoints.

This model requires the following components:

• Ingress voice gateway(s)
• VoiceXML gateway(s) (Can be co-resident with the ingress gateway)
• Unified CVP Server
• Unified CVP Operations Console Server
• Cisco Unified ICM Enterprise
• H.323 gatekeeper (for H.323 deployments)
• SIP Proxy Server (for SIP deployments

Traditional CVP with UCCE Call Flow

SIP Protocol-Level Call Flow

Initial Call Treatment and Self-Service

1. A call arrives at the ingress gateway and sends a SIP invite message to the SIP Proxy Server, which forwards the request to the Unified CVP Server SIP Service.
2. The SIP Service sends a route request to Unified ICM via the Unified CVP Server ICM Service and the VRU PG. This route request causes Cisco Unified ICM to run a routing script based upon the dialed number and other criteria.
3. The Unified ICM routing script utilizes a Send to VRU node to return a label to the SIP Service to have the call sent to a VoiceXML gateway. The Unified CVP Server SIP Service sends an invite message to the VoiceXML gateway via the SIP Proxy Server, which translates the label DN to the IP address of the VoiceXML gateway.
4. The Voice XML gateway sends an HTTP new-call message to the Unified CVP Server IVR Service with the label DN provided by Unified ICM. The IVR Service then sends a route request message to Unified ICM (via the Unified ICM Service), which then allows Unified ICM to re-enter the previously started routing script. The routing script is re-entered at the successful exit path of the Send to VRU node. The Unified ICM routing script then uses Run Script nodes to instruct the IVR service about the desired call treatment. If call treatment requires complex IVR self-services, service control can be redirected to a Unified CVP VXML Server application. Upon completion of the Unified CVP VXML Server application or a request by the caller to transfer to a live agent, service control is returned to the Unified CVP Server IVR Service. If the initial call treatment is simple with just a few prompts, then the IVR Service can utilize Unified CVP microapplications to generate VoiceXML documents for the VoiceXML gateway, and a Unified CVP VXML Server is not required.

Caller Requests to Transfer to Live Agent

1. When the caller requests to transfer to a live agent, the Unified ICM routing script queues the caller for an appropriate skill group and sends Run VRU Script messages to the IVR Service to have queue treatment provided (assuming no agent is available).
2. When a Unified CCE agent becomes available, Unified ICM requests the Unified CVP Server IVR Service to transfer the call the selected agent.
3. The IVR Service then requests the SIP Service to transfer the caller to the dialed number of the selected agent. The SIP Service then sends a SIP invite message to the SIP Proxy Server, which finds the Cisco Unified Communications Manager SIP Trunk IP address associated with this agent DN, and then forwards the SIP Invite message to Cisco Unified Communications Manager (Unified CM).
4. Unified CM accepts the incoming SIP Trunk call and routes it to the selected agent.

Caller Requests to be Transferred to a Second Skill Group

1. If the caller requests to be transferred to a second agent, then the first agent will initiate a transfer from their Unified CCE agent desktop application. This action generates a route request from the agent PG to the Unified ICM central controller. Unified ICM then executes a routing script that queues the call to another skill group. Assuming no agent is available, the Unified ICM script will use the Send to VRU node, which will signal to the SIP Service to release the call leg to the Unified CM SIP Trunk and connect the call back to a VoiceXML gateway.
2. The VoiceXML gateway sends an HTTP new-call request to the IVR Service, which forwards that request to Unified ICM in order to allow the routing script to be re-entered at the exit of the Send to VRU node. Unified ICM then sends Run VRU Script messages to the IVR Service to allow queue treatment to be provided to the caller while waiting for a second agent.
3. When a second Unified CCE agent becomes available, Unified ICM requests the Unified CVP Server IVR Service to transfer the call the selected agent.
4. The IVR Service then requests the SIP Service to transfer the caller to the dialed number of the selected agent. The SIP Service then sends a SIP invite message to the SIP Proxy Server, which finds the Unified CM SIP Trunk IP address associated with the second agent DN, and then forwards the SIP Invite message to Unified CM.
5. Unified CM accepts the incoming SIP trunk call and routes it to the second agent.

Cisco publishes a very useful document on software compatibility called, Cisco Unified Communications Manager Software Compatibility Matrix.  The link is version independent; meaning, you’ll be able to drop it into a bookmarks folder and refer to it for the long haul.

I’ve included a screenshot of the supported CUCM 8.6 direct upgrade version below.

I also want to call out the difference between CUCM Restricted and CUCM Unrestricted.  I’ve see some confusion out there on the forums and it’s imperative you install the correct type of CUCM to be in compliance with the governmental laws of the country the servers are located in.

Note: Be aware that after you install an unrestricted release, you can never upgrade to a restricted version. You will also not be allowed to fresh install a restricted version on a system that contains an unrestricted version.

Restricted:

This CUCM version is the full-blown platform with all features enabled.  This should be the default version you install unless there are certain legal considerations.  Most (if not all) installations within the US will use “restricted.”  This throws many engineers off because they assume restricted means less features.

Unrestricted:

The restricted US export classification on Cisco Unified CM meant that governmental and military customers in many countries could not employ Unified CM in their networks.

In addition to the delay inherent in obtaining export licenses, products classified as restricted by the Department of Commerce (DoC) carry a requirement to allow US government representatives to demand on-site inspections at any time to confirm that the product is being used in accordance with its licensed purpose. This post-shipment verification (PSV) is unacceptable to many customers.

Additionally, some foreign countries maintain import restrictions which prohibited Unified CM from being available to customers in those countries. Both US export and foreign import issues stem from Unified CM support for strong encryption of signaling and media.

So what’s limited in the unrestricted version?

Signaling and media encryption is permanently disabled in the unrestricted version, but remains unchanged in the restricted version.

Migration from the unrestricted version to the restricted version is not supported.