14 Jun
2010
14 Jun
'10
4:35 p.m.
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(a)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