[sr-dev] [tracker] Task opened: dialog doesn't clear calls that were re-INVITEd shortly after ACK (Attachment added)

[sip-router]

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 at 67.202.62.202
	from_tag:: 4207e429
	caller_contact:: sip:sipwise-user1 at 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 at 67.202.62.202
	to_tag:: 6C8F89E9-4F4540EA0001F575-AC557700
	callee_contact:: sip:sipwise-user2 at 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.