Re: [SR-Users] Dialogs not removed from memory, and occasionally persistent in DB as well

On 2012-01-20 at 23:32, Timo Reimann wrote: Hi and sorry for the late response! > Another possible root cause: After calling dlg_manage() on an INVITE, you > do not forward the request (e.g., by calling exit() instead). Could that > be the case? If so, the solution would be (again) to defer dialog > tracking unless you're sure the INVITE will be routed. Thanks, this was indeed at least the main problem! We have no replaced a lot of sl_send_reply("123", "message") with t_newtran() + t_reply("123","message") before exit(), and that solved most of the hanging dialogs. These were by the way hanging in state 1. > If not, the last thing I can think of to try is to do some tracing (using > ngrep or tcpdump, for example) and attempt to catch a dialog that > dangles. If you succeed at that, analyzing the trace will probably help > in determining the issue. We still have a few calls, probably one to two a day, which get stuck in state 4. They have proper INVITE, 200 OK and later BYE. We have tracked the problem down to that once in a while Asterisk, our bridge to PSTN, issues double INVITEs at the extact same time for the same call and in this case there seem to be a race within Kamailio. The call is properly setup and termitated, but the entry is still in the dialog table. Any ideas how to cope with the double INVITEs? We do btw use dlg_match_mode = 1, as we used that in Kamailio 1.5 and that worked like a charm. Have not tested altering it to either 0 or 2.