[Kamailio-Users] Dialog profile persistence - DB vs. memory.

[Alex Balashov]

Jerome,

Jerome Martin wrote:

> 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 ...

That does, indeed, clarify.  Thank you.  I assumed that a "profile" is 
just an abstraction around certain properties of the dialog built into 
its hash information, but was suspecting that there may be more 
meta-data involved.

But as you rightly observe, that does complicate my use case.  In this 
case, if I fail over while a call is in progress and then the BYE for it 
arrives, while it may calculate $DLG_duration usefully for example, the 
proxy will not recognise it as belonging to an existing dialog and 
refuse to forward it or any other in-dialog messages.

So, it seems that while "this allows to perform dialog-matching for 
subsequent requests," this is true in one type of use case but - 
critically and very importantly - not in another.  Since is_in_profile() 
is the only way to check if a request belongs to a known dialog, 
authorisation is thus tied to profiles rather than mere awareness of 
certain dialogs.  This is unfortunate.  All I want to do is check if 
subsequent in-dialog requests belong to a known dialog;  I care not 
whether this is done by dipping into "profiles" or simply asking the 
dialog module, "Do you know about this dialog?"

-- 
Alex Balashov
Evariste Systems
Web    : http://www.evaristesys.com/
Tel    : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599