Chrome/STUN problem?

[PM]

Hi!

I was trying to establish without success a connection with a friend using the https://apprtc.appspot.com and both with chrome version 23.0.1271.95. We also tryed latest Canary version.

We where both using private home network connetions, so under NAT.

We've checked the chrome console logs and the ip addresses sound ok:

Creating PeerConnection. apprtc.appspot.com:193

Created RTCPeerConnnection with config: "{"iceServers":[{"url":"stun:stun.l.google.com:19302"}]}". apprtc.appspot.com:176

Adding local stream. apprtc.appspot.com:195

Sending answer to peer. apprtc.appspot.com:214

C->S: {"sdp":"v=0\r\no=- 566186304 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 0\r\na=group:BUNDLE audio video\r\nm=audio 1 RTP/SAVPF 103 104 0 8 126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4 0.0.0.0\r\na=ice-ufrag:xJNc8jWz3Dx6JHmc\r\na=ice-pwd:brGMw5LcJYEfKrYvIzILqd++\r\na=sendrecv\r\na=mid:audio\r\na=rtcp-mux\r\na=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9Og2/wOO0nR/lQK9ry/cU3S+ttsG+nX8D4/LkkbV\r\na=rtpmap:103 ISAC/16000\r\na=rtpmap:104 ISAC/32000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:126 telephone-event/8000\r\na=ssrc:3027229862 cname:iQ4ZbFyehuilQ59M\r\na=ssrc:3027229862 mslabel:IjmFr4ZtqT8Kduhyk0T5RGbxDWJHamHkYmmN\r\na=ssrc:3027229862 label:IjmFr4ZtqT8Kduhyk0T5RGbxDWJHamHkYmmN00\r\nm=video 1 RTP/SAVPF 100 101 102\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4 0.0.0.0\r\na=ice-ufrag:xJNc8jWz3Dx6JHmc\r\na=ice-pwd:brGMw5LcJYEfKrYvIzILqd++\r\na=sendrecv\r\na=mid:video\r\na=rtcp-mux\r\na=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:9Og2/wOO0nR/lQK9ry/cU3S+ttsG+nX8D4/LkkbV\r\na=rtpmap:100 VP8/90000\r\na=rtpmap:101 red/90000\r\na=rtpmap:102 ulpfec/90000\r\na=ssrc:2212198138 cname:iQ4ZbFyehuilQ59M\r\na=ssrc:2212198138 mslabel:IjmFr4ZtqT8Kduhyk0T5RGbxDWJHamHkYmmN\r\na=ssrc:2212198138 label:IjmFr4ZtqT8Kduhyk0T5RGbxDWJHamHkYmmN10\r\n","type":"answer"} apprtc.appspot.com:227

Remote stream added. apprtc.appspot.com:305

Session opened. apprtc.appspot.com:301

S->C: {"type":"candidate","label":0,"id":"audio","candidate":"a=candidate:2199032595 1 udp 2113937151 192.168.1.89 61605 typ host generation 0\r\n"} apprtc.appspot.com:261

S->C: {"type":"candidate","label":0,"id":"audio","candidate":"a=candidate:2199032595 2 udp 2113937151 192.168.1.89 61605 typ host generation 0\r\n"} apprtc.appspot.com:261

S->C: {"type":"candidate","label":1,"id":"video","candidate":"a=candidate:2199032595 1 udp 2113937151 192.168.1.89 61605 typ host generation 0\r\n"} apprtc.appspot.com:261

S->C: {"type":"candidate","label":1,"id":"video","candidate":"a=candidate:2199032595 2 udp 2113937151 192.168.1.89 61605 typ host generation 0\r\n"} apprtc.appspot.com:261

S->C: {"type":"candidate","label":0,"id":"audio","candidate":"a=candidate:1963125447 1 udp 1677729535 188.251.31.58 55331 typ srflx generation 0\r\n"} apprtc.appspot.com:261

S->C: {"type":"candidate","label":0,"id":"audio","candidate":"a=candidate:1963125447 2 udp 1677729535 188.251.31.58 55331 typ srflx generation 0\r\n"} apprtc.appspot.com:261

