5 ms·
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 ve
by kkielhofner 4y ago
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.
- TMSZ 4y agoI 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.