Centralized installations

With the local PBX setup, which is a centralized installation, unless you have major problems with your LAN there should be no issue with communication between endpoints, such as handsets, and the PBX. If you find that handsets are losing connectivity, then you need to start investigating why this is the case before you proceed any further with implementing or enhancing the system. Otherwise inefficiency of the network is going to cause you a multitude of issues further down the line.

Distributed solutions

We're assuming here that you're going to be running an Asterisk installation at some central site and servicing the remote phone's requests. This may be a billable service you are supplying or a centralized system at your customer's premises that is servicing multiple locations.

With such a setup, a major concern is bandwidth, particularly if you have quite a large number of extensions on a site with no PBX. The reason for this is simple, each call in a hosted environment, whether internal or external, will be required to traverse the WAN to the central PBX. Indeed, internal calls in a remote office are a double whammy, as they are routed via the WAN to the PBX, and then routed back to the same office! As a rule of thumb, it is worth seriously considering moving away from a hosted setup if an office contains more than 50 or so extensions. Although this can come down significantly if available bandwidth is quite limited or internal calls are higher than one would normally expect for an office of that size. The good news is that, for a smaller office, the hardware specification required to run an Asterisk server capable of handling the lower call volumes is modest indeed.

Latency and jitter

With any telephony system, bandwidth will determine the maximum number of concurrent internal and external calls that can be made. However, bandwidth is far from being the only consideration, irrespective of whether your installation is centralized or distributed. The latency characteristics of the circuits, LAN, and WAN, will dictate how well those calls get carried, and how the quality of those calls is perceived.

There are many factors that can influence latency including processor speed, available memory, disk spindle speed, and so on. However, in virtually all hosted installations communication circuits is the defining factor. When there is a limited amount of latency that a commercial system can bear, choosing the most appropriate circuit provider is vital. In fact, choosing a circuit with low latency is arguably even more important than reliability, as it is easier to introduce redundancy to communications circuits based on availability (if circuit A is down switch to circuit B) than it is based on latency (if circuit A is showing high latency switch to circuit B).

Asterisk as a PBX also copes much better than phones with high latency, and has mechanisms to help, such as the qualify= and qualifysmoothing= entries in sip.conf and iax.conf, which ensure that endpoints are pinged by the server periodically to check that they are still available.

As a result of these measures you should only have audio delay and/or echo to worry about, and the latency mentioned above will be the likely cause of that.

exten => *77,1,Echo()

It is also worth mentioning jitter in relation to circuit quality. Whereas latency is the delay between a message being sent from one side of a circuit and received at the other, jitter refers to how consistent this delay is.

So while you can measure latency in terms of a single packet traversing a circuit, you need to measure jitter over time, to see just how consistent that delay is. A low-jitter circuit will tend to deliver packets in pretty much the same order they are transmitted. If jitter is high then packets will start to arrive out of order, with the result that the audio will start to distort.

To illustrate latency and jitter, have a look at the sample graph that follows:

As you can see, the latency over time is consistently between 15 and 25 ms, which for a WAN is not at all excessive. However, it is far from being a smooth graph, and in real life such "jitter" on a circuit would result in a significant deterioration in the quality of the transmitted audio as many packets would be delivered out of order to the endpoint.

Bearing latency and jitter across a WAN in mind, many companies choose to forego the opportunity to save a few pennies by ignoring domestic-grade circuit options (predominately Asymmetric Digital Subscriber Line [ADSL]). The major commercial circuit providers in the UK, such as BT, Tiscali, and the likes are capable of providing circuit SLAs that not just guarantee a certain level of availability but also provide guarantees about latency. As always, it is worth doing your homework before committing to a choice that can make such a huge difference to end-user perception of the system.

exten => *78,1,MilliWatt()

Unfortunately, in any call that terminates outside your company, you only have control over part of the picture. Once the call traffic leaves your system you are at the mercy of the Internet, and the other party's system. If they are still stuck in traditional analog telephony land, then latency and jitter at their end is likely to be low and any problems are probably yours. If they are enlightened VoIP users, then excessive latency or jitter may be down to their LAN/WAN, the Internet, or your LAN/WAN. So you need to make sure your house is in order before you start pointing fingers. However, if you have set up your system with low latency and jitter as a priority, and you run regular checks to make sure that those latency targets are being met, then you should be able to sleep easily. Indeed, having carried out the necessary investigations, research and tuning to ensure yours is a low-latency, low-jitter Asterisk installation, this could be an opportunity for you to share your knowledge, for an appropriate fee of course!

So how do you identify and address these issues? On an Asterisk server, you can get a good idea of the latency between hosts and peers by running the cli commands iax2 show peers—or sip show peers as long as you have qualify=yes in the peer profile. On the PBX CLI type:

 iax2 show peers Name/Username Host Mask Port Status IAXTrunk1 217.14.138.130 (S) 255.255.255.255 4569 Unmonitored 201 192.168.10.201 (D) 255.255.255.255 4569 OK (4 ms) IAXTrunk2 (Unspecified) (S) 0.0.0.0 4569 Unmonitored 3 iax2 peers [1 online, 0 offline, 2 unmonitored]

