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.

References

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/admin/9_1_1/ccmfeat/CUCM_BK_C3E0EFA0_00_cucm-features-services-guide-91_chapter_0110010.html

VoIPNorm

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

http://www.cisco.com/en/US/products/ps11337/products_installation_and_configuration_guides_list.html

Lync 2013 VCS deployment Guide

http://www.cisco.com/en/US/docs/telepresence/infrastructure/vcs/config_guide/X8-1/Cisco-VCS-Microsoft-Lync-Deployment-Guide-X8-1.pdf

Expressway Configuration Guides

http://www.cisco.com/en/US/partner/products/ps13435/products_installation_and_configuration_guides_list.html

Expressway Configuration Guides

http://www.cisco.com/en/US/docs/voice_ip_comm/expressway/admin_guide/Cisco-Expressway-Administrator-Guide-X8-1.pdf

VoIPNorm

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

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

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/collab10/collab10.html

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

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/collab10/models.html#wp1438140

VoIPNorm

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.

https://support.webex.com/webex/meetings/en_US/chrome-firefox-join-faq.htm

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)**

Firefox (Windows, Mac, and Linux)**

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.

VoIPNorm

Understanding Cisco Jabber: Part 2 - Medianet

This is the second part in my Understanding Jabber Series. I thought rather than jumping into a bunch of Jabber features we should look first at the network and how Jabber can take advantage of it through Medianet. This is a pretty high level exploration of Medianet but there is a ton of info available in the reference section if you would like to explore further.

User Experience Matters Beyond the UI

Traditionally most desktop/email/application administrators never really had to deal with real time applications that relied heavily on the networks ability to deliver in a timely manner. Applications such as email, instant messaging, file transfer and database applications typically don’t suffer from the same kinds of issues as real time media.Really the beginning of the end of this relationship or lack of has its roots in the early softphone deployments of the last decade.

Audio quality in those early softphone deployments were typically not that great, well, at least in my experience. There were of course a multitude of reasons for this but over time some of these reasons such as low powered laptops have subsided. One issue that has remained fairly consistent though has been bandwidth restrictions and traffic prioritization.  In the early days of Office Communications Server and to a lesser extent Lync, Microsoft drove the message of application layer Quality of Experience (QoE). The concept of QoE was really to create a relatable scoring system to rate the overall experience through all 7 layers of the OSI model based on a number of metrics beyond QoS. I have to admit even I had a strong belief that applications could deliver a better level of quality without relying on network quality of service (QoS).

Well, here we are some years later and of course things have changed considerably at least for Microsoft in relationship to QoS. If you go back through my own blog posts you can see old QoS posts that suggest at the time Microsoft's knowledge or desire to rely on network QoS was at best limp. Microsoft tells a very different story today in regards to QoS and the recommendations around it. Recently Microsoft released version 2 of its networking guide. While Microsoft has taken significant steps to embrace network QoS they still rely on configuring port ranges as a primary way to fit into a QoS architecture that typically considers the PC untrusted. We will see a little later why this can be problematic approach.

Cisco on the other has had a much longer history in regards to QoS and driving the concepts some of which have become industry standards or best practices.Would you really expect otherwise from a networking company? Not really. Although some would argue that implementing QoS has never been all that easy Cisco recognized very early on the importance of QoS and the association of real time traffic prioritization.

What's my point in all this. User experience matters and whether you like it or not receiving real time packets in the correct order in a timely manner means network QoS matters as well. If you value the user experience you have to look beyond the application to get to the roots of the overall user experience and consider for a moment what your delivering to the network guys can go beyond the firewall of a desktop machine. Its not just the network guys problem once you hand the IP packet to them. End users don’t care that it’s a network issue, its your issue because their desktop application isn't working but email is working just fine. Try explaining to an end user the difference between non-real time and real time traffic and the implications of the network and how this isn't your fault, I dare you.

IP Phone Versus Desktop QoS Requirements

As I mentioned earlier QoS can be complex to apply evenly and consistently across the network. Especially for larger companies where switches and routers may be in the thousands. There have been a number of IOS (IOS is the operating system for Cisco routers and switches not to be confused with Apple devices) macros and applications that have made it easier such as autoQoS and other QoS auditing applications but with soft clients now the norm we have new layers of complexity.

The method for applying QoS to standard IP Phones is widely known and understood. VLANs, ACL’s, untrusted ports, trust boundaries etc. The general configuration required for the stand IP Phone can even be translated across different network vendors by now as well. Desktop and BYOD devices on the other hand have made it a little more difficult to come up with standard practices. AutoQoS and CDP helped somewhat with softphones but really this works only with an all Cisco network and we have moved way beyond softphones running on a PC today.

While I didn’t really intend this to be QoS 101 there are some important points to be made in relation to UC and desktop applications that support real time media.

PC’s and for that matter BYOD are traditionally untrusted on the network for QoS markings. Encryption has made classifying traffic through discovery applications such as NBAR more difficult.

• Classifying and marking packets based on ports alone is problematic for desktop and BYOD applications. Basically any app can use those ports not just our beloved UC apps. End to end QoS with this approach can never be assured.
• Whole Sessions are composites of multiple application flows (Video, Voice, Data). Keep in mind also each of these flows has its own set of traffic characteristics.

So with all this in mind lets talk Medianet.

Medianet Basics

So what is Medianet and how does it help solve some of these issues? To put it simply its applications talking directly to the network through API’s and requesting levels of service. It is an end to end architecture not just a single product or service.  At a high level here are the key areas that Medianet addresses:

• Auto-configuration: managing moves, adds, and changes limiting human configuration errors for QoS.
• Media Monitoring: Enhances visibility into the network. It helps accelerate troubleshooting, and assess and measure the impact of video, voice, and data applications in the network.
• Media Awareness: The network works together with applications for optimal QoE for end-users.

Each of these areas are addressed by the overall architecture that ties together some more traditional methods with newer methods such as flow metadata. There are also a number of tools that work in conjunction with Medianet to get the most out it. Obviously network routers and switches need to support Medianet through IOS configuration. On the server side Cisco Prime Collaboration, Prime LAN Management Solutions and Prime Infrastructure are three Cisco based tools that can use Medianet for configuration and analytics purposes. At the endpoint Medianet Media Services Interface (MSI) does most of the heavy lifting in regards to talking directly to the network on behalf of the application or endpoint. So an application can get the correct level of network service and if trouble arises teams can diagnose down to the network port the machine is located on.With these points in mind Medianet helps solves some of these sticky QoS issues as it relates to desktop Unified Communications (UC) applications.

