The latest and greatest from Cisco’s SRND on release 10:
Deployment Models & Expressway
This is the first time that Expressway has been covered in a SRND. There is a great new section under deployment models that covers VPN and VPN-less access. Cisco’s solution for Collaboration Edge access is one of the most comprehensive in the industry. Having both the ability to provide both VPN and VPN-Less access makes Cisco’s UC solution extremely flexible and gives companies lots of options.
VPN-Less Access with Cisco Expressway
Chrome and Firefox changed their policy to automatically block plug-ins. Below is a Q and A from WebEx support to ensure folks know how to re-enable the plugin . I am guessing that this is going to affect more than just WebEx.
These are the most frequently asked questions about how to join a WebEx meeting on Google Chrome and Mozilla Firefox:
Q. How do I enable the WebEx plug-in to join a WebEx meeting?
A. You will need to follow the steps below after the following estimated browser version release dates:
- Firefox version 27—estimated February 2, 2014*
- Chrome version 32—estimated January 10, 2014*
Follow these steps to enable the WebEx plug-in and join a WebEx meeting:
- 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.
- If you have not already installed the Cisco WebEx meeting application software, install it now.
- 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)**
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.
A. The following browser versions require that you activate the WebEx plug-in:
- Chrome version 32 and later*
- Firefox version 27 and later*
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.
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.
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.
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.
- 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.
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.
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.
Media Services Proxy
Medianet datasheet and System requirements
Jabber 9.2 Medianet
Medianet MSI Developer Center
Auto configuration tutorial
Cisco Prime Collaboration