[sr-dev] Dialog module and confirmed-unacked dialogs
abalashov at evaristesys.com
Fri Apr 25 16:51:24 CEST 2014
I am wondering if perhaps we ought to do something with regard to
specific handling of confirmed-nonacked dialogs (CONFIRMED_NA state in
dlg_hash.h) in the dialog module. These are dialogs where a 2xx reply is
sent to the opening INVITE transaction, but no end-to-end ACK is seen
by Kamailio and thus the dialog is not recorded as transitioning to
This can happen for a variety of reasons, but the most common scenario I
run into is the CANCEL-200 OK race, where the caller cancels the call
just as the callee answers it, near-simultaneously. The 200 OK hasn't
gotten back to the caller yet, so when it receives it, it has no effect,
because from the caller's point of view, the dialog has already been
CANCEL'd. Meanwhile, the CANCEL has no effect on the callee end either,
since, from its point of view, the dialog has already transitioned into
The problem I am running into a lot is that these dialogs stay tracked
up until the dialog timeout period, which can be several hours away. In
high-volume environments, they can clog up concurrent channel counts.
The receiving UAS has, of course, disposed of these dialogs long ago,
after 64*T1, but they remain "stuck" in Kamailio.
I know that RFC 3261 Section 188.8.131.52 ("The INVITE is Accepted") says:
If the server retransmits the 2xx response for 64*T1 seconds without
receiving an ACK, the dialog is confirmed, but the session SHOULD
be terminated. This is accomplished with a BYE, as described
in Section 15.
Now, I know that "SHOULD" != "MUST", and I would imagine that this is
probably the main reason why the dialog module does not time out such
dialogs according to the same timers as the callee UA might.
Nevertheless, they present a problem. Right now, I deal with it by using
a script that combs 'kamctl fifo dlg_list' for dialogs in 'state:: 3'
for more than X seconds and manually ends them.
But, when there's a problem that one runs into nearly ubiquitously in
all deployments with nontrivial deployments, it seems to me it's time to
consider an additional 'dialog' modparam or something of that ilk that
can provide an expedited timeout for nonacked dialogs.
I would be happy to write such a patch. The reason I am bringing it up
to the community is because I am uncertain as to whether this might have
any unforeseen consequences, or whether it's been discussed in various
dialog_ng discussions in the past that I have not carefully monitored.
(With apologies for cross-posting.)
 Or correctly associated based on tight matching.
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Decatur, GA 30030
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
More information about the sr-dev