What a week it has been for WebRTC… time for a recap.
It was an interesting week. It started with the Google announcements (from the previous week), but with great posts that happened elsewhere rather than here. If you are interested in WebRTC, then I wanted to bring your attention to a few of these posts:
- Starting with the sad things, the IETF is still mucking around the mandatory codec issue. Erik Lagerway has his view on the subject. I’ll publish mine in the coming weeks.
- Dave Michels took the time to list 5 threats that could derail WebRTC. His post attracted attention both in the comments section and on social media sites (Facebook and Google+). A good read that reminds us that the game is far from over.
- Graham Machacek listed his own 5 challenges of WebRTC on Macadamian blog. He took it to the challenges required when connecting WebRTC into SIP/PSTN infrastructure. All correct, except for this tiny bit of information that a lot of use cases don’t necessarily need such connectivity, and many of those that do would be quite satisfied with acquiring that piece of technology either as an appliance or a service and be done with it.
-
Camille Mendler of Informa explains how she communicates these days and why she finds Twelephone so appealing. Two things to take note:
- Different people communicate differently. Fragmentation, or more accurately, variety might be a good thing for us moving forward
- There’s an interview with Chris Matthieu, the founder of Twelephone here
- On another note about Twelephone, the service is now in its first round of full rewrite, this time bringing it on par with Skype’s feature set. While I do think there’s not going to be a single Skype killer, this really is great progress for Twelephone. Kudos to Chris and his team.
Two other things I’d like to mention is Amir Zmora’s guest post this week here about WebRTC at MWC 2013 and what operators are doing, and a very enjoyable read by Chris Kranky about selling VoIP to operators – somehow, this seems all too familiar (and ineffective) from my past life. But then he published this piece – about what telcos should do about WebRTC.
–
Read a great post about WebRTC and want to share it? Want to be interviewed on what your company does with WebRTC? Want me to write a guest post on your blog about WebRTC? Got a good post about WebRTC you want to post on my blog? I am game for all of these – drop me a note to get it done.
Hi Tshai,
I have read the blocker things for webrtc over the links. But I could not find any issue like enterprise firewalls .
I have faced this problem with google webrtc discussions and found really interesting. But I could not find any information about this what is being considered for webrtc to solve this issue.
As a known fact enterprise firewalls work as “deny all” mechanism, it allows traffic over only most common ports like 80, 443.
Some problems which I have considered :
1) For example 19302 port is required to communicate with STUN (it may not be 19302 of course , but port number issue will be exist again) and it seems webrtc users inside enterprise firewalls can not communicate with STUN server. So connection will fail at first step.
2) Let’s assume that 19302 is activated , but what about rtp ports which are exchanged between pairs for ice connectivity check? Webrtc uses random ports and may not be guessed which ports will be used. Also developpers may not touch this port allocation process, because they are using only APIs. In this case also rtp stream will not work. Let’s assume that in the future a port range will be provided by webrtc framework, but when we want to use webrtc inside enterprise firewall, what will we say network admins of that big companies. I guess they even do not listen us because they have strict policies.
I have searched a bit how google tries to solve this issue for google hangout. I see that google is trying to check the connectivity over some rtp ports. But when it realizes that there is no way to beat the firewall or NAT, it is using HTTP overloading which means sending streams inside HTTP packets over 80, 443 etc…
Google can do that, because google hangout, gtalk its product. So it can do any manipulate/trick inside its code base to beat firewalls/Nats.
But a poor webrtc developer can do nothing, because he/she has only APIs.
I would like to ask you that as a person who has wide range knowledge about webrtc and attending meetings which I is impossible for me 🙁 ,
is there any plan how to overcome this issues?
PS : I follow your blog since long. I want to thank you that for your posts to inform us.
Regards
Mehmet
Hi Mehmet,
I recommend posting any technical questions to this group: https://groups.google.com/group/discuss-webrtc
WebRTC is built on top of an ICE/STUN/TURN stack.
When STUN fails, TURN is the next option. TURN has several levels, from being a normal relay server, to doing http / https encapsulation. There are several open source TURN servers that can be cheaply deployed on AWS or Google Compute Engine.
My personal hope and opinion is that offering managed TURN services to developers such as yourself will be a good business. I am seeing encouraging things happening on the market in this regard.
/Serge
Hi Serge,
Thanks for your reply.
Actually I would like to learn that what is being talked about this issue within webrtc meetings.
Once I had used a free TURN server as relay only . But I guess this will not solve the problem. Because webrtc uses RTP . And If you deploy TURN server outside the firewall and this TURN server tries to convert the incoming RTP streams to HTTP packets and sends to other peer, this time other peer will not be able to handle this.
In this case maybe your idea is deploying TURN servers inside the firewalls I guess which makes HTTP encapculation.
Regards
Mehmet
The client will do the encapsulation, so the turn server should be outside.