Hi,
I have a question regarding calls and Kamailio restarts.
Suppose Kamailio crashes (and started again), is restarted or failed over to a different server (same IP). What then happens with calls?
Let's suppose the following scenario:
- 1000 calls active on the machine
- Some are in call setup, some are in call, some are in teardown phases
- The proxy is stateful
- The proxy forwards calls from B2BUA machines to an ITSP (outbound only)
- Uses record-routing
- Uses loose routing
What will be the likely outcome of the restart with regards to the calls in the different phases and accounting for said calls?
All the best,
Samuel
On Wed, Jul 12, 2017 at 09:05:27AM +0000, Samuel F. wrote:
Suppose Kamailio crashes (and started again), is restarted or failed over to a different server (same IP). What then happens with calls?
Speaking generically, not a lot.
All SIP messages passing through the proxy can be forwarded statelessly and based on properties of the SIP message alone. This may break route advance or failover scenarios reliant on state, but it will not break the fundamental end-to-end SIP message reachability. In other words, a proxy restart does not fundamentally prevent subsequent signalling for the same call, or even subsequent messages within an open transaction, from reaching their intended destination.
"Loose routing" and "record routing" are not opposed; loose routing is a concept that incorporates Route header processing.
The impact on accounting will depend on whether the accounting is done with recourse to TM or dialog state, which exists in runtime, or in a stateless manner based on received SIP messages.
-- Alex
Hi,
On Wed, Jul 12, 2017 at 11:53 AM, Alex Balashov abalashov@evaristesys.com wrote:
All SIP messages passing through the proxy can be forwarded statelessly and based on properties of the SIP message alone.
There's one thing that could happen: Calls that get cancelled after a restart, could possibly keep on ringing on the far end. At least if you check for an active transaction in your kamailio config.
if (!t_check_trans()) { sl_send_reply("481", "Call/Transaction does not exist"); xlog("L_ERR", "CANCEL: found no matching transaction F=$fu T=$tu R=$ru\n"); return; }
And if you do some sort of random dispatching, CANCELs could end up on a different gateway.
But other than that, a restart shouldn't cause much trouble. Especially in-call requests get routed by Route headers only.
Regards, Sebastian
Thank you for the responses! As a follow up question, how do companies with large loads on their Kamailios handle restarts especially considering the CANCELs?
What is a good (business) process to restart a Kamailio without incurring any interruptions at all? What other components in the infrastructure would be in place and which ones are in use in the wild?
// Samuel
________________________________ From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Sebastian Damm damm@sipgate.de Sent: Thursday, July 13, 2017 2:39:39 PM To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] What happens to calls when Kamailio restarts?
Hi,
On Wed, Jul 12, 2017 at 11:53 AM, Alex Balashov abalashov@evaristesys.com wrote:
All SIP messages passing through the proxy can be forwarded statelessly and based on properties of the SIP message alone.
There's one thing that could happen: Calls that get cancelled after a restart, could possibly keep on ringing on the far end. At least if you check for an active transaction in your kamailio config.
if (!t_check_trans()) { sl_send_reply("481", "Call/Transaction does not exist"); xlog("L_ERR", "CANCEL: found no matching transaction F=$fu T=$tu R=$ru\n"); return; }
And if you do some sort of random dispatching, CANCELs could end up on a different gateway.
But other than that, a restart shouldn't cause much trouble. Especially in-call requests get routed by Route headers only.
Regards, Sebastian
_______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Yeah, Sebastian is quite right. CANCELs do make for an especially challenging case, since they are hop-by-hop. Kamailio has to have some transaction state in order to have an idea of where to relay them.
A good business process is to have two Kamailio instances, tried by all gateways on all sides if the primary is unavailable (whether by means of SRV or just statically configured secondary gateway entries) and some option, set externally at runtime (for example, using $shv() shared variables), which causes Kamailio to refuse further calls. Existing calls would drain off the system, new calls would fail over to the other Kamailio, and then you can restart it.
On Thu, Jul 13, 2017 at 06:22:55PM +0000, Samuel F. wrote:
Thank you for the responses! As a follow up question, how do companies with large loads on their Kamailios handle restarts especially considering the CANCELs?
What is a good (business) process to restart a Kamailio without incurring any interruptions at all? What other components in the infrastructure would be in place and which ones are in use in the wild?
// Samuel
From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Sebastian Damm damm@sipgate.de Sent: Thursday, July 13, 2017 2:39:39 PM To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] What happens to calls when Kamailio restarts?
Hi,
On Wed, Jul 12, 2017 at 11:53 AM, Alex Balashov abalashov@evaristesys.com wrote:
All SIP messages passing through the proxy can be forwarded statelessly and based on properties of the SIP message alone.
There's one thing that could happen: Calls that get cancelled after a restart, could possibly keep on ringing on the far end. At least if you check for an active transaction in your kamailio config.
if (!t_check_trans()) { sl_send_reply("481", "Call/Transaction does not exist"); xlog("L_ERR", "CANCEL: found no matching transaction F=$fu T=$tu R=$ru\n"); return; }
And if you do some sort of random dispatching, CANCELs could end up on a different gateway.
But other than that, a restart shouldn't cause much trouble. Especially in-call requests get routed by Route headers only.
Regards, Sebastian
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
That said, while there are doubtless some environments so large that this becomes a significant business question, I would think carefully about whether this problem is truly worth solving before designing any overly Rube-Goldbergian coping mechanism.
So, CANCELs for a small amount of calls in flight don't make it out the door. Big deal? The two endpoints will sooner rather than later, by various kinds of dead peer detection, discover that the other end is dead. If you restart during a quiet / low-volume time, you can probably keep this sort of thing to a minimum.
If it truly counts, by all means do it, but in my experience there are a lot of folks with "high volume" ideas that are more fantasy than reality who spend a lot of capital designing and optimising for availability scenarios that never turn out to be a problem. I don't know how many times I have heard in Kamailio consulting work that this registrar needs to support five million endpoints and never be down and ... well, that bridge is just never remotely crossed. Off by a few orders of magnitude. :-)
-- Alex
On Thu, Jul 13, 2017 at 06:22:55PM +0000, Samuel F. wrote:
Thank you for the responses! As a follow up question, how do companies with large loads on their Kamailios handle restarts especially considering the CANCELs?
What is a good (business) process to restart a Kamailio without incurring any interruptions at all? What other components in the infrastructure would be in place and which ones are in use in the wild?
// Samuel
From: sr-users sr-users-bounces@lists.kamailio.org on behalf of Sebastian Damm damm@sipgate.de Sent: Thursday, July 13, 2017 2:39:39 PM To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] What happens to calls when Kamailio restarts?
Hi,
On Wed, Jul 12, 2017 at 11:53 AM, Alex Balashov abalashov@evaristesys.com wrote:
All SIP messages passing through the proxy can be forwarded statelessly and based on properties of the SIP message alone.
There's one thing that could happen: Calls that get cancelled after a restart, could possibly keep on ringing on the far end. At least if you check for an active transaction in your kamailio config.
if (!t_check_trans()) { sl_send_reply("481", "Call/Transaction does not exist"); xlog("L_ERR", "CANCEL: found no matching transaction F=$fu T=$tu R=$ru\n"); return; }
And if you do some sort of random dispatching, CANCELs could end up on a different gateway.
But other than that, a restart shouldn't cause much trouble. Especially in-call requests get routed by Route headers only.
Regards, Sebastian
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
The instance which is closed supports the onhoing sessions,means calls arent dropped
On 12-Jul-2017 3:02 PM, "Samuel F." samuel_is_kewl@hotmail.com wrote:
Hi,
I have a question regarding calls and Kamailio restarts.
Suppose Kamailio crashes (and started again), is restarted or failed over to a different server (same IP). What then happens with calls?
Let's suppose the following scenario:
1000 calls active on the machine
Some are in call setup, some are in call, some are in teardown phases
The proxy is stateful
The proxy forwards calls from B2BUA machines to an ITSP (outbound only)
Uses record-routing
Uses loose routing
What will be the likely outcome of the restart with regards to the calls in the different phases and accounting for said calls?
All the best,
Samuel
Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
-
Alex Balashov -
Samuel F. -
Sebastian Damm -
shubh diwase