[SR-Users] Unexpected BYEs from dialog module

[Henning Westerholt]

Hi Alex,

answer inline below

Am 02.09.19 um 10:04 schrieb Alex Balashov:
>> just looked briefly into the code. There is only one place in the
>> dialog module that ends a dialog with "dlg_bye_all" - and this happens
>> in the dlg_ontimeout routine, if there is the proper flag set for the
>> particular dialog.
>>
>> Do you have the send_bye parameter set to 1 or use the
>> $dlg_ctx(timeout_bye) PV? Is there any configured timeout that relates
>> to the ~150s that you see in the module? It is always ~150s or does it
>> change from call to call?

So you've set dhe dlg_bye_all parameter. Could you try to deactivate it 
just for a brief time and see if the problem does occur as well? Then we 
know at for sure that it is related to this functionality.

>> No, mysteriously there is not.
>>
>> While the value of the timeout_avp can vary from call to call, in the
>> case of these particular calls--and indeed, 95%+ of calls--it is set to
>> 7200 sec. The default_timeout modparam is set to 28800 sec (8 hours).
>>
>> The timeout period always seems to be 150-160 sec, but as you note, the
>> arithmetical relationship between this period and any formally declared
>> timeouts is a mystery.

Another idea , there is the dlg_clean_timer which is 90s. But this is 
still a bit off to your observed time period.

Maybe an additional timer is  running before.

>> About the other topic - the matching mode: if there is an existing,
>> but broken RR DID parameter, the code will stop processing and not try
>> again the other match mode.
>>
>> This is correct according the docs "1 - DID_FALLBACK - the match is
>> first tried based on DID and if not present, it will fall back to SIP
>> matching;", but could be changed to be more resilient, I agree.
> Ah, I see. Well, "if not present" is a bit ambiguous from a layperson's
> perspective; in my case the cookie is present but incorrect and so does
> not match a known dialog, so I didn't know offhand if the code treat the
> parameter as though it were altogether absent, or whether it would treat
> it as present but wrong and abort processing as you suggest. :-)

Yes, this could be improved, I agree.

Cheers,

Henning


-- 
Henning Westerholt - https://skalatan.de/blog/
Kamailio services - https://skalatan.de/services