Over the last several years we’ve been working with several clients demanding audio/video functionalities for their systems. We have explored and abandoned numerous technologies. We’ve fought bravely against numerous enemies hiding in the shadows of Red5, Asterisk and WebRTC. We finally ended up putting bits and pieces of several open-source components in order to provide our clients the best and most cost-effective solutions.
Flash and Red5
Back in 2013 when we built TalkTo.MD (the project is no longer live) we were looking for a widely adopted technology that would allow our client to stream live audio and video between a patient and a healthcare proffesional. WebRTC was not an option at that time, and the only technology with wide-enough audience was Flash and the secure version of the RTMP protocol (privacy was a big issue, you can imagine). We went with Flash then and chose Red5 as the streaming server. It turned out to be a bad timing for that set of tools – Flash was having difficulties with RTMPS, on top of that the immature implementations of RTMPS in Red5 at that time made us run in circles for ages until we figured out the combination of parameters that made RTMPS actually work – only to discover that the next minor upgrade of the Flash plugin made our work completely obsolete and took us back to square one. Luckily for our support team the project was shutdown by our client quickly, due to legal issues involved with on-line medical consultations.
Peer-to-peer web chat
Next time we had to deal with the problem Red5 has fortunately neared the 1.0 release and RTMPS worked well enough. But since the project did not require any form of archiving of the audio/video material, our client thought it to be an unnecessary expense to stream the content through a media server. It seemed that a peer-to-peer connection between the 2 endpoints would be a cheaper solution that would also deliver better user experience (higher quality, lower latency). We quickly built a prototype that sent an HD H.264 encoded video over a typical Flash NetStream. It looked amazing. The latency was minimal, motion was crisp and quick, even when tested on a relatively slow link. We were ready to roll out the project and our client began to showcase the system with their business partners. You know – large corporations, running deep-packet-inspection and dumping all Facebook, Instant Messaging and UDP traffic, not to mention peer-to-peer connections. NAT traversal techniques could potientially work, even in a hostile environment such as an enterprise network, but no UDP forced our client to redesign their strategy and emphasise the text-only version of their product, offering audio/video as an option.
Call-center
When we got a call from one of our oldest clients asking about a complete system to operate a call-center we put significant effort into explaining to them the risks involved with using the web and the browser as the platform. Some of the risks were minimized by a fully controlled environment where the system would be deployed – a separate network under our control, dedicated computers with appropriate software versions. Others were outweighed by the potential benefits and the client decided to build the system.
Right from the start we knew that the main component of the system will be Asterisk. Our client has had previous experience with that platform and it was considered industry standard in open-source VoIP telephony. It took us over a month to investigate the state of the former system our client was using and create a safe environment were we could easily transfer a variable number of calls to the new system. Asterisk turned out to be very flexible, but the meanders of its configuration gave us multiple headaches throughout the integration period. One of the requirements upfront was that the whole system would run in the browser. That means your softphone too. No problem, we thought, SipML5, SipJS, JSSip, etc. we’ll find something. Bad timing again. During a period of several months in production we switched from SipML to sipJS to JSSip and back and forth. We also updated Asterisk versions from LTS to current trunk and downgraded back again. The softphone stack in the browser is immature. Chrome’s implementations of NAT traversal are immature. Asterisk’s implementation of WebRTC is completely broken, to the point that it segfaults Asterisk in some cases of SIP communications. Our final solution had to involve a bare Asterisk, that handles only the VoIP part, which it does extremely well and a WebRTC-SIP component that acts as a connector between the browser and Asterisk.
Once again the UNIX philosophy of small tools that do a specific task and do it well – wins, as does our team!