osmo-sip-connector in bad state

[Holger Freyther]

> 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