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 <[email protected]> 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 _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
