If you’ve ever deployed Cisco Unified Presence Server (CUPS) or read about Cisco’s CUPC or Jabber clients, you’ve likely run across the XMPP acronym.

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.

Several year ago, when I started the process of learning Cisco UC, I was a contact center engineer.  I worked for the company that created (and OEM’d) Cisco Agent Desktop (CAD).  Back in those days, large contact center deployments leveraged ICM and IP-IVR.  It seemed complicated; that is, until CVP came along.

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

Continue Reading…

This post is short.  It’s basically a tickler to remind UC engineers out there to be mindful when upgrading CUCM to the next major version (i.e. 4.x, 5.x, 6.x, or 7.x to 8.x).

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.

Continue Reading…