Compare Web SIP client solutions

Web SIP clients -Details and Compare

Web SIP clients are VoIP communication solutions running directly from the user’s browsers, without the need to install a separate software (softphone) on the user’s machine.
They can present a traditional softphone user interface and usually have a JavaScript API, so you can implement any custom solution from browsers connecting to your VoIP/SIP server/softswitch/PBX such as click to call.
SIP clients for browsers can be implemented in multiple ways, each with its advantages and disadvantages. This document aims to compare various solutions and to help to choose the optimal Web VoIP client for your project.

web sip solutions

WebRTC SIP clients

This is the de-facto standard for communication in modern browsers, however with big disadvantages compared to native SIP solutions. WebRTC is a “black-box” technology inside the browsers, so developers don’t have access to the details and are locked to browser vendor implementation.
For example google is forcing VP8 video codec, while the widely implemented codec in IP phones are H.263 and H.264. On the audio codec side it has G.711 and Opus but miss the VoIP word mainstream codec which is G.729. It doesn’t define any signaling protocol and correct TURN/STUN setup can be difficult for users. Also there is a big difference between WebRTC deployments depending on the reliability of the software you use (conversion from WebRTC to SIP signaling, conversion from DTLS/SRTP to RTP, codec conversion, proper TURN/STUN configuration). If your softswitch doesn't have WebRTC support, you will need a WebRTC SIP gateway to use this technology.

Popular implementations:
  • Supported by Firefox and Chrome browsers as part of the HTML5 standards without the need of any plugin download
  • Not supported in some important browsers such as IE and Safari (except the latest Safari 11 which has a low market share)
  • Audio issues on Mobile
  • No built-in G.729 codec and fragmented video codec support
  • No built-in conference support
  • Extra error-prone/complicate server side conversion from websocket to SIP signaling and DTLS/SRTP to RTP for the media

Java applet SIP clients

Java applets once were a perfect candidate to implement fully functional SIP from browsers. Since Java has support for both audio and UDP, native-like softphone can be run in the browsers without the need for any intermediary servers.

Popular implementations:
  • Native-like performance and features
  • No need for any intermediary server or protocol conversion
  • Getting deprecated in modern browsers


Silverlight was an ambitious effort from Microsoft, but it is completely dead on web nowadays. Microsoft officially announced the end of life of Silverlight in 2012.

Popular implementations:
  • Nothing here
  • Not supported at all by today's browsers

Flash SIP clients

Flash is not an ideal platform for VoIP, however previously this was a broadly available technology and a lot of SIP clients were implemented in Flash.

Popular implementations:
  • Compatible with old browsers
  • Deprecated since Adobe and browser vendors started to abandon Flash
  • Requires an additional resource hog media server to convert between RTMP and SIP/RTP
  • Adobe proprietary signaling and media missing the popular VoIP codec's such as G.729 (transcoding)
  • Quality issues especially when routing the media over TCP and both the flash client and the media server ads an additional delay

NPAPI SIP clients

Browsers NP-API and ActiveX providers a way to run native code, thus the ability to implement any software using any programming language, even C/C++.
With time this proved to be too insecure and browsers vendors now are deprecating this plugin.

Popular implementations:
  • Native binaries
  • Doesn’t work in Chrome anymore and Firefox also plans to remove NPAPI. Never worked in Edge.

Hybrid Web SIP clients

Hybrid web sip clients can combine the best of the above solutions, thus taking out the best part of each and providing full browser coverage.
They can adapt to the user browsers and use the optimal technology depending on the circumstances, and with direct SIP/RTP connection to your softswitch whenever possible. Not only you have covered all browsers, but you are adapting for each of them with the most suitable technology, all covered with a single universal API and the same user interface.

Popular implementations:
  • Works in all browser, all OS
  • Native SIP/RTP with direct connect whenever possible
  • Auto choose between multiple VoIP engines: WebRTC, native plugin, Java, Flash, App
  • All features, including voice, video, wideband codec, G.729 codec, chat, dtmf, presence, file transfer, pbx features, click to call features
  • No open-source implementations
Let's see the browser support visually:

WebRTC Java Flash NPAPI Hybrid


until v.52



latest only









  • If you are looking for a simple implementation, we recommend to pick a WebRTC client as that can cover 75% of internet users if properly configured. However please note that proper WebRTC server side setup is a tricky topic and if not done correctly then you actually will end by covering only half of the potential users (for example the most important clients might fail to use your WebRTC solution from behind corporate networks where only TCP port 80 is allowed if you can't configure your software to work also in these circumstances when all UDP ports are firewalled).
  • If your main business is VoIP centered, then you can’t afford to loose a high percent of potential users or the support headache caused by the incompatibilities so the definitive answer in this case is the the hybrid solution represented by the mizu web sip phone. This hybrid solution not only has a SIP optimized WebRTC stack, but also other VoIP engines to maximize availability and optimize voice quality depending on client OS/browser and other circumstances. Beside maximum browser compatibility, this also has other advantages such as ready to use, customizable web softphone user interface, ready to use click to call solution, high level API with flexible parameters and it is optimized for native SIP/RTP avoiding any server side protocol and codec conversion whenever possible, thus saving your server resources and minimizing media delays.


 |  View Topic History  |