I’ve racked my head a few times now trying to calculate how big a pipe I need for various call concurrencies. So I’ve decided it’s finally time to sit down and do the calculations for both SIP/RTP and IAX2.
SIP/RTP
SIP accounts make use of RTP packets to transmit the voice data. The frequency and size of these packets varies based on the actual codecs in use, but hopefully the information here will give you enough info to re-perform these calculations. For the sake of being uniform I’m going to assume the G.729 codec right through this article (The best compression/quality ratio, at 8Kbps there is simply nothing better that I’m aware of).
The general structure of an RTP packet is something like (pardon the ascii art):
[IP Header][UDP Header][RTP Header][Payload]
The IP header is generally of a fixed size at 5 32-bit words (20 bytes) as most IP packets does not contain “options”. This is just because that’s the way IPv4 was designed. In a similar fashion the UDP Header is 8 bytes because it was designed that way. So for TCP/IP overhead we’re looking at 28 bytes per packet.
The RTP header (according to RFC1889) is at least 12 bytes, but can be longer. A lot of sniffing and starting at packet traces shows that 12 bytes is the norm and I’ve very seldomly seen something different.
The G.729 codec can encode at either 10ms intervals, or 20ms, generally though it’s 20ms, so the frequency is 50Hz (or 50 RTP packets per second). The payload size of G.729 at 20ms intervals is 20 bytes (8Kbps => 1000 bytes/second => 20 bytes/frame).
In total we’re thus looking at 20 + 8 + 12 + 20 = 60 bytes per packet, 50 packets per second, or 3000 bytes per second, ie, 24Kbps. Per active channel.
So that’s it hey? Well, no. If you look at for example DSL on ATM, the ATM frame sizes is 48 bytes. So for a 60 byte packet we’re consuming two frames, or 96 bytes per packet. So in fact we’re looking at 96 x 50 = 4800 bytes per second, or 38.4Kbps. Does this difference sound scary? Yes, it does to me. So in essense you have to round the base packet size up to the closest “cell” boundary size (eg, up to the nearest 48 on DSL) before multiplying by the number of packets.
In South Africa there is 3 ADSL line speeds commonly available:
- 384/128Kbps
- 512/256Kbps
- 1024/384Kbps (or 4096/512 Kbps if you’re lucky).
So, now to calculate how many calls we can carry on each of those we take the “up” spead (after the /) and divide by 38.4, and we get to the numbers 3, 6 and 10 (or 13). Experience however has shown that the 384 lines are not that good as Telkom’s congestion ratio’s are just too high and on a 384 line you’re pretty much guaranteed to suffer exhaustion on your “uplink” (which results in you having a stuttering voice). The 512 lines work pretty well, but again, we wouldn’t recommend pushing more than 4 actual calls … oversubscription is a BITCH. Especially in the UP direction where we suspect the contention ratios are higher than on the DOWN link. Telfree claims that you can’t make more than 6 concurrent calls on a single 1Mbps line, we’ve yet to actually perform a scientific test, for the moment we’ll say that you should be able to make 8 but contention might start hammering you. We’ve not had the luxury of being able to test on a 512 uplink yet, but based on the Telfree report 8 should be perfectly viable and we’d reason even up to 10 (and maybe 11). The discrepency between our calculated figures and those reported by Telfree could also be due to codec choices. We do not know which codecs they used during their testing.
IAX2
Whilst IAX2 is not always the best choice, we must say that the voice quality results we’ve seen has been phenominal. Typically we get significantly better quality with IAX2 rather than SIP, however, for an on-site system SIP provides some tangible benifits (possiblity to send extension specific commands to phones etc … also, some features are not available in IAX2 – or we couldn’t make them work). This isn’t really surprising as IAX2 was designed as an Inter-Asterisk-eXchange protocol, not an end-point protocol. Why bother? Well, IAX2 has some bandwidth benifits, and with trunking the “cell” effect from above becomes less problematic.
For starters, let’s consider a single call. As per SIP we have the IP/UDP overhead of 28 bytes.
Then we head of to the internet draft (currently at http://www.ietf.org/internet-drafts/draft-guy-iax-05.txt), to look at the IAX format. This reveals that for single-calls the per-packet IAX2 overhead is generally 4 bytes (section 1.1). This means that we’re looking at 32 bytes of overhead in total compared to the 40 on SIP. Not a big saving. Well, ok, for a single call we end up with 52 bytes per packet (still 96 bytes on DSL), still at 38.4Kbps. Without trunking this will be the per-call overhead. Obviously when using technologies that doesn’t have this much overhead on it’s cell sizes (ethernet has a minimum size of 64 bytes which afaik includes a 14 byte ethernet header, so even at 52 bytes we’re exceeding that). I’m not sure about diginet. Point being that on dsl we don’t gain anything on a single call, and even on ethernet we don’t really gain much. On diginet we might already start seeing a difference.
Now, however, we add a second call. Instead of creating a new IP frame we simply add the two payloads into the same packet (they’re headed to the same IP/port, so why not?). It is not 100 % clear to me exactly how much additional overhead gets added in the packet on a per-call, but it seems that we can say that the 4 bytes increases to 8, with an additional 4 bytes on the packet itself. So the packet size becomes 28 + 4 + (8 + payload_size) x ncalls. So if we have 10 calls with g.729 (20 bytes) we’re looking at a packet size of 312 bytes. Compare this to a total byte size of 600 for RTP! And even on DSL if we round the packet sizes we’re now looking at 336 bytes per packet for IAX compared to the 960 for the 10 packets for the same data in SIP. Thus we need 50 of these packets, or 15600 bytes (16800 on DSL) per second. This is equivalent to 124.8Kbps (134.4Kbps).
A little math get’s us a formulae for the number of calls given the available bandwidth (this doesn’t take into account the cell size and all answers needs to be verified with the above if cell size is an issue):
ncalls = (bandwidth / frequency – 32) / (payload_size + 8).
So if you’ve got a 1Mbps link you should be able to get 88 concurrent calls (Keep in mind the bandwidth above is in bytes per second, not bits). Other factors (like IP fragmentation will bring this figure down. With 80 calls the UDP fragment length becomes 2272 bytes big, dividing it into two IP datagrams, adding another 20 bytes to the whole story.
Using the above the theoretical limits for DSL (In SA at least) is as follows:
- 384/128:Â 9 calls (10 if you ignore the cell size issue).
- 512/256: 21 calls.
- 1024/384: _exactly_ 33 calls (in other words, I’d say 32 or even less for the sake of quality).
- 4096/512: 43 calls.
Conclusion
It’s been shown that IAX can definitely handle WAAY many more calls than SIP on the same link. Please note that these values may well vary based on the actual networking conditions and these are guidelines only. If you give your clients any figures they need to be informed that these are estimates ONLY and cannot be guaranteed (unless someone more knowledgeable than myself can confirm my math, even then, these figures looks higher than what I estimated, especially for IAX2).
