16 Aug
2011
16 Aug
'11
7:54 p.m.
El Tue, 16 Aug 2011 18:38:17 +0200
Timo Reimann <timo.reimann(a)1und1.de> escribió:
Hey Jon,
On 16.08.2011 18:14, Jon Bonilla wrote:
That's what spiral detection is supposed to prevent, i.e., the creation
of multiple structures for the same dialog. However, it only works if
you use the flag to track dialogs, not if you call dlg_manage()
explicitly. I see you have actually configured flag #9 as dialog flag
but just to make sure: Are you using that flag only, not dlg_manage() ?
I use dlg_manage, not the flag. I don't use the flag at all. What would be the
difference using the flag? Any example about how to use the flag instead of
dlg_manage?
Looks
pretty much like two dialog entries were created for the same
dialog. One of them got cleaned up nicely on call termination while the
other one keeps dangling until the dialog timer kicks in (12 hours in
your case).
Most notably, this situation may happen when spiraling calls without
using the spiral detection feature in the dialog module. (A spiral is a
scenario where a proxy is processing the same request twice, e.g., to
implement call forwardings.) Did you possibly toggle the default spiral
detection setting from enabled to disabled?
No I didn't
Here's the dialog modparams:
modparam("dialog","dlg_flag", 9)
modparam("dialog","profiles_no_value","total ;emergency")
modparam("dialog","profiles_with_value","peer ; user ; type ;
peerout ;
userout")
Maybe setting the dialog to TOTAL twice is the problem? I set it before
proxy
authentication. I asume that dialog is erased when sending the 407 back
and a
new one is created for the second INVITE. Even if you did not use dlg_manage(), however, dialogs
would likely not
be tracked properly if you started doing so on unauthenticated calls.
The reason is that terminated calls do not get removed until the
associated transaction is deleted. When that second, authenticated
INVITE is handled by the dialog module, it will find a dialog structure
already in the DELETED state (as the dialog ID matches) and refuse
further processing on it.
This may be considered as a shortcoming of the current implementation.
On the other hand, do you actually need to track unauthenticated calls?
They could just be SIP attacks trying to disrupt your infrastructure and
shouldn't be accounted as real calls whatsoever. If you start tracking
dialogs after authentication, things should look better.
Only the dialog profile mark or also the dlg_manage?
I set it very soon in my scenario because I also receive unauthenticated calls
from trusted ips that I need to track. I'll try to check if I can deal with
this and move it somewhere else.
Cheers,
--Timo
Thanks Timo