Byron, Thank you!!! You are right. You point the point, USE-CANDIDATE. In
WebRTC, it doesn't check USE-CANDIDATE flag when receiving a binding request.
If I add this check when receiving any binding request, and then this issue is
fixed!!!
Thank you very much!!! And here is what I modified. Thanks everybody in this
stream, Thanks!
--- a/talk/p2p/base/p2ptransportchannel.cc
+++ b/talk/p2p/base/p2ptransportchannel.cc
@@ -554,6 +554,12 @@ void P2PTransportChannel::OnUnknownAddress(
AddConnection(connection);
connection->ReceivedPing();
+ // Check USE-CANDIDATE flag
+ const StunByteStringAttribute* use_candidate_attr =
+ stun_msg->GetByteString(STUN_ATTR_USE_CANDIDATE);
+ if (use_candidate_attr)
+ connection->SignalUseCandidate(connection);
+
// Send the pinger a successful stun response.
port->SendBindingResponse(stun_msg, address);
On Wednesday, November 19, 2014 3:00:31 AM UTC+8, Byron Campen wrote:
> Hmm, this sounds like a bug in Chrome. Perhaps it is ignoring the
> USE-CANDIDATE flag in STUN requests from an unknown tuple? What Chrome
> should be doing in this case is forming a new candidate pair and
> scheduling it (https://tools.ietf.org/html/rfc5245#section-7.2.1.4), and
> then checking to see whether USE-CANDIDATE was set and setting the
> nominated flag if so
> (https://tools.ietf.org/html/rfc5245#section-7.2.1.5). It should not
> need a second STUN request on that pair to perform these steps.
>
> Best regards,
> Byron Campen
>
> On 11/18/14 5:39 AM, [email protected] wrote:
> > 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
_______________________________________________
dev-media mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-media
