THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Andrew Pogrebennyk (marduk) Attached to Project - sip-router Summary - dialog doesn't clear calls that were re-INVITEd shortly after ACK Task Type - Bug Report Category - dialog Status - Assigned Assigned To - Timo Reimann Operating System - All Severity - Low Priority - Normal Reported Version - 3.1 Due in Version - Undecided Due Date - Undecided Details - We had a lot of already terminated calls hanging in dialog 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'd want to know why the dialog fails to clear in default mode (DID_ONLY), because the dialog cookie seems to be there in all in-dialog requests, preserved properly. There is nothing in the debug log and trace attached that catches my eye. 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 was 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, I just couldn't get the debug log from that system. But since I've switched to dlg_match_mode=1 though the problem didn't reoccur. Is it a bug? One or more files have been attached. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=206 You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.