[SR-Users] Persistent dialog

[Timo Reimann]

On 16.08.2011 18:54, Jon Bonilla wrote:
> El Tue, 16 Aug 2011 18:38:17 +0200
> Timo Reimann <timo.reimann at 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?

dlg_manage() enables you to start dialog tracking not just on the
initial INVITE but on any sequential request too. If you want to use the
flag, all you need to do is enable it in the configuration script during
the course of an INVITE processing. Practically, you replace a call to
dlg_manage() with setflag().

I hate to say this but there's a compelling need to use dlg_manage() in
your case: If you want to use profiles from INVITE messages, you cannot
use the flag. This is, again, due to deficiencies in the module (sigh)
which should probably be fixed. Until then, you're stuck with the
spiral-detection-less (read: broken) dlg_manage().

You can solve your dilemma by waiting for SIP-Router 3.2 which improves
the dialog module such that spiral detection is employed when calling
dlg_manage() too. Alternatively, you can git-checkout my branch
treimann/acc-cdr which already contains the fix. (This would also be a
cool opportunity to have someone else but me test the code. :) ).


>> 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?

dlg_manage() does the tracking magic; dialog profiling simply assigns
dialogs to user-defined slots.


> 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.

Actually, if you have a legitimate reason to start tracking that early,
the module should be fixed. Time's restricted on my side at the moment,
however, but I'll try to get to it ASAP.

I think it's worth a try to see if my git branch already does better for
your use case. If you could give it a shot I'd be glad to know how it
works or whether it needs further work on.


Cheers,

--Timo