Cisco Jabber and Medianet Media Services Interface

To begin, think of the MSI as a layer between the network and the Jabber application. It is a standalone installer for PC’s that has a set of API’s that Jabber interfaces. The API’s in the case of the PC MSI also allows other Cisco UC Applications (namely WebEx) or third parties to take advantage of the MSI interface. Think of it just like Microsoft Office with its API’s. Instead of passing presence to Office through API’s we are now requesting network service levels through the MSI interface.

Before Cisco Jabber sends audio media or video media, it checks for Cisco Media Services Interface.

• If the service exists on the computer, Cisco Jabber provides flow information to Cisco Media Services Interface. The service then signals the network so that routers classify the flow and provide priority to the Cisco Jabber for Windows traffic.
• If the service does not exist, Cisco Jabber does not use it and sends audio media and video media as normal.

The Jabber MSI sends metadata to the network and advertises what type of flow (audio, video or data) is being sent across the network at any given instant. The network can be programmed to identify the flow type and apply the correct QoS marking. In the slide below; when a user is using Jabber to make a PSTN phone call the metadata flow will allow the network to mark the “phone” traffic as DSCP EF. When the Jabber user is on a video call the incoming metadata will allow the network to mark the Jabber flows as DSCP AF41. Furthermore, video and the associated audio flow both have their own associated metadata which allows for complete QoS marking granularity. Flow Metadata allows the application to convey information allowing appropriate policies to be applied at each hop, end to end.  

The MSI has been adopted by all of Cisco’s UC applications and endpoints and hence they all communicate with Medianet in the same way. This allows a company to build up a uniform network configuration that can be applied to any switch port and is smart enough to recognize and correctly mark any incoming realtime stream from a Cisco Jabber desktop client, A WebEx client or a Cisco physical video endpoint.

Metadata is not just used at the edge of the network but flows across the exact same path that is used by the traffic it is advertising. This allows QoS marking to be verified bi-directionally and end to end via a Medianet capability called Mediatrace. This is quite a different story than traditional QoS architectures and significantly changes the approach to how we can handle traffic coming from PC’s and BYOD applications.

Isn’t Medianet only for Cisco devices?

No. Cisco Medianet technologies are designed to work with Cisco and third-party endpoints. For example, Media Monitoring can be used to monitor and troubleshoot video, voice, and data services, and Auto-configuration can be used to automatically configure the switch port for Cisco and third-party devices.

Could Microsoft use Medianet API’s with Lync?

Yes. Cisco provides API’s for Medianet just like Microsoft provides API’s for Office. Of course this would mean Microsoft is conceding that the network plays an important part in real time traffic and that doing everything at the application layer is not always optimal. So whether Microsoft takes advantage of this your guess is as good as mine. The other alternative is network teams can fall back on Media Service Proxy to discover Lync traffic but this is far from optimal.

Conclusion

A full and meaningful exploration of Medianet would take way more than a single blog post. There really is a lot to Medianet beyond Jabber that’s worth looking into. Hopefully this has helped with some insight into some of the issues brought by the explosion in UC application use and how Jabber at least looks to solve QoS issues beyond the traditional QoS architectures.

References

Medianet Architecture

http://www.cisco.com/web/solutions/trends/medianet/media_services_interface.html

Media Awareness

http://blogs.cisco.com/video/introducing-medianet-media-awareness/

Media Services Proxy

http://blogs.cisco.com/video/announcing-media-services-proxy/

Medianet datasheet and System requirements

http://www.cisco.com/en/US/prod/collateral/routers/ps10536/data_sheet_c78-612429.html

Jabber 9.2 Medianet

http://www.cisco.com/en/US/docs/voice_ip_comm/jabber/Windows/9_2/JABW_BK_C9731738_00_jabber-windows-install-config_chapter_0100.html#JABW_TK_IC6524B0_00

Medianet MSI  Developer Center

https://developer.cisco.com/web/msi/

Auto configuration tutorial

http://www.cisco.com/web/learning/le31/le46/cln/learning_module/autoconfiguration/index.html

Cisco Prime Collaboration

http://www.cisco.com/en/US/products/ps12363/index.html

VoIPNorm

Understanding Cisco Jabber: Part 1- The Basics

Cisco Jabber presents some really interesting options and my hope over the next few weeks is to write a series of posts that address some of these options. I think for most part Jabber is largely misunderstood. Along with assumptions on why things are done the way they are there seems to be this constant comparison between Lync and Jabber when really both solutions approach things very differently .Jabber provides a lot of flexibility which can really be attributed to the underlying architecture. While some may argue that the underlying infrastructure is complex each individual solution can actually stand on its own without the other pieces. Something other UC platforms just can’t do.

You will notice that I will make comparisons with Lync throughout this post. Mainly because I think those familiar with Lync will be interested in how Cisco brings their solution together. This isn't meant as a competitive post but more about explaining the solution in terms that someone more familiar with Lync rather than Jabber will understand. If I just started presenting this using a bunch of Cisco product names, someone who isn't familiar with those product names will quickly become lost.

What is Cisco Jabber?

Similar to Microsoft's Lync brand, Jabber is the brand used to encompass Cisco’s Unified Communications clients and SDK’s. This includes desktop (Windows & MAC), mobile (Blackberry, iOS and Android etc.), SDK and web clients (Jabber Guest). It really isn't any more complicated than that.

Common Framework

I have worked in the IT industry for over 15 years and seen many a deployment of UC among other things. One thing that has remained true is that its hard to bring different teams together in unison on a single project. If I look at how UC has grown up it would be impossible to finger a point in time or a single product that really created the idea of UC (although I am sure someone will claim it). Also, the fact remains that UC means different things to different people. My point here is in general there is still so much market confusion around UC companies in general see UC as an overlay to an underlying infrastructure. I have sat in countless meetings where drawing the bigger picture either isn’t fathomable or just not wanted or “yeah we will get to it”.  Most of the time disparate teams are so focused on their own mission statements of deployment and operational support, to be distracted from that is a big ask.

