Hmm, I don't think there is even a timeout value set on unconfirmed dialogs in memory.
Example (Kamailio 3.3.3): dialog:: hash=1791:10106 state:: 1 ref_count:: 1 timestart:: 0 timeout:: 0 ... Whereas: dialog:: hash=2963:2808 state:: 4 ref_count:: 2 timestart:: 1372772302 timeout:: 114829207 ... Therefore, the unconfirmed dialogs never get cleared automatically, in my experience at least. I hope I'm wrong though :) Cheers, Charles On 2 July 2013 14:31, Henning Westerholt <h...@kamailio.org> wrote: > Am Dienstag, 2. Juli 2013, 14:23:25 schrieb Charles Chance: > > I don't think this will help at all, as regardless of DB mode, > unconfirmed > > dialogs are not stored in DB anyway. > > > > The important thing to remember is that if you are calling > dialog_manage() > > in your config, to only do it once you are ready to forward the request. > If > > you call it but then exit for some reason without actually forwarding, > you > > will probably end up with a stuck dialog. > > > > Maybe someone else can suggest other possible causes? > > > > To my knowledge, there is no existing way to clear these without > restarting. > > Hello, > > AFAIK these stale dialogs are cleaned up after the dialog timeout. There > are > module parameter and also dialog specific parameter to control this > variable. > This stale dialogs needs a bit of memory, but are otherwise harmless. > > Best regards, > > Henning > -- www.sipcentric.com Follow us on twitter @sipcentric <http://twitter.com/sipcentric> Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham B7 4EJ.
_______________________________________________ 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
