Spreading video conferencing to the developing world.
There are companies that have a video conferencing heritage in their blood, and due to my own heritage and pedigree when it comes to development, they definitely have a warm place in my heart and some feeling of kinship.
Temasys has such heritage, which made it interesting for me to hear their perspective on WebRTC and their use of it. Bill lewis, CEO, and Dr Alex Gouaillard, CTO, took the time to answer some of my questions.
What is Temasys all about?
Temasys is about changing (and improving) how people communicate, how businesses relate to customers, suppliers, and other stakeholders, and vice versa. We put the “Visual” in “Visual Communications” and provide the tools to communicate from anywhere to anywhere, on any device, at any time – and our task is to make the underlying technology invisible to the user.
We are about being agile, non-dogmatic, innovative, and challenging, and demand excellence in everything we do.
Based in Singapore we think globally, with offices and representation in Washington DC and London.
We currently have two strong VaaS propositions built on Vidyo and Magor offerings, delivered over a global infrastructure with servers in Singapore, USA, and Europe. This VaaS network serves customers in a variety of verticals: oil and energy, mining, healthcare, education, and maritime.
Our VaaS propositions have now been complemented by the development of a deep, full stack, WebRTC Infrastructure that is capable of scale and functionality.
Staff are international, multi lingual, and with impressive credentials in both start up and mature businesses, operations and engineering, and research and development.
There are many video conferencing services out there using WebRTC already. What differentiates you from them?
From the beginning, we had existing customers use case to work with, and no existing product to maintain, or existing infrastructure we would need to leverage. We quickly realized that there is not one single use case for WebRTC, but as many use cases as there were customers. We do not really believe in a killer app (the web is the app). Web technologies are faster to prototype and deploy, and we became more agile in order to leverage those opportunities.
Given the right infrastructure, and the right “bricks” (more on that later), any idea could be implemented as a one-page prototype within a matter of days. We decided early on to have a research-oriented approach to development. Instead of going for a given use case, one product, and trying to fit everything there, we would develop a strong modular infrastructure and multiple bricks, and only assemble on demand. The bottom of the stack (infrastructure) is pretty stable, but the top of the stack is completely open, and developed on-demand to adjust to customers use case instead of constraining it.
Let me give you a few examples of this.
- TURN Servers. Some clients want you to handle TURN servers for them in your cloud. Others are ok with you handling their server in a public cloud; other clients may want to handle their server in a public cloud. Finally, some customers may want the server within their firewall on premises. To be able to answer all, we provide AWS / GCE pre-installed and configure images, for several locations, or pure VMware / VBox images, or servers as binaries, compiled for multiples architectures and OSes. We set up the internal build and test servers to make sure that all work the same way and are the latest, patched versions. In the cloud versions, we also extended the traditional servers to all have REST API, and developed smart load balancing, and smart security features.
- Middleware (aka API / SDK / Buttons / widgets ). Some clients may already have a website running, and want to either replace a java or flash-based solution, or add additional capacity to their website or portal. We provide the right API / SDK / Button / plug in for them, on top of the needed infrastructure: solutions may require a different language (js, php, …), a plugin for another platform (Drupal, WordPress), a fully embedded widget, and /or there could be constraints in the signaling for content (SIP, XMPP, proprietary) or transport (WS, XHR, GAE Channel, …). We provide a portfolio of solutions to meet these needs.
- Some clients do not have any existing (web-based) product and ask us to develop their custom solutions and/or to white label one of our existing client.
What do you use for signaling in your solution?
We provide maximum versatility: we have clients/servers implementations with raw XMPP, jingle, SIP and different proprietary signaling on top of GAE’s channel, and WS. We have basic implementations of each and also a more complete version of each with support for multiple connections, chat, e-mail invite, etc.
The backend part; what technologies does it use?
Our “backend” service is called WebRTC Skyway. It comprises of web servers, signaling servers, TURN servers, SIP gateway, SIP registers, IP-PBX, etc. Depending on the features demanded by a client all or part of this infrastructure is used. TURN, SIP gateway, SIP registers and IP-PBX are all implemented using additional load balancing and security.
I must give a special thanks here to Oleg Moskalenko, who not only developed a great TURN server (http://code.google.com/p/rfc5766-turn-server/), but was also very responsive on the mailing list, and went the extra mile to help debug some problems. I have drafted a blog post to document the usage on the webrtc/web app / web server part which should be online later this month.
Can you share some of your experiences with dealing with WebRTC?
It’s moving fast, very fast. It impacts many areas and shakes everyone’s comfort zone. We learn every day. Constant iteration, constant review. “ You read a new spec every day. It feels a little bit like reading philosophy books. You read the first spec ….. three times …. then you think you understood something. You move on to the second spec, you read it …. then you go back to the first spec to read it again 🙂 “
More seriously, to everybody that would be thinking about developing in webRTC today: do not expect it to be easy, do not expect it to be well documented at this stage (for plenty of good reasons), be ready to read a lot, experiment a lot. Start small, make modules, harden, test, harden, rewrite, review, and repeat. Do not believe everything you read ;-), test!
Be also aware that the expertise in this area is very scarce: it is very likely that you will not find people with expertise that are not already employed. You might want to consider using third-party (our?) services instead if you want to bootstrap. Any written documentation or book about webRTC is obsolete the moment it is written. If you want to be up-to-date you have to follow the multiple mailing lists (webrtc code, mozilla, W3c, IETF) and write code. There is a lot to get in.
Given the opportunity, what would you change in WebRTC?
That’s a tough one. In WebRTC itself, maybe not much (even though I am part of the discussion about making a better JS API to at least mask some SDP complexity, and to rethink the O/A mechanism). I would love to have access to parameters of the codec and some parameters of the transport from JS. Also, some way to know about devices being plug in or removed in real time (I am plugging in a headset in a middle of a call, what happens ….) would be nice. All these have been reported in the corresponding standard bodies, and I have hoped that it will happen before the standard is final. That’s one of the reasons why we joined W3C and IETF in the first place.
Some features are in the roadmap but not yet implemented like stream relaying (getting a remote stream and passing it through a peer connection to another party) and recording, to only name a few. Other features I would be interested in are discussed but pause additional problems and are not part of the roadmap as of now. In that last case, I’m thinking about screen sharing, or document sharing (collaboration) which each have additional technical challenges, especially on the security side of things.
What’s next for Temasys?
So much. We have to keep everything in par with the WebRTC specs, which is already a large amount of work. We are trying to be active and participate in the next IETF meeting in Berlin this month, as well as W3C in Shenzhen in November to push the standard out. We are participating to the working groups on screen sharing, recording, and relaying of peer connections.
We are in the process of developing clients for other companies like Magor and a few others I can’t cite yet. We are polishing Native clients for Android and iOS for general availability. We are starting a new big infrastructure project next week with my infrastructure team. We continue to hire the brightest and the best.
Expect to see a lot at Santa Clara WebRTC expo and conference in November!
–
The interviews are intended to give different viewpoints than my own – you can read more WebRTC interviews.