[SR-Users] Kamailio 5.0 - Better way of dealing with stateless CANCELs

[Daniel-Constantin Mierla]

Hello,

On 15/03/16 09:16, Alex Balashov wrote:
> [...]
>
> 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
>

-- 
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