[SR-Users] Unexpected BYEs from dialog module

[Alex Balashov]

Hi Henning,

On Sun, Sep 01, 2019 at 09:35:43AM +0000, Henning Westerholt wrote:

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

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.

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

-- Alex

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/