[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 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/5e3651c3/attachment.html>
More information about the nice
mailing list