Re: Turn Server doesn't work if PC is under Airport WiFi AP

Byron Campen Tue, 18 Nov 2014 11:00:51 -0800

Hmm, this sounds like a bug in Chrome. Perhaps it is ignoring theUSE-CANDIDATE flag in STUN requests from an unknown tuple? What Chromeshould be doing in this case is forming a new candidate pair andscheduling it (https://tools.ietf.org/html/rfc5245#section-7.2.1.4), andthen checking to see whether USE-CANDIDATE was set and setting thenominated flag if so(https://tools.ietf.org/html/rfc5245#section-7.2.1.5). It should notneed 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

Re: Turn Server doesn't work if PC is under Airport WiFi AP

Reply via email to