Last week was a teaching week for me. Although I enjoy playing the role of professor in my SIP class, I am happy that it’s only an occasional thing. No matter how much I love the subject matter, it’s tiring talking for hours on end. Thankfully, my lectures appear to sink in and my students leave knowing a whole lot more about SIP than what they knew at the beginning of class.
I also learn from these classes. All my students have been in communications for many years and each one comes with unique experiences and perspectives. Some of those experiences have been good while others have been horror stories. Good or bad, they are all learning tools. In fact, I often learn more from the things that go bad than those that are quick and easy successes.
This led me to consider some of the SIP issues I’ve encountered over the years. While most implementations have gone smoothly, a few were a bit troublesome.
In no particular order, here is a list of the most common problems that you might encounter during and after a SIP roll-out.
SIP isn’t necessarily SIP
SIP is a standard that is managed and enhanced by the Internet Engineering Taskforce (IETF), but like many standards, people have taken liberties with how they’ve chosen to implement SIP. Sometimes it’s a difference in how a header is used or if it’s even used at all. Sometimes it’s how SIP messages are strung together to create a particular service. For instance, Microsoft might implement call transfer with the same SIP messages as Cisco, but the order of those messages might be slightly different.
For a deeper dive into this, please see my article on SIP Adaptation.
Spaghetti
More SIP entities means more connections which means more places for problems to occur. In a full-mesh or point-to-point configuration, five different SIP systems would require ten connections. Increase the number of SIP entities to ten and you now have 45 different connections to manage. The formula to calculate the number of connections is n (n-1) / 2 where n is the number of SIP entities. I’ve dealt with enterprises with at least 100 different sites and the math tells me that a full-mesh SIP configuration would require the creation and management of 4950 connections. Clearly, you can see how quickly things can get out of hand.
The solution is to not create all these point-to-point connections, but to implement Session Management. With Session Management, all SIP entities, or nodes, would connect to a Session Manager. That Session Manager would then create separate connections to all the other nodes. In this “hub and spoke” approach, each node need only concern itself with a single connection to Session Manager. This greatly reduces the complexity of dial-plan changes, bandwidth changes, or any other changes that might occur with the separate nodes.
For more information, please see my article, Session Management.
Misconfigurations
It doesn’t matter how much money you spend on your SIP solution if you don’t configure it properly. In fact, most of the problems I have encountered over the years have been the result of a configuration mismatch. One side sends SIP over TCP/IP and the other is looking for SIP over UDP/IP. Or perhaps you have a Cisco system talking to an Avaya system, but the adaptation module in the middle is for Siemens.
It’s important that you pay close attention to these points of interaction and configure your system properly.
The world keeps turning
SIP has been around for more than 10 years, but the SIP standard is far from solidified. Enhancements are constantly being made. Old ways of doing something make way for a better approach. To help alleviate problems from this ever changing world, SIP Connect was established. Think of SIP Connect as an organization that promotes bake-offs between the different SIP vendors. The producers of SIP products gather on a regular basis to test their wares against each other and to ensure that they all speak the same language. By buying products that comply with SIP Connect 1.1, your enterprise is assured that those products have been tested against one another and any interoperability issues have been clearly documented.
Who broke it?
Unless you have a SIP solution that is completely closed off from the rest of the world, there will be demarcation points where you lose control over what happens next. For example, your Avaya system might use Verizon for SIP trunks. You can trace a SIP call as far as your Sonus SBC, but after that you have to rely on Verizon to do its job. Now, not to pick on Verizon, but you might do everything right when you send a call to them, but because of problems in their network, that call can be dropped or voice quality might degrade substantially. You can’t fix the problems on the Verizon side, but you can install and utilize tools that can establish that you are not the problem child. Don’t allow yourself to get into a finger pointing war with no way of showing where the problem is or the problem isn’t.
Wrapping up
Don’t let this scare you away from SIP. Every problem has an answer and knowing what the potential problems might be is a huge leg-up. Again, careful planning is important, but so is understanding what could go wrong. Murphy may never be your friend, but as the old saying goes, “Keep your friends close and your enemies closer.”
Tao, Zen, and Tomorrow 
Thanks for all the useful information Andrew. What course(s) do you teach and where? Thank you.
You’re welcome. Thank you for reading. I teach a class through my company — Arrow S3. I teach it in person in Bloomington, Minnesota, and occasionally take it on the road.
[…] The issue with SIP is best explained by Andrew Prokop in his article, Getting SIP Right the First Time Around: […]