So how do we bring together disparate technologies and teams that have really grown up over time in their own silo’s? The answer is by having a client that has a common framework that rather than force a change in the infrastructure brings together different services.Notice how I mentioned services. This is because each of these once independent workloads can now be consumed in a variety of ways. On-prem, in the cloud or hybrid. I see each independent workload more as a service and depending on your model, you may choose to consume them in different ways.This really speaks to the cloud trend of course but I see it relative to no matter where this service is coming from. This is a very different approach than Microsoft’s Lync. Rather than take a services approach and combine them into a single client, Lync consumes all major services from a single registration point. Which is fine and has its own set of benefits but at the same time limits deployment models.

By using the common framework we can also reduce a serious issue presented by UC, disruption. Disruption to teams that have a focus on current roles, disruption to services that in all likely hood are already deployed, disruption for users as they are now not faced with having to change an interface or services (voice, video, web). By deploying a UC client that consumes rather than replaces services it has the ability to reduce the disruption across the board. In this post I have focused on the main UC services voice, video, web conferencing but really API consumption can be part of this as well. Think MS Office, Google Apps etc. this really broadens the conversation but for now I want to focus on the main UC services.

Client Services Framework – Cloud or On-Premise

To achieve a services model with a common framework Jabber uses the Client Services Framework.Client Services Framework is a base building block for the client application. Cisco Unified Client Services Framework is a software application that combines a number of services into an integrated client. An underlying framework also provides the benefit of being cross platform portable. So while this may seem complex its actually simplifying the ability for developers to build the client application by being able to build upon CSF.

What this means for companies with large investments in Cisco’s UC infrastructure is a way to bring this together without needing to disrupt current services. You are actually layering CSF across your current infrastructure. This may mean you do not need to deploy any new on-premise infrastructure depending on what you deploy and how you deploy it. Below highlights an all on-premise deployment with everything in place.

So lets suppose for a moment that you wanted to layer on IM&P to an existing Voice deployment but without softphones. You could conceivably follow a deployment per below. Adding softphones from a technical point of view is now just a matter of configuring it.

But lets take this a step further. Lets add in the cloud. Below is a hybrid deployment model with some services on-premise and some in the cloud.

As a first step perhaps I just want IM&P from the cloud.

Next step I may want to layer on voice but this is being consumed from on-prem. Jabber with CSF gives this flexibility to take different services from either on-premise or in the cloud. This could also mean working with a HSC partner delivering voice services so voice could be in the cloud as well.

Some of you may be questioning why I didn’t leave in voicemail while optioning in voice services. Well this is because although visual voicemail in Jabber is a nice to have not every company has Unity Connections as their voicemail platform with Cisco Unified Communications Manager. This shouldn’t be seen as a limiting factor to adding voice for a Jabber or for that matter Communications Manager voice deployment. Fact is Communications Manager is controlling the flow of voicemail and if for instance you have Exchange UM deployed people may be happy just getting voicemail in their email. This really speaks to the flexibility of Communications Manager as a voice platform and having CSF layered over your infrastructure.

Jabber and WebEx

Some of you may be questioning why is WebEx Meeting Center is the diagrams and why Jabber just doesn’t do it all. In my view as a consumable service Web Conferencing can be sometimes be used with a UC client but inevitably I find most companies have more than one Web conferencing service. The reasons vary quite a bit. For some its because an in-house offering doesn’t scale to large meetings or there is an application that is commonly shared that doesn’t work well in one web conferencing solution versus another.What ever the reason the fact remains that a all in one UC client doesn’t always meet the requirements. Over time this may change but the fact Jabber uses WebEx rather than attempt to do it all speaks to the radically different requirements that web conferencing brings.

So although the WebEx messenger service (IM &P) can be directly consumed by Jabber, Jabber does integrate with WebEx Meeting Center rather than consume it directly (aside from P2P desktop sharing). Yes, that means a second application but it also means a consistent end user experience covering far more use cases than a single UC client could possibly do today. In the future this could mean further integration (I am not speaking to any roadmap here, just want to be clear) but this shouldn’t come at the sacrifice of removal of features or use cases just for the sake of a single client experience. From my own personal experience I have seen companies that transitioned from Live Meeting to Lync where this was the case and it caused delays in the migration or a transition to a different service altogether because of a loss of features. This isn't to say they all went to WebEx lets just say “other service” because to be frank some went to WebEx and other went to Citrix, Adobe etc.

Based on my own industry experience I think this is a smart approach. Although in the eyes of Jabber competitors this may be conveyed as a negative, the use cases surrounding Web conferencing are becoming just as complex as voice and other services. Although having a single client user interface is seen by some as the gold standard, in reality getting there and still meeting expectations is a complex task.

What about hybrid Microsoft Cisco model?

This is a really common question. Yes, you can certainly do a hybrid Lync/Cisco UC model. Is it going to get you where you want to end up? Probably not. I say this based on my experience across the last 10+ years. There will always be something you wished worked better together. Although Cisco and Microsoft have made solid efforts to provide interoperability it will most likely never be complete (of course this will depend on which side of the fence your talking to). I think both vendors based on use cases and requirements are at a stage where a company can deploy just one solution to get the greatest benefit. I am sure there are lots of folks out there that agree.

I started my blog based on interoperability. Although I will address it from time to time moving forward, I think the reasons for the hybrid Cisco/Microsoft solution are gone or so significantly reduced that its holds little value in the decision making process. So I will be writing less about it and focusing mainly on Cisco technologies.

Beyond the Marketing Materials

I tried to give a description of Jabber and how it compares in some regards to Lync without trying to be one sided or the other. Examples based on my experience are real world from working as an engineer and also from my time at Microsoft and Cisco. I happen to think Microsoft has helped changed the industry with Lync in many ways but I also want to recognize its limitations with the approach its taken versus Cisco.If I offended any one, tuff its my blog and I write what I want. Feel free to comment in a respectful manner and provide some real insight, don’t just comment to stir because I will delete.

References

Jabber Product Page Home

http://www.cisco.com/web/products/voice/jabber.html

Cisco Collaboration SRND 9.0

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/collabor.html#wp1105337

Jabber for Everyone

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/im_presence/jabber_for_everyone/9_0_1/CUP0_BK_J490464F_00_jabber-for-everyone-solution-90_chapter_00.html

VoIPNorm

Cisco Collaboration Summit Links #csummit

If you happen to be paying attention last week on Twitter you would have noticed that #csummit was a trending topic.

