Codecs, bandwidth and capacity planning

Lesson 2 introduced codecs as the language two endpoints agree to speak. This lesson goes further: how the common wholesale codecs compare, exactly how much bandwidth one call uses, and how to turn traffic numbers into a capacity plan for links, ports and channel limits. All figures are worked examples you can repeat with a calculator.

The codecs you will meet

Two other items travel with the codec list in SDP and matter just as much: telephone-event (DTMF sent as RFC 4733 packets) and T.38 (fax relay). If your partners disagree on DTMF method, IVR menus fail even though voice works.

Anatomy of a voice packet

A codec produces a frame of audio every few milliseconds. The sender bundles one or more frames into an RTP packet; the time covered by one packet is the packetization time, or ptime, usually 20 ms. Every packet then gets headers:

Calculating bandwidth per call, step by step

1. Payload per packet = codec bit rate × ptime ÷ 8. G.711 at 20 ms: 64,000 × 0.02 ÷ 8 = 160 bytes. G.729: 8,000 × 0.02 ÷ 8 = 20 bytes.
2. Packets per second = 1 ÷ ptime. At 20 ms that is 50 pps; at 30 ms, about 33.3 pps.
3. Add headers. IP 20 + UDP 8 + RTP 12 = 40 bytes. On Ethernet add another 18 (header and checksum).
4. Multiply: packet size × pps × 8 = bits per second, in each direction.

Bandwidth (bps) = (payload + headers) × 8 × packets per second

Notice two things. First, G.729 saves a lot but not a factor of eight, because the headers stay the same. Second, a longer ptime saves bandwidth but adds delay and makes each lost packet more audible. Encryption (SRTP) adds an authentication tag of around 10 bytes per packet, and VLAN tags or tunnels add more; include them if you use them.

From one call to a whole link

Voice is symmetric: the figures above flow in both directions at once. Now the important wholesale detail: if your switch relays media (RTP passes through it rather than flowing directly between customer and vendor), every call has two legs on your server.

Worked example. You expect 300 simultaneous calls, half G.711 and half G.729, all relayed through the switch on Ethernet:

150 × 87.2 kbps = 13,080 kbps   (G.711)
150 × 31.2 kbps =  4,680 kbps   (G.729)
one leg, one direction     = 17,760 kbps
two legs (media relay)     = 35,520 kbps  ≈ 35.5 Mbps in AND 35.5 Mbps out
+ about 5% for SIP signalling, monitoring and management
total planning figure      ≈ 37.5 Mbps each direction

Keep links below roughly 70–80% busy-hour utilisation; queues start to add jitter well before a link is technically full. On a 100 Mbps port, that example leaves comfortable room. The same 300 calls all in G.711 would need about 55 Mbps per direction — still fine, but no longer “tiny”.

How many channels do you need?

Channel limits on gateways and vendor agreements are about concurrent calls, not bandwidth. Estimate them from busy-hour traffic in Erlangs: one Erlang is one channel busy for a full hour.

Erlangs = answered minutes in the busiest hour ÷ 60

Example: in the busiest hour you carry 18,000 answered minutes. 18,000 ÷ 60 = 300 Erlangs, meaning about 300 calls in progress on average during that hour. Then add headroom:

• Calls in setup and ringing also hold channels. With low ASR this can be a noticeable share.
• Traffic is never perfectly smooth within the hour. Planning formulas such as Erlang B give the exact number for a target blocking rate; as a rule of thumb, add 20–30% on top of the average.
• So 300 Erlangs → plan for roughly 375–400 channels, and set vendor and customer limits with that in mind.

Transcoding: when the two legs disagree

If a customer sends only G.729 and the vendor accepts only G.711, the switch must transcode: decode one and re-encode the other. That works, but it has costs:

• CPU or DSP capacity. Each transcoded call uses far more processing than a relayed one. Know how many transcoded calls your platform supports and keep a limit on them.
• Quality. Each compression step loses some quality; transcoding twice on one path (G.729 → G.711 → G.729) is audibly worse.
• Delay. A few extra milliseconds per conversion.
• DTMF and fax. In-band tones rarely survive G.729. Use RFC 4733 events for DTMF and T.38 or G.711 for fax.

The cleanest design is to agree codecs during onboarding so both legs share at least one codec, and keep transcoding for genuine exceptions.

A capacity-planning checklist

1. Collect busy-hour answered minutes per customer and per vendor.
2. Convert to Erlangs, add 20–30% headroom, and set channel limits.
3. Note each partner’s codec and ptime, then calculate per-call bandwidth.
4. Double the figure if your switch relays media.
5. Add overhead for signalling, monitoring, recordings and backups.
6. Check the result against port speed and your provider’s commit, keeping utilisation under about 75%.
7. Review monthly; traffic grows quietly until the day it does not fit.

Examples in this course use invented names (Vendor X, Customer Y, Country Z) and documentation IP ranges. Menu names and options differ between softswitch versions; always check your own system and vendor documentation.