> On 6 Mar 2017, at 15:28, Holger Freyther <[email protected]> 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
