This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Holger Freyther holger at freyther.de> On 6 Mar 2017, at 15:28, Holger Freyther <holger at freyther.de> wrote: > Hi! > I was working on a manual testcase for DTMF handling.. and I am able to reproduce this now. Will analyze it now and then return to DTMF. I don't have a fix yet but a workaround. One can patch sofia-sip to not use the IP_RECVERR sockopt. Either patch it out or configure with an ac_... var to not enable the feature. Sofia SIP is using the IP_RECVERR socket option to understand if an error occurred on send (or after, e.g. ICMP unreachable). In my case I tried to the INVITE to 127.0.0._2_:5060 and the kernel knows that no one is there and enqueues an error. The error can only be read with recvmsg+MSG_ERRQUEUE. This happens in sofia-sip in tport_udp_error and is called by the tport_error_event function. Now to the issue. There are three ways to use sofia-sip: * Just call it to poll every X units of time (like LCR) * Implement the complex vtable for event loop integration * Integrate with glib to have the vtable thing work I had ruled out polling early (it wastes energy and has higher latency), and picked glib as it seemed easier to integrate than the abstraction of sofia-sip. After sofia-sip enables the IP_RECVERR option it is doing: events |= SU_WAIT_ERR; This is then registered with g_source_add_poll, e.g. like: 0xb7fd7573 in su_source_register (self=0x807d564, root=0x807d858, wait=0xbfffef2c, callback=0xb7f45fdd <tport_wakeup_pri>, arg=0x8081548, priority=0) at su_source.c:650 650 g_source_add_poll(self->sup_source, (GPollFD*)&self->sup_waits[n]); (gdb) p *(su_wait_t *) 0x8081860 $2 = {fd = 5, events = 9, revents = 0} so SU_WAIT_ERR is set.. but when glib is calling us: (gdb) p fds[2] $23 = {fd = 5, events = 1, revents = 0} I am currently figuring out where it is mapped and lost and will then try to find a conclusion for this. holger