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

[Klaus Darilion]

Alex Balashov wrote:
> 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?"

I think this should not be that hard to implement - maybe a new function 
in the dialog module, eg: is_in_dialog()?


klaus