[OpenSIPS-Users] Dialog DB Timeout Older than Start Time/DLG_LIST Inconsistency.

[Vlad Paiu]

Hello Alan,

About the first issue, when the timeout is in the past and the timestart 
is 0. Both these values are updated at the 200 Ok received for the 
dialog. State 1, as shown by dlg_list, means that there was not reply 
from the callee, not even a provisional one, that's why the timestart is 
0. Internally, timeout was also 0, but it got displayed wrong in dlg_list.

About the second issue with the MySQL, the database insertion was done 
before the lifetime got to be updated, so again the same problem as the 
dlg_list presented itself. The timestart was properly updated, but the 
timeout was still internally considered 0.

I have committed a fix for both these issues in trunk, rev 8202.
Please try it out and let me know if now it's ok.


Regards,

-- 
Vlad Paiu
OpenSIPS Developer



On 08/03/2011 02:21 AM, Alan Frisch wrote:
> Originally I came across this issue in 1.6.4 and documented it in 
> http://opensips.org/pipermail/users/2011-January/016358.html
>
> I've seen a few entries in the dialog DB in 1.6.4 where the call was 
> an old zombie because the start_time was ahead of the timeout.  Now I 
> have been experimenting with 1.7 and my .CFG is in a semi-working 
> state (trying to get topology hiding working), so I am able to see 
> this behaviour in more detail.
>
> What seems to be happening still in 1.7 is that what get's stored in 
> the Dialog DB and DLG_LIST for the timeout are 2 different values.  
> Initially the timeout value in the DB is earlier than the start_time, 
> the value can be one or two minutes older than the actual dialog start.
>
> Starting a call I see the following in DLG_LIST:
>
> dialog::  hash=1624:161014921
>         state:: 1
>         user_flags:: 0
>         timestart:: 0
>         timeout:: 1312326458
>  ...
>
> This initial timeout value is in the past(!).  A few moments later 
> once the state has changed OpenSIPS now displays:
>
> dialog::  hash=1624:161014921
>         state:: 3
>         user_flags:: 0
>         timestart:: 1312326489
>         timeout:: 1312333989
> ...
>
> Which seems to be a proper start time and timeout, the difference is 
> 7500 seconds (as I specified in my .CFG).
>
> Switching over to the MySQL side of things, even after some time the 
> value for time_start is more or less correct, but the timeout is not 
> updated.
>
> mysql> select id,state,start_time,timeout from dialog;
> +----+-------+------------+------------+
> | id | state | start_time | timeout    |
> +----+-------+------------+------------+
> |  1 |     3 | 1312326489 | 1312326459 |
> +----+-------+------------+------------+
> 1 row in set (0.00 sec)
>
> As you can see, the DB has not been updated with the new timeout from 
> the DLG_LIST... it is still the "in the past" initial value of 1312326459.
>
> Not sure if this is one problem or two... but it has bunged up my load 
> balancing on a few occasions with calls hanging around the DB for days 
> (can't remember if I saw them in the DLG_LIST.
>
> Any idea what's happening here?
>
> AF.
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20110803/c3d441e1/attachment.htm>