[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