Like the prevision discussion, some candidates are added by STUN protocol (Binding Request). And that's the problem!!!
I trace the source code of WebRTC, and find the following behavior: 1. FF sends a binding request to the other WebRTC peer. 2. WebRTC peer will add this connection into candidates. (in P2PTransportChannel::OnUnknownAddress) 3. FF sends a binding request again. 4. WebRTC peer will set this connection is "best" (in P2PTransportChannel::OnUseCandidate) So WebRTC peer only sets the connection is "best" when receiving "binding request" if that connection is already in candidates. However, FF sends "binding request" once in sometime. This will lead WebRTC peer only add this connection to candidates, but will not select it. That's the cause of this issue. Does anyone know whey FF only sends "binding request" once in sometime? But sometime FF will sends it twice, or more. On Tuesday, November 18, 2014 1:53:47 AM UTC+8, Byron Campen wrote: > Yeah, this looks like Chrome, but this ICE behavior is the same > that you'll see in Firefox. If no candidates ever arrive from side A, > but a STUN check arrives from side A, side B will look at the source > port/addr and add it as a candidate (that's called a "peer reflexive" > candidate, and what the string "prflx" stands for in the candidate you > did not expect). > > Best regards, > Byron Campen > > On 11/17/14 9:23 AM, Nils Ohlmeier wrote: > > Hi Aslan, > > > > Neither the SDP nor the ICE candidates below are from Firefox. Firefox > > does not (yet) support Bundle or labels. > > Did you just send us the wrong debug output? > > > > Best > > Nils Ohlmeier > > > > On 11/17/14 3:27 AM, [email protected] wrote: > >> I find even the other peer doesn't receive candidates, it still can > >> make connection in sometime. Why? > >> > >> Here is SDP which FF sends to the device: > >> "v=0\r\no=- 8814186103337328720 2 IN IP4 127.0.0.1\r\ns=-\r\nt=0 > >> 0\r\na=group:BUNDLE audio video\r\na=msid-semantic: WMS > >> ARDAMS\r\nm=audio 1 RTP\/SAVPF 103 111 9 102 0 8 106 105 13 127 > >> 126\r\nc=IN IP4 0.0.0.0\r\na=rtcp:1 IN IP4 > >> 0.0.0.0\r\na=ice-ufrag:64BzBMsOxdK6Aelk\r\na=ice-pwd:1qTE1U0TLydIjilff2CJjQmB\r\na=ice-options:google-ice\r\na=fingerprint:sha-1 > >> > >> F8:DA:30:1B:8C:3E:5B:1C:82:2E:D5:65:64:60:64:D0:C8:8E:99:06\r\na=setup:actpass\r\na=mid:audio\r\na=extmap:1 > >> > >> urn:ietf:params:rtp-hdrext:ssrc-audio-level\r\na=extmap:3 > >> http:\/\/www.webrtc.org\/experiments\/rtp-hdrext\/abs-send-time\r\na=sendrecv\r\na=rtcp-mux\r\na=rtpmap:111 > >> > >> opus\/48000\/2\r\na=fmtp:111 minptime=10\r\na=rtpmap:103 > >> ISAC\/16000\r\na=rtpmap:9 G722\/16000\r\na=rtpmap:102 > >> ILBC\/8000\r\na=rtpmap:0 PCMU\/8000\r\na=rtpmap:8 > >> PCMA\/8000\r\na=rtpmap:106 CN\/32000\r\na=rtpmap:105 > >> CN\/16000\r\na=rtpmap:13 CN\/8000\r\na=rtpmap:127 > >> red\/8000\r\na=rtpmap:126 > >> telephone-event\/8000\r\na=maxptime:60\r\na=ssrc:120917423 cname:8c > > pG > >> 2axRBu\/+9r\/Z\r\na=ssrc:120917423 msid:ARDAMS > >> ARDAMSa0\r\na=ssrc:120917423 mslabel:ARDAMS\r\na=ssrc:120917423 > >> label:ARDAMSa0\r\nm=video 1 RTP\/SAVPF 98 96\r\nc=IN IP4 > >> 0.0.0.0\r\na=rtcp:1 IN IP4 > >> 0.0.0.0\r\na=ice-ufrag:64BzBMsOxdK6Aelk\r\na=ice-pwd:1qTE1U0TLydIjilff2CJjQmB\r\na=ice-options:google-ice\r\na=fingerprint:sha-1 > >> > >> F8:DA:30:1B:8C:3E:5B:1C:82:2E:D5:65:64:60:64:D0:C8:8E:99:06\r\na=setup:actpass\r\na=mid:video\r\na=extmap:2 > >> > >> urn:ietf:params:rtp-hdrext:toffset\r\na=extmap:3 > >> http:\/\/www.webrtc.org\/experiments\/rtp-hdrext\/abs-send-time\r\na=recvonly\r\na=rtcp-mux\r\na=rtpmap:98 > >> > >> H264\/90000\r\na=rtcp-fb:98 ccm fir\r\na=rtcp-fb:98 > >> nack\r\na=rtcp-fb:98 nack pli\r\na=rtcp-fb:98 > >> goog-remb\r\na=rtpmap:96 rtx\/90000\r\na=fmtp:96 apt=98\r\n" > >> > >> And also, the candidates which FF sends to the device: > >> {"id":"audio","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:1325399287 > >> > >> 1 udp 2122194687 10.0.1.57 60258 typ host generation > >> 0","label":0,"type":"candidate"} > >> {"id":"audio","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:1325399287 > >> > >> 2 udp 2122194687 10.0.1.57 60258 typ host generation > >> 0","label":0,"type":"candidate"} > >> {"id":"video","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:1325399287 > >> > >> 1 udp 2122194687 10.0.1.57 60258 typ host generation > >> 0","label":1,"type":"candidate"} > >> {"id":"video","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:1325399287 > >> > >> 2 udp 2122194687 10.0.1.57 60258 typ host generation > >> 0","label":1,"type":"candidate"} > >> {"id":"audio","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:8126471 > >> > >> 1 tcp 1518214911 10.0.1.57 60786 typ host tcptype passive generation > >> 0","label":0,"type":"candidate"} > >> {"id":"audio","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:8126471 > >> > >> 2 tcp 1518214911 10.0.1.57 60786 typ host tcptype passive generation > >> 0","label":0,"type":"candidate"} > >> {"id":"video","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:8126471 > >> > >> 1 tcp 1518214911 10.0.1.57 60786 typ host tcptype passive generation > >> 0","label":1,"type":"candidate"} > >> {"id":"video","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:8126471 > >> > >> 2 tcp 1518214911 10.0.1.57 60786 typ host tcptype passive generation > >> 0","label":1,"type":"candidate"} > >> {"id":"audio","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:208798335 > >> > >> 1 udp 1685987071 211.72.69.111 47994 typ srflx raddr 10.0.1.57 rport > >> 60258 generation 0","label":0,"type":"candidate"} > >> {"id":"audio","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:208798335 > >> > >> 2 udp 1685987071 211.72.69.111 47994 typ srflx raddr 10.0.1.57 rport > >> 60258 generation 0","label":0,"type":"candidate"} > >> {"id":"video","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:208798335 > >> > >> 1 udp 1685987071 211.72.69.111 47994 typ srflx raddr 10.0.1.57 rport > >> 60258 generation 0","label":1,"type":"candidate"} > >> {"id":"video","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:208798335 > >> > >> 2 udp 1685987071 211.72.69.111 47994 typ srflx raddr 10.0.1.57 rport > >> 60258 generation 0","label":1,"type":"candidate"} > >> {"id":"audio","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:2926477417 > >> > >> 1 udp 41819903 54.255.152.155 63818 typ relay raddr 211.72.69.111 > >> rport 47894 generation 0","label":0,"type":"candidate"} > >> {"id":"audio","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:2926477417 > >> > >> 2 udp 41819903 54.255.152.155 63818 typ relay raddr 211.72.69.111 > >> rport 47894 generation 0","label":0,"type":"candidate"} > >> {"id":"video","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:2926477417 > >> > >> 1 udp 41819903 54.255.152.155 63818 typ relay raddr 211.72.69.111 > >> rport 47894 generation 0","label":1,"type":"candidate"} > >> {"id":"video","app_conn_id":"cd84a1f7-4ebe-4afe-b265-5c588cffbbec","candidate":"candidate:2926477417 > >> > >> 2 udp 41819903 54.255.152.155 63818 typ relay raddr 211.72.69.111 > >> rport 47894 generation 0","label":1,"type":"candidate"} > >> > >> Finally, the device decides use the connection: > >> Conn[audio:q04sw+5i:1:0:local:udp:192.168.60.107:35856->AJEU5UPx:1:1853759231:prflx:udp:192.168.3.10:47354|CRWI|7961835276047629822|-] > >> > >> > >> > >> My question is why does the device know 192.168.3.10? What am I missing? > >> > >> On Wednesday, November 12, 2014 12:14:08 AM UTC+8, [email protected] > >> wrote: > >>> Hi, > >>> > >>> I found a strange problem on my side. I have a PC under Airport WiFi > >>> AP (but connected by wire), and try to use RTCPeerConnection to > >>> connect the other device. However, the ice status is changed as > >>> "connected", but I can't see any video on my FF. I also try to use > >>> about:webrtc to find the any clue.. Here is the output from > >>> about:webrtc > >>> > >>> PeerConnection:1415678254974000 (id=399 > >>> url=https://10.0.1.12:6666/html/index.html#) 11:58:41 GMT+0800 > >>> ICE statistics > >>> 1415678254974000 (id=399 > >>> url=https://10.0.1.12:6666/html/index.html#): stream1/audio > >>> Local candidate Remote candidate ICE State Priority > >>> Nominated Selected > >>> 10.0.1.25:59672/udp(host) 192.168.60.108:45308/udp(host) > >>> failed 9115038255643886000 > >>> 192.168.3.10:45673/udp(peerreflexive) > >>> 192.168.60.108:45308/udp(host) succeeded 7989386838416440000 > >>> * * > >>> 54.255.152.155:50652/udp(relayed-udp) > >>> 192.168.60.108:45308/udp(host) cancelled 423619839899090400 > >>> Local candidate addr Type > >>> 10.0.1.25:59672/udp host > >>> 211.72.69.111:44545/udp serverreflexive > >>> 54.255.152.155:50652/udp relayed-udp > >>> 192.168.3.10:43905/udp peerreflexive > >>> Remote candidate addr Type > >>> 192.168.60.108:45308/udp host > >>> 1415678254974000 (id=399 > >>> url=https://10.0.1.12:6666/html/index.html#): stream2/video > >>> Local candidate Remote candidate ICE State Priority > >>> Nominated Selected > >>> 10.0.1.25:59674/udp(host) 192.168.60.108:41818/udp(host) > >>> failed 9115038255643886000 > >>> 192.168.3.10:45673/udp(peerreflexive) > >>> 192.168.60.108:41818/udp(host) succeeded 7989386838416440000 > >>> * * > >>> 54.255.152.155:65349/udp(relayed-udp) > >>> 192.168.60.108:41818/udp(host) cancelled 423619839899090400 > >>> Local candidate addr Type > >>> 10.0.1.25:59674/udp host > >>> 211.72.69.111:46313/udp serverreflexive > >>> 54.255.152.155:65349/udp relayed-udp > >>> 192.168.3.10:45673/udp peerreflexive > >>> Remote candidate addr Type > >>> 192.168.60.108:41818/udp host > >>> > >>> Finally, FF decides to use 192.168.3.10:45673, and Turn Server is > >>> canceled. But I still can not see any video on my FF? Why? > >>> > >>> Does anyone know how to fix this issue? > >>> > >>> Thanks. > >> _______________________________________________ > >> dev-media mailing list > >> [email protected] > >> https://lists.mozilla.org/listinfo/dev-media > > > > > > _______________________________________________ > > dev-media mailing list > > [email protected] > > https://lists.mozilla.org/listinfo/dev-media _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