The Collaboration Summit had lots of great news coming out around Cisco’s Collaboration portfolio. Below are some links to latest and greatest info. I have included some general press links but there are a ton more.

Cisco Release info

Summit announcements summary

http://newsroom.cisco.com/press-release-content;jsessionid=B3F9270D862004BBC8B5A11DB40E9762?type=webcontent&articleId=1278077

Rowan Trollope Keynote

https://communities.cisco.com/community/technology/collaboration/collaboration_virtual_experience_2012

Don’t forget the kids blog

https://communities.cisco.com/community/technology/collaboration/business/blog/2013/10/29/collaboration-summit-2013-don-t-forget-the-kids

Working Smarter Blog by Rowan Trollope

https://communities.cisco.com/community/technology/collaboration/business/blog/2013/10/08/working-smarter-the-paradigm-shift-in-business-collaboration

Greasing the Video Collaboration Skids

http://blogs.cisco.com/video/greasing-the-video-collaboration-skids/

Innovative Collaboration Tools for the Desk Worker

http://blogs.cisco.com/collaboration/innovative-collaboration-tools-for-the-desk-worker/

Product Releases

Cisco TelePresence SpeakerTrack 60 Camera

http://www.cisco.com/en/US/products/ps13411/index.html

http://www.cisco.com/en/US/prod/collateral/ps7060/ps11307/ps13436/ps11335/ps13411/datasheet-c78-729836.html

Cisco Expressway

http://www.cisco.com/en/US/products/ps13435/index.html

Jabber Guest

http://www.cisco.com/en/US/products/ps13410/index.html

MX300 G2

http://www.cisco.com/en/US/prod/collateral/ps7060/ps11302/ps11776/data-sheet-c78-729734.html

7800 Series Phone

http://www.cisco.com/en/US/products/ps13220/index.html

Cisco Prime Collaboration

http://www.cisco.com/en/US/products/ps12363/index.html

DX650 Intelligent proximity

 

Akkadian Labs

http://www.marketwired.com/press-release/akkadian-labs-wins-best-overall-application-at-ciscos-collaboration-summit-1844478.htm

General Press

ITBusinessEdge: Cisco Simplifies Collaboration Security via Its New Expressway

http://www.itbusinessedge.com/blogs/it-unmasked/cisco-simplifies-collaboration-security-via-its-new-expressway.html

InfoWorld:Cisco beefs up enterprise collaboration tools

http://www.infoworld.com/d/applications/cisco-beefs-enterprise-collaboration-tools-229356

KBZ

http://www.kbz.com/blog/highlights-cisco-collaboration-summit-2013-csummit

UC Strategies

http://www.ucstrategies.com/unified-communications-strategies-views/a-delightful-experience-in-boca.aspx

No Jitter

http://www.nojitter.com/post/240163025/cisco-is-at-war-with-good-enough

Computer World

http://news.idg.no/cw/art.cfm?id=F461CC27-B333-95CB-1434B124F5C5A78A

FierceCIO

http://www.fiercecio.com/story/cisco-reinventing-its-collaboration-portfolio/2013-10-25

PCWorld

http://www.pcworld.com/article/2057100/cisco-beefs-up-enterprise-collaboration-tools.html

VoIPNorm

Why I am using a PC again.. iPad wins over Surface RT and the Jabber bright spot

Some of you may remember that when I changed jobs I also changed OS systems, switching to a MAC. Well I am now switching between both MAC and Windows regularly which actually turns out to be a positive thing, let me explain. MAC’s coexisting with PC’s is becoming more the norm in most enterprises it seems.I have very few companies I work with that don’t have elements of both in their organizations. So using and understanding both has been a big learning curve for me but at the same time its helped me understand the different issues this brings.

A few things I learned in this experience are Office on a MAC is terrible (no really, just terrible), there is no great Visio substitute on a MAC unless I want to pay for it myself (not happening, I am cheap), and the constant Windows updates being one of the reasons I tried so hard to move to MAC still bug the crap out of me. In the end some of the important stuff I needed to do ended up on a virtual PC running on my MAC which worked but I felt it was ruining my MAC experience. So I settled for second hand PC hardware . I am using my PC as a desktop work machine and all mobile requirements I have are on Apple devices. The PC has some double duties for demos as well when required. Overall though this seems to be working really well. It’s a lot of devices to manage but considering my role I have some unique requirements which makes it somewhat of a requirement to work with and understand different platforms.

BTW I am writing this on a Windows 7 PC and am just about to reboot with another 59 updates. sigh..

Okay, 2 reboots later and I am back.

To be fair it’s a new build on my PC but in saying that I have updated this PC more times in two days than I have my MAC and iPad (iOS 7 upgrade included)combined in three months. Just saying.

In all of this I have found a new admiration for my iPad which I do love. iOS 7 certainly added some good new features which make it easier to multitask. My Surface RT basically sits on shelf uncharged, unloved while my iPad goes with me everywhere even if I have another compute device. Outside of the keyboard on the Surface RT which was handy the iPad (with a Logitech BT keyboard) is a superior device or maybe I should say eco system. The biggest issue with the Surface RT (and Windows Phone for that matter which I still own) is the lack of apps, hence my eco system reference. There were also a few performance issues I encountered with the Surface RT but at the end of the day lack of apps is still the main issue. Surface Pro probably would have been a better device since it can load legacy apps but I don’t have one and therefore I don’t care to go there. iPad wins for me and I can see clearly now why enterprises are choosing it.

Now with all that said I did use my Surface RT quite extensively when I worked at Microsoft. This was mainly because nearly all the apps I used were Microsoft applications. Lync, Skype, Office etc. So if this is your world it is possible to deal with Surface RT even with the app choice limitation. The problem I found was once I stepped out of the Microsoft applications choice was pretty limited. When I was not working I was actually using an iPad. It was my dirty little secret. Merely because the apps I liked were not on the Surface RT. Even reviews of the newly released Surface 2 mention this in nearly everyone one I read. It’s a real issue that Microsoft will need to address for real success on either Surface or for that matter Windows Phone.

