Greetings,
I've run into an issue with 1.4.4 in which the following appears to be happening, and I'm yet to determine the cause:
The total amount of open inbound calls (dialogs) is tracked with the dialog module by putting them in a global profile. Because of a segfault bug with profiles with "no values," a workaround is used wherein a profile "with" values is created and the hash key is always the same value (i.e. "1"). The dialog tracking flag is 2:
modparam("dialog", "dlg_flag", 2)
And profile looks like this:
modparam("dialog", "profiles_with_value", "globalinbound;specificinbound")
Anyway, inbound INVITEs get handed off to a route (route[1]) that performs some logic like this:
route[1] { # Check if DID is assigned to an account with database # and store value in AVP, along with other values.
if($avp(S:did_assigned) == "0") { sl_send_reply("404", "Not Found"); exit; }
get_profile_size("specificinbound", "$avp(S:account_id)", "$var(a_concurrent_calls)");
if($var(a_concurrent_calls) >= $avp(S:port_limit)) { sl_send_reply("486", "Busy"); exit; }
setflag(2); # Track dialog.
set_dlg_profile("globalinbound", "1"); set_dlg_profile("specificinbound", "$avp(S:account_id)"); }
What appears to be happening is that calls coming into unassigned numbers ($avp(S:did_assigned) == "0") increase the size of the "globalinbound" profile, which is something of a mystery to me since I am neither setting flag 2 nor calling set_dlg_profile() until further down in the logic! And after the 404 Not Found reply is sent, the profile size is not decremented. Is the use of statefully tracked replies (t_reply()) required in order to propagate dialog state through to the dialog module? My impression is this was not the case.
More pressing concern is that profile size is increased and not decreased; in my interpretation, such calls should not be added to the 'globalinbound' profile at all.
I have not had the opportunity to try to reproduce this with 1.5.x.
Thanks!
Alex Balashov wrote:
Greetings,
I've run into an issue with 1.4.4 in which the following appears to be happening, and I'm yet to determine the cause:
The total amount of open inbound calls (dialogs) is tracked with the dialog module by putting them in a global profile. Because of a segfault bug with profiles with "no values," a workaround is used wherein a profile "with" values is created and the hash key is always the same value (i.e. "1"). The dialog tracking flag is 2:
modparam("dialog", "dlg_flag", 2)And profile looks like this:
modparam("dialog", "profiles_with_value", "globalinbound;specificinbound")
Anyway, inbound INVITEs get handed off to a route (route[1]) that performs some logic like this:
route[1] { # Check if DID is assigned to an account with database # and store value in AVP, along with other values.
if($avp(S:did_assigned) == "0") { sl_send_reply("404", "Not Found"); exit; } get_profile_size("specificinbound", "$avp(S:account_id)","$var(a_concurrent_calls)");
if($var(a_concurrent_calls) >= $avp(S:port_limit)) { sl_send_reply("486", "Busy"); exit; } setflag(2); # Track dialog. set_dlg_profile("globalinbound", "1"); set_dlg_profile("specificinbound", "$avp(S:account_id)");
For completeness, I should add here:
# Perform dispatcher election - ds_select_domain().
t_on_reply("1"); t_on_failure("1");
if(!t_relay()) sl_reply_error();
exit;
}
Hello,
On 05/19/2009 02:32 PM, Alex Balashov wrote:
Greetings,
I've run into an issue with 1.4.4 in which the following appears to be happening, and I'm yet to determine the cause:
The total amount of open inbound calls (dialogs) is tracked with the dialog module by putting them in a global profile. Because of a segfault bug with profiles with "no values,"
do you have a backtrace?
a workaround is used wherein a profile "with" values is created and the hash key is always the same value (i.e. "1"). The dialog tracking flag is 2:
modparam("dialog", "dlg_flag", 2)And profile looks like this:
modparam("dialog", "profiles_with_value", "globalinbound;specificinbound")
Anyway, inbound INVITEs get handed off to a route (route[1]) that performs some logic like this:
route[1] { # Check if DID is assigned to an account with database # and store value in AVP, along with other values.
if($avp(S:did_assigned) == "0") { sl_send_reply("404", "Not Found"); exit; } get_profile_size("specificinbound", "$avp(S:account_id)","$var(a_concurrent_calls)");
if($var(a_concurrent_calls) >= $avp(S:port_limit)) { sl_send_reply("486", "Busy"); exit; } setflag(2); # Track dialog. set_dlg_profile("globalinbound", "1"); set_dlg_profile("specificinbound", "$avp(S:account_id)");}
What appears to be happening is that calls coming into unassigned numbers ($avp(S:did_assigned) == "0") increase the size of the "globalinbound" profile, which is something of a mystery to me since I am neither setting flag 2 nor calling set_dlg_profile() until further down in the logic!
This is very improbable to happen if you do not call dlg profile set function. Can you add some xlogs around to see when these functions are executed?
As you use the flag mechanism, the dialog is actually created inside t_relay(), upon a tm callback.
Cheers, Daniel
And after the 404 Not Found reply is sent, the profile size is not decremented. Is the use of statefully tracked replies (t_reply()) required in order to propagate dialog state through to the dialog module? My impression is this was not the case.
More pressing concern is that profile size is increased and not decreased; in my interpretation, such calls should not be added to the 'globalinbound' profile at all.
I have not had the opportunity to try to reproduce this with 1.5.x.
Thanks!
Daniel,
I think I posted too early. I am having trouble consistently reproducing the problem and will reply when I have more information about the exact confluence of circumstances that causes it.
-- Alex
Daniel-Constantin Mierla wrote:
Hello,
On 05/19/2009 02:32 PM, Alex Balashov wrote:
Greetings,
I've run into an issue with 1.4.4 in which the following appears to be happening, and I'm yet to determine the cause:
The total amount of open inbound calls (dialogs) is tracked with the dialog module by putting them in a global profile. Because of a segfault bug with profiles with "no values,"
do you have a backtrace?
a workaround is used wherein a profile "with" values is created and the hash key is always the same value (i.e. "1"). The dialog tracking flag is 2:
modparam("dialog", "dlg_flag", 2)And profile looks like this:
modparam("dialog", "profiles_with_value", "globalinbound;specificinbound")
Anyway, inbound INVITEs get handed off to a route (route[1]) that performs some logic like this:
route[1] { # Check if DID is assigned to an account with database # and store value in AVP, along with other values.
if($avp(S:did_assigned) == "0") { sl_send_reply("404", "Not Found"); exit; } get_profile_size("specificinbound", "$avp(S:account_id)","$var(a_concurrent_calls)");
if($var(a_concurrent_calls) >= $avp(S:port_limit)) { sl_send_reply("486", "Busy"); exit; } setflag(2); # Track dialog. set_dlg_profile("globalinbound", "1"); set_dlg_profile("specificinbound", "$avp(S:account_id)");}
What appears to be happening is that calls coming into unassigned numbers ($avp(S:did_assigned) == "0") increase the size of the "globalinbound" profile, which is something of a mystery to me since I am neither setting flag 2 nor calling set_dlg_profile() until further down in the logic!
This is very improbable to happen if you do not call dlg profile set function. Can you add some xlogs around to see when these functions are executed?
As you use the flag mechanism, the dialog is actually created inside t_relay(), upon a tm callback.
Cheers, Daniel
And after the 404 Not Found reply is sent, the profile size is not decremented. Is the use of statefully tracked replies (t_reply()) required in order to propagate dialog state through to the dialog module? My impression is this was not the case.
More pressing concern is that profile size is increased and not decreased; in my interpretation, such calls should not be added to the 'globalinbound' profile at all.
I have not had the opportunity to try to reproduce this with 1.5.x.
Thanks!
Hello,
On 05/19/2009 05:22 PM, Alex Balashov wrote:
Daniel,
I think I posted too early. I am having trouble consistently reproducing the problem and will reply when I have more information about the exact confluence of circumstances that causes it.
ok, thanks, Daniel
-- Alex
Daniel-Constantin Mierla wrote:
Hello,
On 05/19/2009 02:32 PM, Alex Balashov wrote:
Greetings,
I've run into an issue with 1.4.4 in which the following appears to be happening, and I'm yet to determine the cause:
The total amount of open inbound calls (dialogs) is tracked with the dialog module by putting them in a global profile. Because of a segfault bug with profiles with "no values,"
do you have a backtrace?
a workaround is used wherein a profile "with" values is created and the hash key is always the same value (i.e. "1"). The dialog tracking flag is 2:
modparam("dialog", "dlg_flag", 2)And profile looks like this:
modparam("dialog", "profiles_with_value", "globalinbound;specificinbound")
Anyway, inbound INVITEs get handed off to a route (route[1]) that performs some logic like this:
route[1] { # Check if DID is assigned to an account with database # and store value in AVP, along with other values.
if($avp(S:did_assigned) == "0") { sl_send_reply("404", "Not Found"); exit; } get_profile_size("specificinbound", "$avp(S:account_id)","$var(a_concurrent_calls)");
if($var(a_concurrent_calls) >= $avp(S:port_limit)) { sl_send_reply("486", "Busy"); exit; } setflag(2); # Track dialog. set_dlg_profile("globalinbound", "1"); set_dlg_profile("specificinbound", "$avp(S:account_id)");}
What appears to be happening is that calls coming into unassigned numbers ($avp(S:did_assigned) == "0") increase the size of the "globalinbound" profile, which is something of a mystery to me since I am neither setting flag 2 nor calling set_dlg_profile() until further down in the logic!
This is very improbable to happen if you do not call dlg profile set function. Can you add some xlogs around to see when these functions are executed?
As you use the flag mechanism, the dialog is actually created inside t_relay(), upon a tm callback.
Cheers, Daniel
And after the 404 Not Found reply is sent, the profile size is not decremented. Is the use of statefully tracked replies (t_reply()) required in order to propagate dialog state through to the dialog module? My impression is this was not the case.
More pressing concern is that profile size is increased and not decreased; in my interpretation, such calls should not be added to the 'globalinbound' profile at all.
I have not had the opportunity to try to reproduce this with 1.5.x.
Thanks!
In the meantime, tell me this: Is there any set of circumstances I should deliberately avoid, under which a dialog that has been created and is being tracked (via dialog flag set) and added to a profile is not properly removed from stateful tracking in 'dialog' after it ends?
I mean, other than using stateless forwarding for any subsequent messages, of course.
Some problem in stateful vs. stateless replies is I think at the root of this - perhaps CANCEL being misprocessed by me.
My main route architecture is based on the stock configuration file pattern for loose route vs. ACK with to-tag vs. CANCELs.
Daniel-Constantin Mierla wrote:
Hello,
On 05/19/2009 05:22 PM, Alex Balashov wrote:
Daniel,
I think I posted too early. I am having trouble consistently reproducing the problem and will reply when I have more information about the exact confluence of circumstances that causes it.
ok, thanks, Daniel
-- Alex
Daniel-Constantin Mierla wrote:
Hello,
On 05/19/2009 02:32 PM, Alex Balashov wrote:
Greetings,
I've run into an issue with 1.4.4 in which the following appears to be happening, and I'm yet to determine the cause:
The total amount of open inbound calls (dialogs) is tracked with the dialog module by putting them in a global profile. Because of a segfault bug with profiles with "no values,"
do you have a backtrace?
a workaround is used wherein a profile "with" values is created and the hash key is always the same value (i.e. "1"). The dialog tracking flag is 2:
modparam("dialog", "dlg_flag", 2)And profile looks like this:
modparam("dialog", "profiles_with_value", "globalinbound;specificinbound")
Anyway, inbound INVITEs get handed off to a route (route[1]) that performs some logic like this:
route[1] { # Check if DID is assigned to an account with database # and store value in AVP, along with other values.
if($avp(S:did_assigned) == "0") { sl_send_reply("404", "Not Found"); exit; } get_profile_size("specificinbound", "$avp(S:account_id)","$var(a_concurrent_calls)");
if($var(a_concurrent_calls) >= $avp(S:port_limit)) { sl_send_reply("486", "Busy"); exit; } setflag(2); # Track dialog. set_dlg_profile("globalinbound", "1"); set_dlg_profile("specificinbound", "$avp(S:account_id)");}
What appears to be happening is that calls coming into unassigned numbers ($avp(S:did_assigned) == "0") increase the size of the "globalinbound" profile, which is something of a mystery to me since I am neither setting flag 2 nor calling set_dlg_profile() until further down in the logic!
This is very improbable to happen if you do not call dlg profile set function. Can you add some xlogs around to see when these functions are executed?
As you use the flag mechanism, the dialog is actually created inside t_relay(), upon a tm callback.
Cheers, Daniel
And after the 404 Not Found reply is sent, the profile size is not decremented. Is the use of statefully tracked replies (t_reply()) required in order to propagate dialog state through to the dialog module? My impression is this was not the case.
More pressing concern is that profile size is increased and not decreased; in my interpretation, such calls should not be added to the 'globalinbound' profile at all.
I have not had the opportunity to try to reproduce this with 1.5.x.
Thanks!
Hello,
On 05/19/2009 05:29 PM, Alex Balashov wrote:
In the meantime, tell me this: Is there any set of circumstances I should deliberately avoid, under which a dialog that has been created and is being tracked (via dialog flag set) and added to a profile is not properly removed from stateful tracking in 'dialog' after it ends?
the profiles should be updated automatically when dialog ends.
I mean, other than using stateless forwarding for any subsequent messages, of course.
Some problem in stateful vs. stateless replies is I think at the root of this - perhaps CANCEL being misprocessed by me.
My main route architecture is based on the stock configuration file pattern for loose route vs. ACK with to-tag vs. CANCELs.
dlg is added to profile when it is created, which happens after invite transaction is created when you use flags. Then the transaction ends either by cancel, timeout, other negative reply or completes with 200ok.
Cheers, Daniel
Daniel-Constantin Mierla wrote:
Hello,
On 05/19/2009 05:22 PM, Alex Balashov wrote:
Daniel,
I think I posted too early. I am having trouble consistently reproducing the problem and will reply when I have more information about the exact confluence of circumstances that causes it.
ok, thanks, Daniel
-- Alex
Daniel-Constantin Mierla wrote:
Hello,
On 05/19/2009 02:32 PM, Alex Balashov wrote:
Greetings,
I've run into an issue with 1.4.4 in which the following appears to be happening, and I'm yet to determine the cause:
The total amount of open inbound calls (dialogs) is tracked with the dialog module by putting them in a global profile. Because of a segfault bug with profiles with "no values,"
do you have a backtrace?
a workaround is used wherein a profile "with" values is created and the hash key is always the same value (i.e. "1"). The dialog tracking flag is 2:
modparam("dialog", "dlg_flag", 2)And profile looks like this:
modparam("dialog", "profiles_with_value", "globalinbound;specificinbound")
Anyway, inbound INVITEs get handed off to a route (route[1]) that performs some logic like this:
route[1] { # Check if DID is assigned to an account with database # and store value in AVP, along with other values.
if($avp(S:did_assigned) == "0") { sl_send_reply("404", "Not Found"); exit; } get_profile_size("specificinbound", "$avp(S:account_id)","$var(a_concurrent_calls)");
if($var(a_concurrent_calls) >= $avp(S:port_limit)) { sl_send_reply("486", "Busy"); exit; } setflag(2); # Track dialog. set_dlg_profile("globalinbound", "1"); set_dlg_profile("specificinbound", "$avp(S:account_id)");}
What appears to be happening is that calls coming into unassigned numbers ($avp(S:did_assigned) == "0") increase the size of the "globalinbound" profile, which is something of a mystery to me since I am neither setting flag 2 nor calling set_dlg_profile() until further down in the logic!
This is very improbable to happen if you do not call dlg profile set function. Can you add some xlogs around to see when these functions are executed?
As you use the flag mechanism, the dialog is actually created inside t_relay(), upon a tm callback.
Cheers, Daniel
And after the 404 Not Found reply is sent, the profile size is not decremented. Is the use of statefully tracked replies (t_reply()) required in order to propagate dialog state through to the dialog module? My impression is this was not the case.
More pressing concern is that profile size is increased and not decreased; in my interpretation, such calls should not be added to the 'globalinbound' profile at all.
I have not had the opportunity to try to reproduce this with 1.5.x.
Thanks!
This issue can be disregarded. It was my mistake and due to a misinterpretation of the order and timing of call events, and I apologise for this reckless and hasty "bug" "report."
I will strive to be more enlightened and thorough in my allegations in the future.
On 05/21/2009 11:18 AM, Alex Balashov wrote:
This issue can be disregarded. It was my mistake and due to a misinterpretation of the order and timing of call events, and I apologise for this reckless and hasty "bug" "report."
I will strive to be more enlightened and thorough in my allegations in the future.
no problem, thanks for investigating to the end...
Cheers, Daniel
-
Alex Balashov -
Daniel-Constantin Mierla