[sr-dev] Dialog module and confirmed-unacked dialogs

[Alex Balashov]

Hi,

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[1] 
by Kamailio and thus the dialog is not recorded as transitioning to 
CONFIRMED state.

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

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 13.3.1.4 ("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.

Thanks!

-- Alex

(With apologies for cross-posting.)

[1] Or correctly associated based on tight matching.

-- 
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/