Comments on: WebRTC Basics: How (and Why) WebRTC Uses your Browser’s IP Address

By: Jaro Cech

Jaro Cech — Thu, 30 Jul 2015 14:22:34 +0000

P2P is the basic possibility how to communicate via WebRTC. But if you need recording the session and some of additional control, the “star” topology is much more acceptable. So you need WebRTC server – we are working with Freeswitch or Kurento. Both are fine, thus both are used for different usecases …
And if your server sits in the GOOD cloud (Azure in our case) – the latency is no more the issue…
But your point with CPU consumpion is right. If you do some processing of streams in real time – you need a lot of CPU power. And it costs money.
Another trick is to pass the DMZ zones by large companies. P2P is not acceptable. We are using stunnel technology in the combination with WebRTC server. It works …

By: Tsahi Levent-Levi

Tsahi Levent-Levi — Mon, 27 Jul 2015 15:22:54 +0000

In reply to Aswath Rao.

Aswath,

I can always rely on you on providing great feedback here – thanks 🙂

By: Aswath Rao

Aswath Rao — Mon, 27 Jul 2015 15:20:44 +0000

One of the points you make – not using P2P increases latency and chance for packet loss – is made others and often. But I feel this may not be case always. For example consider a service that has point of presence in many ISPs and these POPs are connected via optimal paths. Then it is more likely that P2P paths may have more latency or experience higher loss.

I am not sure that P2P paths maintain privacy either. After all, the service provider has access to call meta data since they have access to SDP and know the identity of the parties involved in the communication.

Even though the objective of your post, it is time we critically analyze the root causes IP address “leak”. WebRTC ensures that user permission is obtained when a server tries to access to mic and camera; but does not worry about Data connection. I don’t think there is a valid reason, except that it is an oversight. Furthermore, WebRTC has modified the original ICE protocol to Trickle ICE. Given Trickle ICE, it may be better to change the order of connectivity check procedure to try relay address (as some do), then try reflexive addresses and finally exchange local addresses only if that will work.

Granted that some NATs will not be able to hairpin a connection between two local hosts. To handle these cases, the browser and the app can ask permission from the user to exchange local addresses.