Closed Bug 904811 Opened 6 years ago Closed 6 years ago

Making a desktop to fxandroid call using stun:stun.l.google.com:19302 fails establish an iceConnection

Categories

(Core :: WebRTC, defect)

defect
Not set

Tracking

()

RESOLVED INVALID

People

(Reporter: jsmith, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [WebRTC][android-webrtc-])

STR

1. Go to http://mysecondwebrtc.appspot.com/ on desktop firefox
2. Setup your camera/microphone on desktop
3. Go to http://mysecondwebrtc.appspot.com/ on fxandroid
4. Setup your camera/microphone on fxandroid
5. Register your remote client ID from fxandroid on desktop firefox

Expected

Call should establish between desktop firefox and fxandroid.

Actual

Call fails to establish. Checking the iceConnectionState on Desktop Firefox shows that the iceConnectionState was failed, implying that ICE failed to establish.

Note that this test app has worked fine in most cases to establish a call on fxandroid to fxandroid.
Questions:

1. Which version of Firefox?
2. What network configuration?
3. Does it fail desktop to desktop?
Also, please attach the SDP
(In reply to Eric Rescorla (:ekr) from comment #1)
> Questions:
> 
> 1. Which version of Firefox?

Nightly 8/13 Desktop Firefox 26

Nightly 8/13 FxAndroid 26

> 2. What network configuration?

Desktop Firefox is on the Mozilla network on ethernet.

FxAndroid is on 4G Data (point of comparison - we confirmed 4G PC calls are possible with fxandroid to fxandroid).

> 3. Does it fail desktop to desktop?

Nope.
Offer SDP

"v=0o=Mozilla-SIPUA-26.0a1 3120 0 IN IP4 0.0.0.0s=SIP Callt=0 0a=ice-ufrag:724e9d16a=ice-pwd:3eee8f6776ada80579613a6a44e78738a=fingerprint:sha-256 37:E8:F1:DE:37:A1:A4:1F:8B:91:1B:F8:1F:9D:79:B2:90:C0:63:D3:39:16:11:F9:A2:2B:10:3D:CA:64:55:D4m=video 33070 RTP/SAVPF 120c=IN IP4 63.245.220.240a=rtpmap:120 VP8/90000a=sendrecva=candidate:0 1 UDP 2111832319 10.250.6.18 59271 typ hosta=candidate:1 1 UDP 1692467199 63.245.220.240 33070 typ srflx raddr 10.250.6.18 rport 59271a=candidate:2 1 UDP 2111701247 10.250.4.213 59272 typ hosta=candidate:3 1 UDP 1692336127 63.245.220.240 55770 typ srflx raddr 10.250.4.213 rport 59272a=candidate:4 1 UDP 2111766783 192.168.56.1 59273 typ hosta=candidate:0 2 UDP 2111832318 10.250.6.18 59274 typ hosta=candidate:1 2 UDP 1692467198 63.245.220.240 50438 typ srflx raddr 10.250.6.18 rport 59274a=candidate:2 2 UDP 2111701246 10.250.4.213 59275 typ hosta=candidate:3 2 UDP 1692336126 63.245.220.240 54933 typ srflx raddr 10.250.4.213 rport 59275a=candidate:4 2 UDP 2111766782 192.168.56.1 59276 typ hosta=rtcp-fb:* nacka=rtcp-fb:* ccm firm=application 32777 DTLS/SCTP 5000 c=IN IP4 63.245.220.240a=fmtp:5000 protocol=webrtc-datachannel;streams=16a=sendrecva=candidate:0 1 UDP 2111832319 10.250.6.18 59277 typ hosta=candidate:1 1 UDP 1692467199 63.245.220.240 32777 typ srflx raddr 10.250.6.18 rport 59277a=candidate:2 1 UDP 2111701247 10.250.4.213 59278 typ hosta=candidate:3 1 UDP 1692336127 63.245.220.240 42275 typ srflx raddr 10.250.4.213 rport 59278a=candidate:4 1 UDP 2111766783 192.168.56.1 59279 typ hosta=candidate:0 2 UDP 2111832318 10.250.6.18 59280 typ hosta=candidate:1 2 UDP 1692467198 63.245.220.240 41524 typ srflx raddr 10.250.6.18 rport 59280a=candidate:2 2 UDP 2111701246 10.250.4.213 59281 typ hosta=candidate:3 2 UDP 1692336126 63.245.220.240 60101 typ srflx raddr 10.250.4.213 rport 59281a=candidate:4 2 UDP 2111766782 192.168.56.1 59282 typ host"

Answer SDP

"v=0o=Mozilla-SIPUA-26.0a1 6048 0 IN IP4 0.0.0.0s=SIP Callt=0 0a=ice-ufrag:0d4af7d3a=ice-pwd:f4214084d697c249cc5c35b1694820a3a=fingerprint:sha-256 43:73:21:06:BC:21:CD:59:BE:FA:61:F0:EE:F9:57:8C:4B:56:16:3B:A1:45:DC:18:1A:F4:ED:8B:3B:33:A5:FAm=video 13426 RTP/SAVPF 120c=IN IP4 70.197.2.69a=rtpmap:120 VP8/90000a=sendrecva=candidate:0 1 UDP 2111832319 10.163.44.43 58291 typ hosta=candidate:1 1 UDP 1692467199 70.197.2.69 13426 typ srflx raddr 10.163.44.43 rport 58291a=candidate:0 2 UDP 2111832318 10.163.44.43 56528 typ hosta=candidate:1 2 UDP 1692467198 70.197.2.69 13429 typ srflx raddr 10.163.44.43 rport 56528a=rtcp-fb:* nacka=rtcp-fb:* ccm firm=application 13408 DTLS/SCTP 5001 c=IN IP4 70.197.2.69a=sendrecva=candidate:0 1 UDP 2111832319 10.163.44.43 35321 typ hosta=candidate:1 1 UDP 1692467199 70.197.2.69 13408 typ srflx raddr 10.163.44.43 rport 35321a=candidate:0 2 UDP 2111832318 10.163.44.43 34984 typ hosta=candidate:1 2 UDP 1692467198 70.197.2.69 13432 typ srflx raddr 10.163.44.43 rport 34984"
Whiteboard: [WebRTC]
Depends on: 904894
No longer depends on: 904894
Interestingly enough this only happens when the phone is on 4G, but the desktop machine is on wifi. When the phone is on wifi and desktop is on wifi, the call works.
Given that this is a developer-focused release and a path does exist to have a video/audio call on Android from desktop to android, we probably don't need to block on this.
Whiteboard: [WebRTC] → [WebRTC][android-webrtc-]
(In reply to Jason Smith [:jsmith] from comment #5)
> Interestingly enough this only happens when the phone is on 4G, but the
> desktop machine is on wifi. When the phone is on wifi and desktop is on
> wifi, the call works.

Crossing two separate NATs where both are symmetric, likely; TURN is probably required in this case.  The android 4G to 4G case may not be crossing the same NAT boundaries.
Invalid because mobile data to wifi will only work on TURN, not STUN.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.