Awards ...

Reliable, cost effective videoconferencing over converged enterprise WAN

Videoconferencing is probably the most challenging application to run over an enterprise wide area network (WAN). Just as for VoIP, end to end quality of service (QoS) must be provided to ensure that whenever congestion occurs, the videoconferencing video and VoIP packet streams get real-time priority. On top of that there needs to be sufficient bandwidth to support the videoconferencing session(s) alongside other business applications on the network. With a single videoconference session typically consuming between 400Kbps of bandwidth for a small standard definition picture to north of 1 Mbps for an HD call, a T1/E1-based MPLS network for remote offices just doesn’t have the bandwidth to support video simultaneous with other critical business applications. Doubling private WAN MPLS bandwidth just to enable videoconferencing is often simply not an option due to the high cost of bandwidth.

Talari’s Adaptive Private Networking (APN) WAN Virtualization technology addresses the challenging requirements of videoconferencing in a number of ways:

Abundant Bandwidth

Bandwidth using APN is 30 to 100 times cheaper than private WAN bandwidth, so businesses can afford to provision much more bandwidth than they otherwise could afford. Existing bandwidth provisioned only for VPN-based backup or local Internet access can be used immediately. Aggregating 2 – 4 broadband DSL or cable modem connections together with an existing MPLS network is easily done, and more bandwidth can be added as needed.

Further, if a videoconferencing session is too large for a single upstream WAN link — something quite possible with ADSL upstream bandwidth, for example — the session can be striped across multiple WAN links, enabling HD videoconferencing even where an MPLS network or any single 1.5Mbps upstream link is unavailable.

Ingress QoS

An APN conduit between two sites can have up to 10 classes of service which allows videoconferencing and VoIP packets to be assigned the appropriate priority relative to email or file transfers for instance. This guarantees that videoconferencing/VoIP packets are not delayed in getting on to the WAN. Limits can also easily be placed on the real-time traffic to prevent starving of other business traffic. To determine which traffic is videoconferencing/VoIP and deserves real-time priority, Talari’s Mercury APN appliances can be configured to honor IPTOS and DSCP markings and also can be configured to make this classification decision based on flow characteristics such as port number and/or source or destination IP address.

Congestion Avoidance

At the start of a call, APN will automatically pick the path which currently has the best characteristics for a videoconferencing call (low loss, low jitter, sufficient bandwidth). Since APN continually monitors these characteristics of a path it can quickly reroute videoconferencing/VoIP packets, sub-second, to a new path with minimum disruption in sound/video quality.

Optional Packet Replication

To offer the highest possible video and sound quality, it is possible to trade additional — and thanks to APN, inexpensive — bandwidth for ‘platinum’ quality. By replicating real-time videoconferencing packets over two disparate paths across the network, suppressing duplicates at the receiving appliance, APN can always pick from the most timely of 2 videoconferencing packets and so be able to hide packet loss or excessive delay on either of the paths. This replication also can be set to occur only when sufficient bandwidth is available for the replicated traffic, and/or could be set for the voice portion and not the video portion of the call.

Destination Traffic Shaping / Egress QoS

Before traffic leaves the sending location and is placed on the WAN, APN ensures that the sum total of traffic heading for a destination matches the available link bandwidth to avoid “self-induced” congestion at the entry to the last mile link. This avoids the congestion-based quality problems when traffic is entering a link from two different sources which TCP on its own is actually designed to cause.

Learn More