Language: English Español Русский Українська Help!

Payload is with2 ms or frames3 per packet.
RTP is
 Silence Suppression4      RTCP5      channel(s)6

Average7: kbps
Maximum8: kbps
Packet rate12
Average: pps
Maximum: pps
Frame: ms
Lookahead: ms
Algorithmic: ms


  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 50% of what it would have been without silence suppression. (Estimates of the resulting bandwidth vary widely from 35% to 80%, but 50% seems about right.) 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 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.729 at 1 frame per packet using RTP silence supression across a 33.6kbps PPP link because this only consumes 22.4kbps on average. However, when there is a voice signal, one will need 44.8kbps, 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.

Other Online VoIP Bandwidth Calculators

Standalone VoIP Bandwidth Calculators

Authorized Mirror Sites