Packetization, schmacketization
Packetization, or the amount of voice payload placed in each packet, is measured in Milliseconds. The packetization options available to you depend on the CODEC you choose. For the purposes of this post I would like to focus on G.729. The default for CallManager is 20ms and the available options are 20, 30, 40, 50, or 60ms. Voice packets are very different from normal data packets (I use this as a generic term for data traffic, not just layer 3) in that headers make up a major portion (49 – 74%, depending on packetization) of the packet size. By choosing to place more voice (ex. 60ms) in each packet, you are effectively reducing the number of packets needed to carry a second of your voice and also reducing your administrative overhead (non-voice portion of the packet).
Since this all sounds rosey and wonderful, why would Cisco set the default at 20ms? Put another way, what is good about packetizing at a lower increment? More packets, while costing you bandwidth, would help ease the effects of packet loss. Losing a single packet at 60ms would be the equivalent of losing 3 packets at 20ms. The de-jitter buffers on your Cisco routers can make up for the loss of a packet at 20ms, but not at 60ms. Outside of easing packet loss, packetizing at 20ms means you wait for 20ms of voice, then put it into a packet. 60ms then would delay sending that first packet by 40 additional ms. While 40ms is not that big of a deal in the grand scheme of things, it is a fairly significant portion of the 150-200ms recommended one-way delay.
Without going into the math, G.729 uses 31.2Kbps at 20ms and 15.7Kbps at 60ms. So are you willing to part with some survivability and add 40ms of delay to get twice the number of calls? It really depends on your available bandwidth. If you are humming along at OC-192, you would REALLY need to make a lot of phone calls for a change from the default to make sense. In the Marine Corps, a lot of our external communications are satellite based and very low bandwidth. If you are lucky and you only need one satellite hop to get to your destination, you are already at 300ms (propagation delay out to space is a beast). With the recommendations for delay no longer within reach, why not add an additional 40ms and make twice the calls?