Understanding Jabber: Part 3- Extend & Connect

Being the third part in this series I thought I would take a look at one of the features that quite frankly is a little misunderstood. Jabber Extend and Connect seems to get confused with Unified Mobility quite often. Even though it has some similarities it is a very different feature.

Extend & Connect

Extend and Connect was introduced in Cisco Unified Communications Manager (CUCM) 9.0. It is a unique feature in that it takes the concept of controlling a phone and allows you to take advantage of any phone in conjunction with your Unified Communications application. In this case it happens to be Jabber. What's unique to Extend and Connect is that it does not require the phone to be on any particular system but it can be any phone on any system. A home phone or a cell phone are good examples of devices that typically are not part of a CUCM deployment that can be used by Extend and Connect. The Jabber user has the ability to set the number to any routable number that Communications Manager (CUCM) is configured for. What I really like about this is the limited amount of integration that is required between Communications Manager and the legacy or other system you are using the device on. This is because this is being mostly contained within the Cisco UC environment and the only thing required to an external system is typical gateway/trunk connectivity.

The Extend and Connect feature for Unified CM provides the following UC features:

  • Receive incoming enterprise calls
  • Make Call
  • Disconnect
  • Hold and Retrieve
  • Redirect and Forward
  • Call Forward All
  • Do Not Disturb
  • Play DTMF (out-of-band)
  • Consult Transfer, Conference
  • Add, edit, and delete Remote Destinations
  • Set Remote Destination as Active or Inactive

How does it work?

Below is a diagram overview of Jabber controlling an external endpoint. In this case it can be either the home phone or a third party PBX phone. CUCM has a CTI remote device based on the users Enterprise DN configured in its database. The Remote device is associated with the user Jabber device through the user account. Now I don’t want to bore everyone with a bunch of configuration mumbo-jumbo, the important thing to remember is that through CTI integration with Jabber we can basically control any device we want.


Below is a screenshot of what the user would see.


In this case I have created a fake number in the CTI Remote destination profile just to show how it functions. If I had entered the number though Jabber, CUCM will check that the number is routable. This ensures that the user doesn’t enter an incorrect number that is never going to work. In the example below I entered a non-routable number and Extend and Connect shows up with the red X to show the error.


Difference Between Unified Mobility and Extend & Connect

To put this simply Unified Mobility is really designed for redirecting calls destined to your enterprise phone number to other personal devices. There is no ability to provide any call control of this other device (transfer, hold etc). You can however retrieve a call back on your enterprise phone once you have ended the call from your personal device but the whole idea is more akin to single number reach.Ring your enterprise number and a whole bunch of other devices ring with it and you can retrieve the call basically anywhere you desire.

Extend and connect on the other hand gives the user  control over any endpoint and allows inbound calls to their enterprise number to ring this CTI controlled device. It has some similarities to Unified Mobility in that respect but that is where it ends. This basically now allows a user to use the external phone devices as if it were a enterprise device. of course having a UC application like Jabber to work with the feature is a must and this is how CTI control is maintained.

Extend & Connect Use Cases

The most obvious one is a UC migration. Taking the latest Cisco has to offer and layering it over a legacy PBX install. This enables being able to gradually migrate phones over time is a great option. It also opens the door to replacing phones altogether but allowing users to get comfortable with softphone phone services first but still have the ability to take control of a hard phone if they want to.

Next use case is the remote user that may not have good IP connectivity and using a more traditional phone service might work better. A hotel is a good example or if you are a teleworker and landline based services are just more reliable. Being able to direct and manage calls to any phone is what gives Extend and Connect it advantage versus other similar features on other platforms.

Lync Remote Call Control versus Jabber Extend & Connect

I thought this was an interesting comparison of two similar features on two different platforms. The actual original intent of RCC in Lync was similar to that of Extend and Connect but the features of RCC have slowly been depreciated over the years as Microsoft looks to have a more robust voice feature set. Setting this aside the concept of the UC overlay on top of a legacy PBX made a compelling use case and still does as some companies look to more slowly adopt UC features. Although Extend and Connect takes this beyond just a UC overlay RCC’s sole purpose was the overlay as it required SIP/CSTA integration. This meant that to take advantage of RCC you required an on-premise PBX that had the ability to do SIP/CSTA or some sort of CSTA gateway that could do the interoperability. In either case you are limited to on-premise PBX’s with RCC.

RCC also limits a user between switching from using the client as a softphone or remote controlling a another desk set on the fly. Once a user is set for RCC there is no switching to softphone mode unless an administrator makes a change for the user. This used to be allowed when Microsoft had interoperability with Nortel PBX’s but has since been removed. Microsoft clearly designed RCC for migration from legacy PBX to Lync softphones and not as a feature extension once the migration is complete.