With iPad the only limitation I have found is the lack of Microsoft Office apps (not exactly a surprise) but there is a work around for that. IOS 7 brings the Apple productivity apps for free. Although these aren't the equivalent of Office they are good enough for light work. I can envision lots of different job functions getting away with just an iPad and the right apps. There is no denying that BYOD is at critical mass. An IT support model where the user buys their own device and supports it. Basically you have just outsourced OS/application updating and device support to Apple or Google (didn’t want to leave Android fans out in the cold). What company wouldn’t in some manner think this was attractive? I can certainly see in the future where a company just has a compute allowance for users. I can remember early attempts at this by some companies back around 2005 but I see it as more achievable now.  I have not run into a large company doing this yet but I am sure they are out there or will be soon.

Anyway, these are my thoughts and pains of dealing with multiple OS’s and devices.The bright spot in all of this has been Jabber. Across all my devices I have had the opportunity know to give Jabber a solid workout. Jabber focuses more on the personal side of communications bringing together devices and software for the end-user while having deep integration into WebEx for web conferencing. While I know a great deal of you will argue every company wants everything in one application, practically this is not always optimal. This is due to the large variation of features that both personal communications and conferencing encompass.Having come from Microsoft where Live Meeting Service is still often used for larger events instead of Lync, it proves to me that just one application tied to one service delivery infrastructure can be a limitation. Jabber provides a  solid middle ground of tying services together for the end-user whether the service is coming from the cloud or on-premise. This is really cloud on your terms for communications which is the flexibility companies are looking for and has given me a new perspective on delivering UC services.

BTW If your interested in signing up for early releases of Jabber here is the signup on Cisco communities:

 https://communities.cisco.com/community/technology/collaboration/eap_signup

VoIPNorm

Project Workplace

I have tweeted about Project Workplace a few times in the last few weeks. If you haven't visited Project Workplace and have any interest in enterprise video and collaborative spaces its worth a few minutes to check out. This is a continuously updated website that lays out the format for collaborative spaces right down to seating positions to get the best experience.

http://www.cisco.com/assets/sol/tp/workplace_app/index.html?page=home/

It also has a section on best practices to help with things like lighting levels and reverb.

Enjoy.

VoIPNorm

WebEx Connect and CUPS IM and Presence on a Windows Phone

Cisco has yet to release a Windows Phone client but there is an alternative open stands XMPP client to at least do Instant Messaging and Presence. I rarely us anything beyond IM & P on my smartphone device even when I had the ability to do so with other UC clients so this fits my needs nicely. This will most likely work with a Cisco Unified Presence deployment as well but I have yet to test that. I have used it with WebEx Connect successfully and it functions just fine although its not the prettiest of clients as you will see below. Its really basic which some people may actually like.

Jabbim will work with any XMPP based service and happens to be one of the few existing XMPP clients available on Windows Phone. To set it up for WebEx Connect your administrator will require that a DNS SRV record is in place so that the service can be located by the client but other than that if WebEx Connect has been enabled for your organization you should be good to go. I have included some screenshots below which show the basics of the client and the setup.

The trickiest pieces is to ensure you have the right server record for the account settings. For WebEx Connect users, use the DNS SRV record in the form of c2s.<your org>.com.webexconnect.com. The other settings are just general user name, domain, password etc. Port for WebEx Connect does not need to be changed.

Like I said earlier its not pretty but it is effective. This shows Cisco’s commitment to open standards and XMPP for both the Connect service and CUPS. Having the option for third party clients without having to require additional plugins is a nice to have.

Update: Thanks to a peer @ Cisco I have since tried a few more apps and settled on IM+. Seems to be a much nicer looking client and I am already using it on my iPad. Only draw back is the free version has Advertising. All the XMPP capable clients can be found here:

http://xmpp.org/xmpp-software/clients/

Gotta love open standards.

VoIPNorm

Device Review: Cisco DX650 - The Desk phone just got a lot smarter

When I first come across the DX650 it wasn’t clear to me what the use case was and I was more interested in the list price which as everyone points out no body pays anyway. While working for Microsoft I was heavily focused on their own ecosystem of products that getting time to evaluate a Android device just wasn’t at the top of my priority list (and maybe frowned upon somewhat:). Although other desk phone manufactures are using Android as a phone OS it’s a locked down version that somewhat obscures Androids real capabilities. The DX650 has the capabilities to lockdown the user to only the preloaded app’s but the part of power of any Android device is the Google Play Store. Which I will cover more a little later.

I am not going to chant through all the technical details of this device as there are quite a few. Below is the main product video which is about an hour long run through of the entire device which is much nicer than me writing about it here. Look out for David Scott, he really knows his stuff on the DX650. David is a product manager at Cisco so he gives some great insight into the product and its configuration inside CUCM.

DX650 on TechWiseTV

Also here are some links to some more tech spec which should cover the deeper technical questions.

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/phones/ps12956/ps12959/solution_overview_c22-726842.html

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/phones/ps12956/ps12959/solution_overview_c22-726841_ps12956_Product_Solution_Overview.html

My view

I have been using the DX650 for a few weeks now. It’s a interesting product with some compelling use cases. Probably the most interesting of which is remote worker/telecommuter and VDI access. There are others like remote video enabled contact center agent but that’s an entire post all on its own.

Remote worker

I have been a telecommuter/remote worker for a good part of 7-8 years now. At Microsoft and now Cisco I have never been allocated desk space and my previous employer before either of those mentioned I telecommuted at least one day a week. Seattle traffic sucks btw. So having a solid work at home solution for communications is very beneficial. A PC/MAC with soft client although good short term for longer term home worker there are better solutions. Obviously a highly mobile worker at their desk less than 25% of their time is not going to benefit as much as say a knowledge/contact center worker.

I have tried a host of solutions over the years from PC with soft client to personal telepresence video solutions and now the DX650. While those other solutions have their place the DX650 seems to be better suited to someone like me that needs a communications solution but my company may not be willing to spend large amounts of dollars on something more high end like an EX90/EX60.

One thing I noticed and this might just be me but even now working at Cisco, if the remote device only does voice it doesn’t get used and I go back to a soft client which has more functionality. So in other words if the device doesn’t have integrated contacts, calendar integration, video etc., it turns into a dust collector. The only time I used a voice only device is if someone calls and my MAC wasn’t up and my cell phone was MIA. So to me a well integrated desktop device is way more functional and therefore more likely to get used than just a normal desktop phone (in my opinion). I have found using WebEx on the DX650 is the new audio conference for this device. 

There are a few things that make the DX650 so compelling in this situation:

• Easy access to video
• Secure always on connection with VPN if required
• Integrated WebEx and Jabber
• Access to the Google Play store to add additional functionality

