Bandwidth Calculator

Notes:

1. Select the outermost, or lowest-protocol-level, headers to include in calculations. For example, selecting "RTP" includes the payload and RTP header but not UDP, IP, or link headers.
   
2. Payload packetization can be specified in terms of packet delay (in milliseconds) or number of frames per packet. Specify either one and the calculator will figure out the other based on the frame delay for the selected codec.
   
3. For frame-based codecs, e.g., G.723.1, this field specifies the number of frames per packet, or fpp. For sample-based codecs, e.g., G.711, this field specifies the number of samples per packet. Note that
   this calculator does not follow the H.323 convention of a "frame" being eight samples in the case of sample-based codecs. If this confuses you, just specify packetization in terms of packet delay.
   
4. This reduces total bandwidth to 35% of what it would have been without silence suppression (this reduction typically ranges from 35% to 50%). Any SID frames are not included in the bandwidth calculations.
   
5. This increases bandwidth in the reverse direction by taking into account RTCP traffic. Bandwidth, not including link headers, is increased by 5%. RTCP traffic may indeed be lower, so this should be considered a liberal estimate.
   
6. This is the number of unidirectional channels, so for the total bandwidth used for media during a simple two-way call, you would specify 2 in this field.
   
7. Average bandwidth is the same as Maximum bandwidth except when the silence-suppression checkbox is checked, in which case it is lower.
   
8. This is the maximum instantaneous bandwidth. When silence suppression is used on a physical channel that has fixed capacity, e.g., 33.6kbps, one must especially consider this metric because when a voice signal is present, one needs all of the maximum bandwidth, and the Average-bandwidth metric is not really useful. For example, it would appear, based on the calculated Average bandwidth, that one should be able to transmit G.711 64kbps at 160 samples per packet using RTP silence supression
   across a 33.6kbps PPP link because this only consumes 28.8kbps on average. However, when there is a voice signal, one will need 82.4kbps, so this codec is not suitable for this application.
   
9. Computational delay is not included in any of these values. Like the DSP MIPS metric, computational delay is implementation dependent and can vary considerably although it is usually not a significant portion of the end-to-end delay.
   
10. This is the MIPS required for an encoder/decoder pair and not just one or the other. It is implementation dependent and varies considerably from one implementation to another.
    
11. Mean Opinion Score is very subjective and varies from one scoring episode to another depending on a variety of things, e.g., sample size, acoustic environment, and methodology. The values presented here are for audio with no packet loss. Some codecs fare better than others under packet-loss conditions.
    
12. Packet rate is especially important for sizing a network against a router because routers are not only constrained by bandwidth but the number of packets per second, or pps, that they can process.