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