iax2 show peers (above) lists a number of iax2 trunks (status Unmonitored) and an iax2 extension. The extension is showing a delay of 4 ms, which is indicative of an extension on the local LAN (which this is). On the PBX CLI type:

 sip show peers Name/username Host Dyn Nat ACL Port Status SIPTrunk1 217.10.79.23 N 5060 OK (79 ms) SIPTrunk1 217.10.79.23 5060 OK (79 ms) 251/251 192.168.10.201 D N 5060 OK (54 ms)

sip show peers (shown above) also shows registrations of both trunks and extensions. In this case, we can see that the local extension 251 is showing a delay of 54 ms, which is high for a device on the same LAN and should be investigated.

If all devices on the network support ICMP, and I would certainly recommend that you allow ICMP internally, then ping can also be used on the server to verify this information. If the ping delay is similar to the delay shown in the commands above, then you have a latency issue on your LAN/WAN. If the ping command is much lower, then the problem is likely to be with the device itself.

Tracking the cause of latency issues, particularly in a distributed environment, can be greatly assisted by the use of the tracert and tracepath commands. If a packet has to pass through a number of routers and switches to get from server to device, these commands will give you an indication of how long each step takes. It can even reveal that unexpected routes are being traversed. The commands are virtually synonymous, so use whichever you prefer.

Jitterbuffer

If you wish to look at the latency and jitter information for an active IAX2 (Inter-Asterisk Exchange) call then you can use the iax2 show netstats command, which shows the latency, jitter, and lost packets for all active IAX2 calls. This command assumes that you have enabled the Asterisk jitterbuffer on the IAX2 channel. The jitterbuffer is a mechanism for dealing with excessive jitter on a channel. Up to version 1.4 of Asterisk, the jitterbuffer only worked on IAX2 and ZAP channels, but from 1.4 onwards, it will also work with RTP channels such as SIP and H.323. The jitterbuffer works by buffering incoming packets, examining their timestamps and, where possible, re-ordering them so that they are delivered to the endpoint in the right sequence.

To enable the Asterisk jitterbuffer for a SIP channel, for example, you should add the following lines to the [General] section of your sip.conf file:

jbenable = yes|no (Enables the use of a jitterbuffer on the receiving side of a SIP channel.)
jbforce = yes|no (Forces the use of a jitterbuffer on the receive side of a SIP channel. Defaults to "no".)
jbmaxsize = Number (Max length of the jitterbuffer in milliseconds.)
jbresyncthreshold = Number (Jump in the frame timestamps over which 
the jitterbuffer is resynchronized. Useful to improve the quality of 
the voice, with big jumps in/broken timestamps, usually sent from 
exotic devices and programs. Defaults to 1000.)
jbimpl = fixed|adaptive (Jitterbuffer implementation, used on the 
receiving side of a SIP channel. Two implementations are 
currently available - "fixed" (with size always equals to jbmaxsize) and 
"adaptive" (with variable size, actually the new jb of IAX2). Defaults 
to fixed.)
jblog = no|yes (Enables jitterbuffer frame logging. Defaults to "no".)

Care should be taken in using jbforce, as it will introduce a delay for all inbound traffic, whether it has excessive jitter or not. Indeed, for this reason, you should only consider the use of a jitterbuffer at all if you are finding that jitter is adversely affecting the quality of a significant percentage of calls. If your circuit latency is marginal, then adding a jitterbuffer into the mix could introduce enough latency to make echo detectable on calls.

Echo

These commands should provide you with enough information in most cases to at least give you a head start on the likely causes of any latency issues. Thereafter you can use commands such as sip set debug or iax2 set debug to gather more detailed information on the fly which can then be examined in the log.

So what level of latency in a system can be deemed to be acceptable? It's well documented that the human ear can detect delays in audio above 300 ms, so if there is latency greater than 300 ms, the user will hear an audible delay or even an echo. Why? Back in days of yore, telephone engineers found that they needed to feed what you were saying back into the ear piece, a feature known as sidetone. If they didn't, then the user would think they'd been disconnected. Of course, traditional PSTN systems, with their inherent low latency, only had an issue when large distances were involved. In other words, national calls tended to be fine, but international and intercontinental calls suffered to a greater or lesser degree from echo as well as significant delay between the transmission and reception of the voice signal. Bad echo makes it very difficult to concentrate on a conversation.

Another downside of high latency is that not all IP phones cope well with it, although some do better than others. For example, experience has shown Linksys phones to be good in distributed installations. Others will fail to register overtime and therefore go off-line. This isn't always immediately obvious, either leading to the potential for important calls to go straight to voicemail, or even be lost altogether.