There are others like Wifi, Bluetooth etc but the ones above really stick out. Below is the DX650 with a personalized wallpaper image. I am actually using a Logitech USB headset with it but this could be a Bluetooth device just as easy. This is the logon screen which requires a pin to unlock. It gives me a quick view of event, voicemail etc without having to unlock the device.

Below is my customized start screen, I have added a RDP client from the Google Play Store and placed a calendar widget on my start screen. No Angry Birds as yet! This is a screenshot btw. When I first started writing this post I was taking photos of the screen before it dawned on me that there must be away to take screenshot. Of course there is with Android ICS. Volume down button and lock button pressed simultaneously dummy.

You will also notice a WebEx app. This was way more capable than I first thought it would be. You can do most things from generating the invitation, to starting and hosting the meeting from the DX650. Below is a photo of a screen sharing session with my home PC.

So if I happen to be on my MAC working jumping on a WebEx no longer ties up my MAC to keep the content front and center. This is an issue with always using a MAC/PC to attend virtual meetings because once you switch off of the content its pretty easy to loose focus or have an issue finding the right window again.

Below is the contacts which can be imported from a variety of places but you'll notice that some are showing presence being imported from Jabber.

Finally calendar integration.

So really well integrated communications platform, much more akin to a smartphone but with a better quality user experience for voice and video. I even loaded Twitter!

Remote desktop/VDI Experience

Let me first give a bit of a description of my setup. I have MAC running VMware Fusion that is running a Windows desktop. I wanted to test out RDP running from the DX650 so I loaded a free RDP client from the Google Play Store on the DX650 than launched a RDP session to the virtual desktop. I also have a Bluetooth Keyboard paired with the DX650 because typing on screen just didn’t make sense for this.

Below is the logon screen during the RDP session:

Logged into the RDP session and running Jabber. Not that this is it real use case but basically this is way to run any legacy Windows app just add your flavor of VDI into the mix such as VMware or Citrix.

During my RDP testing I only added a keyboard and used the on screen touch to drive the interface but a mouse could be added as well as using a dual display. Having a communications device that can produce high quality voice and video as well as run a VDI session overcomes one of the biggest limitations to VDI. Real time media within the VDI session. Although there are plugins there is always some limitation around the underlying OS or the quality isn't great depending on the hardware, it just seems as though removing the media from the VDI is a more sensible approach.

Obviously this removes the need for another device to run the VDI session and having a separate communications device.

The Power is in the Apps

As I pointed out earlier part of the power of this device is in the apps delivered through the Google Play Store. I was able to create an RDP session just with a simple app download. So this makes for a powerful communications device. If I just look at my device I can access Twitter, Google Hangouts, Enterprise HD Video & Voice, Webex, email (Exchange and Google), calendar, VDI, RDP etc etc all with the use of apps. Some are DX650 specific and others are typical downloads from the Play Store. So making the desktop phone relevant again for various use cases but also a communication hub for the user.

Hell, if Samsung wants to put a internet connection in a fridge we should expect more from communications devices. Taking advantage of the established Google Play Store makes a lot of sense to provide a richer experience for the user.

Does it run Lync?

No it doesn’t. Mainly because Microsoft controls which hardware and software Lync can load onto that they have tested. It can however run a number of other UC clients that run on Android.

Conclusion

The DX650 is not your ordinary desktop replacement. Thinking that you would replace every users phone with a DX650 probably isn't going to happen at most organizations but with the right use case it may make sense versus the cost. This is an intelligent device that takes communications to a new level. Everyone seems fixed on using a tablet for everything that maybe this device can do but like I mentioned in a tweet, no one wants to see nose cam every time you make a video call especially in the contact center. I also haven't ventured into CEBP and how Android apps combined with the device could really skyrocket use cases like telemedicine (should be renamed to collabhealth) but I will leave that for another day.

VoIPNorm

Switching from PC to MAC and from Microsoft to Cisco

As some of you may have noticed I have had a recent lull in activity both here on VoIPNorm and on Twitter. I was going through somewhat of a techie rebirth. I know that sounds a little hippie but it is the best way I could think to describe it. Let’s put it this way for a least a while my head was spinning and I wasn’t sure if it was just going to pop off with all the gyrations. With all the head spinning though when I informally announced my move to Cisco on LinkedIn through a profile update I got lots of questions and congrats. I know I haven't responded to everyone directly but hopefully this blog post will help do that.

Switching from PC to MAC 

Out of all the things I have done in my career this was one of the most frustrating weeks of my life but its not all that it seems. After 14 years or so of working on a Windows machine, I was switching my work PC to a MAC in my first week at a new job at a new company. This is not something I would recommend to everyone but in the end a lot of my frustration was mainly self inflicted by not asking for help.

This is what I have learnt about the MAC. Microsoft Office on the MAC or more to the point Outlook is no where even close to the Windows version. PowerPoint and Word are just fine for what I need but I really don’t like Outlook. The Windows version is better but it’s a Microsoft product on a Apple platform so I can’t say that I am all that surprised. So I am in search of a better mail client I just don’t know what that is yet. The native client has been suggested to me but I am going to do some digging before I make a change.

OneNote which I used heavily previously is not available on the MAC. I really like OneNote so I was bummed there was no MAC version, but a great alternative is Evernote. It is a little less organized in its layout compared to OneNote but I like the way it syncs across my MAC and other devices without needing to put anything on SkyDrive. I noticed some folks running a Windows VM on the MAC but that just didn’t seem attractive to me. I would rather find alternative applications if needed.

My last frustration came down to my lack of MAC knowledge which was the track pad. Two finger tap is a right mouse click dummy. It took a coworker to help me solve that puzzle. If I had just asked for help earlier!

In the end it was a combination of a lack of MAC knowledge and finding substitutes for applications causing most of my frustration, most of which I have remediated. Overall though I am impressed with the stability and usability of the MAC. I have had to reboot for updates once or twice but that’s been it, the MAC is super stable. Obviously MAC presents less hardware choices which leads to a more stable platform but the design of the MAC hardware is pretty impressive.

So I am sticking with my MAC and marching forward. Everyday gets a little easier for this 14 year PC veteran.

Switching from Microsoft to Cisco

Of course this probably came as a huge surprise to a lot of people and something at one stage I may have never considered but change is good. There are a lot of similarities but also a lot of differences between the two companies. This was never “its greener on the other side of the fence” type situation but something I looked on as a personal growth opportunity.

