Sip In The Contact Center
“While SIP isn’t the only way to deliver functionality centers seek, it is a good way, and sometimes the ‘best’ way.”
Session Initiation Protocol (SIP) has been around for many years and has become the de facto answer for both network trunking and endpoints, or “phones.” Vendors, analysts and perhaps even your IT department may position SIP as a panacea for the contact center. But what is it really, and why should you care?
This article provides a guide for understanding SIP and its role in the center, with some input on where it fits and how to get it right.
What is SIP?
The “P” is for protocol, and that’s really all SIP is: a protocol standard for initiating and managing “sessions” or connections between point A and point B. Standards are attractive for the promise of interoperability, competition, lower prices, and common knowledge and understanding across vendors, developers and users—basically the antithesis of proprietary approaches. SIP is one of many standards that have been defined over the years, and is competing with or replacing predecessors such as H.323. SIP fits with “Voice over Internet Protocol” (VoIP), which is pretty much the way voice communications works today, regardless of vendor or solution (unless you have a really old system). In fact, you might find some people equate SIP to VoIP. But SIP isn’t just about voice it can manage sessions for a variety of media (e.g., voice, video, chat), supporting the “omnichannel” contact center.
SIP’s role is as simple as its name implies: It establishes and manages sessions. It generally doesn’t carry the “payload.” For voice communications, the system will use other protocols, like Real-time Transport Protocol (RTP). A SIP configuration typically involves a proxy server, registrar and/or SIP server that helps with the address resolution, determining where to actually point a given address. Endpoints such as phones register with the proxy server or registrar. A Session Border Controller (SBC) is often the termination for trunking and sits between the network and the IP-based PBX (phone system). The SBC can govern both the signaling (SIP) and the media stream (e.g., RTP). It can also provide security, acting as a firewall, and manage quality—two areas where SIP needs help outside the protocol. (See Figure 1.)
A protocol standard for establishing and managing connections between point A and B.
For user endpoints (SIP phones), for trunks that connect your center to the network, and therefore, customers (SIP trunks), and for core contact center technology systems that leverage the protocol (SIP-enabled systems).
Lower cost, greater agility/flexibility, more choice, good fit with today’s technology (e.g., cloud) and operations (e.g., remote agents).
Choose SIP phones that are compatible with your system; choose carriers that offer SIP trunking with good reliability, quality, security and service; size capacity appropriately; choose system providers that readily integrate and leverage SIP; work together with vendor partners to manage the network performance and cost.
Talk to your IT and vendors—both for your network and your core contact center technology.
SIP has contact center implications for desktops, trunking and integration, including between core components of a SIP- enabled system. Some vendors have their own version of SIP to address issues that we’ll talk about such as encryption and security, or offer greater functionality. In these cases, they are basically offering a proprietary protocol that is based on SIP but extends beyond it to do more. This may sound like the best of both worlds to some, but a failure to comply with standards to others.
Many phones are SIP-based, whether traditional “hard” phones with a handset users can pick up, or “soft” phones that are software-based and typically use a USB headset. A contact center technology solution provider may have their own SIP phones (true SIP or proprietary version), or you may be able to use a third-party product from companies like Polycom, Yealink, Panasonic, Audiocodes or Spectralink. When systems are truly SIPcompliant, buyers have choice and presumably find lower cost phones. However, don’t assume the promise of interoperability means any SIP phone works with any SIP-based system. You’ll want to select from approved options that have been interoperability tested, or take on that burden yourselves.
Solution vendors and carriers support SIP trunking. Some are even pushing only SIP at this point, clearly showing the migration from the traditional Public Switched Telephone Network (PSTN) is on. SIP trunking uses what we typically think of as data connections to carry voice and other media. It lets companies use their internet connections if they choose, or a dedicated connection if they prefer.
SIP’s Role in the Center
While SIP isn’t the only way to deliver functionality centers seek, it is a good way, and sometimes the “best” way. For voice, it can be the call control for all calls, including IVR interactions. Because it’s a multimedia protocol, it can also play a role in contact control and be part of the omnichannel vision. A session could be established for one media and cross to another, such as a chat session evolving into a phone call, or a phone call into a video call. A smartphone session could use SIP to click to dial from a mobile app. And unlike voice, SIP can actually carry the payload of text-based messages.
Computer Telephony Integration (CTI) has become more or less transparent; nobody buys CTI anymore. The functionality of call control and routing are distributed in SIPenabled applications, and SIP can be the source of information for screen pops (for example, the “address” in a SIP message can be used to look up the customer).
When you implement quality monitoring, you have a variety of integration points to choose from. SIP is increasingly the answer, whether line side or trunk side integration. A Session Border Controller (SBC) connects to the recording server, and a Session Recording Protocol (SIPREC) interface triggers capture of both the voice stream and the signaling messages from the SBC. Alternatively, the recording server can connect to the LAN/Ethernet switch on the network that the VoIP communication is traversing and capture the data via port spanning (basically replicating the voice packets).
Remote workers are yet another function that doesn’t require SIP but is increasingly implemented with SIP because it’s easy to deploy. Use SIP-based softphone over an internet connection and your remote agents can be set up quickly and operate from anywhere.
Perhaps the most visible role SIP is playing in the center today is on the trunking side. Many companies pilot SIP trunking, and then migrate to it. In fact, many companies have a mix of SIP and PSTN trunking today, with plans to continue their migration to SIP. IT/Telecom staff see the value in leveraging the internet connection(s) for centralized trunk aggregation. Voice and data can dynamically share capacity, and the capacity can flex to the business needs. Many mission-critical and/or large-scale operations will set this up with dual ISPs for additional resiliency and business continuity.
Where Does SIP Fit?
So with the strong market momentum, it may seem like SIP is for everybody. But that is not reason enough to make significant changes when budgets and resources are limited. So let’s look at what compels companies to migrate to SIP beyond “the vendor made me do it.”
The biggest advantage of SIP may be in the trunking flexibility and agility. It is relatively quick and easy to set up, and you can buy what you want or need, as opposed to the increments of 23 in traditional PRI trunking. You can adjust capacity quickly, even on the fly, as it is software-driven. Companies with seasonal or bursty traffic will find this very attractive, as they can procure based on lower volume off-peak and pay for bursts when needed. And you can reroute quickly, offering a degree of resiliency that many seek. If business continuity/disaster recovery is a driver, companies will set up alternative paths and build that resiliency into the network configuration.
WebRTC and SIP
WebRTC is another “standard” that supports endpoints for voice, video and chat communications. The goal of WebRTC is to support real-time communications from a web browser—without needing to install any type of client. The likely use case today is agent endpoints, but the potential is greater. For example, WebRTC could enable a customer browsing your website to seamlessly communicate with your center using a variety of media such as video, call and chat.
WebRTC is described as an “open framework” that is Application Programming Interface (API)-based. It is emerging for many vendors as the latest option for endpoints, although a limited set of browsers are compliant today (predominantly Chrome and Firefox). WebRTC typically leverages SIP (or another protocol) for session setup/teardown. Some vendors will have multiple agent client offerings—e.g., let you choose which client to use. Their “SIP” softphone client may be more mature and have extensions that support proprietary functionality. Consider tradeoffs of functionality vs. compatibility and fit for your scenario when choosing between WebRTC and other options.
Beyond agility, lower cost can drive the transition from traditional trunking (e.g., PRI), but each company needs to make its own comparison. You can find quotes of SIP being 50% lower cost than traditional trunking, and decreasing annually. (See Eastern Management Group research.) Some argue the cost benefits only come with compression of the voice, and if that is the case, you need to make sure quality isn’t compromised. In some cases, less hardware required, but look at the total cost of ownership for the configuration is important, as it’s not just about the trunks themselves, as SIP requires SBCs, proxy servers, etc. Some companies have network features such as percent allocation that may be replaced as a new network and configuration is put in place with SIP, so these costs should be considered as well.
For endpoints and architecture, the value is in choice and flexibility in endpoints, which in many cases can translate to lower costs. This doesn’t mean you would make a specific choice of “do I do SIP” here; it is inherently part of a solution architecture, and which phones the vendor uses will depend on what they sell and what they have tested. If the solution supports third-party SIP phones, you are more likely to have lower cost options (e.g., $50-150 SIP phones from Polycom, Panasonic, Yealink, etc.). SIP can also enable integration between dissimilar systems, including hybrid premise/cloud solutions.
How to Do SIP Right
While all this may sound attractive, nothing is perfect. Here are some risks to be aware of and mitigation methods to employ.
Interoperability is not guaranteed, and you can’t use any SIP appliance on any SIP-compatible system. You need to select tested and approved options or bear the risk of failure.
SIP is not inherently the “toll quality” voice that we experience on the traditional PSTN. Like all VoIP approaches, SIP is subject to performance issues on the network, such as latency/delay, jitter and packet loss. Voice is time sensitive and requires good, consistent performance. Compression can alter quality as well. So don’t undersize capacity or ignore Quality of Service (QoS). Size your network to meet the business demands, and configure your routers to prioritize voice traffic. If you compress voice, perform testing and ongoing monitoring.
SIP is also not inherently secure. SIP trunking is vulnerable to IP-based attacks, and SIP across the public internet is not encrypted. With the increasing number of attacks and individuals or organizations seeking to cause harm to systems and networks, attention to protecting networks is growing. Your IT and security team will need to work with the vendors (system and carrier) to define an approach to protecting your infrastructure. You have options to encrypt voice between networks (e.g., using Transport Layer Security—TLS) and within your domain (using SIP Secure—SIPS), or to use encryption tunneling, for example.
You need in-house expertise to support SIP, or you can procure managed services from a provider. Cross-trained support staff who understand converged voice/IP network and devices can leverage management tools beyond what was traditionally used for just data networks or just voice networks. Keep in mind that many cloud solution providers are also carriers. If your IT is interested in less responsibility, a provider that brings both the system and the network services may be appealing.
The good news is the value of SIP applies whether you have a premise-based solution or cloud solution. The bigger issues are whether the communication is over a public or private network. The public network heightens the security issues, whether premise or cloud. Recognize many vendors may suggest or even require SIP trunking, and they will dictate endpoint options, so work with them to understand and configure SIP to meet your specifications.
SIP will likely be a part of any solution in today’s market, and its momentum for trunking migration is strong. Understand your options and don’t take “standard protocol” the wrong way. Choose your carrier(s) carefully, seeking Tier 1 redundant network and Service Level Agreements (SLAs) that show a commitment to solid, reliable service. Use proven, tested solutions and vendors, and allow time for testing with endpoints and trunking. Make thoughtful decisions about configuration: size appropriately, prioritize voice, and put appropriate security in place for your configuration and business needs. Then manage SIP well, keeping an eye on security, capacity, routing, performance and costs.
Lori Bocklund is Founder and President of the independent consulting firm Strategic Contact.
Ken Barton is a Senior Consultant at the independent consulting firm Strategic Contact.
– Reprinted with permission from Contact Center Pipeline, http://www.contactcenterpipeline.com
You must be logged in to post a comment.