BroadSoft Secrets Revealed: Luck is Better Than Smart
By Scott Hoffpauir, Managing Partner
In my last blog, I talked about the risks with making technology decisions that ensure your products are future proofed and have the longevity to survive in our ever changing industry. I gave an example of one of the things that kept me up at night, which was our decision to use Java as the underlying platform for BroadWorks. The other big decision for us at BroadSoft was our decision to use SIP as our core communications protocol. Let me tell you that story.
Now, back in 1998, the Internet was pretty new. The Mosaic browser was introduced in 1993 and we were in the middle of the dot com bubble. People were trying all kinds of crazy things, most of which didn’t survive. The telecom industry had its own bubble, with massive growth driven by broadband access. Industry experts knew that the existing circuit switched voice solutions would transition to use packet switched technology, and that spurred us to start BroadSoft.
Back then, there were lots of people working on different protocols and approaches for packet switched telephony. While it’s obvious now that VoIP was the way to go, that wasn’t the consensus in the industry in the late 90s. I can remember an industry analyst telling us that VoIP would never work, and that we should focus on VoATM (And no, that’s not Voice over Automated Teller Machines). Even with VoIP, there were multiple protocol options including MGCP, H.323 and SIP.
Our first prototype used SGCP (an early version of MGCP). It was a pretty simple protocol with a client server type approach, very similar to how most class 5 switches controlled their peripheral equipment (e.g line cards). By the way, Mike is a hardware guy and developed a line card at Nortel. I’m a software guy and insisted that we have the “Soft” in BroadSoft so that we would never do hardware. Anyway, MGCP was easy to implement, but the interoperability was challenging. It seemed like every vendor implemented the protocol in a slightly different way. We wanted to have an open platform which worked with as many devices as possible, and MGCP wasn’t going to work for that.
Most vendors at the time used H.323, which was a tremendously complex protocol combining the worst of legacy video conferencing protocols and the worst of telephony protocols (e.g. ISDN). I started my career at Nortel, and once tried to configure an ISDN Basic Rate Interface in the lab. It took me three days to get it working. Given our desire for interoperability with lots of devices, we wanted something simple that device vendors could easily implement. H.323 clearly wasn’t that.
Around this time, a new protocol came out called the Session Initiation Protocol or SIP. It was based on the HTTP, the backbone protocol of the Internet. It was designed by crazy Internet people, not telecom people, who had a mission of making it open, royalty free and accessible to anyone. The first SIP standard was completed in 1999, and there were a lot of smart people embracing it. We had been looking at H.323 and were about to spend $300K on a stack. At the last minute, we decided to go with SIP. We made a huge bet on a new protocol that was clearly better but not proven.
And that’s where the fun began. I remember we participated in the second SIP interoperability event, called a SIP bake off (name had to be changed later because Pillsbury didn’t like the group using the term bake off). Here’s a link if you’re into history. Alex Doyle and Jamie Palmer rented a minivan and drove from Maryland to Long Island to participate. Since Alex grew up in Connecticut he drove, and for some reason drove through Times Square in Manhattan. Even a South Louisiana boy such as myself knows that wasn’t the thing to do.
The bake off was great. Everyone worked towards an open ecosystem, and enhancing the protocol, but this first version of SIP was pretty basic. For example, in a telephony switching network, ringback is provided by the far end. That’s why when you call a different country, you hear their ringback and not what you normally hear in your country. So, while you could use SIP to set up a call, ringback had to be provided by the near end, which caused an unacceptable user experience issue.
So, the smart guys in the industry went off and added new standards to address these issues. It took time, but everyone was motivated to move quickly and get things done. Oftentimes, implementations were done before the standards. Since we had an application, we worked closely with all of the major device and softswitch vendors. In many cases, they used our product as the baseline for their testing. If it worked with BroadWorks, it would work with anything.
After a few years, we started moving towards replacing PBXs, which have a lot of complex features like multiple line appearances, music on hold, conferencing, busy lamp fields, etc. Our direct competitor used a proprietary MGCP variant and moved quickly, surpassing our capabilities. We had to define our own SIP extensions and work with device vendors to replicate these features. Since SIP was originally designed to be a peer to peer protocol, we had to “enhance” it to be more of a client server protocol, which was no easy feat.
I remember Jamie Palmer and Stephane (Stef-Anne) Proulx spent a few months researching how shared call appearances worked on the Nortel products. They then spec’d out how to do the same thing using SIP. We then went out to talk to all of the device vendors. We were lucky that Polycom saw the potential of having an open SIP phone that was able to do all of the same things as a PBX phone. They worked in lock step with us developing these critical features, and eventually ended up being our primary phone partner.
So, getting SIP to do everything you could do in a PBX took a lot of time, definitely more time than we thought. But, it was the right decision. Our customers and partners all wanted an open ecosystem. They wanted choices and competition. We had to commit a lot of resources in not only development but also interoperability. Even though we didn’t sell devices, we had to treat the devices as an integrated part of our solution. That’s what our partners and end customers expected.
SIP eventually won out as the protocol of choice for all telephony. Now, it’s used for consumer VoIP, mobile VoIP, hosted PBX, SIP trunking, video conferencing, and messaging. If you make a phone call today, chances are pretty good that it uses the SIP protocol. While it took longer than we thought for the industry to adopt it, our decision to use SIP was the right one. It enabled us to provide a product that stood the test of time. It also enabled us to provide an open environment and ecosystem, which I think was one of the biggest reasons for our success. I’d like to say we were really smart guys and had a vision for the future, but really we took a chance and got lucky. And as I always say — it’s better to be lucky than good.
We’d love to hear your stories around SIP and the early days. I’m sure they’re some great ones that I haven’t heard!