Lync presents a great software solution but as anyone in the industry knows it takes more than great software to build a communications solution. Cisco offered me a chance to get a better insight into an end to end solution that is unrivaled in the industry for completeness of vision. I will be the first to admit that both companies face unique challenges in todays UC market. This makes for an exciting transition with moving to Cisco and seeing the challenges from both sides now.

In my opinion there is nothing more challenging than understanding a completely different perspective than the one you have today. It has certainly opened my eyes to a whole new way to look at UC which  only serves to benefit the companies I am trying to help succeed with Cisco UC. I really did enjoy my 4 years at Microsoft but am looking forward to new success at Cisco.

VoIPNorm

Updated: CUCM SIP URI Dialing to Lync 2013–New SIP URI Normalization rules on CUCM

I created the original post for this configuration back in July of last year and its seen quite a bit of traffic and had some great comments. I just thought with the release of Lync 2013 and some new interesting developments it would be worth adding new info and refreshing some of the content to better speak to Lync 2013.

I have recently added community fixes to issues that have arisen so this post is certainly worth a revisit when I make updates. Please continue to comment and make suggestions. I know quite a few companies are now using this configuration based on this blog post so keep the info and questions coming and I will keep updating.

What's this post all about?

I have seen quite a bit of using Cisco’s mobility feature to dual ring a Cisco phone and Lync. There is an interesting feature in CUCM that could make your life easier. Its called SIP URI dialing. This isn't a new feature as its been around since 7.x days or possibly earlier. It sparked my interest back in 2008 but I never really investigated it further until 2012.

SIP URI dialing is really a pretty basic concept. Instead of using a normal DID route pattern to designate a destination you use a SIP URI such as lyncuser1@contoso.com. By specifying @contoso.com as your SIP route you assign a SIP trunk that points to Lync. Its actually pretty simple and works with Cisco’s mobility feature used in Remote Destination Profiles.

There are some caveats with this feature though and its not terribly flexible. It does require some special configuration but could possibly make dial plans and  interoperability a little easier. Also you can remove the issue of requiring unique DID’s on both systems because now that your ringing between systems with a unique SIP URI using the same DID on both systems is much less problematic. So users don’t have to change numbers or use a new number for Lync, it can be the same as their Cisco IP phone.

To make things a little easier to understand, in this post I am referencing the To field in a SIP message when I am talking about Tel URI or SIP URI. I am using Tel or SIP to define trunk routing behavior even though both are configured as SIP trunks when configured in CUCM. Its just the routing behavior based on the address format I am trying to better define. Hope that’s not to confusing.

Why use it?

While working in the field I get a lot of questions from engineers around how do I make my Cisco phone and Lync ring at the same time. As I have covered here on my blog there are a couple of ways to do this from either CUCM, Lync or even potentially from a gateway. But there is a level complexity in regards to how to configure DID’s and how to make DID’s unique enough so that you can route between the two platforms. Well using SIP URI dialing instead of DID’s this simplifies this portion of the configuration and leaves Lync’s Sim Ring feature open for users to configure it for their cell phones. Using Sim Ring as the tool to ring a Cisco desk phone in my opinion is a waste of an easy to configure end user setting. I strongly believe this feature is better used to ring a cell phone or other devices self administered by the user.

The interface for configuring Cisco Remote Destination Profiles is potentially very intimidating for normal users. There are settings and timers that if set incorrectly can cause issues. That’s why in my opinion RDP’s should be configured by an administrator and Sim Ring on Lync is a better choice for self service by the average user. There is only one timer and phone number fields can be prepopulated making the users phone number selection easy. Also Sim Ring has the ability to use the business hours set in Outlook where as Cisco’s RDP requires this to be recreated under the RDP profile. If your using RDP’s for more than just ringing Lync this might be handy.

From a self service point of view Lync allows the user to set Sim Ring and Business hours which are inherent in Outlook straight from within Lync. Timers for voicemail forwarding are available but other timers are system controlled and not exposed to users removing the potential to create issues. Sim Ring can also be changed by the user from all the mobile apps.

RDP’s although not overly end user friendly can be used in different ways to help integrate Lync into your preexisting environment. It can ring up to 5 endpoints. RDP could also be used as way to keep voicemail in a different voicemail messaging platform other than Exchange UM for Lync users but still allow a user to have Lync as a softphone. This might be important for companies that do want voicemail in email for compliance reasons etc. So RDP has some great uses for working around common issues.

Caveats for SIP URI dialing?

The single biggest caveat for SIP URI dialing is that when you create a SIP Route pattern in CUCM it does not allow assigning a route group to it. You have to directly assign a trunk to the route pattern. The main issue is that once assigned to the SIP route pattern you can no longer assign the same trunk to a route group which limits your options. The best way to deal with this is to have a SIP trunk just for SIP URI routing. In CUCM 8.6 you can have multiple endpoints (in our case mediation servers) assigned within a SIP trunk which means that this isn't a redundancy problem. Its more a configuration issue on the CUCM side but since this configuration is for a specific purpose I don’t consider this a show stopper.

With Lync 2013 this trunk can now have its own port within the Lync trunk configuration. This means we can create a trunk with its own rules on either system. It really doesn’t mean that its simpler but certainly more configurable from a call control point of view.

How to set it up?

The easiest way to do the setup is to follow this guide with a few alteration which I will call out below. This is the Microsoft produced guide. In the Microsoft guide they make use of Calling Search Spaces (CSS) which gives a more complete picture of the settings required. In the Cisco guide there is no call authorization setup so unless you know which CSS to configure you could easily miss a setting as there are multiple places to set CSS on various pages. The one that caught me out was the rerouting CSS on the Remote Destination Profile.

What's needed for Lync?

The SIP URI trunk is for inbound use only. This means that setup on the Lync is pretty simple if you already have a SIP trunk setup for your CUCM deployment. As long as your CUCM servers are already added to the topology as gateways you are already done. Just make sure that the inbound SIP URI trunk to Lync is using already established ports.

In Lync Server 2013 we can take the configuration a little further than 2010. We can define individual trunks for each dialing type. Like I said earlier this doesn’t make it simpler to configure but it can make the configuration clearer to understand. Now we have two well define trunks to the same gateway and we can name it accordingly so we have a clear understanding of the configuration.

