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

[Øyvind Kolbu]

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.

-- 
Øyvind Kolbu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20120131/1c927a5d/attachment.pgp>