This is exactly how it was fixed in opensips by introducing a new tm callback: TMCB_RESPONSE_PRE_OUT.
Regards, Ovidiu Sas
On Mon, Jun 14, 2010 at 9:23 AM, Klaus Darilion klaus.mailinglists@pernau.at wrote:
Am 14.06.2010 15:01, schrieb Klaus Feichtinger:
Hello Ovidiu,
I've been testing reproducablility of the described error and found that it is reproducable in "standard" mode onyl. This should mean: forked application with child processes. As soon as I start the application even as non-forked or with only one child (children=1), the error was not reproducable until now. I've fastened reproduction with SIPp the call generating tool and in standard mode this error messages are visible after about 1-2 minutes (the call rate is one call per second with a pause of 1500ms between ACK and the following BYE).
Under these test circumstances no subscription for presence or dialog state was active; it was tested on a "isolated" server where no other UAs were active; only SIPp and one other UA were active.
I found that this problem is UserAgent-independent, too. Do you have an idea how to find out any more details about this problem?
This sounds like a race condition where process X received the 200 OK, forwards it and then gets suspended before before updating the dialog table.
Then, the ACK is received, forwarded and dialog state updated by process Y.
Maybe it can be solved by updating the dialog state before sending out the message.
regards klaus