Editor’s Note: Welcome to our weekly Reader Forum section. In an attempt to broaden our interaction with our readers we have created this forum for those with something meaningful to say to the wireless industry. We want to keep this as open as possible, but we maintain some editorial control to keep it free of commercials or attacks. Please send along submissions for this section to our editors at: dmeyer@rcrwireless.com.
If you manage an enterprise IT network, chances are that “high-quality video sessions” are the last words you want to see. As most businesses are still trying to figure out how they’ll deliver voice and instant messaging services to a small army of different mobile devices (thank you, “bring-your-own-device”), the thought of adding high-quality video to the mix is too much, too soon, right? But the truth is, whether you’re an enterprise or a service provider with enterprise customers, you need to consider how you’ll deliver high-quality video today or you’ll find yourself left out of the conversation tomorrow.
In recent studies, three out of four enterprises identify themselves as having either partially or fully deployed unified communications solutions in their network. Why is this significant? Because UC drives the demand for video services. In our company (Sonus), for example, we’ve seen a dramatic rise in the number of video conferences since implementing Microsoft Lync at the beginning of the year. Employees have spoken: they want video, they want it often, and they want it to look good.
Unlike voice over IP, video over IP presents unique challenges with its own networking requirements. The human ear is forgiving of microsecond gaps in conversation, but the human eye is very sensitive to any delays or dropped packets. As a result, video sessions require not only greater network bandwidth, but also an assurance of end-to-end quality for the duration of the session. Guaranteeing end-to-end quality of service for video sessions is risky, though, because of the natural separation between the application and transport layers of the network. In laymen’s terms: the application (e.g., a Lync video call) and the transportation (i.e., the network including various devices like routers and gateways) do not communicate with each other to ensure quality of service. The responsibility, therefore, falls to enterprises and service providers in the form of several choices:
–Over-provision network capacity to accommodate the rising bandwidth demands of video.
–Enforce consistent quality-of-service policies across multiple networks for each video session.
–Ignore the problem and hope that employees and customers learn to live with occasionally choppy video.
Option No. 1 is costly, especially for wireless service providers where network bandwidth is at a premium. Option No. 3 is just as costly in the end, since customers aren’t likely to tolerate poor-quality video any more than they accepted poor-quality audio in the early days of VoIP. On the surface, option No. 2 may sound more costly and complicated than option No. 1, but it’s actually the simplest solution to high-quality, end-to-end video.
Video sessions use the same networking protocol – session initiation protocol – as other real-time, IP-based communications such as VoIP and instant messaging. SIP communications are common in today’s service provider and enterprise networks, with the latter often purchasing a specified amount of SIP bandwidth through a SIP trunking service hosted by the service provider. In between the enterprise and service provider networks sits a device – a session border controller – that protects the network like a firewall, routes calls to various destinations to and from the network, and enforces specific user and network policies within the network.
With an SBC, networks already have the SIP architecture in place to support policy-enforced video communications. Unfortunately, an SBC alone only allows you to enforce QoS policies for video sessions in your network. An SBC doesn’t “see” what happens at the other end of that conversation. For example, to upgrade a Lync voice call I’m having with a customer in Texas to a video-conference so I can share my whiteboard, three networks suddenly need to upgrade the amount of available bandwidth to ensure a high-quality video session: mine, the service provider’s and the customer’s. Without visibility into the available bandwidth of those other two networks, any video session is a crap shoot as far as quality is concerned.
There are networking products, however, that do provide that kind of visibility. Devices like Juniper Network’s Session and Resource Control engine, for example, can map out a multi-network path in microseconds that looks at each router (or hop) in the path to determine whether there is the end-to-end bandwidth capacity to support video. Without an SRC, the SBC can only enforce call admission control as far as the next hop in the network. With an SRC, the SBC can decide whether to allow/deny a video call based on the conditions of all network hops in the session’s path.
Let’s revisit that video call with an SBC and SRC working in tandem. As my Texas customer and I upgrade from voice only to videoconferencing, my SBC receives a request to initiate a video session and signals to the SRC to determine the end-to-end bandwidth capacity along the current network path. The SRC looks at the state of the routers in the path and presents my SBC with a “yes/no” response regarding current bandwidth conditions, leaving me with a series of options based on the responses:
–Yes, you’ve got plenty of bandwidth—go for it!
–Yes, but with provisions – my SBC may need to reduce the bandwidth requirements, try another codec for a lesser quality video session or simply proceed with the best effort possible.
–No, there’s not enough bandwidth to support a high-quality video call – try an alternate route, deny the call or fall back to audio.
What’s particularly attractive about this approach is it leverages network investments that many service providers and enterprises already have in place, such as SIP trunking architecture and an SBC. Using the network-to-network intelligence of an SRC-type device, service providers and enterprises can deliver end-to-end video quality assurance to their users based on dynamic, per-session policy decisions that take into account user profiles, time-of-day/week, service level agreements and other parameters – all without re-architecting their networks or re-configuring routers and SBCs. Should traffic volumes exceed the maximum threshold, the SRC preserves the video quality of calls already in progress by throttling back the last call to accommodate the available bandwidth.
Any way you look at it, the more your SBC sees, the more control it gives you over video quality.
