dialog doesn't clear calls that were re-INVITEd shortly after ACK
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?
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
participants (1)
-
Andrew Pogrebennyk