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