11 Nov
2008
11 Nov
'08
1:15 a.m.
Alex,
You are getting confused between the actual dialogs stored persistently
in databe and the dialog _profiles_ information.
The dialogs are persistent in db_mode > 0, and upon restart of the
proxy, based on proxy IPs, the dialogs will be restored in memory from
database. This allows to perform dialog-matching for subsequent
requests.
For instance, if you start a dialog, then restart the proxy (reloading
the dialog info from database), you will notice that a BYE for this
dialog that arrives after the restart will trigger the correct
computation of $DLG_duration (this is just an example).
Dialog profiles, on the other hand, is transient, in-memroy information
that is not currently stored in database. I think the main reason is
that dialog profiles were initially intended to be used for statistics,
not dialog matching/accounting/authorisation.
However your use case, IMHO, is valid and deserves to be taken into
consideration for future dialog module improvements.
I hope this clarifies the point of storing dialogs in database ...
Regards
On Mon, 2008-11-10 at 14:27 -0500, Alex Balashov wrote:
On Mon, November 10, 2008 2:25 pm, Ovidiu Sas wrote:
The profiling mechanism is not persistent and
therefor you cannot use
it in a failover scenario.
So, what is the point of storing dialogs in the DB then? What is it good
for, in terms of persistence?