[SR-Users] Dialog module timeout behaviours

Daniel-Constantin Mierla miconda at gmail.com
Thu May 25 17:55:35 CEST 2017


Hello,

iirc, if the ACK is not received or not matched with the dialog, then the
module is doing a 'hard' cleanup in like 1-2 minute of 'unconfirmed
dialogs'. Likely the BYE is ignored in regards to updating dialog state if
the dialog is not marked as answered (not yet in confirmed state).

Cheers,
Daniel

On Thu, May 25, 2017 at 5:38 PM, Alex Balashov <abalashov at evaristesys.com>
wrote:

> Hello,
>
> I'm running 4.3.5:1b0c0a and have run into two distinct, bizarre issues
> with the dialog module that I am unable to explain.
>
> In all cases, I am using $dlg_ctx(send_bye) = 1, and passing in a dialog
> timeout of 7200 sec via AVP (timeout_avp modparam).
>
> 1) Local BYEs are sent after either ~60 or ~120 sec --
>
> This happens on a very small number of answered calls for no apparent
> reason. I have spent days poring through the traces trying to figure out
> if there's anything eccentric about how the messages, but can't find
> anything out of the ordinary except (a) 1 retransmission of 200 OK to
> INVITE due to not receiving ACK fast enough due to end-to-end latency,
> and (b) consequently, retransmission of ACK.
>
> My understanding is that the dialog module does not prophylactically end
> calls as a response to strange or improper messaging, but only (a) when
> the dialog timeout is reached or (b) keepalive OPTION pings (if enabled)
> fail.
>
> Keepalive OPTIONS pings are not enabled in these scenarios, and are not
> sent in the traces.
>
> (2) Local BYEs sent in response to race conditions that result in
> strange dialog state transitions --
>
> There are some calls that look something like:
>
> A. Caller INVITEs callee;
> B. Callee sends progress;
> C. Callee sends 200 OK answer and immediately sends BYE (e.g. 1 ms
> later);
> D. Kamailio receives these nearly simultaneously and forwards the BYE
> first;
> E. Caller sends 487 Request Terminated response (processing BYE as if it
> were CANCEL);
> F. Kamailio forwards 200 OK back to caller, who ignores it.
> G. Callee retransmits 200 OK through Kamailio.
>
> A few minutes later, Kamailio sends BYE in both directions even though
> dialog should have been removed from state tracking long ago because of
> the dispositive 487 reply.
>
> ...
>
> In particular, I'm curious as to whether there have been any fixes to
> deal with scenarios like #2 since 4.3.5. I wasn't able to spot any
> obvious ones in the commit history for the module. I'm also at a
> complete loss to explain #1.
>
> I have traces for all of these scenarios, but would prefer to send
> privately.
>
> Many thanks!
>
> -- 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/
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>



-- 
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20170525/5a94527a/attachment.html>


More information about the sr-users mailing list