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
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
