13 Mar
2014
13 Mar
'14
7:36 p.m.
Daniel,
On 03/12/2014 04:27 AM, Daniel-Constantin Mierla wrote:
On 11/03/14 18:44, Alex Balashov wrote:
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/
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.