Hi, 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: 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. I plugged in 5 for the BHT (20 customers, each getting 3 X 5 minute calls/hour = 5 Erlangs) and the default 0.01 for the Blocking. It worked out to 264 kbps. Does this sound reasonable? If so great! A business DSL could support this. Comments welcome! Cheers, H -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20061004/060c6608/attachment.htm
Hi, 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: 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. I plugged in 5 for the BHT (20 customers, each getting 3 X 5 minute calls/hour = 5 Erlangs) and the default 0.01 for the Blocking. It worked out to 264 kbps. Does this sound reasonable? If so great! A business DSL could support this. Comments welcome! Cheers, H -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20061004/1cd7534f/attachment.htm
> > I wasn't sure what "Packet Duration to select so I took the default > 20ms (2 samples) - whatever that means. I plugged in 5 for the BHT > (20 customers, each getting 3 X 5 minute calls/hour = 5 Erlangs) and > the default 0.01 for the Blocking. It worked out to 264 kbps. Does > this sound reasonable? If so great! A business DSL could support this. > > Comments welcome! >Sounds about right to me. 8kbps + overhead. Transcoding 20 simultaneous channels requires a relatively hefty machine I think
Let me paste my old reply to this: Let's do some calculations on that: g729a 20ms results in 20 bytes RTP payload in each packet, in order to traverse the OSI model there's some headers that need to be added, as RTP gets an RTP header, the RTP packet gets an UDP header and the UDP datagram gets an IP header: So add a 12 byte RTP header, 8 byte UDP header and a 20 Byte IP header This results in: 20 byte RTP payload + 12 byte RTP header + 8 byte UDP header + 20 byte IP header=60 byte on the ip layer. Thats a 40 byte overhead (so 2/3 of the packet is just headers :) and were still only on the IP layer now) So to transmit just 1 RTP packet you are actualy transmitting 60 bytes on the IP layer, so in order to get the real used bandwidth we need to knowhow many packets we are sending and on which medium (DSL/ethernet/slip/smokesignals): 20 ms results in 50 packets/s so: 50 packet/s *60 bytes/packet=3000 bytes/s that's 300*8=24000 bit/s total bandwidth on the IP layer so the overhead is 24000-8000=16000 bit/s. The fun starts if you are going to send this over DSL, let's continue the calculation: 50 packets of 60 byte IP, add the 2 byte PPPoA header for DSL= 62 bytes per packet. However, DSL operates with 53 bytes ATM cells, in which you can fit 48 bytes payload (and a 5 byte header) so in order to transmit the 62 bytes of data you need: 62/48=2 ATM cells. Why 2 cells you say? Because ATM can't utilize the unused part of cells, so to transmit 62 bytes you use the same amount of bandwith (on dsl) as you would use to transmit 96 (48*2) bytes. So 1 RTP packet uses 96 bytes on the DSL line, as you already know we have 50 packets/s so that's 50 packets/s*2 cells=100 Cells/s 100 cells/s * 53 byte = 5300 bytes/s on the DSL line thats 42400 bits/s to transmit a 8 kbit/s stream :) So in order to use 5 simultaneous calls you would need a 1:1 DSL line of at least 5*42400=212000 bps so a 256/256 DSL would do, however if you need 20 calls that would be 20*42400=848000 bps so that would be a 1M/1M line (and some bandwidth to spare) Erik Versaevel hugolivude wrote:> Hi, > > 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: > 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. I plugged in 5 for the BHT (20 > customers, each getting 3 X 5 minute calls/hour = 5 Erlangs) and the > default 0.01 for the Blocking. It worked out to 264 kbps. Does this > sound reasonable? If so great! A business DSL could support this. > > Comments welcome! > > Cheers, > H > > > ------------------------------------------------------------------------ > > _______________________________________________ > --Bandwidth and Colocation provided by Easynews.com -- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-usersErik Versaevel
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.
>>>>> "h" == hugolivude <hugolivude@gmail.com> writes:h> I wasn't sure what "Packet Duration to select so I took the default h> 20ms (2 samples) - whatever that means. I plugged in 5 for the BHT h> (20 customers, each getting 3 X 5 minute calls/hour = 5 Erlangs) h> and the default 0.01 for the Blocking. It worked out to 264 kbps. h> Does this sound reasonable? If so great! A business DSL could h> support this. DSL has excessive overhead for small packets, due to ATM. No matter which codec you pick, you probably won't get below 2 ATM frames per voice packet. So for G.729 and 20ms frames, that means 50 packets/sec * 2 frames/packet * 48 bytes/frame * 8bits/byte 38.4kbps per voice call, per direction. A bit worse if you include the ATM overhead, then it's 50 * 2 * 53 * 8 = 42.4kbps. /Benny
J. Oquendo wrote:> Benny Amorsen wrote: >>>>>>> "rJ" == raphael Jacquot <sxpert@sxpert.org> writes: >>>>>>> >> >> rJ> ATM cell tax is actually 10% as there's 5 header bytes for each53>> rJ> bytes cell, >> >> For VoIP the cell tax is much larger. In the example, each RTP packet >> contains 20 useful bytes and 40 bytes IP overhead. 60 bytes doesn't >> fit in one cell, so you end up with 106 bytes at the ATM layer to >> transport 20 bytes of G.729. The ATM-caused overhead is thus 46 bytes >> per voice packet, thereby making the needed bandwidth 77% larger. >> >>> CRTP solves this issue (40byte waste)cRTP is a great idea that is not widely implimented. Not very many endpoint support it, and Asterisk currently does not. In version 1.4, Asterisk will support configurable RTP packetization. So you could use 40ms for your G729 payload and reach a 50/50 split between payload and overhead (before ATM encapsulation for DSL). At 50ms for g729, you get a nice fit into two ATM cells, while a small bump to 60ms will force you into three ATM cells. Of course you need to be mindful of the latency between endpoints when you start increasing the payload, but a healthy network and tuning the payload can greatly reduce bandwidth requirements. AND most endpoints do support configurable RTP packetization. If Asterisk and more endpoints supported cRTP, then combining that feature with larger RTP payloads would result in very low overhead numbers. Dan