No Jitter is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

SIP Decisions

Connecting to SIP trunks is more than a technology decision as I learned in the San Francisco Voicecon workshop, "Implementing SIP Trunking." Sorell Slaymaker divided the session into five parts. He opened with the most important question, "Is SIP trunking right for you?" His entire workshop presentation is on the Voicecon SFO site, Powerpoints and audio (available only to conference attendees with username and password).Of course there are the sales reasons for moving to SIP trunking:

* Lower your cost compared to T1/PRI trunks * Create a flexible service * Offer new services

We have heard these reasons from many sources. They are valid; however, SIP trunking is not quite plug and play. The number of trouble tickets will be much higher in the first year, maybe two, than the number of trouble tickets for T1/PRI trunks. Be ready to wait a while before your SIP trunking implementation becomes stable.

There are four SIP trunking categories that service providers offer. Each of these possibilities has its own requirements, limitations and conditions.

* Long distance connections, inter LATA and international calls * Toll free * Local with DID * Internet calls like Skype

Sorell raised many issues and offered many recommendations that should be followed. The one I found most important was the support by the provider of SIPconnect 1.1 that is a recommendation for the SIP trunking interface.

One area he covered was security. He recommends that the SIP trunk operate through a DMZ just the same as any Internet connection. This brought up the subject of Session Border Controllers (SBC). If you are not familiar with the SBC, you should learn more before embarking on SIP trunking.

The SBC is the alternative to a firewall that is better suited for this task. Here are the reasons for selecting the SBC:

* Provides the firewall rule set while also mapping layer 5 to layer 3 address. * Intrusion detection and prevention * DoS prevention * VPN separation for shard resources * SIP-TLS transmission * Secure RTP support * Possibly supporting IPsec Tunnels

The SBC can also be used for transcoding, i.e., conversion between different codec technologies.

He raised the issue of voice quality over the SIP trunk. The default codec today is ITU standard G.711. This works for non compressed speech. If compression is to be implemented to reduce bandwidth, then iLBC is recommended. It is the most robust. HD voice may be supported but only for Internet calls. These do not work over the PSTN. HD codecs have to be converted to G.711 for transmission over the PSTN. He warned that transcoding can add delay, so you need to measure this as well. Another area of concern with voice quality is the implementation and policing of QoS over the trunk.

Part 4 of his presentation raised a number of considerations that all who pursue SIP trunking should investigate. For example, if something fails, how is the customer alerted? Are the calls automatically re-routed? If not, how long does the re-routing take?

What if it is not an outright failure, but an intermittent condition? Are .WAV files exchanged in both directions to evaluate the problem? Is there SBC monitoring of the call admission control to ensure the trunk is not overloaded? Can the calls per second rate be controlled so that when service is restored there is not an instant overload as everyone tries to re-dial the lost calls?

The SBC will be the demarcation point between the customer and the service provider. Is the SBC the customer's or the provider's? Can the SBC help reduce the finger pointing to resolve the problem faster?

There was a discussion about having two trunks with load balancing. How is the load balancing performed? If there are two different SIP trunk providers, each with one trunk, how is the balancing performed? If there are DID numbers on one trunk, what happens to the DID numbers when that trunk fails?

So the SIP trunking implementation will mean learning about the SBC and determining what features, functions and survivability are desired. Finally, the customer must be prepared for initial problems and trouble tickets before the SIP trunking service is stable.