SIP Interoperability?

Sometimes, when I read datasheets that list what kind of RFC the SIP phone supports, I don’t know if I should laugh or cry. Interoperability has become a disaster in the SIP world. If you buy a cell phone, there is the “GSM” logo printed on it and you can be pretty sure that the core features just work. In SIP, that’s not the case and there is not even a logo. Naïve customers, big or small, but SIP devices and expect that they just work out of the box. Seems like ten years after SIP got the heads up, the SIP RFC is more like a place for fame (not fortune) for the authors instead of solving basic problems. There is an interesting site that lists the explosion of SIP standards, http://rfc3261.net/.

On the desktop phones, snom accumulated more than 700 settings that tell the phone all kinds of things, including parameters for the SIP stack. My most famous example is the “Refer-Brackets” setting, which tell the phone weather it should put those < and > brackets around the destination or not. Believe it or not, but in the year 2011 this setting is still in use. LMAO. How can you know when you want to register a phone to your server if you should turn the setting on or off??? Another funny setting is the “Broken Registrar”, which practically turns off any security check on the phone, so that anyone in the network can bomb the phone with UDP and make it ring.

In the m9, we tried another approach. Because the number of settings on the desktop phone is significantly bigger than the number of servers in the market, we decided to make settings called “server type” that handles all those tricky special cases. For example, if you are using snom ONE, just set the server type to “snom ONE” and then the interoperability should be working okay. This is not only a lot easier for the user; it is also a lot easier for the CPU. Having 700 settings does cost memory space, and having just one setting and some if-the-else checks in the code makes the code a lot more compact.

There are still some settings outside of the main server type setting. For example, there is still a settings “SRTP enabled” which kind of parameterizes the server behavior. There are other settings that just have no influence for certain server types (like “use ICE”), maybe one day we can add a JavaScript in the web page that just hides those settings when you select a certain server type. Anyway.

There are some attempts to get the situation with the SIP standard under control. Especially on the SIP trucking side (that’s where the money is!), there are some promising activities that try to standardize the way all those RFC should be used. For the snom m9, this means: As soon as those standards are clear, we will start adding those to the dropdown menu to make the users life easier and give SIP a better experience than trying hundreds of settings out!