OnSIP and WebRTC: An Interview With Will Mitchell

How does a hosted PBX SIP service makes use of WebRTC? Ask OnSIP.

If you ask me, all VoIP vendors should be moving to WebRTC in one way or another – and not just as a paintjob on top of whatever legacy architecture they have. Somehow, the SaaS players grok that more than their vendor counterparts.

When I saw what OnSIP are up to, I knew I had to get some answers. Here’s what Will Mitchell, Lead Developer at OnSIP had to say.

What is OnSIP all about?

OnSIP provides business VoIP services to small and medium-sized businesses. The company began back in 2004 as a SIP trunking provider and launched OnSIP Hosted PBX in 2007. Today, we are mainly known for OnSIP Hosted PBX— over 20,000 use OnSIP with standard SIP phones to meet their every-day phone system needs.

However, we aren’t your traditional phone system provider. We’ve built a geographically redundant and scalable platform with open source projects and using standard protocols SIP and XMPP. As we don’t pay software licensing fees, we are able open our platform to application developers (a.k.a Platform as a Service). For example, OnSIP supports SIP over WebSockets, allowing developers to utilize JavaScript SIP clients like JsSIP and sipML5 to build phones in a browser.

To demonstrate our platform scalability and WebRTC support, we just released a free instant video chat application, www.getonsip.com.

Why have you decided to add WebRTC into the mix?

WebRTC has produced an interesting collision between telephony and the web world. It’s opening up real time communications and SIP to a whole group of people that have never had access to them before.

What signaling have you decided to integrate on top of WebRTC?

Session Initiation Protocol (SIP). We’re a SIP house, so this was simply a natural extension of our platform.

What technologies and architectures are you using?

We’re running JsSIP to do SIP over Websockets on the front end. We have a layer of edge proxies that use OverSIP. This ties into our existing platform which is a combination of mostly OpenSIPS and FreeSWITCH running on CentOS.

You already had a running service. How did you find the integration of WebRTC into it?

Good and bad. We didn’t want to treat WebRTC as a separate world. We wanted to integrate it into our service as natively as possible, so each part we added resulted in incremental upgrades across our platform. The edge proxy layer is completely new. Our service was previously based entirely on UDP, but these edge proxies allow us to manage Websocket connections. In the future, we want these same proxies to support TCP and TLS connections. Getting our FreeSWITCH boxes to handle DTLS and ICE was also challenging. Even getting down to little changes, such as parsing SIP addresses that end in .invalid, also proved to be surprisingly difficult.

How about the codecs? Where do you stand there?

Our platform strives as much as possible to be codec agnostic. For peer WebRTC to WebRTC calls, it doesn’t matter what codec is used, whether it be G.711 or Opus or various video codecs. If we have to gateway the call to a non-WebRTC enabled device, we limit it to G.711 and VP8. We don’t do any video transcoding at this point.

Where do you see WebRTC going in 2-5 years?

Progress is going to be slow until it’s ratified by the W3C. Once it’s ratified, hopefully Internet Explorer will support it, and we will see a huge wave of usage. Apple is a big wildcard on that front, too. On the application side, right now we are seeing mostly single-page apps or isolated websites using WebRTC. When it really takes off, I think we will see a lot of cross-domain apps interacting in interesting ways. Interoperability will switch from being a problem to a feature, since everything will talk WebRTC.

If you had one piece of advice for those thinking of adopting WebRTC, what would it be?

Think about your signaling carefully. If you’re making a single webpage, it seems really easy to make some homegrown solution on the web server, but if you’re looking for any sort of advanced features, you’ll soon be trying to recreate the wheel.  For example, SIP and XMPP have both had plenty of time to work out things like presence, transfers and call control, and event pubsub. There are drawbacks to these protocols, too.  Each developer needs to weigh what is important for their particular needs.

Given the opportunity, what would you change in WebRTC?

Some features that are specific to calls, such as hold and mute features, would be nice. In general, though, I’d like a better way to modify the session. The API right now is very limited, and it results in a lot of string operations to modify the SDP, effectively trying to trick the browser into believing in some alternate reality. That isn’t fun.

What’s next for OnSIP?

More WebRTC! We just rolled out a free video chat application, www.getonsip.com, but we certainly have our eyes on more. We are busy building business-enhancing applications for hosted PBX customers and application-enhancing tools leveraging WebRTC and the OnSIP platform.

–

The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.