[SR-Users] dialog doesn't clear calls that were re-INVITEd shortly after ACK

Andrew Pogrebennyk apogrebennyk at sipwise.com
Wed Feb 29 15:57:13 CET 2012


Since Timo is most likely busy these days I will create an issue in the
tracker for that.

On 02/22/2012 08:48 PM, Andrew Pogrebennyk wrote:
> 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 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 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?
> 
> 
> 
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users




More information about the sr-users mailing list