[SR-Users] Call in Progress Recovery in Redundancy

Wed Aug 5 15:03:24 CEST 2020

Hello,

first we need to clarify that it seems you are actually not looking for
redundancy of active transactions, which I tried to focus on the answer
during the ClueCon session last evening.

My answer there related to htable was about the ability to route CANCEL
requests where the INVITE was forwarded.

Like Julien replied on another email, SIP has couple of mechanism to
"recover" or "go through" in case of transaction states being lost. For
example, with UDP if the proxy is restarted after receiving the INVITE
and not sending any reply, then there is a retranmission of the INVITE
for couple of times (can be up to 30seconds or more, depending on UA
settings). So the INVITE comes again to the proxy, which can handle it
(assuming a fast enough restart). Then, if the INVITE was forwarded, the
responses to it can be routed without any problem, using the Via headers.

Considering that the SIP transaction is about keeping the states of
routing the request until a final response is sent out, one of the main
benefits is the ability to re-route the request to a new address if the
first selected destination doesn't answer (aka, serial forking). But if
you have one-to-one routing policy (like receiving from the phone and
sending to a freeswitch), then you can also do stateless forwarding. In
such case, if you migrate the ip to another Kamailio node, it can route
the replies even when the request was routed by previous active node.

As far as I can remember from some demos at past cluecon events, the
FreeSwitch call recovery was based on re-INVITEs, which means the call
has to be established to know where to send the re-INVITE, be aware of
caller/callee contact addresses, codecs, routing headers, ... Recovering
a progress call from a B2BUA like FreeSwitch can be as difficult as for
a proxy, if you want to cover over possible scenarios related to serial
and parallel forking, branches added on the fly when a new registration
comes in, different retransmission timers per branches, storage of most
relevant replies for branches, etc ... just to enumerate from the impact
on the SIP specification, but each application has a lot of event
callbacks, structures and parameters associated with a transaction
(e.g., for accounting, message logging, ...), ... so the eco-system
around a SIP transaction is very fluid, shifting to another node could
be impossible.

For example, consider that first retransmission has to be done in 500ms,
followed by 1sec, 2sec, 4sec -- in a case of a shared IP active-standby
system, detection that node is done typically takes a few seconds
itself, so retransmission steps can be lost for sure.

Kamailio itself is not a B2BUA so it cannot re-INVITE inside a call, but
many Kamailio systems can route SIP requests/replies from the same call
(e.g., INVITE routed by Kamailio A and the BYE by Kamailio B), it is a
matter of what you set in Record-Route headers, or do anycast routing to
a cluster of Kamailio nodes. When you hear about getting out of the
call, is about RTP (audio/video) streams, because from signaling point
of view, a B2BUA is an endpoint in each of the two legs of the calls, it
can do re-INVITE to move RTP streams to be end-to-end, but it has to
stay in the signaling path. An endpoint can get out of the call via a
transfer to another endpoint, but then it cannot transfer the call back
to it.

Also, let's say the call is completed without going to freeswitch with
the initial INVITE, afterward you cannot hand it over to Freeswitch. But
you can route initial INVITE to Kamailio, do not do record-routing, and
send it to freeswitch. By not doing record-routing, requests within
dialog (re-INVITE, BYE, etc..) and not coming to Kamailio, they go
directly to FreeSwitch. But you have to be careful with natted devices,
typically they can get messages back only from the box where they sent
the initial INVITE.

The discussion can be long here, as I tried to say, if you have the very
simple scenario of one-to-one routing rule, then even going
(sip-transaction-)stateless can work, but to cover all cases with
parallel/serial forking and multiple active branches at different stages
of processing is not working.

My feeling is that you were thinking from your experience with
freeswitch/b2bua systems, where when you restart the b2bua in a ringing
state the call does not complete. But if use Kamailio to route the call
from Alice to Bob, it gets to ringing state, then you can restart
kamailio and call gets completed (the answer -- the 200ok response -- is
routed by Kamailio correctly). Of course, depending on what other
modules you use, some specific processing may be lost for such calls,
but case by case, there can be solutions.

Cheers,
Daniel

On 05.08.20 12:36, amitsharma at coraltele.com wrote:
>
> Dear Daniel/Team,
>
>  
>
> I had raised one question in “Workshop 3 – Kamailio” at Cluecon
> 2020(Last Night), i.e. Can Progress Call(Ringing Calls) be recovered
> in case of redundancy with Kamailio. You were told me that straight
> way it is not possible but try with hash table once. I had tried
> following link
> https://wazo-platform.org/blog/kamailio-ha-dispatcher-and-dmq and able
> to recover Call in progress within 2-3 nodes.
>
>  
>
>  1. My one question is that either this approach will work in
>     production or not.
>  2. I have been using Freeswitch for last 6-7 years but “Call in
>     Progress Recovery in Redundancy” is not possible there in
>     “Freeswitch”, So I tried Kamailio and got success. My Second
>     question is that can it be possible that Call established on
>     Kamailio and after call set up Kamailio leave that call and handed
>     over it to Freeswitch for further processing(Like Re-homing
>     available in OpenSIPS). This will save years of time that I have
>     invested building features around Freeswitch.
>
>  
>
> Please suggest me the best way possible to achieve this.
>
>  
>
>  
>
>  
>
> *Thanks & Regards,*
>
> *Amit Sharma*
>
> *(Sr. Team Leader)*
>
> * *
>
>  Copy of 34643416.jpg
>
>
> *(An ISO 9001:2008 company)*
>
>  
>
> *Mobile: tel:9891612004*
>
> *PH:  +91 120 2595870*
>
> *Ext.: tel:870*
>
> *Email : amitsharma at coraltele.com <mailto:amitsharma at coraltele.com>*
>
> Web : *www.coraltele.com* <blocked::http://www.coraltele.com>
>
>  
>
> https://docs.google.com/uc?export=download&id=0BwYYBqN87-tfM2JiYmhMSFdSZkk&revid=0BwYYBqN87-tfZW5iNExpazJqc01WUDZpOWFXd09SakhuUWJRPQ
>
>  
>
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200805/9be05e92/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2177 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200805/9be05e92/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.png
Type: image/png
Size: 2232 bytes
Desc: not available
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20200805/9be05e92/attachment.png>