Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In a call centre environment, what bandwidth would be required for 55 lines? This would be on SIP protocol, would we be best to use G729 codec as i know that our sip provider supports this? What type of internet connection would be best for such a task? Would SDSL 1:1 be sufficient (im in the UK)?

Hoping someone with experience in the field can give me some tips...

share|improve this question
up vote 9 down vote accepted

A good rule of thumb comes from old telephony .. an phone T1 line 24 voice channels and a control channel. This equates to roughly 64Kb/s per phone line. This rule works (roughly) for uncompressed VoIP. There are various codecs that do compression .. the G729 should roughly triple that, so get 72 voice channels on a T1.

If you expect all 55 phones to be on external calls at the same time, you will utilize roughly 75% of a T1. That is pushing the realistic limits. A single T1 will be fine if you expect less than 80% or so phone utilization. Generally speaking, as you push the bandwidth limits you will see degraded quality before you see calls fail, so a T1 should be OK for the occasional peak to 100%.

IMHO the kind of connection matters little, as long as you get low latency between between the phone and the "switch" (aka the VoIP server).

Were I in your shoes I would get a T1 and watch the performance, call quality, the number of phones, and the average phone utilization. I would also be careful about compression .. it can really do a number on call quality, particularly when combined with tight bandwidth.

Also, if you are going to put phones and PCs on the same network, make sure you get QoS running properly on the internal switches and the internet router. It would suck to have enough bandwidth but have poor call quality because of the call center reps watching videos on YouTube or opening files on the server. If you don't know how to deal with QoS, either get someone who does, or put the phones and computers on separate networks and use separate internet connections.

share|improve this answer
Thats a great help, thank you very much tomjedrz for the great answer. – Gary B2312321321 Nov 18 '09 at 18:42
T1's don't exist in the UK and their UK equivalents are out of date and thus hard to find and expensive for what you get. He's far better of with dedicated ethernet. – Chopper3 Nov 18 '09 at 23:48
Nearest equivalent still in common use here in the UK is the humble ISDN 2e; expensive and a stupid decision to make these days unless you want a point-to-point failover. Businesses with big cash to spend either provision 8 Mbit SDSL or just use bonded DSL / EFM / FTTC/FTTP with guaranteed bidirectional QoS and Assured Rate. You're looking for the lowest RTT for packets, and a nice stable, non-packetlossy connection. If you get ADSL2+, ensure you can disable interleaving (fastpath). Every few miliseconds makes a difference. On a SoHo ADSL2+ line at work, I've got total audio delay to 40 ms! :> – Christopher Woods Feb 17 '13 at 5:31
Personally I use G.711 a-law as G.729 has minimal bandwidth savings, has a noticeable codec lag and sounds crap. 711 beats analogue POTS quality in more than a few cases. Choose the specific 711 codec based on the gear you're connecting to (depending on its design it may have slightly less encode/decode delay with µ-law). If you need to share voice & data on one LAN, FOR THE LOVE OF GOD - QoS AND VLAN THEM. Make all data types suffer in favour of SIP, RTP and UDP traffic. Voice traffic is incredibly time sensitive and your call quality MOS will quickly suffer before you fully block the tubes. – Christopher Woods Feb 17 '13 at 5:32

The best place to start would be with the voip equipment vendors documentation. Barring that, there are several web based calculators. Here are a few to start you off with:

share|improve this answer

I'm no expert at SIP, but here is what I've found out earlier:

Number of connections * bandwith (kbit/s) per connection = bandwith for SIP

You'd also want to reserve some data for other traffic - say 20% extra.

And - for the love of every person who's going to make calls - Use QoS agressively if you're using the link for anything other than SIP. This also applies to your internal routers/switches that the VoIP traffic runs through.

share|improve this answer

If this system is an important part of your business and you need high up-time I'd strongly advise against SDSL, it just can deliver the quality you'd need, it's just not designed for that. I was called in to sort a very similar problem with a 100-user call centre a few years ago just outside London, we moved them to a pair of 10Mbps BTnet leased ethernet lines and the problems literally disappeared overnight.

share|improve this answer

We are looking at VoIP right now, and our vendor said that each active SIP channel would use 64kbps. For 55 active calls, you would need about 3.5mbps sustained bandwidth. In our case, we'll never have more than a couple calls running simultaneously, so 200 kbps would be plenty.

share|improve this answer
64k works for uncompressed. The codec he cites will compress (in theory) by a factor of 8, but realistically it works out to be about a factor of 3. – tomjedrz Nov 18 '09 at 0:01

As noted by joeqwerty, you should check actual bandwidth consumption using some available calculator like the one hosted at

As a rule of thumb, we usualy reserve 35kbps symmetrical for each active g729 call, so 55 simultaneusly used lines would requiere 2 Mbps just for VoIP. If the link will also be used with some other app, QoS and traffic policing is a must.

Also, with VoIP, jitter and latency is as important as bandwidth, so you should go with a good quality link.

For 55 g729 calls, you will use a lot of CPU for compression. Don't discard using some hardware assisted coding, Digium has a card just for that. You will spend on the card but save on the codec.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.