The SIP in SIP trunking stands for Session Initiation Protocol, and it’s used to create and control real-time media communications sessions like phone calls, IMs, and video chats. It’s a protocol standard that defines how messages are sent back and forth between the endpoints involved to set up, manage, and take down the connection. When it comes to SIP-based systems and devices, if the standards aren’t followed to a tee in every component, calling features are lost, calls are dropped, and the only thing you have left to communicate is your mind-bending frustration.
The path to failure
The current standard for SIP is RFC 3261 as established by The Internet Engineering Task Force (IETF®). An RFC (Request For Comments) document is a set of guidelines for best practices when working within the RFC’s subject matter, in this case, SIP.
In that sense, SIP is not an end to end system, it’s a set of rules for establishing communications. SIP works by delivering session descriptions between participants (phones, PBXs, service providers,…) that authenticate and authorize users for services, implement provider call-routing policies, and explain how call info should be sent and received. For more on that, read this.
SIP follows a request/response transaction model. Each transaction consists of a request that, based on the guidelines laid out in the RFC, align with a function of call management, and as such, they expect a certain kind of response. If one end isn’t following the expected protocol, you can end up with problems in the connection like bad or one-way call audio, dropped calls, or calls that never connect at all.
What can go wrong
Many of the larger providers have integrated SIP into legacy infrastructure over the course of multiple upgrades, acquisitions, and patches. As a result, they are often not RFC compliant because they’ve needed to make allowances for their existing systems.
One provider we’ve seen only accepts five entries in the connection codec line of the INVITE packet. It’s not malicious, they’re trying to be efficient and enforce a standard of interoperability. But, the way many SIP-based endpoints communicate is to offer to communicate with just about every codec. There could be 12 codecs listed as acceptable, and a lot of times the last codec on the list is DTMF (which is responsible for touch tone capabilities) so it would get dropped with this particular provider. Than means, if you’re calling into an IVR system and DTMF isn’t included on the list of accepted codecs, you’re unable to navigate through the menu because your tones aren’t passed.
What you can do
Pay attention. When you’re installing new equipment, infrastructure, or on-boarding a new service provider into your SIP trunking system, check for RFC 3261 compliance. If you’re building a system, build it to the most current specifications [http://www.ietf.org/rfc/rfc3261.txt]. SIP RFC lays out the fundamental building blocks for how your communications connect and the functions that are available when they do. Without the proper foundation, your communications will crumble into a bad dream.
