[asterisk-users] Bandwidth requirements

[Brian Candler]

On Wed, Oct 04, 2006 at 07:51:14PM -0400, hugolivude wrote:
>    Age old question it seems but I haven't been able to get a handle on
>    it yet.  Let's assume I'm using a g729 codec.  If I wanted to handle
>    20 simultaneous calls, how much bandwidth would I need?  Is there a
>    general formula for this?
>    I tried this caluclator:
>    [1]http://www.voip-calculator.com/calculator/eipb/
>    I wasn't sure what "Packet Duration to select so I took the default
>    20ms (2 samples) - whatever that means.

A 20ms packet duration means that 20ms of audio is stuffed into one IP
packet. Since each packet carries 1/50th of a second of audio, that means
you're generating 50 packets per second for each channel.

With g729 your audio is 8000 bits per second.

The overhead on each packet is 20 bytes (IP) + 8 bytes (UDP) + 12 bytes
(RTP) = 40 bytes or 320 bits.

So your bandwidth requirement per channel is:
- 8000 bits per second for payload
- 320x50 = 16000 bits per second for overhead
making a total of 24000 bits per second.

20 simultaneous calls is therefore 480,000 bits per second.

That is a bit of an underestimate though, because it doesn't include any
layer 2 framing overhead (i.e. for encapsulating the IP frames in the
underlying medium). For example, if it were HDLC serial on a leased line,
that would be just 2 bytes per frame for flags, maybe a couple of bytes for
CRC, plus occasional bit-stuffing.

However on ADSL, you have to add the 15% ATM cell tax. And you would be wise
to add 20% headroom (i.e. so your line is not more than 80% full)

As you can see, the packetisation overhead is twice as large as the useful
data you're transporting. You can reduce this by increasing the packet
duration, but that increases the latency of your audio (and ADSL links
already add 20-30ms of latency themselves). Too much latency is
objectionable to users.

I have read that if you use IAX2 trunking it's able to combine audio from
multiple streams into a single packet, thus sharing the overhead between
them, but I have no experience of this myself.

HTH,

Brian.