I'm working on a Python wrapper for launching SIPp scenarios and ran into a weird issue when launching the default uac scen and providing an invalid remote address:

The following should expose the issue:

sipp 99.99.99.99:5060 -sn uac

You can now pass q to stdin twice before the curses ui stops updating. Passing q a 3rd time triggers a message similar to the following:

Last Error: Aborted call with Call-ID '23-20007@fe80::215:ff:fee3:e25c%w...

At this point the process does not respond to SIGUSR1 or any further qs passed to stdin. Passing the -timeout 1s arg seems to make no difference.

NOTE: if I pass -recv_timeout 100 (or any shorter ms value) the process does in fact terminate when signaled as expected but only after a timeout event has taken place. However, if I pass a longer value, say 10 secs -recv_timeout 10000, then the same problem can be triggered if type the 3 qs prior to the timeout of the first call attempt.

I attached with the debugger and found that the problem seems to do with the stat check here:
https://github.com/SIPp/sipp/blob/master/src/sipp.cpp#L736

It looks like the call to main_scenario->stats->GetStat(CStat::CPT_C_CurrentCall) returns the number of active calls counter (also what the curses ui reports)? The loop doesn't terminate when the bug is triggered because this counter seems to never be decremented/reset.
Oddly, after a call timeout it does seem to have been decremented elsewhere and eventually decreases to 0 after a couple more loops in traffic_thread().