Warakorn - Fotolia
Editor's note: To receive a copy of Sturt's SIP provider selection MindMap -- which gives an overview of the key considerations, risks and opportunities -- click here.
Session Initiation Protocol may have become the next big thing for unified communications, but how do you ensure your requirements are met by prospective SIP provider companies?
At issue are the SIP capabilities an enterprise can reasonably expect from its wide area network (WAN) services provider. It's important for organizations to accurately define and communicate their requirements to prospective SIP providers. The outcome in these cases is much better than situations in which SIP services are procured on a commodity basis.
At the most basic level, IT managers need to make sure they have a good grasp on traffic volume, features, concurrent calls, expected quality, interoperability and future business strategy. Before assessing potential suppliers, organizations have to translate those metrics into a statement of requirements. Let's look at some of the fundamentals.
Access type. SIP is available across multiple mediums, including Multiprotocol Label Switching (MPLS), virtual private LAN service (VPLS) and Internet-based services. The decision about which type of connectivity is best suited to your organization will no doubt be governed by whether you prefer private- or public-based networking. MPLS and VPLS are both private WAN services and therefore do not carry the overhead of encryption. They also support application quality of service (QoS), which allows you to add strict priority queuing across the network. This means your SIP traffic will take priority, or as it's known in the trade, get expedited forwarding (EF). With EF, however, you must ensure there is enough bandwidth allocated to match the EF setting because packets will be dropped when the assigned bandwidth limit is met. This is standard EF practice; delay-sensitive traffic should always remain in the EF queue and should never be treated with anything but strict priority.
With this in mind, then, why would an organization consider the public Internet for its SIP services? There are a few options, among them:
- Using a single public IP backbone for SIP provider access
- Using the Internet to provide SIP access
Of the two, using a single public IP backbone, in which your Internet service provider provides both Internet access and SIP services, is the only option I'd recommend. In this approach, your traffic remains on a single provider backbone -- enabling you to predict performance. In contrast, accessing SIP through multiple providers creates an environment where performance can't be reliably predicted because traffic will hop between networks. In some scenarios -- for example, small offices or home users -- the use of multiple Internet providers is acceptable.
Concurrent call quantity and codec type. Calculating your concurrent calls is an important part of selecting a SIP provider because the number you determine translates into required bandwidth and SIP trunk costs. We have already mentioned QoS and the importance of calculating EF correctly. In this sense, the technical framework must consider call quantity, which in turn provides the basis of costs.
To that end, bandwidth will equal the number of calls you wish to maintain at any one time versus the codec. Everything else being equal, SIP call quality is the direct result of the codec used within the ISP's package of services. With bandwidth becoming more plentiful due to the prevalence of Ethernet connectivity, most organizations opt to use the G.711 codec, which essentially provides excellent call quality between sites. A few years back, the G.729 standard was leading the way. Voice quality wasn't as good, but the codec required much less bandwidth. The G.711 protocol requires approximately 100 Kbps per concurrent call; with 10 concurrent calls, an enterprise would need at least 1 Mbps of connectivity.
Data center interconnects. Perhaps the simplest way to tap into multiple SIP providers is to use interconnects within the data center. In one recent example, we deployed a BT-managed VPLS for one client. This required access to an existing SIP provider. 'To eliminate access we engineered a back-to-back interconnect within its data center. To centralize access, a back-to-back interconnect within its data center. This eliminated the need for QoS, since the connectivity between BT and the SIP provider was essentially a patch cable.
Interoperability. Once your organization has narrowed down the number of SIP providers to consult with, the next step is to make sure your hardware interoperates with the ISP's SIP platform. SIP platforms not only must support telephony but messaging, presence, video and collaboration as well. Ensuring there is interoperability between your hardware and the SIP provider is critical, especially if you are intent on deploying local hardware. The hardware you use, from PCs to desk phones, will need testing to determine whether any features or functionality are missing.
Cloud SIP providers. Mirroring the majority of IT, a cloud option exists for SIP services. Requirements and performance expectations are the same; latency, bandwidth and jitter will govern performance in much the same way they do with on-premises equipment. The key consideration is support and how proactive the cloud provider will be when it's troubleshooting issues and setting up new functionality and services.
Redesigning WAN for UC
Procuring your MPLS not for faint of heart