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?