libnice issueshttps://gitlab.freedesktop.org/libnice/libnice/-/issues2020-11-18T10:08:43Zhttps://gitlab.freedesktop.org/libnice/libnice/-/issues/17Eliminate NiceSocket in favour of GDatagramBased2020-11-18T10:08:43ZPhilip WithnallEliminate NiceSocket in favour of GDatagramBased## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#3318)](https://phabricator.freedesktop.org/T3318)**
## Description
With [`GDatagramBased`](https://bugzilla.gnome....## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#3318)](https://phabricator.freedesktop.org/T3318)**
## Description
With [`GDatagramBased`](https://bugzilla.gnome.org/show_bug.cgi?id=697907) we can now abstract socket interfaces (as long as they are datagram based, rather than stream-based). `NiceSocket` and its ill-defined and non-standard semantics and non-`GObject`-ness can go.
This should also make the socket implementations more generally reusable outside libnice.
Finally, if libnice internally starts using `GDatagramBased` for handling all its underlying sockets, it allows the possibility of creating a mock socket object for unit testing, which could eventually allow testing of complex network situations without the need to physically reproduce them. Regression tests for ICE!https://gitlab.freedesktop.org/libnice/libnice/-/issues/15libnice overly generic <agent.h>2020-11-18T14:53:13ZPhilip Withnalllibnice overly generic <agent.h>## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#113)](https://phabricator.freedesktop.org/T113)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop...## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#113)](https://phabricator.freedesktop.org/T113)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90013)
libnice stores its headers in e.g. /usr/include/nice/ but 'pkg-config --cflags nice'
gives '-D_REENTRANT -I/usr/include/nice' meaning a generic-named header should as agent.h, debug.h or interfaces.h is includable as:
#include <agent.h>
#include <debug.h>
#include <interfaces.h>
Moreover, the include-guard used in e.g. agent.h:
#ifndef _AGENT_H
#define _AGENT_H
is overly generic as well, and risks collision with other packages.https://gitlab.freedesktop.org/libnice/libnice/-/issues/14nice_agent_attach_recv with NULL callback results in endless loop2020-11-18T14:53:13ZPhilip Withnallnice_agent_attach_recv with NULL callback results in endless loop## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#112)](https://phabricator.freedesktop.org/T112)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop...## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#112)](https://phabricator.freedesktop.org/T112)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89841)
nice_agent_attach_recv(agent, stream_id, component, context, NULL, data) results in libnice repeatedly and endlessly entering component_io_cb (in a busy loop).
I suspect this is due to the fact that if neither a callback is registered nor recv_messages is pending, messages are never read from the socket, and somehow the notification keeps coming again and again (why?).https://gitlab.freedesktop.org/libnice/libnice/-/issues/13Add nice_agent_remove_stream_async() for PseudoTCP fin-ack completion2020-11-18T14:53:13ZPhilip WithnallAdd nice_agent_remove_stream_async() for PseudoTCP fin-ack completion## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#110)](https://phabricator.freedesktop.org/T110)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop...## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#110)](https://phabricator.freedesktop.org/T110)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85640)
Currently, there’s a nice race in component_close(), between pseudo_tcp_socket_close() (which sends the first packet in the TCP FIN handshake), and freeing all the agent’s candidates (and hence closing their underlying sockets).
The only way to reliably fix that is to make pseudo_tcp_socket_close() block on completing the handshake, or timing out. But blocking for that long would be terrible, so the solution also has to involve making component_close() and all of its callers, all the way up to nice_agent_remove_stream(), asynchronous, a la g_io_stream_close_async().
See the mailing list thread: http://lists.freedesktop.org/archives/nice/2014-October/000979.html
And the FIXME commit: http://cgit.freedesktop.org/libnice/libnice/commit/?id=88cd37a4ffbe4bc623eda2c0ac01565d467976f3https://gitlab.freedesktop.org/libnice/libnice/-/issues/11Add support for name resolution of servers2021-12-06T09:16:14ZPhilip WithnallAdd support for name resolution of servers## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#108)](https://phabricator.freedesktop.org/T108)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop...## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#108)](https://phabricator.freedesktop.org/T108)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85222)
STUN servers could be provided as a DNS name by other APIs (e.g. WebRTC), but libnice currently only accepts numeric server names. It would be great if libnice could do the DNS resolution, which probably requires adding some async API around GResolver for this. Otherwise every application has to do that themselves.0.1.18https://gitlab.freedesktop.org/libnice/libnice/-/issues/10Add API to specify multiple STUN servers2022-10-12T18:16:42ZPhilip WithnallAdd API to specify multiple STUN servers## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#107)](https://phabricator.freedesktop.org/T107)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop...## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#107)](https://phabricator.freedesktop.org/T107)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85221)
WebRTC supports this and it can be useful if one or more of the possible servers are too busy every now and then, or not working, or if there are geographic restrictions for some servers.0.1.18https://gitlab.freedesktop.org/libnice/libnice/-/issues/9Add async wrapper around nice_agent_gather_candidates()2021-12-06T09:16:13ZPhilip WithnallAdd async wrapper around nice_agent_gather_candidates()## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#106)](https://phabricator.freedesktop.org/T106)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop...## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#106)](https://phabricator.freedesktop.org/T106)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84187)
[0001-agent-Add-an-asychronous-version-of-nice_agent_gathe.patch](/uploads/18311b6411e741620377d84086942a9e/0001-agent-Add-an-asychronous-version-of-nice_agent_gathe.patch)
agent: Add an asychronous version of nice_agent_gather_candidates()
WIP patch attached to add a GIO-style asynchronous wrapper around the libnice candidate gathering and connection establishment process.
This does everything from nice_agent_gather_candidates() through to adding remote candidates and TURN servers, and establishing a TCP or UDP connection, at which point the asynchronous task completes.
It does not handle emitting local candidates or adding remote candidates (though it has API which must be notified when the final remote candidate has been added to the NiceAgent). It also does not handle local or remote credentials.
I wonder if it would be a good idea to incorporate those into the API as callbacks (which would be guaranteed to be emitted in the GTask’s main context, to avoid the g_main_context_invoke() dance which we have to do internally).
For this reason, I’m declaring the API in this patch as a work in progress, and feedback would be greatly appreciated.
Basically I hope this new API can become the default all-in-one easy way to use libnice, and the existing API can be reserved for more advanced use cases.
http://cgit.collabora.com/git/user/pwith/libnice.git/log/?h=async-gather-candidates
There are a few comments about what work still needs to be done in the commit message. I don’t currently have time to finish this off, but it’s close — the biggest remaining task is unit testing. :-(https://gitlab.freedesktop.org/libnice/libnice/-/issues/8Signals being emitted from wrong thread2021-12-06T09:16:13ZPhilip WithnallSignals being emitted from wrong thread## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#103)](https://phabricator.freedesktop.org/T103)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop...## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#103)](https://phabricator.freedesktop.org/T103)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81917)
A new-local-candidate signal could be emitted from either the main thread (for local host candidates) or from the 'streaming' thread, if the nice_agent_attach_recv is attached on a different GMainContext than the main thread, and the local candidate is a server reflexive candidate.
Libnice would need to do the g_signal_emitv from the main context of the agent whenever this happens to ensure all signals are always sent from the same thread.https://gitlab.freedesktop.org/libnice/libnice/-/issues/7assert in test-icetcp2021-12-06T09:16:13ZPhilip Withnallassert in test-icetcp## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#102)](https://phabricator.freedesktop.org/T102)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop...## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#102)](https://phabricator.freedesktop.org/T102)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81691)
Asserts when running the test-icetcp sometimes.https://gitlab.freedesktop.org/libnice/libnice/-/issues/5Fix socket function naming2021-12-06T09:16:13ZPhilip WithnallFix socket function naming## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#98)](https://phabricator.freedesktop.org/T98)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop.o...## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#98)](https://phabricator.freedesktop.org/T98)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=75598)
nice_agent_send() is non-blocking, but nice_agent_recv() is blocking. The naming somehow needs to be reconciled.https://gitlab.freedesktop.org/libnice/libnice/-/issues/4Add API to set the SNDBUF and the RCVBUF2021-12-06T09:16:13ZPhilip WithnallAdd API to set the SNDBUF and the RCVBUF## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#97)](https://phabricator.freedesktop.org/T97)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop.o...## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#97)](https://phabricator.freedesktop.org/T97)**
## Description
(Migrated from Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=57420)
Currently, we're not able to set the SO_SNDBUF and the SO_RCVBUF, the defaults on Linux are amazing. But some lower platforms (iOS) aren't so amazing.
Branch to add API:
http://cgit.collabora.com/git/user/tester/libnice.git/log/?h=set-udp-sndrcvbufhttps://gitlab.freedesktop.org/libnice/libnice/-/issues/3XMPP/Jingle doesn't connect while using multiple networks on eth02021-12-06T09:16:13ZPhilip WithnallXMPP/Jingle doesn't connect while using multiple networks on eth0## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#96)](https://phabricator.freedesktop.org/T96)**
## Description
[Empathy.AudioVideo-16-05-11_20-39-17_EDITED.log](/...## Submitted by Philip Withnall `@pwithnall`
Assigned to **Philip Withnall `@pwithnall`**
**[Link to original bug (#96)](https://phabricator.freedesktop.org/T96)**
## Description
[Empathy.AudioVideo-16-05-11_20-39-17_EDITED.log](/uploads/91f6923c0d5d1a6d8fbfc5431043e86b/Empathy.AudioVideo-16-05-11_20-39-17_EDITED.log)
(MIgrated from Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=37269)
I experienced a strange behaviour of the Emapthy/Telepathy when trying to make an audio call over XMPP/Jingle. (More precisely, the call is initiated by the other part which is using the Psi XMPP client.) This worked fine until I configured my Laptop to have more networks hung on the eth0 interfaces (I used NetworkManager as provided by up-to-date Fedora 14: I Simply added in nm-applet > right-click-menu > Edit connections > Wired > [some connection] > IPv4 Settings > Adresses more IP / mask entries).
The reason for this setup was that I configured in this time some routers and similar devices which have they default adresses set-up mostly in the 192.168.0.0/24, 192.168.1.0/24 or 192.168.2.0/24 address space. The aim of setting up more addresses was not to have to switch between various NM profiles while configuring the routers etc.
Now with this setup the above mentioned call cannot be set up (It says something like "the connection cannot be established").
See attached ANONYMIZED log (Empathy -> Help -> Debug -> Empathy.AudioVideo). (192.168.*MY*.*IP* is the address seen from my LAN gateway)
I'm currently using the up-to-date telepathy/empathy packages from Fedora 14:
$ rpm -qa | grep pathy
telepathy-glib-0.11.16-1.fc14.i686
gnome-phone-manager-telepathy-0.65-9.fc14.i686
telepathy-haze-0.4.0-2.fc14.i686
telepathy-gabble-0.10.5-1.fc14.i686
telepathy-filesystem-0.0.2-1.fc12.noarch
telepathy-logger-0.1.7-1.fc14.i686
python-telepathy-0.15.18-1.fc14.noarch
empathy-2.32.2-1.fc14.i686
telepathy-idle-0.1.7-1.fc14.i686
telepathy-farsight-0.0.14-2.fc14.i686
telepathy-stream-engine-0.5.11-1.fc12.i686
telepathy-sofiasip-0.6.6-1.fc14.i686
telepathy-mission-control-5.6.1-1.fc14.i686
telepathy-butterfly-0.5.14-1.fc14.noarch
telepathy-salut-0.4.0-1.fc14.i686https://gitlab.freedesktop.org/libnice/libnice/-/issues/36agent signal emission order is not preserved after agent unlock2018-06-05T18:56:34ZBugzilla Migration Useragent signal emission order is not preserved after agent unlock## Submitted by Fabrice Bellet `@bellet`
Assigned to **Fabrice Bellet `@bellet`**
**[Link to original bug (#7878)](https://phabricator.freedesktop.org/T7878)**
## Description
```
15:56:41.526769 (empathy:17512): libnice-DEBUG: A...## Submitted by Fabrice Bellet `@bellet`
Assigned to **Fabrice Bellet `@bellet`**
**[Link to original bug (#7878)](https://phabricator.freedesktop.org/T7878)**
## Description
```
15:56:41.526769 (empathy:17512): libnice-DEBUG: Agent 0x612001159240 : XXX agent_signal_new_candidate, 1/1 UDP TURN '9' [92.243.x.x]:63250
15:56:41.526824 (empathy:17512): libnice-DEBUG: Agent 0x612001159240 : XXX agent_queue_signal queuing sig 540 (qlen=0)
15:56:41.526876 (empathy:17512): libnice-DEBUG: Agent 0x612001159240 : XXX agent_queue_signal queuing sig 534 (qlen=1)
15:56:41.526928 (empathy:17512): libnice-DEBUG: Agent 0x612001159240 : Adding new refresh candidate 0x632000150800 with timeout 540000
15:56:41.526980 (empathy:17512): libnice-DEBUG: timer source is : 0x60b0027b0cb0
15:56:41.527032 (empathy:17512): libnice-DEBUG: agent_recv_message_unlocked: Valid STUN packet received.
15:56:41.527100 (empathy:17512): libnice-DEBUG: agent_recv_message_unlocked: Agent 0x612001159240: no message available on read attempt
15:56:41.527152 (empathy:17512): libnice-DEBUG: component_io_cb: 0x612001159240: no message available on read attempt
15:56:41.527204 (empathy:17512): libnice-DEBUG: Agent 0x612001159240 : XXX agent_unlock_and_emit emitting signal 540
15:56:41.527256 (empathy:17512): libnice-DEBUG: Agent 0x612001159240 : Candidate gathering FINISHED, stopping discovery timer.
15:56:41.527308 (empathy:17512): libnice-DEBUG: Agent 0x612001159240: gathered UDP local candidate : [92.243.x.x]:63250 for s1/c1. U/P '(null)'/'(null)'
15:56:41.527369 (empathy:17512): libnice-DEBUG: Agent 0x612001159240: gathered UDP local candidate : [92.243.x.x]:63249 for s1/c2. U/P '(null)'/'(null)'
15:56:41.527468 (empathy:17512): libnice-DEBUG: Agent 0x612001159240 : XXX agent_signal_gathering_done
15:56:41.527572 (empathy:17512): libnice-DEBUG: Agent 0x612001159240 : XXX >> sid 1, gathering=1
15:56:41.527679 (empathy:17512): libnice-DEBUG: Agent 0x612001159240 : XXX agent_queue_signal queuing sig 532 (qlen=0)
15:56:41.527774 (empathy:17512): libnice-DEBUG: Agent 0x612001159240 : XXX agent_unlock_and_emit emitting signal 532
15:56:41.527834 (empathy:17512): libnice-DEBUG: Agent 0x612001159240 : XXX agent_unlock_and_emit emitting signal 534
```
We can see that the two signals for the local candidate of stream 1/component 1 are queued (sig 540, 534). Upon agent unlocking, the first one is emitted (540). Another thread running the discovery code queues the signal gathering-done (sig 532), and emits it before 534.
The signal queuing order is not preserved, because signals are emited after the agent lock has been released. This is somewhat unexpected. Even if, in this case, the supplementary local candidate is sent separately at a later time, altough it's been signalled _before_ the gathering-done signal.https://gitlab.freedesktop.org/libnice/libnice/-/issues/18ICE thread is constantly woken up for nothing2020-11-18T10:08:43ZBugzilla Migration UserICE thread is constantly woken up for nothing## Submitted by Joshua Roys `@roysjosh`
Assigned to **Joshua Roys `@roysjosh`**
**[Link to original bug (#3328)](https://phabricator.freedesktop.org/T3328)**
## Description
I started looking into https://github.com/meetecho/janus-...## Submitted by Joshua Roys `@roysjosh`
Assigned to **Joshua Roys `@roysjosh`**
**[Link to original bug (#3328)](https://phabricator.freedesktop.org/T3328)**
## Description
I started looking into https://github.com/meetecho/janus-gateway/issues/154 as it is fairly reproducible for me. Like the OP of that bug, janus-gateway's "ice thread" pegs a CPU core at 100% showing an eventfd being returned from a poll as having IO ready. When I saw that 0.1.4 did not show the bug and most recent versions did, I decided to do a git bisect on libnice. It narrowed down the commits that introduced this behavior to the following:
243c47ecc9d694ecfe230880081634936770a959
agent: Add nice_agent_recv() allowing blocking receives on sockets
c56727025dd1ffa2e0513bf6bfc5218b58e2b483
agent: Move GSource handling into Component
12ee430ef3dbe61e52fe1ace5196f1931cf1e2c4
agent: Fix format specifiers in debug messages
2b6370a87c34236e3996fb182751267e05ee11ac
agent: Support invoking I/O callbacks in non-default contexts
Please let me know if you need any more information to track this down.