We continue publishing set of articles about interesting technology areas and solutions we have implemented or encountered in our projects.
This article briefly describes our experience in implementing video chat for medical consultation solution using WebRTC.
Our solution
In the past year we had two situations when we required to implement video chat function to our project. One was a part of a system for medical consultations where site members can order a time limited consultation with a selected medical professional. Another solution required was part of social mobile application. The function of free or paid/time limited video chat or conference is popular currently in other areas as well like expert chat (http://clarity.fm/ and others).
Years ago we were implementing video conference feature by making it all from scratch, based on both existing and custom protocols. Now the technology is changing and there is a number of solutions available that require from few hours to few days to make a good video chat solution.
One extremely popular approach is WebRTC technology which is supported by major web browsers and allows to perform peer 2 peer real time communication including video calls. We had a demo solution implemented using WebRTC and it works great, allows multi user conferences, no additional installation to user computer, etc. But it also requires additional work to implement support of communication from behind specific NATs, using additional TURN and STUN servers, security implementation, iOS support, and also an infrastructure for scaling in case user base will be growing quickly. Even if it’s not that difficult, it still takes time.
So what we did is to took a good look at several popular services for video conferencing /chatting and found two that are suitable for our goals:
- http://tokbox.com/ – OpenTok solution is based on WebRTC.
- http://quickblox.com/ – chat solution including video calls also is using WebRTC as one of their protocols.
After careful review and proof of concepts we decided to use both solutions in project where they fit the best: tokbox for medical consultation and quickblox for social chat function.
Interesting Challenges
Following challenges were completed in scope of the project:
- WebRTC proof of concept:
- Multi-user video/audio conference,
- logic to limit the video time,
- STUN server usage,
- TURN server usage,
- scaling tests.
- Quickblox implementation in iOS and Android app:
- peering users from contact lists /user database,
- video and voice calls, and text chats support.
- Tokbox/OpenTox proof of concept followed by full implementation:
- consultation module integrated with our user and billing databases,
- real-time video chat able to scale quickly once the system requires it.
Definitions
WebRTC (Web Real-Time Communication)
WebRTC (Web Real-Time Communication) is an API definition drafted by the World Wide Web Consortium (W3C) that supports browser-to-browser applications for voice calling, video chat, and P2P file sharing without plugins.
STUN (Session Traversal Utilities for NAT)
STUN (Session Traversal Utilities for NAT) is a standardized set of methods and a network protocol to allow an end host to discover its public IP address if it is located behind a NAT. It is used to permit NAT traversal for applications of real-time voice, video, messaging, and other interactive IP communications. It is documented in RFC 5389. The STUN URI scheme is documented in RFC 7064. STUN is intended to be a tool to be used by other protocols, such as ICE.
TURN (Traversal Using Relays around NAT)
Traversal Using Relays around NAT (TURN) is a protocol that allows for a client behind a network address translator (NAT) or firewall to receive incoming data over TCP or UDP connections. It is most useful for clients behind symmetric NATs or firewalls that wish to be on the receiving end of a connection to a single peer. TURN does not allow for users to run servers on well known ports if they are behind a NAT; it supports the connection of a user behind a NAT to only a single peer, as in video telephony, for example. In that regard, its role is to provide the same security functions provided by symmetric NATs and firewalls, but to turn the tables so that the client on the inside can be on the receiving end, rather than the sending end, of a connection that is requested by the client.
