El Tue, 16 Aug 2011 18:38:17 +0200
Timo Reimann <timo.reim...@1und1.de> escribió:
> Hey Jon,
>
>
> On 16.08.2011 18:14, Jon Bonilla wrote:
> >> 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.
>
> 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?
> 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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
