10 Nov
2008
10 Nov
'08
9:12 p.m.
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
10 Nov
10 Nov
9:25 p.m.
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(a)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(a)lists.kamailio.org
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
9:27 p.m.
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 Balashov
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
11 Nov
11 Nov
1:15 a.m.
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?
1:41 a.m.
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
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671
Mobile : (+1) (706) 338-8599
12 Nov
12 Nov
1:50 a.m.
Alex Balashov wrote:
Jerome,
Jerome Martin wrote:
I think this should not be that hard to implement - maybe a new function
in the dialog module, eg: is_in_dialog()?
klaus
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?"
7:33 p.m.
Klaus Darilion wrote:
Alex Balashov wrote:
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
Jerome,
Jerome Martin wrote:
I think this should not be that hard to implement - maybe a new function
in the dialog module, eg: is_in_dialog()? 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?"
5860
days inactive
5862
days old
6 comments
4 participants
participants (4)
-
Alex Balashov -
Jerome Martin -
Klaus Darilion -
Ovidiu Sas