Greetings,
Is some of the dialog profile information kept in in-memory structures inside the Kamailio instance even when one is using a database?
I am using the dialog module in an HA configuration and fail over the database and proxy between two machines. The database and the proxy are both started on the secondary node during failover, and the database uses on-disk data and indices on a shared filesystem.
What I am finding is that if I initiate some dialogs on the primary and then trigger the failover, the proxy on the secondary node is not aware of them. I see the entries for them in the database table from the secondary node - they're definitely there, and I am using db_mode 1 (real-time). However, the profile sizes are all showing as 0. I have also tried it with different match_modes with the same results whether I am using the RR cookie or SIP attributes purely.
It's rather important that I get this working because I require dialog tracking for secure loose-routing of subsequent (non-initial) in-dialog requests and for concurrent call limit control. I was imagining that storing all the dialog info in the database would create the necessary persistence layer for another proxy instance to have the exact same profile information as the first.
Is this a bug, or is it supposed to work this way?
Cheers,
-- Alex
The profiling mechanism is not persistent and therefor you cannot use it in a failover scenario.
Regards, Ovidiu Sas
On Mon, Nov 10, 2008 at 2:12 PM, Alex Balashov abalashov@evaristesys.com wrote:
Greetings,
Is some of the dialog profile information kept in in-memory structures inside the Kamailio instance even when one is using a database?
I am using the dialog module in an HA configuration and fail over the database and proxy between two machines. The database and the proxy are both started on the secondary node during failover, and the database uses on-disk data and indices on a shared filesystem.
What I am finding is that if I initiate some dialogs on the primary and then trigger the failover, the proxy on the secondary node is not aware of them. I see the entries for them in the database table from the secondary node - they're definitely there, and I am using db_mode 1 (real-time). However, the profile sizes are all showing as 0. I have also tried it with different match_modes with the same results whether I am using the RR cookie or SIP attributes purely.
It's rather important that I get this working because I require dialog tracking for secure loose-routing of subsequent (non-initial) in-dialog requests and for concurrent call limit control. I was imagining that storing all the dialog info in the database would create the necessary persistence layer for another proxy instance to have the exact same profile information as the first.
Is this a bug, or is it supposed to work this way?
Cheers,
-- Alex
-- 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 Users@lists.kamailio.org http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
On Mon, November 10, 2008 2:25 pm, Ovidiu Sas wrote:
The profiling mechanism is not persistent and therefor you cannot use it in a failover scenario.
So, what is the point of storing dialogs in the DB then? What is it good for, in terms of persistence?
Alex,
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 ...
Regards
On Mon, 2008-11-10 at 14:27 -0500, Alex Balashov wrote:
On Mon, November 10, 2008 2:25 pm, Ovidiu Sas wrote:
The profiling mechanism is not persistent and therefor you cannot use it in a failover scenario.
So, what is the point of storing dialogs in the DB then? What is it good for, in terms of persistence?
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 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
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 -
Jerome Martin -
Klaus Darilion -
Ovidiu Sas