Bandwidth requirements for the transmission
There are many factors involved when calculating the bandwidth required through a network. This white paper aims to explain these factors, and to offer a simple means of making such calculations. It starts with a basic 'rule of thumb', and then expands this to take specific voice coding algorithms into account.
There are many ways to reduce the bandwidth requirements, and these can be particularly important in the wide area network. These include silence suppression, RTP header compression and RTP multiplexing. These methods are not considered in this document.
You can try out the calculations described in this white paper by visiting our free Lines to IP Bandwidth Calculator. It can be used online, now.
In our white paper Voice over IP Protocols for Voice Transmission, we concluded that the standard method of transporting voice samples through an IP based network required the addition of three headers; one for each layer. These headers are IP, UDP and RTP. An IPv4 header is 20 octets; a UDP header is 8 octets and an RTP header is 12 octets.
The total length of this header information is 40 octets (bytes), or 320 bits, and these headers are sent each time a packet containing voice samples is transmitted. The additional bandwidth occupied by this header information is determined by the number if packets which are sent each second.
For the purposes of this document, we define packet frequency as the number of packets containing voice samples which are sent per second. The packet frequency is the inverse of the duration in seconds represented by the voice samples. For example, if the voice samples in one packet represent a duration of 50 milliseconds, then 20 of these samples would be required each second. The packet frequency would therefore be 20.
The selection of this payload duration is a compromise between bandwidth requirements and quality. Smaller payloads demand higher bandwidth per channel band, because the header length remains at forty octets. However, if payloads are increased, the overall delay of the system will increase, and the system will be more susceptible to the loss of individual packets by the network.
We know of no recommendations concerning packet duration. In RFC1889, the Internet Engineering Task Force include an example where the duration is 20ms, but they do not suggest this as a recommended value.
There is no absolute answer to this question, but for the remainder of this document, we will assume that voice samples representing 20ms are sent in each packet.
If one packet carries the voice samples representing 20 milliseconds, the 50 such samples are required to be transmitted in every second. Each sample carries a IP/UDP/RTP header overhead of 320 bits. Therefore, in each second, 16,000 header bits are sent.
Therefore, as a general rule of thumb, it can be assumed that header information will add 16kbps to the bandwidth requirement for voice over IP. For example, if an 8kbps algorithm such as G.729 is used, the total bandwidth required to transmit each voice channel would be 24kbps.
The designer of any network convergence solution that includes voice will need to decide upon which coding algorithm to use. CODECs perform the conversion from an analogue voice waveform to a digital stream of information. They sample the analogue signal at regular intervals (125 microseconds is a typical value), and convert the measured analogue value into a numeric representation (known as quantising). The resultant output comprises discreet blocks of information sent at regular intervals.
The method suggested in the previous section offers a simplistic view of the bandwidth calculation process. It is valid for most coding algorithms, however, it assumes that voice samples can be transmitted within a 20ms datagram. For coding algorithms which use much smaller sampling periods, multiple samples can be sent within each packet, and the samples can be buffered for up to 20ms. However, some algorithms do not produce samples which can be fitted exactly into 20ms datagrams, and for those algorithms, the 16kbps rule of thumb becomes invalid.
The following tables shows the relevant characteristics of the most common coding algorithms.
The algorithms listed which do not fit into the 16kbps rule of thumb are the two G.723.1 systems (highlighted on the table). As their sample duration is 30ms rather than 20ms, only 33 frames are sent each second. This reduces the header overhead to 10.66kbps.
Detailed consideration of each coding method is beyond the scope of this document, but it should be understood that the various coding methods vary in the levels of complexity, delay characteristics and quality. The CODECs which are expected to become prevalent within the Voice over IP arena are G.729A and G.723.1.
This document has offered a quick method of calculating the bandwidth requirement for individual calls being transmitted through an IP network. As a rule of thumb, it is suggested that 16kbps be added to the compressed voice bandwidth to calculate the total bandwidth required. This assumes a packet duration of 20 milliseconds. G.723.1 requires special treatment, because its packet duration is 30ms.
For a typical 8kbps compression scheme, the overhead is 16kbps (or 200%). Methods exists, or are being developed, which reduce this overhead. These include silence suppression, RTP header compression and RTP multiplexing. These will be the subject of further documents published at this Web site.
Send E-mail to
TSN@The-Saudi.Net with questions or
comments about The Saudi Network.