Unexpected timeouts on canceled connecting call

[Koshub]

Hello. I am using baresip v 1.0.0 as a library (on iOS so with kqueue). My use cases require to stop baresip main loop and restart when required. I have found the edge case when on finishing the call which is trying to connect and trying to shut down baresip completely I have some delay which may take about up to 20 seconds or so. So the next call I can start only after the main loop finished and I start the new one. The sequence is something like this:

• start baresip main loop
• ua_connect
• the call is trying to connect
• ua_hangup
• ua_stop_all(0) inside mqueue callback
• here I get a long delay until re_main returns

I do not get a delay in case the call was connected and then finished using ua_hangup. So probably there are some issues only when a call can not be connected and start waiting for something to happen.

Are there any timeout settings or so?

[alfredh]

the re_main loop will process N filedescriptors, and the timeout is the shortest time for all timers.
if the number of filescriptors is zero, the re_main will block forever.

it is important that the FD set is updated from the same threads as the re_main loop,
i.e. via fd_listen handler or timer handler. otherwise the FD set will not be updated.

in the past I have used mqueue to execute code in the context of the re_main loop thread.
you can send a dummy event via mqueue to "wakeup" the re_main thread.

PS: the general advice is to have one thread running re_main loop all the time.
it will sleep when there is nothing to do.
It is not an advice to keep starting/stopping the re_main thread.

[Koshub]

@alfredh thank you for your reply. I use one thread to run re_main. I also use mqueue to run ua_stop_all(0) inside that thread. So it should work. And it works as expected when the call is normally operated - connected, answered, closed. But in case the call can't connect it waits and after I send ua_stop_all(0) re_main does nothing until some event. That event is just emitted by some logic after a too long time. So what I am trying to find out is what exactly that event is and how to reduces its timeout. I know about the inability to connect is that the other part is set behind a firewall. So probably this is some edge case and in this case there is some delay that does not appear in usual scenarios.

Do you have any ideas what could cause this behavior? Or should it be enough to send some dummy event after ua_stop_all(0)?

[Koshub]

@alfredh BTW. This issue was transferred to baresip-ios. This is not specific for iOS, it is about integration with OS. I suppose you may find the same issue on any system which uses kqueue because re_main just stucks in fd_pull waiting for kevent in the use case I described above.

[sreimers]

kqueue because re_main just stucks in fd_pull

this is at first the normal behavior, fd_poll waits for a event by a file descriptor or until the next timer expires. Is there a difference if you force ua_stop_all with ua_stop_all(true)?

[Koshub]

@sreimers Sorry for the delay in the answer. And again thanks for support. It's really hard to test to understand the truth. It sounds like ua_stop_all(1) makes things more delayed. But I am not sure.

this is at first the normal behavior, fd_poll waits for a event by a file descriptor or until the next timer expires

I understand that. I have just found some configuration here:

enum {	SIP_T1 =  500,	SIP_T2 = 4000,	SIP_T4 = 5000,};

Is it possible timers using these values could work too long to fire appropriate events (say, here) ? Could I configure re_main exit timeout using these values or it is better to leave them as is?

[alfredh]

can you try to debug the timers and see which timers are active when this happens ?

please note that when the SIP register client is unregistering, it will wait for 200 ok
from the server. if the response does not arrive, at will timeout after N seconds.

my advice is to add lot of debug printf and try to see where the delay comes from :)