15 Mar
2016
15 Mar
'16
5:29 a.m.
Hello,
On 15/03/16 09:16, Alex Balashov wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio World Conference, Berlin, May 18-20, 2016 - http://www.kamailioworld.com
[...]
However, I don't know what other dependencies it would have; are
branches not a part of TM state as well? Or is it just a question of
far too many data structures to dump/restore?
It is a ton of stuff there, from avps, xavps, flags, branch flags, the
list with changes done in request route, the list of changes done in
each branch_route, the list of changes per responses, last most relevant
response per branch. Those and other fields use shortcuts point in
existing buffers in memory, so they need to be converted in a form
suitable for storage and then restore ...
So storing full transaction info and restoring is not going to be easy,
of course, doable, it's open source, but will costs significant
resources. Also, there can be performance penalty if done for each
transaction and each change of state/content...
Tracking only some routing info for invite to help with cancels can
eventually done easier as suggested previously, even now.
Cheers,
Daniel
This is a thing of investing a lot of resources
to get a solution
for 0.01% or less, which in most of the cases sort out themselves
fairly nice.
Fair enough. I think you're probably right on that, I just wondered if
maybe there was a lower-hanging fruit option.
I do think you're right that the best mitigation for this problem is
probably to have two Kamailio servers and an externally settable (i.e.
via MI/RPC) $shv that allows one to take it "out of service", i.e.
reject all new requests. Let the calls bleed off, then restart it.
-- Alex