Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

most time ICE candidate failed on 2 device difference network.(WIFI n 4G) #59

Open
xelven opened this issue Feb 20, 2016 · 7 comments
Open

Comments

@xelven
Copy link

xelven commented Feb 20, 2016

Hi guys,
I got 2 question for the current ICE candidate flow design and the lib used.

First it is wired issue, when the network are same LAN or mobile network are fine, because there connect direct, but on difference network they will relay.
But is so wired when I generated Offer the 192.168.18.138 is my ip in LAN, and 116.226.127.167 is my public IP, and the 54.178.56.14 relay to IP in LAN 192.168.18.138?

sdp = "v=0
\no=- 1455866151015045000 1 IN IP4 127.0.0.1
\ns=-
\nt=0 0
\nm=audio 1 RTP/SAVPF 111 8 0
\nc=IN IP4 0.0.0.0
\na=rtcp-mux
\na=sendrecv
\na=rtpmap:111 OPUS/48000/2
\na=rtpmap:8 PCMA/8000
\na=rtpmap:0 PCMU/8000
\na=ice-ufrag:f8Yo
\na=ice-pwd:X0FxC4+LXWlcB23wVhWjaT
\na=candidate:1 1 UDP 2013266431 192.168.18.138 52356 typ host
\na=candidate:4 1 UDP 1677722111 116.226.127.167 52356 typ srflx raddr 192.168.18.138 rport 52356
\na=candidate:7 1 UDP 167772671 54.178.56.14 55246 typ relay raddr 192.168.18.138 rport 52356
\na=candidate:7 1 UDP 167772671 54.178.56.14 49222 typ relay raddr 192.168.18.138 rport 52356
\na=candidate:7 1 UDP 167772671 54.178.56.14 63946 typ relay raddr 192.168.18.138 rport 0
\na=candidate:7 1 UDP 167772671 54.178.56.14 52947 typ relay raddr 192.168.18.138 rport 0
\na=fingerprint:sha-256 7C:CB:98:73:65:12:10:A5:98:EE:DE:E6:56:4E:73:C2:6B:F4:D2:0F:4D:21:E6:AC:02:F6:3F:CB:2E:AD:2C:9C
\na=setup:actpass
\n";
        type = offer;
    };
}

the second question is at same environment 80% will got

