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