Voicespan

This is the first of a series of tips taken from the recent Packt publication Asterisk 1.4 – The Professional’s Guide, of which I am a co-author. I hope you enjoy it and find it useful.

Asterisk is a very capable telephone system, that’s a pretty uncontroversial point of view. It’s also pretty safe to say that Asterisk-based systems in active, commercial use are concentrated mainly in the SME sector rather than in large enterprises. This is not to say that Asterisk does not scale to large deployments – it does. Indeed there are university campuses and other large, Asterisk-based systems in active use. However, in the corporate world, factors other than price and functionality become more important when making the purchasing decision – reputation is one that springs to mind. Although whether or not that should be the case is another matter, and another blog post for the future.

Back to Asterisk deployments. One of the great benefits of Asterisk is that it conforms to internationally agreed standards. If you like SIP, then Asterisk fits very comfortably into that world straight out of the box. If you use other standards then they can almost certainly be accomodated too, with the minimum of fuss. SIP is probably the most common protocol for Asterisk systems though, if for no other reason than there are a plethora of SIP endpoints out there for you to choose from.

Sticking tens of SIP endpoints on your network should be a painless exercise. If you’ve planned your network properly then 100 Mb/s is more than adequate to carry the resulting VoIP traffic. But if you start talking about hundreds of endpoints instead of tens, whilst remaining with a single Asterisk PBX, then you may find that on a regular basis your network is briefly flooded with traffic (a ‘packet storm’). You may also discover that some endpoints are disconnecting from time to time. Why is this happening? You have enough bandwidth, but still you have problems.

The clue is in the fact that some endpoints lose connectivity. Any endpoint on the network needs to let the Asterisk PBX know that it’s still there every so often. Otherwise a device could do an initial register, and then fail without the PBX being aware it has done so. Asterisk avoids this by use of the command

qualify=yes

in either sip.conf or iax.conf. Using this command promts the server to query the status of every appropriate device (i.e. all SIP registrations if specified in sip.conf) on a regular basis. The only problem is, if you have a large Asterisk PBX with a large number of SIP endpoints, then the network traffic generated each time the devices are queried is significant. In extreme cases it can, as already intimated, cause all other traffic to be delayed resulting in devices de-registering or even in latency for voice traffic.

So what is the solution? Well, a couple of obvious suggestions can be discarded straight away. You should not use QoS to reduce the priority of this traffic, as that will only exacerbate the delay and cause more devices to de-register. Neither should you increase the time between polls of the devices, as some may time-out and de-register, and you will still generate a packet storm when you do the poll.

There are a couple of things you can do, however. The first is pretty drastic, namely to introduce more Asterisk servers into the mix so that the number of endpoints per server is reduced. However, this move can be justified as part of a project to improve resilience too. The other, preferred, solution is to utilise a feature that many endpoints have, namely to initiate a poll of the server from their end. This will almost certainly (unless you are hugely unlucky) result in the polling of the server being spread pretty evenly over a time span.

Now I’m sure you’ll want to know how many endpoints can register with a server before this starts to become an issue. I’m afraid there is no accurate answer to this are there are so many variables – the PBX performance, the tolerance of the endpoint to slow polling, the existing network traffic, the available bandwidth, the route between endpoint and PBX, etc., etc. However, it’s safe to say that you should be keeping an eye out for occasional de-registrations around your network at all times, and have this scenario in mind when investigating it.