Extend and Connect on the other hand isn't bound by the CSTA constraint. By using CTI along with Jabber and substituting numbers within CUCM, other than normal PSTN connectivity nothing else is required to make Extend and Connect function. Admittedly the manner in which some features function is a little different compared to RCC mainly because there is no direct integration ties beyond normal voice connectivity but I see this as a positive as it makes setting it up easier.

Extend and Connect also doesn’t limit the users options to switch the client to use other Jabber features. This means a user has three options with Jabber as it relates to telephony

    1. Jabber as a softphone,
    2. Jabber with Extend and Connect or
    3. Jabber Desktop phone control of a CUCM registered IP Phone or TelePresence endpoint.

This gives an organizations lots of options for a migration from a legacy PBX. It also enables a number of options for remote workers.

Hope everyone is enjoying the series.




Cisco VCS and Expressway 8.1 now Available

New on CCO. Expressway and VCS has now released version 8.1. More to come on Expressway with my Understanding Jabber Series.

VCS Deployment Guides


Lync 2013 VCS deployment Guide


Expressway Configuration Guides


Expressway Configuration Guides



Cisco Collaboration Systems 10.x Solution Reference Network Designs (SRND)

The latest and greatest from Cisco’s SRND on release 10:


Deployment Models & Expressway

This is the first time that Expressway has been covered in a SRND. There is a great new section under deployment models that covers VPN and VPN-less access. Cisco’s solution for Collaboration Edge access is one of the most comprehensive in the industry. Having both the ability to provide both VPN and VPN-Less access makes Cisco’s UC solution extremely flexible and gives companies lots of options.

VPN-Less Access with Cisco Expressway



Chrome and Firefox Move to Automatically Blocking Plug-ins

Chrome and Firefox changed their policy to automatically block plug-ins. Below is a Q and A from WebEx support to ensure folks know how to re-enable the plugin . I am guessing that this is going to affect more than just WebEx.


These are the most frequently asked questions about how to join a WebEx meeting on Google Chrome and Mozilla Firefox:

Q.  How do I enable the WebEx plug-in to join a WebEx meeting?

A.  You will need to follow the steps below after the following estimated browser version release dates:

  • Firefox version 27—estimated February 2, 2014*
  • Chrome version 32—estimated January 10, 2014*

Follow these steps to enable the WebEx plug-in and join a WebEx meeting:

  1. Select the Join link that appears in your email invitation or instant message, or select Join in your meeting list or the meeting space on your WebEx site. 
  2. If you have not already installed the Cisco WebEx meeting application software, install it now.
  3. If the WebEx software is installed, you will see the Join meeting page with a tiny icon near the address bar that will allow you to enable the WebEx plug-in. See the images below for instructions on how to enable this plug-in in Chrome and in Firefox:

Chrome (Windows and Mac)**

Image demonstrating how to enable the WebEx plug-in for Chrome

Firefox (Windows, Mac, and Linux)**

Image demonstrating how to enable the WebEx plug-in for Firefox

Q.   How often will I need to enable the WebEx plug-in?

A.   You will need to enable the plug-in once per WebEx site (example: Mysite.webex.com) for each browser you use (Chrome and Firefox).

If you use multiple computers, you will need to enable the plug-in separately for each computer.

Q.  Which versions of Chrome and Firefox will require me to activate the WebEx plug-in?

A.  The following browser versions require that you activate the WebEx plug-in:

  • Chrome version 32 and later*
  • Firefox version 27 and later*

Q.  What changed? Why do I need to enable the plug-in now?

A.  Chrome and Firefox changed their policy to automatically block plug-ins. Mozilla and Google separately announced that their browsers will automatically block the Netscape Plugin Application Programming Interface (NPAPI) starting in February* for Firefox and January* for Chrome.

Q.  What is a plug-in?

A.  A plug-in is a technology that allows additional functionality to be added to the browser. The Cisco WebEx plug-in allows the browser to communicate with the Cisco WebEx meeting application software that is installed on your computer.

Q. Since Google will be removing NPAPI support from Chrome, what long-term plans does WebEx have for allowing users to join meetings?

A.  Google has announced that Netscape Plugin Application Programming Interface (NPAPI) support will be completely removed from Chrome by the end of 2014. Cisco is committed to providing a simple and easy way for users to join WebEx meetings. We are currently investing in new, alternative methods to join meetings that do not require the use of NPAPI support. We will advise on the recommended alternatives at a later date.