4 ms·
[SIP author here, for better or worse] SIP's victory over H.323 was definitely an odd story. Henning Schulzrinne wrote a draft called SCIP, which was essentia
by mhandley 4y ago
[SIP author here, for better or worse] SIP's victory over H.323 was definitely an odd story. Henning Schulzrinne wrote a draft called SCIP, which was essentially HTTP for multimedia calling. SCIP overlapped with what Eve Schooler and I were already doing. We thought his version was too complicated (ha!), so I rushed out a draft based on what I had been coding in the MBone session directory sdr, which was a simpler UDP-based SIP. We presented them both at the same IETF meeting in 1997 where I was already standardizing SDP, and got general support from the room, but the main message we took home was there can be only one! So we met up at Columbia a month later and spent a day arguing out which features of the two protocols to keep. The resulting protocol is the basis of the SIP we know today.
By this time, H.323 was gaining lots of momentum and Microsoft and Intel had adopted it. What chance for a few academics against Microsoft and Intel? But I was chairing the MMUSIC WG in the IETF and, quite simply, no-one told us to stop. So with the hubris of youth, we just carried on anyway. Loads of people told us we couldn't possibly win, but H.323 was just too ugly and telco-like, and (in the early versions) took so many round trip times to do anything at all, that we really didn't like it.
Around this time it started to occur to some of the telcos that Internet traffic would before long exceed phone traffic, and it would then make no sense to run two networks. In particular Henry Sinnreich at Internet MCI started to look around for what they should do, and he thought SIP's proxy architecture would fit their needs better than H.323. As a result I went down to Dallas and gave a couple of days tutorial to all the Internet MCI folks about how we saw IP-based internet multimedia working out. After that, Internet MCI started to push SIP, and other telcos noticed. Increasingly it seemed our main allies were telcos. And so it turned out that in the early VoIP space, telcos held more sway than Microsoft and Intel. Eventually Microsoft moved to SIP too. The downside was that SIP rapidly accumulated lots of telco cruft, and the original peer-to-peer email-address-based nature of SIP wasn't what actually took off.
So, H.323 came from bell-heads, but got backed by net-heads. SIP came from a few net-head academics, but got backed by bell-heads. In the end, for better or worse, the latter won. Ever since an IETF meeting around 2000 where there was more than 100 SIP-based internet drafts, I've regarded SIP as being my success disaster. It's a huge success, but it could have been so much simpler and cleaner.
- Aloha 4y agoSIP has crept into so many spots - Need to connect two two-way radio systems? its SIP in a fancy dress. Need to connect a two-way to a console system? its SIP in a different colored fancy dress. NXDN is completely SIP internally, it's not standard SIP, but you can still construct a call ladder with conventional tools (or just read the captures), and have a rough idea of what it's doing, even if the headers are weird. P25, and DMR use SIP in various other places, either for logging, or for console connections. The workaround so you have Calling Party ID on radio systems is to imbed the metadata for a talkspurt inside the audio stream. The one gripe I have about SIP, is - I suspect mostly because (but not entirely) of the telco cruft, you can have two standards compliant SIP implementations that can't interop in a meaningful way. The lack of a required minimum codec support does add to those challenges, but I've seen SIP also fail to work even when both sides have the same codecs, but rather do not emit headers the other side expects. (For example when OPTIONS must occur before REGISTER) Gripes aside, I will take a SIP derived protocol any day over a binary protocol that needs some sort of magic decoder ring, I have to work with those, and I loathe them for obvious reasons. So thank you for the work you did to standardize something that has touched my daily working life for 15 years now.
- kjellsbells 4y ago> you can have two standards compliant SIP implementations that can't interop I spent years in telco. You would not believe how painful getting telco A to talk to telco B was, despite it all being SIP. There was a bazillion-dollar market for session border controllers that did nothing but protocol fixup all day. Incredibly, one of the things that SBCs had to do was transcode audio in near-real-time between one telco and another. This was very technically demanding since end users don't like glitchy audio, but also, in some sense, totally a waste of everyone's time and expensive DSP resources, since the two endpoints spoke the same codec but had to cross internal networks that did not.
- Aloha 4y agoThat doesnt surprise me, there is a market at least for conversion between uLaw and aLaw - I've used Asterisk (as well as some other boxes from AudioCodes and another manufacturer who's name escapes me), in a similar role.