| Tuning is performed to improve efficiency. You tune the radio to get a stronger, clearer signal. If you have an older car, you give it a tune-up to increase the efficiency of the engine. Likewise, you can make tuning choices to improve the efficiency of a network and VoIP deployment. When tuning your network, consider the trade-offs. Depending on the environment, you may trade increased CPU utilization for less RAM, or more delay for less risk of lost data. Often, tuning involves configuration changes—to the routers, switches, VoIP servers, or IP phones. Default configuration values don't always work well, so you may need to make adjustments to improve efficiency. TCP/IP Tuning The TCP/IP protocol stack generally operates with very high efficiency. However, in some cases, tuning can improve performance. Here are some obvious areas you can adjust: -
TCP window size— The TCP window size determines the amount of data that can be sent before the sender has to stop and wait for an acknowledgment. If you have a very reliable network—in which the chances for data loss are very small—then increasing the window size can improve throughput. On the other hand, if the network loses data frequently, a larger window size would force more data to be retransmitted when packets get lost, resulting in lower throughput. Most TCP/IP stacks adjust the window size dynamically to optimize performance over a wide range of network conditions. -
MTU sizes and low latency— The maximum transmission unit (MTU) or maximum frame size on a data network is usually 1500 bytes. This is reasonable for elastic applications, but at an extremely slow speed such as 56 kbps, 1500 bytes takes longer than 200 ms just to put the packet on the wire. To avoid breaking your delay budget for VoIP, you have to set a smaller MTU size to be forwarded through the slower-speed links. Although this costs a small amount of data efficiency, you should not need to change anything other than one router configuration command. Current Microsoft Windows TCP/IP stacks routinely perform "black hole detection" and adjust their MTU accordingly. (For a detailed discussion of black hole detection, see RFC 2923.[9]) -
Concurrent sessions per URL— When you type a URL into your web browser, the browser opens TCP/IP connections to retrieve the data. A typical web page may consist of many files of information to retrieve. TCP/IP application writers have to make a tuning choice—open the optimal number of connections to retrieve the data in a relatively small timeframe. The trade-off for concurrent downloads is extra memory and programming complexity. The benefit is faster response time. VoIP Tuning Trade-Offs Tuning VoIP implementations entails many possible trade-offs. Often, you are trading off quality (or risk) against some limited resource, such as bandwidth. The following sections describe a few VoIP tuning possibilities, accompanied by their trade-offs. IP Phone Configuration Configuring IP phones offers a series of choices. Although most phone vendors do a good job of choosing defaults for configuration parameters, in some cases you need to make configuration changes. Here is an overview of some of the trade-offs: -
Codec— Call quality is heavily impacted by the codec you choose. But higher-quality codecs generally require more bandwidth. Codecs, such as G.711, consume many times more bandwidth than G.729. However, the G.711 codec provides a higher MOS given the same network conditions. When choosing a codec, you are inevitably faced with the trade-off of quality versus bandwidth consumption. -
Silence suppression— Silence suppression means that when you are not talking, little or no data is sent over the wire. Offered by certain IP phones and softphones, silence suppression can reduce the bandwidth required for a VoIP call by 50 percent or more. However, the resulting speech may sound choppy or clipped, and it may be unnerving for users when they hear total silence during parts of a call. Again, you have to consider the trade-off of quality versus bandwidth consumption. -
Jitter buffer size— A jitter buffer can smooth out any variations in packet arrival times that may be introduced by the network. If jitter is a problem on your network, a larger jitter buffer can hide the jitter problem. Some phones can configure the size of their jitter buffers dynamically. Ideally, you would make the jitter buffer as large as the maximum jitter experienced. However, jitter buffers add delay, which can break your delay budget and reduce the call quality. So, you have to consider the trade-off between increased delay and call quality. -
Speech packet size (delay between packets)— The speech packet size reflects the size of the payload that is sent in each VoIP packet. The larger the payload, the more voice data that is transferred in a single packet, with a resulting reduction in header overhead. However, if a larger packet gets lost, the impact on the quality is greater than it may have been if smaller packet sizes had been used. You have to consider the trade-off of quality versus bandwidth consumption. Most IP phones have codecs that optimize the speech packet size, so this tuning parameter is best reserved for advanced tuning. Call Admission Control—H.323 Gatekeeper Call admission control (CAC) is a tuning technique that can constrain access to a resource. Networks are often oversubscribed, as discussed earlier, and WAN links have a finite amount of bandwidth. Allowing unlimited user access to a finite resource makes everyone unhappy. Admission control schemes try to address this problem. For VoIP deployments, the trade-off is call quality versus allowing all users the opportunity to make a phone call at the exact same time. -
The H.323 standard for multimedia transmissions provides CAC with a device known as a gatekeeper. Gatekeepers, as the name implies, control admission of VoIP calls into a network. Assuming that allowing too many calls over a single link degrades the quality of all calls, the gatekeeper's job is to prohibit a new call if the network can't provide adequate bandwidth. To do this, the gatekeeper must keep track of the number of calls in progress and the bandwidth available. You therefore need to consider the number of calls that will be managed by each gatekeeper. If numerous users make phone calls that are rejected by the gatekeeper, you will probably have some dissatisfied users. Figure 5-15 shows a gatekeeper environment. Figure 5-15. The Gatekeeper Controls How Many VoIP Calls Are Admitted into the Network 
UDP Checksums By now, you have probably recognized that the complexity of a VoIP deployment rests largely on the sheer number of parameters you can potentially configure. Even a UDP checksum could be considered a VoIP tuning parameter. The UDP checksum is a field in the UDP header that provides a check for datagram integrity. The datagram sender performs a mathematical computation on the contents of the datagram and stores a value in the UDP Checksum field. Then, the datagram receiver applies a mathematical computation to the UDP Checksum field to detect errors that may have occurred during transmission. Figure 5-16 shows the UDP Checksum field in the UDP header. Figure 5-16. The UDP Checksum Field Is Usually Ignored by the Sending and Receiving Sides for VoIP Call Traffic 
Some IP phones and VoIP gateways set the UDP Checksum value in VoIP datagrams to a value of 0, effectively disabling the data integrity checking that occurs on the receiver side. The reason for doing this with VoIP traffic is to improve the efficiency of RTP header compression and to save the time needed to compute the checksum. With normal UDP Checksum values, the field changes for every datagram. By using a value of 0, which does not change throughout a VoIP call, the cRTP algorithms can better compress the header fields. VoIP accepts the trade-off of a risk of data error versus better compression and slightly reduced delay. |
