Hello, On 05/19/2009 02:32 PM, Alex Balashov wrote: do you have a backtrace? 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: 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! >>> >>> >>> > >