If creating two trunks in Lync 2013 the individual trunks are identified by the inbound port on the gateway side of the configuration (in our case CUCM).

The trunk configuration is then completed in the Lync Control Panel or PowerShell. Below are a couple of screen shots for the configuration I completed in my lab but for more complete details on setting up a SIP trunk to CUCM refer to this document http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=26800. Although this document refers to Lync 2010 a lot of the same rules apply to 2013. Also keep in mind there are variances in the exact setup according to the version of CUCM you are using. In my example lab REFER is support by CUCM 8.6 so I left it as enabled but other versions this will differ. Use this link to match your CUCM version setting requirements http://technet.microsoft.com/en-us/lync/gg131938.aspx.

Trunk settings for encryption, enable media bypass and REFER for CUCM 8.6.

The last time I posted this info Alex Lewis asked the question about “You say the DID can be the same in Cisco and in Lync but if I'm in Lync and dial another user then only their Lync endpoint will ring.” Well thanks to an Anonymous tipster I believe that we have somewhat of a solution to this. There is an attribute that can be added to the users Tel URI that will stop Lync from doing the usual RNL behavior. This means that any call to the users extension can be routed to CUCM regardless of whether its configured in Lync as the user line URI while allowing the RDP in CUCM to ring the Lync client. Now this is by no means a perfect solution. There is potential hair pinning of calls through Lync to CUCM and back to Lync. While this has the potential to consume some extra resources its not going to be life threatening in most cases. Its just a matter of planning for it and understanding call flows in your environment.

What you potentially end up with is a Line URI that looks like this:

tel:+12345678;ext=5479;ms-skip-rnl

The ms-skip-rnl is what will cause Lync to pass the call directly out to CUCM rather than follow normal reverse number look up behavior for calls to be routed to users. This attribute is actually used else where in the product for certain functions such as CAC and RCC so its not a total mystery of its existence but this is not its normal use.

Lastly I just want to mention, use this configuration at your own risk. This is not the usual configuration that one would follow in setting up Lync. When calling in a support ticket this attribute may be required to be removed if you are having issues. As my friend and college Doug wrote to me in an email exchange “The mechanism that it leverages will probably remain in the product forever but, if they called support, the engineer would probably go, “huh?”. I think you get the idea now.

How do I configure CUCM?

In my testing I was using CUCM 8.6 so your settings may vary depending on the version you have.

SIP Trunk

The thing with this configuration is that you are creating a SIP trunk for one purpose and that is to ship messages with headers that have the “to” field with a SIP URI format to Lync. So LyncUser1@contoso.com as an example.

Your Tel URI and SIP URI SIP trunks can share the same SIP Security Profile and outbound ports to Lync but you will need to use different DNS/SRV names or IP address DNS name combinations. So as an example:

SIP URI Trunk – FQDN – 2013-lync-fe.contoso.com

Tel URI SIP Trunk – IP Address 192.168.0.170

Below is my trunk configuration for my SIP URI routing with a FQDN for my Lync 2013 Mediation Server.

SIP Profile for calling out a specific listening port:

In my case I used a IP address on one trunk for Tel URI calling and the FQDN on the SIP URI trunk. Now if you are not that fixed on configuring route groups and route lists for the SIP trunk connecting to Lync you can configure the trunk directly on both DID and SIP URI route patterns and just have one trunk. I tried both in my lab and it worked either way.

In this 2013 update I changed around my configuration somewhat to route to separate trunks that have separate port numbers as well. Like I said earlier this give the ability to create more control at either end of the trunk on either Lync or CUCM.

Update: SIP Normalization Rules

I received quite a few emails and comments from people that ran across an issue. If your Lync deployment was larger than a single pool the port specified in the SIP invite from CUCM would cause calls to fail. If you user wasn’t part of the pool associated with the mediation server receiving the invite from CUCM redirecting the invite to the correct pool would fail. The error message generated indicated a port issue.

LogType: diagnostic
Severity: warning
Text: Message was discarded by the application
Result-Code: 0xc3ee7964 ES_E_REQUESTURI_VALIDATION_FAILED
SIP-Start-Line: INVITE sip:firstname.lastname@contoso.com:5060 SIP/2.0
SIP-Call-ID: a5c03a60-e790-4490-9e02-75baf13b8250
SIP-CSeq: 51567 INVITE
Data: application="http://www.microsoft.com/LCS/UserServices"
$$end_record

Seems Lync didn’t like the header with port 5060 being part of it when passed to another pool. The exact reason why it doesn’t like it I am not sure why but this was the issue identified.

This really stumped me. I wasn’t quite sure how to work around it but luckily a reader supplied the answer. CUCM has the ability to create normalization scripts to fix header issues like this. This is somewhat similar to MSPL scripts in Lync which many of you are probably familiar with but uses an open source scripting language called Lua http://www.lua.org/docs.html. Here is a similar example I also found that replaces IP address with a domain name.

Creating the Script: Device>Devices Settings>SIP Normalization Script

Add new-

Paste in the follow contents, name the script and save::

M = {}
function M.outbound_INVITE(msg)
local method, ruri, ver = msg:getRequestLine()
local uri = string.gsub(ruri, "5060", "5061")
msg:setRequestUri(uri)
end
return M

Finally apply the script to your CUCM SIP trunk for SIP URI dialing.

SIP Route

Probably the new piece of configuration to most people will be the SIP route itself. Its pretty easy to configure. See below. I created a domain route to contoso.com to route my SIP URI traffic that I setup for my users on their Remote Destinations.

User Setup

As far as the user setup goes the only variation between the standard setup mentioned in the guide I referenced earlier is to configure the user with a SIP address to route calls in the Destination Number under Remote Destination configuration. In my case I used garthf@contoso.com as my destination number rather than a DID or other number.

This configuration is probably one of the most important interoperability pieces I have written in a while. I can see this alleviating quite a few issue I have come across in the field and hopefully this article will get good circulation so more people know about it. If I look over all the possible ways to do interoperability between Lync and CUCM (RCC, Plugins etc, etc) this really does give the best of both worlds without sacrificing one for the other unlike other methods like plugins which ruin the Lync UI experience. There are some complexities for the initial setup but at the end of the day your using the features available of both products without the use of third parties or additional servers. Call it the biggest bang for your buck if you will.

If folks need more explanation please feel free to post your questions.

VoIPNorm