Author: Patrick Tredway

It’s no secret that WebEx clients have existed on the iOS and Andriod platforms for quite some time. Having said that, the release of the iPad2 and the latest WebEx Meeting Center release…things have gotten pretty cool! At last, the usability of the tablet device in a WebEx session feels comparable to sitting at a desktop. From the high quality view of shared content, native VoIP integration for the audio call path, the tight integration with the built in cameras, there’s not a whole lot you will find missing.

 

With the Cisco Cius just becoming orderable at the end of May 2011, we eagerly awaiting our new tablets to see how they compare. Even Cameron seems excited…see below!

 

 

As you may have read, TBL recently hosted its first Ask Harley : Guitar Hero Edition. As a part of this session, we hosted a live broadcast of Harley and Mr. TBL rocking out to “Beat It” by the late Michael Jackson. Those in attendance to the event received a link where they could feast there eyes upon these savant sirens. While Harley and Mr. TBL were the most obvious players in the video, there was some pretty nifty camera work and technology underpinning the event.

Holstered with nothing more than a Cisco VT Camera and a laptop, Bryce Hazlewood, one of our support engineers, captured the event with professional like precision. The laptop in Bryce’s possession streamed the live video feed to a TBL owned Cisco Show and Share portal server which external participants ultimately used to watch on. I only wish we could have had cameras on the participants as I’m sure we would have captured some great reactions.

In all seriousness, this event marked the beginning of TBL’s adoption of these video technologies to capture, store, categorize, and report on the plethora of video content floating around our organization. Just this week our CEO used the technology to record and post an internal company update. TBL is by no means the biggest company in town, but even we are seeing the need to solidify how we will create and distribute video content efficiently and securely.

If you haven’t heard yet, there’s a new kid on the block as it relates to connecting dial tone to your phone switch. Nearly all of the traditional service providers (and even some new ones) have come up with some sort of SIP offering for PSTN connectivity. However, seeing as the technology is still in an embryonic stage when compared to its ISDN forefathers, each service provider seems to have their own little tweaks to SIP delivery.

Now, not every PBX or phone switch out there is ready to support SIP dial tone…which, in my opinion, should be the second thing you investigate. The first and most important question to ask is “What does SIP offer to my company that traditional TDM based dial tone does not?”

To illustrate this important point, let’s go back a few years – the birth of VoIP. Back in those days, a little more than a decade ago now, Cisco led the charge in converging TDM based voice technologies onto a packetized, often IP driven, data networks. In doing so, we all became ever so aware of some of the risks and more importantly the risk mitigation techniques needed to be employed to make the conversion plausible. While we got the benefit of toll bypass, we picked up the responsibility of assuring an even level of service to RTP streams across our wide area network – quality of service (QoS). While we assumed all the advantages of a single PBX instance for an entire enterprise, we acquired the responsibility for providing local call processing for a remote site when a network failure occurs.
Some had to learn these lessons through hard knocks. So, my question is to you, how will you learn from history and avoid being doomed to repeat it? I have a few suggestions…

1. Start with a solid business case (or lack thereof) for a SIP rollout. From my position, I see two strong cases:

   a. Cost Savings – I have a few clients who have multiple remote sites that require PRIs for functional reasons, but may not have the usage requirements to support 23 bearer channels. A regional bank is probably the best illustration of this. While a bank branch may need DID, DNIS, addressable CLID functionality, they typically will have fewer than 3 or 4 concurrent calls during any period of the work day. So in this case, if we can bring those 3 or 4 talk paths onto a data circuit and relieve the cost of the PRI loop, we can save some money.

   b. Disaster Recovery – This is a big one. When you have a site or a remote PBX go down, you have few options to get those numbers re-routed to another site and avoid the “All circuits are busy” message being played repeatedly to your customers. At best, you can call your service provider and request an emergency call forward on a few numbers which typically gets put in place within a few hours – just in time for your circuit to come back online…wash, rinse, repeat. With SIP, most carriers allow for backup IP addressing for where a call is delivered to your network. This gives us the flexibility to offer at least one other point of entry to the network for those numbers…without having to call a soul.

2. TEST, TEST, TEST and then TEST some more. Seeing as most of these service offerings come from providers who are already offering you data services today, it stands to reason that you could have a few test numbers lit up and use those to test. Some key items you will want to watch out for – voice quality, DTMF exchange (call into an IVR), call forwarding and outbound CLID preservation. Once you think everything is working fine, port a few DIDs for a few users. Nothing says you need to cut an entire site or even a heavily used number the first time.
3. Pick a good partner. SIP cutovers don’t always go as smoothly as you might like. You’ll want to have a partner who has done a number of these cuts before and is adamant about having a solid reversion plan. If you’re having trouble finding one, give me a call…I should have a recommendation or two.

Cisco has begun sunsetting their media convergence servers (MCS) server line which has been supporting Unified Communication applications for nearly a decade. This sunsetting began about eighteen months ago with the removal of all HP based MCS servers, leaving only IBM. The removal of HP based MCS servers was timed shortly around the announcement of Cisco’s new home grown Unified Computing (UCS) line of servers. The UCS platform is purpose built for virtualization and offers quite a bit of cost savings and efficiencies over the traditional platforms.

Beginning with the 8.0 and continuing into the 8.5 releases, Cisco’s collaborative products are being certified for co-resident operations in virtual environments. Specifically, the UCS C210 and B200 platforms have been selected to replace what used to be MCS 7835 and 7845 servers. With a price point coming in just under the cost of a single MCS 7845, the C210 server can support four 7845 equivalents on a single piece of hardware.

Add into that, the advent of the Cisco Unified Workspace Licensing (CUWL) model, the UCS line allows for the to standing up and testing new services which organizations had previously been entitled to under CUWL but may have been hardware constrained in completing.

With all of that…why buy another MCS?

As the collaborative experience is evolving in the workspace, it is driving the need for more and more rich media and therefore better performance of the underlying hardware and network. The fastest growing medium of this new experience is video. In the time that it takes to write this article, google will have serviced 70 million search requests and the second most utilized ‘search engine’ will service 30 million searches – YouTube.

Combine the onslaught of video and rich media collaboration with another market trend, virtual desktops, and we get an interesting situation. Virtual desktop protocols are great at doing what they were originally designed to do – transmit screenshots, mouse clicks, and keyboard strokes. These protocols (RDP or ICA) are lacking in their ability to deliver rich media content over the network within reasonable bandwidth constraints. Some protocols (PCoIP) have risen to the forefront of the market to address this need but are still lacking.

Think about it. If you take a point to point video call between to pc’s, the video is encoded in a protocol that is purpose built for delivering high quality video over a packetized network. H.264 is a great example.

Imagine that same call between two virtual desktops, the bandwidth between the desktops themselves doesn’t change, but we now introduce another leg for that media to travel – between the virtual image and the thin client connected to the remote keyboard and monitor. The protocols used in this leg are the weak point. They can take what is a 128Kbps video call and increase the load on the network to over 2Mbps between the virtual image and the thin client. That’s an increase of 1600%.

So where’s the solution? Meet the ‘Virtual Experience Infrastructure’!

Cisco has formed a coalition of companies, all working in the virtual desktop space, to design products that offer the best of both worlds, local media processing and virtual desktop services. The first tangible products to be born from this group will be the Cisco VXC 2100 and 2200 thin clients, which are due out Q2CY11. The 2100 will be a backpack model hanging off the rear of a Cisco 8900 or 9900 series IP phone. The 2200 model will be standalone.

Check back for more details as the products release.