Failover in Dialplan
Moderator: Brekeke Support Team
Failover in Dialplan
1. Brekeke Product Name and Version:
SIP Serer 3.8.6.4
2. Java version:
1.8.0_181
3. OS type and the version:
Windows 7 Pro SP1
4. UA (phone), gateway or other hardware/software involved:
Various, including 3CX
5. Your problem:
In the Wiki, it shows a basic dialplan failover like this:
[Deploy Patterns]
To = sip:100@192.168.0.100
$session = failover sip:101@192.168.0.101 sip:102@192.168.0.102
Does this mean that after the INVITE Timeout or if an SIP error is received before the INVITE timeout, that the dialplan will try the first IP address in the $session string and then if that one doesn't work, the dialplan will try the second IP address in the $session string?
Somewhere I came up with the idea of using a $session string for each failover IP address, like this:
$session = failover sip:101@192.168.0.101
$session = failover sip:102@192.168.0.102
Is this not correct? Or does it matter (will each do the same thing)?
Also, there's an example of failover for specific error codes or groups of error codes, such as:
[Deploy Patterns]
To = sip:100@192.168.0.100
$session = failover sip:101@192.168.0.101
&failover.pattern.response = 4..
Is it possible to watch for multiple error codes or groups of error codes, such as 4.. OR 5.., such as the following?
[Deploy Patterns]
To = sip:100@192.168.0.100
$session = failover sip:101@192.168.0.101
&failover.pattern.response = 4.. OR 5..
John Rayfield, Jr.
SIP Serer 3.8.6.4
2. Java version:
1.8.0_181
3. OS type and the version:
Windows 7 Pro SP1
4. UA (phone), gateway or other hardware/software involved:
Various, including 3CX
5. Your problem:
In the Wiki, it shows a basic dialplan failover like this:
[Deploy Patterns]
To = sip:100@192.168.0.100
$session = failover sip:101@192.168.0.101 sip:102@192.168.0.102
Does this mean that after the INVITE Timeout or if an SIP error is received before the INVITE timeout, that the dialplan will try the first IP address in the $session string and then if that one doesn't work, the dialplan will try the second IP address in the $session string?
Somewhere I came up with the idea of using a $session string for each failover IP address, like this:
$session = failover sip:101@192.168.0.101
$session = failover sip:102@192.168.0.102
Is this not correct? Or does it matter (will each do the same thing)?
Also, there's an example of failover for specific error codes or groups of error codes, such as:
[Deploy Patterns]
To = sip:100@192.168.0.100
$session = failover sip:101@192.168.0.101
&failover.pattern.response = 4..
Is it possible to watch for multiple error codes or groups of error codes, such as 4.. OR 5.., such as the following?
[Deploy Patterns]
To = sip:100@192.168.0.100
$session = failover sip:101@192.168.0.101
&failover.pattern.response = 4.. OR 5..
John Rayfield, Jr.
Forgot a couple of other questions...
I've also seen $target used for failover in a dialplan.
What are the advantages and/or disadvantages of using $target instead of $session = failover?
I'm also unclear as to what &failover.timer.provisional affects. I've seen that used with the $session = failover string.
John Rayfield, Jr.
I've also seen $target used for failover in a dialplan.
What are the advantages and/or disadvantages of using $target instead of $session = failover?
I'm also unclear as to what &failover.timer.provisional affects. I've seen that used with the $session = failover string.
John Rayfield, Jr.
> Does this mean that after the INVITE Timeout or if an SIP error is received before the INVITE timeout, that the dialplan will try the first IP address in the $session string and then if that one doesn't work, the dialplan will try the second IP address in the $session string?
YES
> Is this not correct?
Right, it is not correct
> &failover.pattern.response = 4.. OR 5..
&failover.pattern.response = [45]..
YES
> Is this not correct?
Right, it is not correct
> &failover.pattern.response = 4.. OR 5..
&failover.pattern.response = [45]..
Note $target doesn't replace From/To headers while Failover plugin does automatically.
$target can be used if you want to keep original From/To headers and
forward SIP packets to another SIP server. (as SBC).
> What about the advantages and/or disadvantages of using $target instead of $session = failover?
Advantages:
$target is implemented inside the proxy engine so it doesn't require any plugin. It means you can use $target with any custom Session Plugin.
(because $session variable can be used only once, you can not use another Session plugin if you use $session=failover together. )
> &failover.timer.provisional
It is the timeout for waiting for a provisional response (1xx)
$target can be used if you want to keep original From/To headers and
forward SIP packets to another SIP server. (as SBC).
> What about the advantages and/or disadvantages of using $target instead of $session = failover?
Advantages:
$target is implemented inside the proxy engine so it doesn't require any plugin. It means you can use $target with any custom Session Plugin.
(because $session variable can be used only once, you can not use another Session plugin if you use $session=failover together. )
> &failover.timer.provisional
It is the timeout for waiting for a provisional response (1xx)
It is not easy but possible.
FYI: https://en.wikipedia.org/wiki/Regular_expression
A provisional Responses such as 180 is always passed.
Code: Select all
&failover.pattern.response = ^([46]..)|(5[1-9].)|(50[^3])
A provisional Responses such as 180 is always passed.
Another question.
I need that the SIP/URIs that are passed as arguments of the failover plugin has URI-parameters.
For example:
failover <sip:218001@192.168.1.26:5060;cd40rs=R2>
But I can see that the INVITE that is sent does not have the parameter in the REQUEST nor in the "To" header.
Is there any way to do it?
I need that the SIP/URIs that are passed as arguments of the failover plugin has URI-parameters.
For example:
failover <sip:218001@192.168.1.26:5060;cd40rs=R2>
But I can see that the INVITE that is sent does not have the parameter in the REQUEST nor in the "To" header.
Is there any way to do it?
Try like this.. It puts a packet back to DialPlan again.
Rule-1:
[Matching Patterns]
$request = ^INVITE
$localhost = ^true
To = sip:spiral-(.+)@
[Deploy Patterns]
To = <sip:%1@192.168.1.26:5060;cd40rs=R2>
Rule-2:
[Matching Patterns]
$request = ^INVITE
[Deploy Patterns]
To = sip:111@
$session = failover sip:spiral-218001@localhost
First, the rule-2 is executed and sends INVITE to sip:spiral-218001@localhost virtually.
Second, the rule-1 is executed, because the INVITE was sent to localhost and the prefix "spiral-" is found. The rule-2 sends INVITE to 192.168.1.26 as <sip:218001@192.168.1.26:5060;cd40rs=R2>
Rule-1:
[Matching Patterns]
$request = ^INVITE
$localhost = ^true
To = sip:spiral-(.+)@
[Deploy Patterns]
To = <sip:%1@192.168.1.26:5060;cd40rs=R2>
Rule-2:
[Matching Patterns]
$request = ^INVITE
[Deploy Patterns]
To = sip:111@
$session = failover sip:spiral-218001@localhost
First, the rule-2 is executed and sends INVITE to sip:spiral-218001@localhost virtually.
Second, the rule-1 is executed, because the INVITE was sent to localhost and the prefix "spiral-" is found. The rule-2 sends INVITE to 192.168.1.26 as <sip:218001@192.168.1.26:5060;cd40rs=R2>