[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