C->S: {"type":"candidate","label":0,"id":"audio","candidate":"a=candidate:1681997092 1 udp 2113937151 192.168.1.66 49542 typ host generation 0\r\n"} apprtc.appspot.com:227

C->S: {"type":"candidate","label":1,"id":"video","candidate":"a=candidate:1681997092 1 udp 2113937151 192.168.1.66 49542 typ host generation 0\r\n"} apprtc.appspot.com:227

C->S: {"type":"candidate","label":0,"id":"audio","candidate":"a=candidate:2454799600 1 udp 1677729535 82.155.122.200 64879 typ srflx generation 0\r\n"} apprtc.appspot.com:227

C->S: {"type":"candidate","label":1,"id":"video","candidate":"a=candidate:2454799600 1 udp 1677729535 82.155.122.200 64879 typ srflx generation 0\r\n"} apprtc.appspot.com:227

S->C: {"type":"candidate","label":1,"id":"video","candidate":"a=candidate:1963125447 2 udp 1677729535 188.251.31.58 55331 typ srflx generation 0\r\n"} apprtc.appspot.com:261

S->C: {"type":"candidate","label":1,"id":"video","candidate":"a=candidate:1963125447 1 udp 1677729535 188.251.31.58 55331 typ srflx generation 0\r\n"} apprtc.appspot.com:261

S->C: {"type":"candidate","label":1,"id":"video","candidate":"a=candidate:3448860643 1 tcp 1509957375 192.168.1.89 49536 typ host generation 0\r\n"} apprtc.appspot.com:261

S->C: {"type":"candidate","label":0,"id":"audio","candidate":"a=candidate:3448860643 1 tcp 1509957375 192.168.1.89 49536 typ host generation 0\r\n"} apprtc.appspot.com:261

C->S: {"type":"candidate","label":0,"id":"audio","candidate":"a=candidate:717406676 1 tcp 1509957375 192.168.1.66 55850 typ host generation 0\r\n"} apprtc.appspot.com:227

C->S: {"type":"candidate","label":1,"id":"video","candidate":"a=candidate:717406676 1 tcp 1509957375 192.168.1.66 55850 typ host generation 0\r\n"} apprtc.appspot.com:227

End of candidates. apprtc.appspot.com:293

S->C: {"type":"bye"} apprtc.appspot.com:261

Session terminated. apprtc.appspot.com:325

S->C: {"type":"bye"}

The only way we can communicate, is if at least one of us is using LTE internet adapter that generates public IP address, or if we both be in the same private network.

In the recent past with the Peerconnection00 implementation and older browser versions we where able to establish connection in private networks, but not now with the new implementation and browser.

What can it be the problem?

[Robert Ferenc]

Up, I noticed the same thing...   

[Warren McDonald]

Hi,

STUN reliability was increase dramatically for our tests when we set up a some local (Sydney AU, AWS instance) STUN servers and stopped relying on the sole Google address published. Also having more than one STUN server in the ICE Servers list also seemed to help. 

Including a TURN server sweetens the deal for the odd occurrence when STUN does not seem to work. On that point I have seen great variability in the fallback to TURN. In some instances, a connection working with STUN as Peer to Peer direct, would use TURN relay on the next page refresh, a few minutes later, it would be happy with STUN again. This make me think that it is some STUN server response threshold condition. So not whether it really needs TURN or not, but that it is unhappy with response from the only other ICE Server, so reverts to the TURN server. I would need more STUN server instances (and time) to test this theory.  :(

Warren   

[Justin Uberti]

STUN and TURN have been working properly for us when using AppRTC. The only times STUN has failed are when behind a NAT that is not compatible with STUN.

stun.l.google.com:19302 is deployed in many data centers worldwide, and should always be "close" to your location. I'm surprised that using your own STUN server changed things; I'd be interested to know what stun.l.google.com resolves to from your part of the world.

Right now TURN needs to be manually enabled in AppRTC, but we plan to roll out full automatic TURN support for AppRTC this month.

--
 

---
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Warren McDonald]

Hi Justin,

It currently resolves to 74.125.31.127 

From Sydney it routes via Tokyo with 144 ms response time. 

Warren