Avoiding SIP Pitfalls

by Andrew Prokop | Arrow Systems Integration

Let’s face it. Even with careful planning and meticulous follow-through, things go wrong. The more time you spend upfront designing a solution, the less time you will spend fixing problems, but unfortunately Murphy’s Law tends to prove itself over and over again. However, understanding exactly what might go wrong will help you mitigate the time spent finding and fixing issues that arise during after deployment.

The following is a list of the most common problems that you might encounter 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 the SIP messages are used to create a particular service. For instance, Microsoft might implement call transfer with the same SIP messages as Cisco, but order might be slightly different.

For a deeper dive, please see my article on SIP Adaptation.


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 10 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 the Session Manager. This greatly reduces the complexity of dial-plan changes, bandwidth changes, or any other change that might occur and any of the other nodes.


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 expects 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.

The world keeps turning

SIP has been around for a little 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 every 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 to ensure that at best they work together or at a minimum they understand any connections issues that might exist. By buying products that comply to 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. Otherwise, you might find yourself in a war of finger pointing with no way to show where the problem is and the problem isn’t.

Wrapping up

Don’t let this scare you off 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 might go wrong. Murphy may never be your friend, but as the old saying goes, “Keep your friends close and your enemies closer.”

Share this article

The thoughts and opinions in these blogs belong to the individual blogger and do not necessarily represent the views or opinions of Arrow Systems Integration.