Strange behavior with reflexive connectivity/srflx candidates

[silkroadnomad]

I replaced my libjingle library last weekend with the WebRTC-iOS pod. Because old libjingle had a strange issue with very slow and freezing remote video to any peer. (poor remote video quality - the send out video and audio was clear and fluent). Additionally I had (kind of) the same problem which did not disappear (only on iOS):

I made following observations which not just currently drive/drove me a bit crazy.

I have 2 different networks: Network A (a home router) results on the webrtc test (https://test.webrtc.org/) completely "green" which means reflexive and relay candidates work here and a Network B (in a coworking space and right now in the café) this test fails in reflexive connectivity

Also I work with Kurento Media Server on a server in the Internet which acts itself as media router (so no direct data between my video/audio endpoints - Kurento send receives candidates itself)

When I disable my turn server the following happens:

1. My Android and Browser (Firefox, Chrome) WebRTC clients still work perfectly in the same network (without reflexive connectivity) and it doesn't seem to use relay/turn at all. Clear video and audio.
2. my iOS Phone can't establishe a connection to another phone nor webrowser in the same network but can interoperate with devices which come from networks which have a working reflexive connectivity.

I'd kindly ask you, if anybody of you could do any tests regarding to calling from and into networks which "do not support" srflx candidates (reflexive connectivity) and what your observations are regarding to that. Or if that all works for you and was never a problem for you.

[silkroadnomad]

sorry, I have to correct my observation. Since turning of the turn server results also to a not working android and webbrowser configuration. So everything seems to be correct. I just was thinking STUN works also over TCP and not just over UDP. So STUN-UDP Packages should be able to received. (but it doesn't seem so) I am closing this issue since its not related to my question. I apologize for the disturbance. Also video over TURN seems now on iOS much more fluent then before. But it still seems to have a longer delay then the video on Android. (for what ever reason)

[gunjot-mansa]

I see, this issue is closed. It is weird, but i have found kind of a similar scenario. When i connect my iOS with my 4g network, it needs a TURN server, and in absence of a TURN server it fails to deliver or receive remote stream (Although, it receives Remote Stream, but it never make it to Screen - Shows Black Screen).

And now, if i do the same test while using same 4g network with my android device or My Desktop Browser (Mozilla/Chrome), it works fine, without providing any TURN server.

Now, i understand that 3g/4g network works behind NAT and most need TURN server to relay the connection. But why same network - doesn't need TURN for android but doesn't work without TURN in iOS.

Kind of disturbing!

[silkroadnomad]

Yes, it could be that your mobile phone provider does not allow peer2peer connections in general. You should check this. Especially if its only from the mobile network it does not work. Which country / mobile provider are you? Checkout also http://test.webrtc.org if its all green from your mobile it must (should) work. if reflexive connectivity (stun) does not work it always uses TURN as fallback.

N.

Am 19.10.2016 um 07:41 schrieb gunjotSinghMansa notifications@github.com:

I see, this issue is closed. It is weird, but i have found kind of a similar scenario. When i connect my iOS with my 4g network, it needs a TURN server, and in absence of a TURN server fails to deliver or receive remote stream (Although, it receives Remote Stream, but it never make it to Screen - Shows Black Screen).

And now, if i do the same with my android device or My Desktop Browser (Mozilla/Chrome), it works fine, without providing any TURN server.

Kind of disturbing!

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Anakros/WebRTC/issues/9#issuecomment-254715485, or mute the thread https://github.com/notifications/unsubscribe-auth/AART4lJWfzett8NI6-hKb57cdMvmmRUeks5q1a1ugaJpZM4KUlxw.

[gunjot-mansa]

The scenario i wanted to mention is:

If i use 4g connection with android, it doesn't need TURN to make a successful connection and streaming. Although, iOS needs TURN server with same 4g connection. I have checked this on Latest stable release of WebRTC.framework.

For android i have used this : webrtc-android, which is using ibjingle_peerconnection(I know it is outdated now)

I am from India using JIO 4g connection.

[silkroadnomad]

What does https://test.webrtc.org say from the mobile network say? Its quite important to me. Everything green? When I switch my turn server of in certain scenarios android can’t connect either. So first we should verify in which exact scenario. N.

P.S. If you use my implementation of it could be also a problem if my implementation and not of the webrtc framework, in that case we should continue the discussion on another place. I’d be happy to solve this issue with you together.

Am 19.10.2016 um 10:35 schrieb gunjotSinghMansa notifications@github.com:

The scenario i wanted to mention is:

If i use 4g connection with android, and it doesn't need TURN to make a successful connection and streaming. Although, iOS needs TURN server with same 4g connection. I have checked this on Latest stable release of WebRTC.framework.

I am from India using JIO 4g connection.

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/Anakros/WebRTC/issues/9#issuecomment-254749474, or mute the thread https://github.com/notifications/unsubscribe-auth/AART4oalhCqLgGzoDbamb02NhzVBP3_Sks5q1dZWgaJpZM4KUlxw.

[gunjot-mansa]

Yes, it shows issue in Reflexive connectivity - [ INFO ] Gathered candidate of Type: srflx Protocol: udp Address: 169.149.xxx.xx [ WARN ] Could not connect using reflexive candidates, likely due to the network environment/configuration.

P.S. Yes, I am using your implementation. Now, it is clear that Reflexive connection doesn't work here, So TURN server is required and i agree to that. But it is working in android without TURN- weird!

[silkroadnomad]

Are you 100% sure that its working on Android with a switched of Turn Server? Please double check! Because I was thinking the same for a long time! Maybe you have another configuration then I have? How does your ice configuration look like for ios, android and browser?

I thought its often that if one client can connect through stun, it can connect the the other too. (maybe kurento is doing some magic here) You using kurento right?

I found out Android nor the browsers (!) don't work either without TURN when reflexive connectivity (stun) is not working. (which is completely right!)

I am right now in a café in Barcelona where reflexive connection doesn’t work either. I switched of Turn…. absolutely nothing works! (no ios, no android, no browser)

Nico

Am 19.10.2016 um 11:05 schrieb gunjotSinghMansa notifications@github.com:

Yes, it shows issue in Reflexive connectivity - [ INFO ] Gathered candidate of Type: srflx Protocol: udp Address: 169.149.xxx.xx [ WARN ] Could not connect using reflexive candidates, likely due to the network environment/configuration.

P.S. Yes, I am using your implementation. Now, it is clear that Reflexive connection doesn't work here, So TURN server is required and i agree to that. But it is working in android without TURN- weird!

Nico Krause

Laptop/Landline: +49 8721 128 96 00-0 Mobile: +49 174 9 89 19 49

[gunjot-mansa]

I checked it in deep, and made sure no TURN server is in use for android.

Yes, i am using Kurento - and doing Many To Many Call with it. So connection is in between peer and kurento media server(which acts as peer) .

I will look more into it and will share ice configuration and my other findings.

Very thanks!!