All posts tagged Q&A

Last year we interviewed Oleg Moskalenko and presented the rfc5766-turn-server project, which is a free open source and extremely popular implementation of TURN and STURN server. A few months later we even discovered Amazon is using this project to power its Mayday service. Since then, a number of features beyond the original RFC 5766 have been defined at the IETF and a new open-source project was born: the coTURN project.

Today we are catching up  with Oleg again to see what’s new and to learn what coTURN is about. ...  Continue reading

I’m at the IIT RTC Conference this week in Chicago which is an excellent, no-BS conference that featured many WebRTC luminaries and one of best events I have attended in a long time.

On Tuesday I moderated a panel with WebRTC contributors and ORTC promoters, Robin Raymond of Hookflash, Bernard Aboba of Microsoft, and Peter Thatcher of Google, asking many of the same questions I did on the ORTC Q&A several weeks ago.

Dan Burnett was in the room, asking a lot of questions. If you don’t know Dan, he is a long time W3C author and editor. He is also one of the Godfathers of WebRTC who was there right at the beginning. He also has a highly regarded book on WebRTC coauthored with Alan Johnston. ...  Continue reading

Biggie vs. Tupac. Gates vs. Jobs. Apple vs. Samsung.  Nothing catches people’s attention for no legitimate reason like a feud. Unfortunately this isn’t just a celebrity phenomenon. Feuds have been endemic even to real communications as well. From the very beginning, Elisha Gray’s dispute with Alexander Graham Bell over the original telephone patent showed the industry has a propensity for squabbles. Unfortunately we have become so accustomed to feuds that we sometimes fabricate battles that do not really exist. I fear that this is often the case with one of the most important, but misunderstood efforts affecting WebRTC’s future – Object Real Time Communications (ORTC). ...  Continue reading

One of the most vexing challenges for WebRTC developers is “what do you do with IE and Safari?” Do you ignore them? Tell your users to use something else? Can you even tell them what to do? Maybe you fall back to flash? There are no easy answers and WebRTC is supposed to be easy, right?

Perhaps you just wait and hope that Microsoft and Apple implement WebRTC soon? This brings a lot of risk – what exactly are they going to implement?  For Microsoft it seems it will likely be ORTC, definitely not the current spec. When exactly are they going to implement it? What is Apple going to do? What will you miss out on in the mean time? ...  Continue reading

Want to try out a newly released WebRTC feature or capability? Odds are Muaz Khan has already done it. I cannot think of any other individual who has contributed more open source WebRTC application experiments to the community than Muaz and his webrtc-experiment.com. His GitHub repository boasts 44 different projects.

He did all that in less than 2 years and he is just getting started. What is even more amazing is Muaz had done all this with very limited resources from a remote village. He doesn’t event have electricity for large portions of the day in some months! ...  Continue reading

As Reid previously introduced in his An Intro to WebRTC’s NAT/Firewall Problem post, NAT traversal is often one the more mysterious areas of WebRTC for those without a VoIP background. When two endpoints/applications behind NAT wish to exchange media or data with each other, they use “hole punching” techniques in order to discover a direct communication path that goes from one peer to another through intervening NATs and routers but not traversing any relays. “Hole punching” techniques will fail if both hosts are behind certain types of NATs (e.g. symmetric NATs) or firewalls. In those cases, a direct communication path cannot be found and it’s necessary to use the services of an intermediate host that acts as a relay for the media or data packets, which typically sits on the public Internet. The TURN (Traversal Using Relays around Nat) protocol allows an endpoint (the TURN client) to request that a host (the TURN server) act as a relay. So far TURN, along with ICE and STUN, has seen little deployment. Now that it is a fundamental piece of WebRTC, it is gaining some momentum. In fact, at the IETF we’re now starting a new effort that will focus on enhancements to TURN/STUN that will be applicable to WebRTC deployments. This new effort is called TRAM (Turn Revised And Modernized), and we’re currently discussing its charter...  Continue reading