WebRTC on Android: Stability/STUN behaviour

[Enrico Sarradi]

Hi,

I've been playing around for a while with the Android native library and still haven't managed to get something "releasable" to the public.
I've mainly 2 concerns:


1. Which version is stable?

First of all, I observed VERY different results using different releases of the pre-compiled libraries.

http://mvnrepository.com/artifact/io.pristine/libjingle

After trying and retrying, I found that the 9702 release seemed to be the best one... Quite surprising, considering the latest precompiled binary is 11139...
From my experience, going any further than this, causes major pain in stability.


2. STUN Behaviour.
 I am unable to make it work on all network setups without the usage of TURN.
Let me clarify: using TURN it works, but if you pretend to use just STUN it doesn't.
I've tried and retried and it seems a problem of the inner implementation rather than STUN/TURN configuration. This is also confirmed by the latest AppRTCDemo

Network A - Network A: works
Network B - Network B: works
Network A - Network B: doesn't work
Network B - Network A: doesn't work
Network A - Internet Address: works
Internet Address - Network A: doesn't work
Network B - Internet Address: works
Internet Address - Network B: doesn't work


That would made sense if one of those Networks had problems contacting the STUN Server (which in fact is stun.l.google.com at 19302) but using https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ you can see the STUN server doing its job from both sides (translating IPs)...

I am a bit lost...

As I said, having a TURN server solves the problem... but you don't want to re-route ALL your traffic.

Any ideas?

[Istvan Fenesi]

It is not enough that both endpoints can connect to your STUN server.
STUN only helps to find the external address (IP:port) of the RTP endpoint.
Packets needs to find a way to bypass the NAT device to have RTP audio.
So, simply this means that your NAT is a little bit restrictive and the two endpoints cannot communicate directly with each other (regardless of the STUN success).

[Enrico Sarradi]

That's interesting... But what surprises me the most is that in some times communication works from A to B but not from B to A. In theory if certain ports are not available for just one client, the communication shouldn't be possible at all, am I right?

[Taylor Brandstetter]

You're right, the direction of offer/answer shouldn't matter for ICE. It affects which endpoint takes the ICE "controlling" role, but that only means a different endpoint decides the final successful candidate pair. It shouldn't affect the ordering or success rate of connectivity checks.

If you believe what you're seeing is an issue with the WebRTC stack, please file a bug with a native log. You can get this by calling "rtc::LogMessage::LogToDebug(rtc::LS_INFO)" in your app, or by using a debug build, and then filtering "libjingle" in logcat.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/5e2ac5f9-f60f-4f11-ae3d-1c4644227ccf%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.