I’ve dealt with the VoIP protocols battle several times in the past on my blog at RADVISION.
Time to revisit this topic in this new home of mine.
And as with anything in these past few weeks, I am going to attribute the change that we will be experiencing to WebRTC.
Quick recap:
- What is WebRTC?
- How will it affect video conferencing? How will a room system look like?
- What will WebRTC do to VoIP?
Time to ask: what is going to happen with VoIP protocols due to WebRTC?
First, I need to to thank Shimon for his wise comment on my previous post:
how can you ignore skype?
today it is the biggest enterprise video conferencing system in the world!!
To put things in perspective: H.323, SIP and other VoIP protocols for signaling account for a fraction of what VoIP really is. Most of it is probably just Skype, which runs a proprietary protocol. And while I do think WebRTC will affect Skype as well (and there are signs of adoption by Skype for WebRTC), I am going to ignore it again here.
I am interested in SIP and H.323 – both are a burden when it comes to WebRTC. Why? Because they are pretty hard to implement in a native web browser environment.
H.323 has no such implementation. I dare you to develop one.
SIP has something called sip-js. Rather new. It won’t encompass the whole complexity of SIP, and it is a single option. Compare it to the 10s of open source and commercial offerings of SIP SDKs out there, this isn’t enough.
XMPP on the other hand, has a few Java Script implementations, making it suitable for native web browsers. 9 such libraries are listed in XMPP’s home page. Why? Because it was built in a way that makes it easier to embed into browsers.
Now let’s see what is going to happen.
You are a web developer. You need to add video calling feature into your website. So you are going to use WebRTC. Only thing left is to decide how to do the signaling in order to negotiate and open that video call.
Are you going to:
- Use H.323, because this is how video calling is done in enterprises
- Use SIP, because this is… well… SIP is how you do VoIP
- Use XMPP, as this is how instant messaging works on the web
- Use Java Script, you are a web developer after all
Guess what the answer is going to be? Java Script.
So it is either going to be proprietary or you are going to get an XMPP implementation in Java Script. Case closed.
SIP and H.323 are going to be reserved for legacy – for connecting into existing networks or when you have a strict requirement of using them. The rest is just going to move on to the web.
This shift won’t happen this year or the next, but it will happen. And vendors need to be prepared for it.
Hi Tsahi
Check how I made Findme@amdocs.
Eyal
You’re entirely right that H.323 and SIP are becoming legacy. I also agree that WebRTC will be important. However, they will all co-exist, because each has its place.
While I’m favorable to a web-based A/V solution, I’m also favorable to a highly-distributed solution that is not tied to a web server. I’ve long argued that the world should not just revolve around port 80. So, another system that is still being developed (and still at very early stages) is H.325. The idea is that you can use your mobile device to interact with all of the devices and applications around you to have a seamless communication experience.
I think the future will include a combination of all of these, but I certainly do expect that the legacy SIP and H.323 systems will slowly fade once better technology comes onto the scene.
Hi Tsahi,
What is the signaling system? What is the relationship between signaling sys. with WebRTC?
Sorry I am from outside of tele-com industry but feel interested in WebRTC
Thanks a million.
OrNot
OrNot,
WebRTC is a media engine. You tell it where to send media, from where to receive and in what codecs and it works. The question then is, how do you know where to send the media. That’s where signaling comes along.
I’ll do a post on the difference in a few weeks time – hope it will help.
Tsahi
Hi Tsahi,
So SIP plays the same or similar role as STUN, ICE, TURN?
I have read WebRTC ‘s doc, but can’t get a clear big picture from it. Hopefully your post can help on it.
Thanks again
OrNot,
Here’s the post trying to explain a bit more about signaling and media: http://bloggeek.me/voip-signaling-101/
Hi
Do you have any information about the traffic of these protocols in the world? for example what percentageof the whole traffic correspond to H.323 and what percentage correspond to Sip and the others….
If you have any information plese let me know.
Thanks
I don’t have percentage information.
What I can say is this:
* In most (almost all) enterprise settings, “managed” video conferencing is done using H.323. Even if the systems support SIP – they end up configuring them to do H.323.
* Almost all VoIP is done using SIP in enterprises (I include Microsoft Lync as SIP here).
* On consumer, most is proprietary, as Skype is proprietary. And so is ooVoo and Viber as far as I know. FaceTime is “SIP” but that doesn’t help anyone. Tango – I have no clue – probably proprietary as well.
I hope this helps…
I think Tsahi summarized it pretty well. There is still a fair amount of H.323 traffic in the public Internet and private networks for voice, but largely for toll bypass. Most service providers have adopted IMS as a replacement for their legacy telephone network. IMS means a variant of SIP. However, it really is nothing but a PSTN replacement. Inside the enterprise, most people are using H.323 for video.
In fact, every time I call into Cisco to join a video conference, I use H.323 from my desk. There are new services like Spranto (www.spranto.com) where you can use H.323 to make calls from home, work, Starbucks, etc. to any H.323-compatible device in the world over the Internet. You can connect to MCUs in the cloud to do conference calls using H.323, like Blue Jeans and Vidtel.
Another fun fact is that the move away from E.164 numbers is made possible. You can call me directly using my email address (at home or work)! 🙂
I agree with one of the sentences of the article: “H.323 becoming a legacy”
I am using Ozeki Phone System XE and this system applies H.323 to specify how the data should be transferred. This page gave me a nice starting point: ozekiphone.com/what-is-h323-324.html
Hi Tsahi,
I’ve looked over at sipML5, JS open source HTML5 SIP client, and its companion webRTC2SIP. for me it looks like it fills in the needed gap for the signaling part. also allowing the interconnect to legacy/IMS network.
have you had a chance to explore that solution?
Effi,
I am not sure this is such a good idea – it really depends on the problem you are trying to solve.
As far as I remember, the sipML5 one is 1.5 Mb in size, which isn’t that nice for mobile devices. In a lot of the vendors out there, I’ve seen solutions which use SIP in the backend but prefer using a proprietary protocol (or XMPP) for the client side to connect with it.
To me this seems like the better approach for a large set of problems.
Regarding size consideration: I am currently using mizu webphone. Everything in a single jar file at around 800 KB. A legacy SIP implementation including media stack will all kind of codec. It even includes a user interface although better used as an SDK.