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

[Alex Balashov]

Klaus Darilion wrote:
> 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()?

I have submitted a patch for this:

http://lists.kamailio.org/pipermail/devel/2008-November/016803.html


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