2016-02-19 16:57:49.300 Picowork[1717:273256] socket status = 3
0:00:14.746520000 �[332m 1717�[00m 0x159d8068 �[31;01mERROR  �[00m �[00m          owrsession owr_session.c:765:_owr_session_emit_ice_state_changed:<OwrMediaSession@0x1629c0a0>�[00m Session 1, ICE failed to establish a connection!
ICE state changed from gathering to failed

or

owrsession owr_session.c:765:_owr_session_emit_ice_state_changed:<OwrMediaSession@0x1629c0a0>�[00m Session 1, ICE failed to establish a connection!
ICE state changed from connecting to failed

is there any call back let me notify to UI, cause the current UX are petty bad, when the state failed, rtc never connect or reconnect, the UI just hold on the Connecting always.

@stefanalund
Copy link
Contributor

There should be an API to listen for ICE events (and other errors), but it hasn't been implemented yet. @superdump @pererikb what would be the best way to expose these signals up to the Objective-C API?

@xelven
Copy link
Author

xelven commented Feb 21, 2016

@stefanalund thank u for your replay, I just found there have double 1.
anyway I think I found way out for my second question "the ICE State call back",
I made the code to add "component-state-changed" listener from "transport_agent->priv", now is works for me.

But for the first question I still need to take look, I think is wired.
please lets discuss on it.

@stefanalund
Copy link
Contributor

Can that be made in to a generic solution that can be exposed up to the Objective C API? Would be great with a ICEConnectionStateListener protocol or similar.

@xelven
Copy link
Author

xelven commented Feb 22, 2016

@stefanalund I think we should figure out what's wrong on ICE candidate relay or on TURN server first, let this lib more robust such as this issue it's should not be happened all the time,
then thinking about more details or api will better, what do your think.

@xelven
Copy link
Author

xelven commented Mar 4, 2016

there is really wired thing happened,

here is 2 candidate paired, seems everything is ok.
my iOS device connect Wi-Fi ip is 192.168.1.187 as CANDIDATE_TYPE_HOST are fine.
But the other iOS device connect 4G in other county,
the ip address seems 192.168.1.101, and then we paired with them 192.168.1.254, type are CANDIDATE_TYPE_PEER_REFLEXIVE ???

and then my device thinking has been connected start send source to Agent 0x16237000 : s1:1: sending 1 messages to [192.168.1.254]:58831

and they will never connected.

(<unknown>:251): libnice-CRITICAL **: file address.c: line 196 (nice_address_get_port): should not be reached
nice_remote_candidate No.1 NiceCandidateType: CANDIDATE_TYPE_HOST,NiceCandidateTransport: TRANSPORT_TYPE_UDP,addr: 192.168.1.101,port:51992, base_addr: H,base_port: 0,priority: 2013266431, stream_id: 1, component_id: 1,username: (null),password:(null), 
NO TURN
nice_remote_candidate No.2 NiceCandidateType: CANDIDATE_TYPE_PEER_REFLEXIVE,NiceCandidateTransport: TRANSPORT_TYPE_UDP,addr: 192.168.1.254,port:57972, base_addr: 192.168.1.254,base_port: 57972,priority: 1853824767, stream_id: 1, component_id: 1,username: (null),password:(null), 
NO TURN
nice_remote_candidate No.3 NiceCandidateType: CANDIDATE_TYPE_PEER_REFLEXIVE,NiceCandidateTransport: TRANSPORT_TYPE_TCP_ACTIVE,addr: 192.168.1.254,port:58831, base_addr: 192.168.1.254,base_port: 58831,priority: 1853824767, stream_id: 1, component_id: 1,username: (null),password:(null), 
NO TURN
local_candidate No.1 candidate_type: CANDIDATE_TYPE_HOST,component_type: COMPONENT_TYPE_RTP,foundation: 1,transport_type: TRANSPORT_TYPE_UDP,address: 192.168.1.101, port: 51992, priority: 2013266431,related_address: ,related_port:0

 the --- session 1 --- component_id 1 state is: connecting
2016-03-04 18:09:57.874 TestWebRTC[251:10257] in calling status changed text = connecting...
2016-03-04 18:09:57.883 TestWebRTC[251:10319] local_min_port = 40000, local_max_port = 65535


---

2016-03-04 18:09:57.889 TestWebRTC[251:10319] --------------on_new_selected_pair1---------------------
pair Local_Candidate No.0 NiceCandidateType: CANDIDATE_TYPE_HOST,NiceCandidateTransport: TRANSPORT_TYPE_TCP_PASSIVE,addr: 192.168.1.187,port: 55570,base_addr: 192.168.1.187,base_port: 55570,priority: 1015022079, stream_id: 1, component_id: 1,username: (null),password:(null), 
NO TURN
pair Remote_Candidate No.0 NiceCandidateType: CANDIDATE_TYPE_PEER_REFLEXIVE,NiceCandidateTransport: TRANSPORT_TYPE_TCP_ACTIVE,addr: 192.168.1.254,port:58831, base_addr: 192.168.1.254,base_port: 58831, priority: 1853824767, stream_id: 1, component_id: 1,username: (null),password:(null), 
NO TURN
2016-03-04 18:09:57.889 TestWebRTC[251:10319] -----------------------------------

@stefanalund
Copy link
Contributor

@alessandrod is looking in to this.

@ZTGeng
Copy link

ZTGeng commented Jul 15, 2016

I also got the same problem. My two Android devices in the different networks got ICE failure when they try to build video connection.

owr_session.c:555:_owr_session_emit_ice_state_changed: Session 1, ICE failed to establish a connection! ICE state changed from disconnected to failed

Any advice?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants