<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Hello,</p>
<p>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.</p>
<p>My answer there related to htable was about the ability to route
CANCEL requests where the INVITE was forwarded.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Cheers,<br>
Daniel<br>
</p>
<div class="moz-cite-prefix">On 05.08.20 12:36,
<a class="moz-txt-link-abbreviated" href="mailto:amitsharma@coraltele.com">amitsharma@coraltele.com</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:005d01d66b14$540c2b90$fc2482b0$@coraltele.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1706633518;
mso-list-type:hybrid;
mso-list-template-ids:-842757382 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
{mso-level-text:"%1\)";
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level4
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
@list l0:level7
{mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-number-format:roman-lower;
mso-level-tab-stop:none;
mso-level-number-position:right;
text-indent:-9.0pt;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Dear Daniel/Team,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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 <a
href="https://wazo-platform.org/blog/kamailio-ha-dispatcher-and-dmq"
moz-do-not-send="true">https://wazo-platform.org/blog/kamailio-ha-dispatcher-and-dmq</a>
and able to recover Call in progress within 2-3 nodes.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ol style="margin-top:0in" type="1" start="1">
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo1">My one
question is that either this approach will work in
production or not.<o:p></o:p></li>
<li class="MsoListParagraph"
style="margin-left:0in;mso-list:l0 level1 lfo1">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.<o:p></o:p></li>
</ol>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Please suggest me the best way possible to
achieve this.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:gray">Thanks
& Regards,<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:gray">Amit
Sharma<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:gray">(Sr.
Team Leader)<o:p></o:p></span></b></p>
<p class="MsoNormal"><b><span style="color:#1F497D"><o:p> </o:p></span></b></p>
<p class="MsoNormal"><span style="color:gray"> </span><span
style="color:#1F497D"><img style="width:.9083in;height:.6in"
id="Picture_x0020_1"
src="cid:part2.F453BA6B.908F9CE0@gmail.com" alt="Copy of
34643416.jpg" class="" width="87" height="58" border="0"></span><span
style="color:#1F497D" lang="EN-IN"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:gray"><br>
</span><b><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:gray">(An
ISO 9001:2008 company)</span></b><span
style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:gray"> </span><span
style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:gray">Mobile:
<a href="tel:9891612004" moz-do-not-send="true"><span
style="color:blue">tel:9891612004</span></a></span></b><span
style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:gray">PH:
+91 120 2595870</span></b><span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:gray">Ext.:
<a href="tel:870" moz-do-not-send="true"><span
style="color:blue">tel:870</span></a></span></b><span
style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><b><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:gray">Email
: <a href="mailto:amitsharma@coraltele.com"
moz-do-not-send="true"><span style="color:blue">amitsharma@coraltele.com</span></a></span></b><span
style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:gray">Web : <a
href="blocked::http://www.coraltele.com"
title="http://www.coraltele.com
blocked::http://www.polycom.com/" moz-do-not-send="true"><b><span
style="font-size:10.0pt;font-family:"Arial",sans-serif;color:gray">www.coraltele.com</span></b></a></span><span
style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="color:#44546A"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="color:black"><img
style="width:5.075in;height:.25in" id="Picture_x0020_2"
src="cid:part7.B244597E.C550475D@gmail.com"
alt="https://docs.google.com/uc?export=download&id=0BwYYBqN87-tfM2JiYmhMSFdSZkk&revid=0BwYYBqN87-tfZW5iNExpazJqc01WUDZpOWFXd09SakhuUWJRPQ"
class="" width="487" height="24" border="0"></span><span
style="color:#44546A"><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Kamailio (SER) - Users Mailing List
<a class="moz-txt-link-abbreviated" href="mailto:sr-users@lists.kamailio.org">sr-users@lists.kamailio.org</a>
<a class="moz-txt-link-freetext" href="https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users">https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre>
</blockquote>
<pre class="moz-signature" cols="72">--
Daniel-Constantin Mierla -- <a class="moz-txt-link-abbreviated" href="http://www.asipto.com">www.asipto.com</a>
<a class="moz-txt-link-abbreviated" href="http://www.twitter.com/miconda">www.twitter.com/miconda</a> -- <a class="moz-txt-link-abbreviated" href="http://www.linkedin.com/in/miconda">www.linkedin.com/in/miconda</a>
Funding: <a class="moz-txt-link-freetext" href="https://www.paypal.me/dcmierla">https://www.paypal.me/dcmierla</a></pre>
</body>
</html>