Hacker News Reader

Comment by Ekaros | Hacker News Reader

I think issue with SIP is that it is and was driven by the industry. And I wouldn't call it exactly simple or easy protocol to follow and implemented. Thus many alternatives or self-made solutions are more likely to be chosen. It does a lot, but at the same time it is increasingly complex protocol. At least compared to others.

View on HN

To me the fundamental issue with SIP is the recognition by vendors that a standard protocol is "here" while still being incentivized (of course) to implement vendor lock-in. It was also clear that SIP for trunking (with very basic call setup/teardown) was the path forward to replace PRI, POTS, etc.

Consider government, large corp, etc purchase requirements. "Oh SIP is the standard. Cisco do you support SIP?" Cisco says "Of course!". Check the box and buy.

Meanwhile at the time their ecosystem is 99% Skinny (their proprietary protocol) and SIP is an afterthought for anything other than extremely basic call functionality, trunking, etc. Even when pushed to release SIP firmware for their (at the time) $500 hardware phones the SIP firmware was so feature crippled you're literally throwing money away by using it.

So everyone installs Call Manager to be done with it and have something that actually works. Even when Cisco got around to essentially being SIP native getting 30 year old features like hold, transfer, busy lamp fields, provisioning, etc working between vendors was nearly impossible.

Repeat for just about every implementation in existence.

I do believe that Cisco SIP implementation in 7000 series phones is non-interoperable by design. One major issue is that they are sending SIP messages from different port than the port they are receiving on. Because of this they practically do not work with any kind of NAT and I haven't heard of any consumer service provider that would work with this (the standard behavior is to assume that port passed in Contact line might be incorrect). Some of phones from that line have "NAT" true/false setting, but some don't - when tracing changelog I saw that this setting was removed in later firmware version, but for many phones this earlier firmware version was never available.

Why is industry-driven an issue? And compared to what others? On the contrary, SIP is as readable and understandable as HTTP. Someone who understands HTTP can learn SIP-based VoIP quite easily using their software/web background without needing a telecoms background.

To the extent SIP was industry driven, it was due to the fuzzy standards themselves which left a lot of room for vendor specific handling especially used to max out their own device to device performance often supported by proprietary enhancements. The biggest trade show was called Interop for a reason. At this point SIP might have served its purpose, but the basic approach of separating a control signaling plane from media paths has stood the test of time.

Reply on news.ycombinator.com