There are a few inaccuracies as well as important unmentioned facts in this article:

*Riverbed doesn't have to be inline (although they prefer it).

*Riverbed and Cisco do not have the abiity to even process UDP traffic so providing any benefit to VoIP is impossible from a compression perspective (not to mention that their algorithms do not handle precompressed data well anyway).

*Riverbed recommends, and Cisco defers, to doing QoS on the router. In both cases (and as observed in the article for Riverbed), this is primarily because their WAN optimization devices do not perform these functions well.

*The above scenario creates a paradox from a network standpoint. If you're not processing ALL of the traffic on the network (TCP and UDP), how can you truly provide an overall benefit to the totality of the applications using it? Further, by deferring to the router for QoS, you obviate the ability to prioritize and shape the virtualized bandwidth provided by the compression mechanisms. There is no way that a device external to the optimization product can have any knowledge of that virtualized bandwidth.

There are products in the WAN optimization space that provide all of the functions - process all network traffic; provide the ability to process precompressed data 9and not add additional latency overhead to sensitive traffic such as VoIP); perform critical QoS function within the platform to control both physical and virtual bandwidth. These products should be considered as well when performing a true evaluation of viable WAN optimization products.