[SR-Users] Call in Progress Recovery in Redundancy
Daniel-Constantin Mierla
miconda at gmail.com
Wed Aug 12 11:58:10 CEST 2020
Hello,
Kamailio is not an end point, thus it does not answer the call, it is
only a SIP proxy (a node in the middle of the SIP signalling channel,
relaying the SIP messages between caller and callee sides).
Unless you develop code in both kamailio and freeswitch, there is no way
to have freeswitch recognize and handle a call was answered and not
routed through freeswitch in the first place.
Cheers,
Daniel
On 12.08.20 11:27, amitsharma at coraltele.com wrote:
>
> Hello Daniel,
>
>
>
> Please suggest is there any workout for this problem.
>
>
>
> Thanks,
>
> Amit Sharma
>
> *From:* amitsharma at coraltele.com <amitsharma at coraltele.com>
> *Sent:* Tuesday, August 11, 2020 11:13 AM
> *To:* 'miconda at gmail.com' <miconda at gmail.com>; 'Kamailio (SER) - Users
> Mailing List' <sr-users at lists.kamailio.org>
> *Subject:* RE: [SR-Users] Call in Progress Recovery in Redundancy
>
>
>
> Hello Daniel,
>
>
>
> Thanks once again for your reply and sorry for late reply from my side.
>
>
>
> From below point No. 2, I just want to understand that “Is Kamailio
> process DTMF or not”.
>
>
>
> Now we are working on a modal where Kamailio will be used as Proxy and
> Freeswitch as Media server. I am able to route calls from Kamailio to
> Freeswitch but my next requirement is that how to route call from
> Kamailio to Freeswitch only when call is getting answered in Kamailio.
> Now what is happening all the invite routing directly from Kamailio to
> Freeswitch.
>
>
>
> What I have done is attached in mail. I have added **# Freeswitch
> routing blocks** in Kamailio.cfg.
>
>
>
> Any help would be appreciated.
>
>
>
>
>
> Thanks,
>
> Amit Sharma
>
>
>
> *From:* Daniel-Constantin Mierla <miconda at gmail.com
> <mailto:miconda at gmail.com>>
> *Sent:* Thursday, August 6, 2020 11:25 PM
> *To:* amitsharma at coraltele.com <mailto:amitsharma at coraltele.com>;
> 'Kamailio (SER) - Users Mailing List' <sr-users at lists.kamailio.org
> <mailto:sr-users at lists.kamailio.org>>
> *Subject:* Re: [SR-Users] Call in Progress Recovery in Redundancy
>
>
>
> Hello,
>
> On 06.08.20 16:26, amitsharma at coraltele.com
> <mailto:amitsharma at coraltele.com> wrote:
>
> 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
>
>
>
> 2. How can capture sip-info from Kamailio to Freeswitch. Means
> DTMP pressed.
>
> I do not understand this one, maybe you can elaborate more.
>
> Cheers,
> Daniel
>
> 3.
>
>
>
> Thanks in advance.
>
>
>
> Amit Sharma
>
>
>
> *From:* Daniel-Constantin Mierla <miconda at gmail.com>
> <mailto:miconda at gmail.com>
> *Sent:* Wednesday, August 5, 2020 6:33 PM
> *To:* Kamailio (SER) - Users Mailing List
> <sr-users at lists.kamailio.org>
> <mailto:sr-users at lists.kamailio.org>; amitsharma at coraltele.com
> <mailto:amitsharma at 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 at coraltele.com
> <mailto: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 <mailto:sr-users at 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
>
> --
> 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
--
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/20200812/036cc662/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/20200812/036cc662/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/20200812/036cc662/attachment.png>
More information about the sr-users
mailing list