WebRTC Connection Problems [Question]

[Lars Bork]

Hello,

I have a question regarding WebRTC connections we were trying to establish recently.

We had three different parties at three different locations (e.g. one in Paris, one in Munich and one in Berlin) all using the same software.

We have a STUN and a TURN server for WAN connectivity.

But after all we couldn't solve this problem:

Paris was able to connect to Munich and Berlin.

Munich was able to connect to Paris, but couldn't connect to Berlin.

Berlin was able to connect to Paris, but couldn't connect to Munich.

So what could be reasons for the connection-problem between Munich and Berlin? Is there any possible explanation for this regarding NAT, or could this be a problem from our implementation?

From my understanding the TURN server should be able to solve this problem!

Thanks a lot and have nice day!

[Philipp Hancke]

What candidates are generated and added by each side?

See http://testrtc.com/webrtc-api-trace/ "Example #1 – My WebRTC app works locally but not on a different network!" for the list of things to look for.

--

---
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-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/fe9a7196-7dd6-4f15-b841-7d9f17b98b0c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Kaiduan Xie]

Lars,

Can you share the STUN/TURN configuration you used in the app particularly TRUN configuration? For one example

turns:turn01.uswest.xirsys.com:443?transport=tcp

/Kaiduan

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CADxkKiJ1YnxGX2zvUh0OLEbGC8-Kv6_%2BSZbo0vra1Q9Bc95z0A%40mail.gmail.com.

[shakeeb nazmus]

TURN Server may be working fine for Paris but is not working properly for Munich and Berlin.

WebRTC can establish call properly if TURN works for one side only. You can verify if TURN is working properly by anyone the following ways 

1. Seeing offering candidate from chrome://webrtc-internals/. If there is no relay candidate in the offering SDP then TURN is not working for the client 

2. Verifying WebRTC log.

3. Verifying TURN message from Wireshark capture.  

   

It may be possible that TURN is not at all working for you and  Paris to Munich and Paris to Berlin calls were established P2P.

If you can provide the log 1,2 and 3 then it is possible to pinpoint the issue.

Thanks,  

Shakeeb

[Lars Bork]

Thanks for your help, I really appreciate that!

I am using the native iOS and Android SDK, so I won't be able to use chrome://webrtc-internals/ but I will try to NSLog to ICECandiates instead.

I will let you know what I find out.

[Lars Bork]

Ok, so what I found out is the following:

Normal ICE candidates can be received from the TURN server and look like this:

candidate:1172136001 1 udp 41754367 172.42.42.205 59148 typ relay raddr 80.42.42.136 rport 20197 generation 0 ufrag whh0 network-id 4 network-cost 900

So in general I can say, that our TURN server is working and is reachable. I also confirmed this by using this tool: https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

But sometimes it happens that only local candidates are being generated (not even STUN):

candidate:2922735942 1 udp 2122262783 2a01:4242:4242:4242:4242:fa06:40cd:bc82 54290 typ host generation 0 ufrag q0hO network-id 4 network-cost 900

candidate:1362691580 1 udp 2122194687 10.42.42.72 56253 typ host generation 0 ufrag q0hO network-id 3 network-cost 900

Do you know why this could happen? Why do I only receive local candidates sometimes?

Am Freitag, 27. Januar 2017 07:27:02 UTC+1 schrieb shakeeb nazmus:

[Philipp Hancke]

2017-01-27 11:08 GMT+01:00 Lars Bork <polarapps...@gmail.com>:

Ok, so what I found out is the following:

Normal ICE candidates can be received from the TURN server and look like this:

candidate:1172136001 1 udp 41754367 172.42.42.205 59148 typ relay raddr 80.42.42.136 rport 20197 generation 0 ufrag whh0 network-id 4 network-cost 900

That is a candidate gathered via UDP.

 

So in general I can say, that our TURN server is working and is reachable. I also confirmed this by using this tool: https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

But sometimes it happens that only local candidates are being generated (not even STUN):

candidate:2922735942 1 udp 2122262783 2a01:4242:4242:4242:4242:fa06:40cd:bc82 54290 typ host generation 0 ufrag q0hO network-id 4 network-cost 900

candidate:1362691580 1 udp 2122194687 10.42.42.72 56253 typ host generation 0 ufrag q0hO network-id 3 network-cost 900

Do you know why this could happen? Why do I only receive local candidates sometimes?

Some networks block UDP. Configure TURN/TCP and TURN/TLS in addition to UDP.

 

Am Freitag, 27. Januar 2017 07:27:02 UTC+1 schrieb shakeeb nazmus:

TURN Server may be working fine for Paris but is not working properly for Munich and Berlin.

WebRTC can establish call properly if TURN works for one side only. You can verify if TURN is working properly by anyone the following ways 

1. Seeing offering candidate from chrome://webrtc-internals/. If there is no relay candidate in the offering SDP then TURN is not working for the client 

2. Verifying WebRTC log.

3. Verifying TURN message from Wireshark capture.  

   

It may be possible that TURN is not at all working for you and  Paris to Munich and Paris to Berlin calls were established P2P.

If you can provide the log 1,2 and 3 then it is possible to pinpoint the issue.

Thanks,  

Shakeeb

On Wednesday, January 25, 2017 at 10:40:03 PM UTC+8, Lars Bork wrote:

Hello,

I have a question regarding WebRTC connections we were trying to establish recently.

We had three different parties at three different locations (e.g. one in Paris, one in Munich and one in Berlin) all using the same software.

We have a STUN and a TURN server for WAN connectivity.

But after all we couldn't solve this problem:

Paris was able to connect to Munich and Berlin.

Munich was able to connect to Paris, but couldn't connect to Berlin.

Berlin was able to connect to Paris, but couldn't connect to Munich.

So what could be reasons for the connection-problem between Munich and Berlin? Is there any possible explanation for this regarding NAT, or could this be a problem from our implementation?

From my understanding the TURN server should be able to solve this problem!

Thanks a lot and have nice day!

--

---
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-webrtc+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/6d13599d-2121-4352-855c-50d33e024cc8%40googlegroups.com.

[Lars Bork]

Hi Philipp,

how can I test if my TURN server supports TCP? I think that it is capable to do so, but how can I verify this? Do I need to block UDP manually on my network to get the TCP candidates?

Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Philipp Hancke]

2017-01-27 11:27 GMT+01:00 Lars Bork <polarapps...@gmail.com>:

Hi Philipp,

how can I test if my TURN server supports TCP? I think that it is capable to do so, but how can I verify this? Do I need to block UDP manually on my network to get the TCP candidates?

The trickle-ice test page can do that. You don't configure a STUN or TURN/UDP server but just one with an url like

   turn:some.host:12345?transport=tcp

or

   turns:some.host:12345?transport=tcp

(for TURN/TLS)

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/8a71a8ee-3eec-49a4-b67c-4ae0cf016d66%40googlegroups.com.