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