[SR-Users] Bizarre dialog profile tracking behaviour

[Alex Balashov]

Daniel,

On 03/12/2014 04:27 AM, Daniel-Constantin Mierla wrote:

>
> On 11/03/14 18:44, Alex Balashov wrote:
>> We appear to have fixed this problem by calling dlg_manage() before
>> doing any set_dlg_profile() manipulations.
>>
>> The documentation is not clear on whether dlg_manage() needs to be
>> called first before doing this. But it makes me wonder: if
>> dlg_manage() is prerequisite, then why would the profile manipulation
>> work at all beforehand?
>>
> Should work both ways. But I said in previous email, for the second
> invite, the dialog might be found in memory and reused. In that case it
> might not get the new profile for local static lists... so I guess that
> a set_dlg_profile() before dlg_manage() doesn't find dialog shortcut
> (which probably is set by dlg_manage()) and will add to local static
> lists. When the dlg_manage() is executed, first looks for the dialog and
> finds it, then don't create a new one. When creating a new structure,
> the code is looking to local static lists and add the dialog in those
> profiles. Code has to be checked, though, only my guess here.

When dlg_manage() was called after the set_dlg_profile() calls, the 
profile count looked like this:

    0 -> 1 -> 2 --> 0 (abrupt crash to 0 after 18x messages)

When we put dlg_manage() prior to the set_dlg_profile() calls, the 
profile count looks like this:

   0 -> 1 -> 2 -> 1 --> 1

This is closer to what we want, of course. The issue is that the dialog 
module takes 1-2 seconds to delete the old dialog in this scenario (the 
'2 -> 1' step), and for a high volume of calls, that can be a problem 
because it inflates the number of calls currently in process by a 
substantial proportion, breaking the ability to do concurrent call 
limiting effectively.

Since dialog relies on TM callbacks, my question is: are there any 
timeouts we can tweak on the TM side that would have the effect of aging 
the old (407-challenged) dialog out faster, perhaps nearly instantly, 
once the hop-by-hop ACK for the 407 is received?

That is the fundamental problem we're trying to solve at this point.

Thanks,

-- Alex

P.S. if(is_present_hf("Proxy-Authorization")) { track dialog }

... would be an attractive solution. Unfortunately, authentication is 
not used in all cases by the upstream gateway, and we cannot predict 
which cases those will be.

-- 
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/