[libnice] TCP Passive Ice Candidate Connectivity Issue

hng.jms at gmail.com hng.jms at gmail.com
Wed Jun 22 17:33:02 UTC 2016

No changes.

> On Jun 22, 2016, at 6:12 AM, Olivier CrĂȘte <olivier.crete at collabora.com> wrote:
> 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 53302 typ host
>>>> a=candidate:2 1 TCP 1019216639 0 typ host tcptype active
>>>> a=candidate:3 1 TCP 1015022335 55855 typ host tcptype passive
>>>> -----------------------answer sdp-----------------------
>>>> a=candidate:1 1 UDP 2013266431 65305 typ host
>>>> a=candidate:2 1 TCP 1019216383 0 typ host tcptype active
>>>> a=candidate:3 1 TCP 1015022079 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/5e3651c3/attachment.html>

More information about the nice mailing list