New subject: dialog doesn't clear calls that were re-INVITEd shortly after ACK

22 Feb 2012

Hi,
I noticed dialog module showing calls that have already been terminated
with state=4.
The kamailio version is 3.1.5, I'm aware of certain limitations of
dialog module in this version (must use stateless replies, create dialog
after 407), but this is something rather new.
In kamailio config I'm using dlg_manage() for initial INVITEs and
BYE/CANCEL and in-dialog requests are loose-routed, so nothing finicky.

The call scenario is: A calls B, B answers the call, A immediately after
sending ACK for the 200 OK issues re-INVITE. After some seconds A hangs
up, and the dialog stays in memory in state=4, e.g.:

dialog::  hash=3304:623200556
	state:: 4
	ref_count:: 2
	timestart:: 1329938667
	timeout:: 78590167
	callid:: MGExMjRiYzMzN2Q5YWU4YjRiMjFjYTYwYWZlMGFlMzY.
	from_uri:: sip:sipwise-user1@67.202.62.202
	from_tag:: 4207e429
	caller_contact:: sip:sipwise-user1@80.108.64.151:46420
	caller_cseq:: 3
	caller_route_set::
<sip:127.0.0.1:5060;lr;r2=on>,<sip:67.202.62.202:5060;lr;r2=on>
	caller_bind_addr:: udp:127.0.0.1:5062
	callee_bind_addr:: udp:127.0.0.1:5062
	to_uri:: sip:43991002@67.202.62.202
	to_tag:: 6C8F89E9-4F4540EA0001F575-AC557700
	callee_contact:: sip:sipwise-user2@127.0.0.1:5080
	callee_cseq:: 11
	callee_route_set::

When I set dlg_match_mode=1 the problem goes away. I would like however
to understand why the dialog fails to clear in default mode (DID_ONLY),
because the dialog cookie seems to be preserved by caller in all
in-dialog requests properly. There is nothing in the debug log and trace
attached that catches my eye. Do you see anything wrong there?

In trace file the proxy address is 127.0.0.1:5062. You may notice that
the actual signaling flow is a little bit more complicated, I will
gladly answer any questions about it. For this test I've used two lines
in the eyeBeam softphone, when one line answers the other is
automatically put on hold which is what I want. Then I un-hold the
callee and clear the call.

The customer is reporting multiple stale calls when re-INVITE is sent by
Cirpack PSTN gw immediately after call connect, which is basically the
same call flow I am talking about, it is just not practical for me to
run kamailio with debug=3 there all the time. I am going to try
theredlg_match_mode=1 though and see if the problem goes away.

Any ideas?