[SR-Users] How to cleanup unconfirmed dialog in memory?

Tue Jul 2 16:22:24 CEST 2013

Now that you mention it, it makes perfect sense since this function sends
BYE to both legs which only makes sense with confirmed dialogs.

I run out of alternatives. Maybe patching the module is the only solution.

Regards,
Carlos

On Tue, Jul 2, 2013 at 10:16 AM, Charles Chance <
charles.chance at sipcentric.com> wrote:

> That doesn't work I'm afraid. Also from
> http://www.kamailio.org/docs/modules/3.1.x/modules_k/dialog.html#id2524783
> :
>
> *Note: Works only for confirmed dialogs.*
>
>
> It's something I've been meaning to look further into for a while, but
> haven't yet had chance. I suspect a small patch will be required though.
>
> Regards,
>
> Charles
>
>
>
> On 2 July 2013 15:11, Carlos Ruiz Díaz <carlos.ruizdiaz at gmail.com> wrote:
>
>> Ok, I haven't noticed that, although I can't tell for sure whether it
>> will work or not.
>>
>> If you can dump the dialogs using xmlrpc or rpc interface, maybe you
>> could parse the info and tear down those unconfirmed dialogs using
>> dlg_end_dlg:
>>
>> http://www.kamailio.org/docs/modules/3.1.x/modules_k/dialog.html#id2524783
>>
>>
>> On Tue, Jul 2, 2013 at 10:02 AM, Charles Chance <
>> charles.chance at sipcentric.com> wrote:
>>
>>> The parameter does not work for us. We have modparam("dialog",
>>> "default_timeout",7200), but it only has an effect on confirmed dialogs. As
>>> you can see from my previous example, there is not even a "timestart" value
>>> on the unconfirmed dialog, so how can Kamailio know when timeout is
>>> reached?
>>>
>>>
>>>
>>> On 2 July 2013 14:51, Carlos Ruiz Díaz <carlos.ruizdiaz at gmail.com>wrote:
>>>
>>>> There is, but for all dialogs, not only the unconfirmed ones.
>>>>
>>>>
>>>> http://www.kamailio.org/docs/modules/3.3.x/modules_k/dialog.html#default-timeout-id
>>>>
>>>>
>>>> On Tue, Jul 2, 2013 at 9:49 AM, Charles Chance <
>>>> charles.chance at sipcentric.com> wrote:
>>>>
>>>>> 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 <hw at 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 at lists.sip-router.org
>>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Carlos
>>>> http://caruizdiaz.com
>>>> +595981146623
>>>>
>>>> _______________________________________________
>>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>>>> sr-users at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>>
>>>>
>>>
>>>
>>> --
>>> *Charles Chance*
>>> Managing Director
>>>
>>> t. 0121 285 4400    m. 07932 063 891
>>>
>>> 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 at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>>
>>>
>>
>>
>> --
>> Carlos
>> http://caruizdiaz.com
>> +595981146623
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>>
>
>
>
> 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>

-- 
Carlos
http://caruizdiaz.com
+595981146623
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130702/3a641d31/attachment-0001.html>