Many organizations are moving (or considering the move) to cloud-based UC services as a way to reduce costs and increase availability. The cloud-based UC provider can achieve efficiencies of scale and streamline operational functions. The result is the ability to offer UC services at a price that's very competitive with an organization's ability to provide the services internally.
But using a cloud UC implementation doesn't mean you can overlook the need for QoS mechanisms.
An organization's bandwidth requirements can vary significantly, from LAN speeds in campus environments to WAN speeds that service remote offices. Mobile staff can be limited to network connections over a mobile phone connection and Internet connections at available hotspots (i.e., at a coffee house or hotel), where QoS is ignored. The mix of environments suggests that traffic be classified and marked when it enters the enterprise network. Outside the organizational network boundaries, the QoS policy is likely to be: Hope for the best.
UC applications
The typical UC applications are voice, interactive video, streaming video, screen sharing, and interactive chat. I've listed them in the order in which most QoS policies will prioritize them. The reasoning is that voice is the most important service and has the tightest constraints with respect to timely packet delivery. It uses UDP, with specific port ranges that allow the definition of QoS policies for prioritizing voice over other flows. Interactive video uses UDP, too, for both the video and audio flows -- although it's more important for the audio stream to reach the recipient than it is for an unblemished video stream to reach the recipient. The importance of the audio stream requires that QoS policies favor the audio stream over the video stream.
TCP data flows apply to streaming video and screen sharing, which are next in priority. The use of TCP allows for reliable delivery, while deep buffering by the receiving codec minimizes playback delays. Packet loss in a streaming video session can cause delays as TCP retransmits data. These delays appear to the user as "Buffering..." pauses when the receiver's codec waits for data to display.
Read the rest of this article on No Jitter.