Hello Daniel,
Thank a lot for such an elaborative reply, it will really help in many
ways. It is clear that in case of big system the Progress call
transition may not be possible.
I want to know two more things :
1. Can we built Re-Homing around Kamailio (Move call from Kamailio to
Freeswitch). Is there any possibility of doing it.
Both applications are open source and you can develop extensions in both
of them to share call data and maybe you will get what you want. But
from the SIP specification, there is no mechanism to migrate a server
from a proxy (like Kamailio) to an endpoint/b2bua like FreeSwitch.
Therefore at this moment is no option to do that.
As I mentioned, another kamailio can route just fine requests belonging
to a call initiated via another Kamailio. FreeSwitch (or other
B2BUA/endpoint) can do re-INVITE and recover the call after a crash and
restart on the same system or on another system, but that because it was
part of the call and it is allowed to change its contact/IP address
1. How can capture sip-info from Kamailio to Freeswitch. Means DTMP
pressed.
1.
Thanks in advance.
Amit Sharma
*From:* Daniel-Constantin Mierla <miconda(a)gmail.com>
*Sent:* Wednesday, August 5, 2020 6:33 PM
*To:* Kamailio (SER) - Users Mailing List
<sr-users(a)lists.kamailio.org>rg>; amitsharma(a)coraltele.com
*Subject:* Re: [SR-Users] Call in Progress Recovery in Redundancy
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(a)coraltele.com
<mailto:amitsharma@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(a)coraltele.com <mailto:amitsharma@coraltele.com>*
Web : *www.coraltele.com* <blocked::http://www.coraltele.com>
https://docs.google.com/uc?export=download&id=0BwYYBqN87-tfM2JiYmhMSFdS…
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla --
www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Funding:
https://www.paypal.me/dcmierla