[sr-dev] cleaning up long lasting dialogs

Daniel-Constantin Mierla miconda at gmail.com
Wed Nov 5 15:00:52 CET 2014


Hello,

I thought of starting a dedicated thread to discuss the cleaning of
dialogs stuck for long time in a state that it shouldn't, following the
sr-dev debate on a commit from Alex (cc-ed).

Finding a root cause it is always the best, but some time it is hard or
even impossible given the nature of sip, where packets can be mis-routed
or overtake the order, or even sip is relying on changing state based on
timeouts. This is supposed to be last resort in dealing with exceptional
cases and be safe with memory and call limits.

Existing code was cleaning dialogs not answered for more than 5 min,
based on the fact that theoretically such case doesn't happen. At the
time of adding this, I reviewed that dialog and tm don't keep the
pointer for long time relying on reference counter, it such cases it
should clone the dialog id and lookup again.

Pointed by Alex, this is not completely if it happens that lookup of a
dialog in this special situation (staying too long in a state that
theoretically shouldn't be) is done when the cleanup task discovers the
anomaly.

My first thought to fix it is to track the last usage and based on it to
clean. So the condition to clean would become: dialog is too long in a
state that shouldn't be and last access to dialog was quite a while ago.

I am trying to figure out if anyone else thinks of different/better
solution.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 24-27, Berlin - http://www.asipto.com




More information about the sr-dev mailing list