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@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? > > > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
