The approach we take is not to try and eliminate blocking in our calculations, but to split the bandwidth calculations into two discrete steps:
- Forget VoIP, and just estimate the number of lines required to carry the offered busy hour traffic within your blocking target
- Work out how much bandwidth each line required using your chosen voice compression algorithm, and multiply that by the number of lines estimated in step two.
The alternative would be to try and roll the calculations into one model or formula, which probably wouldn’t be accurate or appropriate for the following reasons:
- You would need some metric for quality of service (availability, delay, jitter etc.). These values are not easy to quantify.
- It would not model a ‘real-world’ implementation.
This is the method we published in our White Paper: Bandwidth Requirements for Voice over IP Transmission, and which Cisco advocate in their guide: Planning the IP Telephony Network.
I’ll expand on the second point:
In reality, Voice over IP implementations would use some form of Access Control, such as that implemented by an H.323 Gatekeeper. The gatekeeper is responsible for a number of clients within its zone. It doesn’t route calls, but it’s permission is required before a call can be set up.
Typically, the Gatekeeper would make its judgement on whether to allow a call to be set up based on the bandwidth limitations within and outside its zone. It would prevent calls from being set up if it considered that the calls quality would be below a required standard. Instead if saying it would ‘prevent’ a call, I could have said it would ‘block’ a call.
See what I’m getting at? Blocking would exist in the VoIP network, because the gatekeeper would only allow a certain percentage of calls through. If you only accept that 1% of calls are to be blocked, then you have pretty much arrived at the traditional Erlang B calculation method!
We have nearly finished developing our new product VoIP Select. It will be launched in March 2000, and will support the two step calculation I have described. We are inviting visitors to register their interest in the product now, for a 36% discount when it is launched by clicking here.
Lastly, you’ll probably have worked out by now that there is nothing wrong in using the Poisson model. It is a little dated though, and I would suggest you consider using Extended Erlang B instead.