[libnice] TCP Passive Ice Candidate Connectivity Issue

Olivier Crête olivier.crete at collabora.com
Wed Jun 22 13:12:20 UTC 2016


Hi,
Did you make any substantive change? or is that only a debugging
statement?
On Tue, 2016-06-21 at 16:14 -0700, James Huang wrote:
> oh the nice_tcp_active_socket_connect issue is a logging mistake. 
> I put the statement right before the
> nice_tcp_bsd_socket_new_from_gsock() call and it works now 
> 
> 
> On Tue, Jun 21, 2016 at 3:51 PM, James Huang <hng.jms at gmail.com>
> wrote:
> > Hi all,
> > 
> > I'm trying to get an openwebrtc iphone-to-iphone stream working,
> > and it uses libnice as the underlying connectivity manager. It's
> > running on the 1.13 release, but there have been about 14+ months
> > of bug fixes to the master branch so I've updated to the latest
> > version. 
> > 
> > I'm getting the following messages when I try to establish a
> > connection.
> > 
> > > ICE failed to establish a connection!
> > > ICE state changed from connecting to failed
> > 
> > This is a dump of my logs with NICE_DEBUG turned on. 
> > http://pastebin.com/vQtmk4hX
> > 
> > 
> > An example below: 
> > 
> > > With the following ICE candidates
> > > -----------------------offer sdp-----------------------
> > > a=candidate:1 1 UDP 2013266431 192.168.1.27 53302 typ host
> > > a=candidate:2 1 TCP 1019216639 192.168.1.27 0 typ host tcptype
> > > active
> > > a=candidate:3 1 TCP 1015022335 192.168.1.27 55855 typ host
> > > tcptype passive
> > > -----------------------answer sdp-----------------------
> > > a=candidate:1 1 UDP 2013266431 192.168.1.245 65305 typ host
> > > a=candidate:2 1 TCP 1019216383 192.168.1.245 0 typ host tcptype
> > > active
> > > a=candidate:3 1 TCP 1015022079 192.168.1.245 52295 typ host
> > > tcptype passive
> > 
> > 
> > I'm getting a TCP handshake over the tcp-passive port 55855/52295,
> > which triggers some code in agent.c:
> > > /* Passive candidates when readable should accept and create a
> > > new
> > >          * socket. When established, the connchecks will create a
> > > peer reflexive
> > >          * candidate for it */
> > > new_socket = nice_tcp_passive_socket_accept (nicesock);
> > 
> > But that seems to be out-of-band data or something according to the
> > return value?
> > 
> > But it seems like a new connectivity check never happens and the
> > pair times out. I also don't fully understand what the comment
> > means.
> > 
> > When I run the linux-linux version it appears 
> > conncheck.c conn_check_handle_inbound_stun-
> > >priv_reply_to_conn_check() 
> > gets called, and everything works fine but on the iphone it does
> > not. 
> > 
> > I've removed STUN and TURN servers and have been running 2 phones
> > off of the same wifi just to simplify the connection paths, but
> > I've also tried adding in STUN servers. 
> > 
> > This pull request problem (https://github.com/libnice/libnice/pull/
> > 6) seems suspiciously like my issue except that particular code
> > path never executes for me. I've added it in anyways just to be
> > safe. 
> > 
> > Oh, the other thing that I've seen is the only call
> > to nice_tcp_active_socket_connect is to seemingly garbage src/dst
> > ip:port numbers like:
> > > [<unknown>]:903479824 -> [(null)]:1336121346 
> > it's unclear to me right now when/where they turn into garbage . 
> > 
> > Anyways, I'm a little lost and not sure what to investigate. But
> > I'm happy to add extra logging to figure this thing out. Any advice
> > would be appreciated. 
> > 
> > 
> > 
> > 
> 
> _______________________________________________
> nice mailing list
> nice at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/nice
-- 
Olivier Crête
olivier.crete at collabora.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/nice/attachments/20160622/24e31b41/attachment.html>


More information about the nice mailing list