SIP – The Challenge Of Voice Delay
One of the major recurring challenges with IP deployments is that of voice delay, or audio latency, i.e. a substantial delay between a word being spoken and the word being heard at the far end. Excessive delay can seriously hamper attempts at fruitful conversation, and is a potential problem with any calls that travel fully or partially over SIP networks.
Let’s take a look at what causes delay in these calls and what can be done to minimise it.
Ideally, voice audio would travel from A to B in a single, unbroken line – rather like driving from New York to Miami; you hop on the I95 and keep going. The reality is that the journey of a call can often be broken into many portions, or legs, as data is routed over organisational networks and often several different carriers, and converted from SIP to TDM and back again (perhaps several times). Despite the appearance of simplicity from major carriers, the fact is that they often sub-contract portions of the call route to other carriers, in order to reduce costs – perhaps they have reciprocal arrangements, perhaps they are simply employing least cost routing, perhaps they have a bulk deal. As a result, a call may travel via many separate carriers to get from A to B.
The trouble is that at each point where the call has to cross between 2 networks, whether SIP/SIP or SIP/TDM, the data will be held up. It’s rather like driving NY to FL but having to stop at each state border to change your shoes.
There are 2 main reasons for this delay:
- Any media streaming over IP is broken up into chunks, or packets. Jitter (or packet delay variation) can occur because packet travel is by no means consistent. Packets may travel at slightly different speeds (like overtaking on the I95), so that they arrive in the wrong order; they could arrive in the correct order but with erratic timing; or some could be entirely missing. In order to cope with this uncertainty, every node along the way will very likely make use of a jitter buffer. A jitter buffer’s job is to maintain the best possible voice quality, no matter how the packets arrived, passing them on in the correct order or synthesising/ substituting if they are missing. And this means holding packets in a queue until the buffer can be sure that the data can be passed correctly.
- Each SIP leg of the journey can potentially use a different signalling protocol – e.g. G.711 (uncompressed), G.729 (compressed) and others. If this is the case, then at the border, packets must be decoded from the 1st and recoded to the 2nd protocol. Every time this happens, a delay is introduced.
We can see that the more borders there area on the journey, the more delay is introduced.
If you think you have a delay problem (or if your agents have complained about it!), then it’s time to measure the problem and set about rectifying it.
Measure the problem
You can quantify the delay from one end of the call to the other quite precisely. We have often done this by recording both ends of the conversation and then comparing them. This gives a precise offset between the point at which a word was spoken and the point at which it was heard.
Fix the problem
- Talk to your carrier. Ask if they can do anything to minimise the number of borders for your calls. If the answer is ‘No’, then it may be time to consider switching to a different carrier
- Certify your originating SIP stack with your carrier. By eliminating the need for routers and session border controllers, several borders within your own infrastructure can often be removed
- Inspect session border policies to see if any differences in protocol can be removed
As SIP communication matures, we expect to see a rise in carrier-to-carrier arrangements and certification, so that delays at the border are minimised or even eliminated. It would be great to get from New York to Florida with just a couple of changes of footwear!
This is a complex area. Make sure you are working with a technology provider who can help you with navigation.
