Originally I came across this issue in 1.6.4 and documented it in <a href="http://opensips.org/pipermail/users/2011-January/016358.html">http://opensips.org/pipermail/users/2011-January/016358.html</a> <br><br>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.<br>
<br>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.<br>
<br>Starting a call I see the following in DLG_LIST:<br><br>dialog:: hash=1624:161014921<br> state:: 1<br> user_flags:: 0<br> timestart:: 0<br> timeout:: 1312326458<br> ...<br><br>This initial timeout value is in the past(!). A few moments later once the state has changed OpenSIPS now displays:<br>
<br>dialog:: hash=1624:161014921<br> state:: 3<br> user_flags:: 0<br> timestart:: 1312326489<br> timeout:: 1312333989<br>...<br><br>Which seems to be a proper start time and timeout, the difference is 7500 seconds (as I specified in my .CFG).<br>
<br>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.<br><br>mysql> select id,state,start_time,timeout from dialog;<br>+----+-------+------------+------------+<br>
| id | state | start_time | timeout |<br>+----+-------+------------+------------+<br>| 1 | 3 | 1312326489 | 1312326459 |<br>+----+-------+------------+------------+<br>1 row in set (0.00 sec)<br><br>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.<br>
<br>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.<br><br>Any idea what's happening here?<br>
<br>AF.<br><br><br>