5 Aug
2020
5 Aug
'20
1:36 p.m.
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)
(An ISO 9001:2008 company)
Mobile: <tel:9891612004> tel:9891612004
PH: +91 120 2595870
Ext.: <tel:870> tel:870
Email : <mailto:amitsharma@coraltele.com> amitsharma(a)coraltele.com
Web : <blocked::http://www.coraltele.com> www.coraltele.com
5 Aug
5 Aug
4:03 p.m.
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 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
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
6 Aug
6 Aug
5:26 p.m.
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.
2. How can capture sip-info from Kamailio to Freeswitch. Means DTMP
pressed.
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)
(An ISO 9001:2008 company)
Mobile: <tel:9891612004> tel:9891612004
PH: +91 120 2595870
Ext.: <tel:870> tel:870
Email : <mailto:amitsharma@coraltele.com> amitsharma(a)coraltele.com
Web : <blocked::http://www.coraltele.com> www.coraltele.com
_______________________________________________
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
8:54 p.m.
Hello,
On 06.08.20 16:26, amitsharma(a)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
1. 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
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
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
11 Aug
11 Aug
8:43 a.m.
Hello Danial,
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(a)gmail.com>
Sent: Thursday, August 6, 2020 11:25 PM
To: amitsharma(a)coraltele.com; 'Kamailio (SER) - Users Mailing List'
<sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Call in Progress Recovery in Redundancy
Hello,
On 06.08.20 16:26, amitsharma(a)coraltele.com
<mailto:amitsharma@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 <mailto:miconda@gmail.com>
<miconda(a)gmail.com>
Sent: Wednesday, August 5, 2020 6:33 PM
To: Kamailio (SER) - Users Mailing List
<mailto:sr-users@lists.kamailio.org> <sr-users(a)lists.kamailio.org>rg>;
amitsharma(a)coraltele.com <mailto:amitsharma@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)
(An ISO 9001:2008 company)
Mobile: <tel:9891612004> tel:9891612004
PH: +91 120 2595870
Ext.: <tel:870> tel:870
Email : <mailto:amitsharma@coraltele.com> amitsharma(a)coraltele.com
Web : <blocked::http://www.coraltele.com> www.coraltele.com
_______________________________________________
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
--
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
12 Aug
12 Aug
2:43 p.m.
You should first train youself about SIP, Kamailio It's a SIP-Proxy/Router, It
doesn't "answer" calls ... It's just sitting in the SIP signaling path
of the call.
About DTMF, the same ... if you use SIP-INFO for DTMF, you will see them routed throught
Kamailio, but anything more.
You have a very deeply missundestunding of what Kamailio do/could do or is used for.
From: amitsharma(a)coraltele.com
To: miconda(a)gmail.com, "Kamailio" <sr-users(a)lists.kamailio.org>
Sent: Tuesday, August 11, 2020 6:43:07 AM
Subject: Re: [SR-Users] Call in Progress Recovery in Redundancy
Hello Danial,
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(a)gmail.com>
Sent: Thursday, August 6, 2020 11:25 PM
To: amitsharma(a)coraltele.com; 'Kamailio (SER) - Users Mailing List'
<sr-users(a)lists.kamailio.org>
Subject: Re: [SR-Users] Call in Progress Recovery in Redundancy
Hello,
On 06.08.20 16:26, [ mailto:amitsharma@coraltele.com | amitsharma(a)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
BQ_BEGIN
1. How can capture sip-info from Kamailio to Freeswitch. Means DTMP pressed.
BQ_END
I do not understand this one, maybe you can elaborate more.
Cheers,
Daniel
BQ_BEGIN
1.
Thanks in advance.
Amit Sharma
From: Daniel-Constantin Mierla [ mailto:miconda@gmail.com | <miconda(a)gmail.com> ]
Sent: Wednesday, August 5, 2020 6:33 PM
To: Kamailio (SER) - Users Mailing List [ mailto:sr-users@lists.kamailio.org |
<sr-users(a)lists.kamailio.org> ] ; [ mailto:amitsharma@coraltele.com |
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, [ mailto:amitsharma@coraltele.com | amitsharma(a)coraltele.com ] wrote:
BQ_BEGIN
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 |
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)
(An ISO 9001:2008 company)
Mobile: [ tel:9891612004 | tel:9891612004 ]
PH: +91 120 2595870
Ext.: [ tel:870 | tel:870 ]
Email : [ mailto:amitsharma@coraltele.com | amitsharma(a)coraltele.com ]
Web : [ blocked::http://www.coraltele.com | www.coraltele.com ]
_______________________________________________
Kamailio (SER) - Users Mailing List
[ mailto:sr-users@lists.kamailio.org | sr-users(a)lists.kamailio.org ]
[ https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users |
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users ]
BQ_END
--
Daniel-Constantin Mierla -- [ http://www.asipto.com/ | www.asipto.com ]
[ http://www.twitter.com/miconda | www.twitter.com/miconda ] -- [
http://www.linkedin.com/in/miconda | www.linkedin.com/in/miconda ]
Funding: [ https://www.paypal.me/dcmierla | https://www.paypal.me/dcmierla ]
BQ_END
--
Daniel-Constantin Mierla -- [ http://www.asipto.com/ | www.asipto.com ]
[ http://www.twitter.com/miconda | www.twitter.com/miconda ] -- [
http://www.linkedin.com/in/miconda | www.linkedin.com/in/miconda ]
Funding: [ https://www.paypal.me/dcmierla | https://www.paypal.me/dcmierla ]
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
12:27 p.m.
Hello Daniel,
Please suggest is there any workout for this problem.
Thanks,
Amit Sharma
From: amitsharma(a)coraltele.com <amitsharma(a)coraltele.com
Sent: Tuesday, August 11, 2020 11:13 AM
To: 'miconda(a)gmail.com' <miconda(a)gmail.com>om>; 'Kamailio (SER) - Users
Mailing
List' <sr-users(a)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.
Sent: Thursday, August 6, 2020 11:25 PM
To: amitsharma(a)coraltele.com <mailto:amitsharma@coraltele.com> ; 'Kamailio
(SER) - Users Mailing List' <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org> >
Subject: Re: [SR-Users] Call in Progress Recovery in Redundancy
Hello,
On 06.08.20 16:26, amitsharma(a)coraltele.com
<mailto:amitsharma@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 <mailto:miconda@gmail.com>
<miconda(a)gmail.com Sent: Wednesday,
August 5, 2020 6:33 PM
To: Kamailio (SER) - Users Mailing List
<mailto:sr-users@lists.kamailio.org> <sr-users(a)lists.kamailio.org>rg>;
amitsharma(a)coraltele.com <mailto:amitsharma@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)
(An ISO 9001:2008 company)
Mobile: <tel:9891612004> tel:9891612004
PH: +91 120 2595870
Ext.: <tel:870> tel:870
Email : <mailto:amitsharma@coraltele.com> amitsharma(a)coraltele.com
Web : <blocked::http://www.coraltele.com> www.coraltele.com
_______________________________________________
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
--
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
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(a)gmail.com <mailto:miconda@gmail.com>
12:58 p.m.
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(a)coraltele.com wrote:
Hello Daniel,
Please suggest is there any workout for this problem.
Thanks,
Amit Sharma
*From:* amitsharma(a)coraltele.com <amitsharma(a)coraltele.com>
*Sent:* Tuesday, August 11, 2020 11:13 AM
*To:* 'miconda(a)gmail.com' <miconda(a)gmail.com>om>; 'Kamailio (SER) - Users
Mailing List' <sr-users(a)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(a)gmail.com
<mailto:miconda@gmail.com>>
*Sent:* Thursday, August 6, 2020 11:25 PM
*To:* amitsharma(a)coraltele.com <mailto:amitsharma@coraltele.com>;
'Kamailio (SER) - Users Mailing List' <sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>>
*Subject:* Re: [SR-Users] Call in Progress Recovery in Redundancy
Hello,
On 06.08.20 16:26, amitsharma(a)coraltele.com
<mailto:amitsharma@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(a)gmail.com>
<mailto:miconda@gmail.com>
*Sent:* Wednesday, August 5, 2020 6:33 PM
*To:* Kamailio (SER) - Users Mailing List
<sr-users(a)lists.kamailio.org>
<mailto:sr-users@lists.kamailio.org>; amitsharma(a)coraltele.com
<mailto:amitsharma@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
--
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
1565
days inactive
1572
days old
7 comments
3 participants
participants (3)
-
amitsharma＠coraltele.com -
Daniel-Constantin Mierla -
Raúl Alexis Betancor Santana