On 6 Mar 2017, at 15:28, Holger Freyther holger@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