Recently, I've been musing in this post about a self hosted alternative to Skype for communication between family members using Asterisk on a Raspbery Pi and the Ekiga SIP client. With the recent discovery that Microsoft is actually listening into Skype text conversations that need has grown even stronger. Then I've read that the upcoming Firefox 22 will have the full WebRTC API implemented and activated. So far my knowledge about WebRTC has been rather limited, I just knew it had something to do with web browser based peer to peer communication but not much else. Time to fill the gaps:
The Wikipedia entry on WebRTC is actually quite brief and pretty much reflected what I already know: There's almost nothing about how it works. The FAQ over at webrtc.org is quite enlightening however. Here are some key facts that will help you to better understand WebRTC if you know about how VoIP works with SIP:
According to the FAQ and this blog post, WebRTC can be thought of as a web browser based
- To access camera and microphone
- To connect to another peer (i.e. to the destination user)
What is not defined is how the other peer is discrovered initially and how audio and video codecs are negotiated. Traditionally this is done with a number of different protocols, SIP being one of them. In other words, the SIP protocol and communication with a SIP server is not part of WebRTC and has to be implemented by the web app on its own (for details see the blog post linked above). What is defined however is the use of the Session Description Protocol (SDP) to describe the audio and video codecs available on each end.
So one the simplest use case would be to replace native SIP clients with a browser based WebRTC client that implements its own SIP stack. WebRTC clients can even communicate with native SIP clients over a proxy server if both support a common audio and video subset. This seems to be the case with WebRTC supporting the G.711 and G.722 audio codecs that are widely used in the SIP world today.
This obviously fits into Google's overall (Chrome) strategy to have everything running via a centralized server in the network and in the web browser on user devices. While this is not exactly what I have in mind due to my preference of hosting my own web services at home the architecture is open so nothing would prevent me from running my own SIP server at home with an open sourced WebRTC client and proxy. Having the client run in the browser also means that the client software can be deployed without any hassles. The use case implemented by Ericsson over here gives an insight of what's possible with "just in time" deployed communication clients. At this point, WebRTC breaks with today's technology to offer new and interesting possibilities to explore.
For further insight, have a look here on SIP servlets and here for a HTML5 SIP client (+proxy) implementation with WebRTC.
6 thoughts on “A WebRTC Client as a Skype Alternative”
You can’t say that browser has a full SIP stack in it. It’s false as SIP is only a signalling protocol and WebRTC is signalling agnostic. The only thing WebRTC provides to SIP is the SDP to send in INVITEs.
Thanks very much for this clarification! I got that important point wrong when I wrote the blog entry and have corrected the post accordingly.
This is how I am using: RPi is running a webrtc app in a server. I am signed into it from a browser which maintains a websocket conn. I give an http URL to you. You visit the URL from a browser. RPi will authenticate you with OpenID/OAuth and if you are in my whitelist (it is a dynamic one), it will maintain a web socket conn with your browser and will inform me. If I respond we two can continue in our conversation.
I think G.722 is not part of the standard. G.711 and OPUS are.
Hi, according to the FAQ linked above “The currently supported voice codecs are G.711, G.722, iLBC, and iSAC”.
Why incorporate the SIP stack into WebRTC in the first place? I may be missing a lot, however, it would seem to make more sense to not (duplicate) a SIP stack within WebRTC on the basis that it should be called as other applications stacks and might otherwise lead to conflicts in development.
Comments are closed.