Oleg_Moskalenko

All posts tagged Oleg_Moskalenko

webrtcH4cKS: ~ Does Amazon’s Mayday use WebRTC? A Wireshark analysis

Posted by Chad Hart on March 4, 2014
Posted in: Guide.
Tagged: , , , , , , , , , , .
10 comments

Many in the industry, including myself, reference Amazon’s Kindle Fire HDX Mayday button as using WebRTC or at least as something that is WebRTC like. The Kindle Fire HDX is not available everywhere, so if you have not seen this the Android Authority has a good video of this feature here.

First lets think about how we tell if an app is using WebRTC. If the app is a webpage it is fairly simple – just look for the use of the getUserMedia and CreatePeerConnection APIs in the site’s Javascript using your browser’s developer console. It is a little more complex if WebRTC is embedded inside a native application. We could start with a debate about “What makes an app a WebRTC app”? If it uses part of WebRTC source code and not the W3C API’s does it count? Since this blog is for developers, not philosophers, let’s start by figuring out what Mayday actually does by looking at a Wireshark trace. ...  Continue reading

webrtcH4cKS: ~ The Open Source rfc5766-turn-server Project – Interview with Oleg Moskalenko

Posted by Victor Pascual on November 18, 2013
Posted in: Technology.
Tagged: , , , , .
3 comments

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