failover based on initial INVITE timeout
I am trying to implement failover dialing plan as described in: http://wiki.freeswitch.org/wiki/Channel_Variables#originate_timeout I figured out that originate_timeout must be passed as {originate_timeout=<timeout>} in front of the dial string to have any effect (setting it as channel variable as described in the example above has no effect). I have set the timeout to 1 second, so expected behavior is to try the second gateway if no response is received from the first one in 1 second. The problem is that FS cancels the first request with [NO_ANSWER] and tries to route the call via the second gateway even though it receives response from the first during that 1 second. The response received is "100 Trying" provisional response (checked with sofia siptrace). I'm guessing that either 100 provisional responses don't cancel the originate_timeout timer (bug?) or I am doing it the wrong way. I was also thinking of using the timer-T1 or timer-T1X64 parameter in the sip profile, but I need this to be set per dial string, not per profile, besides, it seems that these timers (T1, T1X64) affect both invite and non-invite requests, so this is not really an option. Also, I tried leg_timeout, but it doesn't really do what I need it to. Anyone has any idea how to implement this?
I think you wanna use progress_timeout http://wiki.freeswitch.org/wiki/Channel_Variables#progress_timeout /b On Aug 18, 2009, at 10:24 AM, Hristo Trendev wrote:
I am trying to implement failover dialing plan as described in: http://wiki.freeswitch.org/wiki/Channel_Variables#originate_timeout
I figured out that originate_timeout must be passed as {originate_timeout=<timeout>} in front of the dial string to have any effect (setting it as channel variable as described in the example above has no effect).
I have set the timeout to 1 second, so expected behavior is to try the second gateway if no response is received from the first one in 1 second. The problem is that FS cancels the first request with [NO_ANSWER] and tries to route the call via the second gateway even though it receives response from the first during that 1 second.
The response received is "100 Trying" provisional response (checked with sofia siptrace). I'm guessing that either 100 provisional responses don't cancel the originate_timeout timer (bug?) or I am doing it the wrong way.
I was also thinking of using the timer-T1 or timer-T1X64 parameter in the sip profile, but I need this to be set per dial string, not per profile, besides, it seems that these timers (T1, T1X64) affect both invite and non-invite requests, so this is not really an option. Also, I tried leg_timeout, but it doesn't really do what I need it to.
Anyone has any idea how to implement this?
progress_timeout will wait for media (tried it, but I don't need that). I want to detect the case when the destination gateway is down and there is no response (not even 100, 407, etc) to the initial INVITE sent by FS. According to the wiki, this is exactly what originate_timeout is used for. Actually the wiki gives as example for originate_timeout exactly what I'm trying to accomplish. It seems to me that FS ignores 100 and alike messages, which are sent as response to initial INVITE and doesn't cancel originate_timeout timer if such message is received. The more I look into this, the more I start to think that it's a bug. On Tue, Aug 18, 2009 at 6:33 PM, Brian West<brian@freeswitch.org> wrote:
I think you wanna use progress_timeout http://wiki.freeswitch.org/wiki/Channel_Variables#progress_timeout /b On Aug 18, 2009, at 10:24 AM, Hristo Trendev wrote:
I am trying to implement failover dialing plan as described in: http://wiki.freeswitch.org/wiki/Channel_Variables#originate_timeout
I figured out that originate_timeout must be passed as {originate_timeout=<timeout>} in front of the dial string to have any effect (setting it as channel variable as described in the example above has no effect).
I have set the timeout to 1 second, so expected behavior is to try the second gateway if no response is received from the first one in 1 second. The problem is that FS cancels the first request with [NO_ANSWER] and tries to route the call via the second gateway even though it receives response from the first during that 1 second.
The response received is "100 Trying" provisional response (checked with sofia siptrace). I'm guessing that either 100 provisional responses don't cancel the originate_timeout timer (bug?) or I am doing it the wrong way.
I was also thinking of using the timer-T1 or timer-T1X64 parameter in the sip profile, but I need this to be set per dial string, not per profile, besides, it seems that these timers (T1, T1X64) affect both invite and non-invite requests, so this is not really an option. Also, I tried leg_timeout, but it doesn't really do what I need it to.
Anyone has any idea how to implement this?
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
use TCP then if you get an ICMP unreachable it'll move on instantly. /b On Aug 18, 2009, at 12:48 PM, Hristo Trendev wrote:
progress_timeout will wait for media (tried it, but I don't need that). I want to detect the case when the destination gateway is down and there is no response (not even 100, 407, etc) to the initial INVITE sent by FS.
According to the wiki, this is exactly what originate_timeout is used for. Actually the wiki gives as example for originate_timeout exactly what I'm trying to accomplish.
It seems to me that FS ignores 100 and alike messages, which are sent as response to initial INVITE and doesn't cancel originate_timeout timer if such message is received.
The more I look into this, the more I start to think that it's a bug.
TCP is not really an option for me. I have tried using different sofia profile for that and set: <param name="timer-T1X64" value="1000" /> This works the way I want and INVITEs to dead gateways are disconnected with [RECOVERY_ON_TIMER_EXPIRE], but: 1. It affects all calls sent via this "custom timer" profile 2. I need to use one more SIP port to bind to (I need keep the "default timers" profile as well) 3. The timer is used by transactions other than the initial invite message and that may cause unexpected problems. Obviously originate_timeout doesn't work the way it's supposed to (according to the wiki) so I will report it as bug. The profile trick above actually solves my problem and may happen to be a better solution after all, but I will need to test it for some time before I know. On Tue, Aug 18, 2009 at 9:00 PM, Brian West<brian@freeswitch.org> wrote:
use TCP then if you get an ICMP unreachable it'll move on instantly.
/b
On Aug 18, 2009, at 12:48 PM, Hristo Trendev wrote:
progress_timeout will wait for media (tried it, but I don't need that). I want to detect the case when the destination gateway is down and there is no response (not even 100, 407, etc) to the initial INVITE sent by FS.
According to the wiki, this is exactly what originate_timeout is used for. Actually the wiki gives as example for originate_timeout exactly what I'm trying to accomplish.
It seems to me that FS ignores 100 and alike messages, which are sent as response to initial INVITE and doesn't cancel originate_timeout timer if such message is received.
The more I look into this, the more I start to think that it's a bug.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
setup gateways and turn on the ping option. /b On Aug 18, 2009, at 1:24 PM, Hristo Trendev wrote:
TCP is not really an option for me. I have tried using different sofia profile for that and set:
<param name="timer-T1X64" value="1000" />
This works the way I want and INVITEs to dead gateways are disconnected with [RECOVERY_ON_TIMER_EXPIRE], but: 1. It affects all calls sent via this "custom timer" profile 2. I need to use one more SIP port to bind to (I need keep the "default timers" profile as well) 3. The timer is used by transactions other than the initial invite message and that may cause unexpected problems.
Obviously originate_timeout doesn't work the way it's supposed to (according to the wiki) so I will report it as bug.
The profile trick above actually solves my problem and may happen to be a better solution after all, but I will need to test it for some time before I know.
I've seen this parameter when I started testing, but the name suggest that it will do icmp ping to detect failed gateways (haven't really tried it though). I need to detect sip service failure as well - the case where the destination server is up (ping replies are received), but the sip process is down and there is no response to sip requests. If the ping parameter uses sip-based ping (like OPTIONS ping) this may be a solution for me as well. On Tue, Aug 18, 2009 at 9:30 PM, Brian West<brian@freeswitch.org> wrote:
setup gateways and turn on the ping option. /b
On Aug 18, 2009, at 1:24 PM, Hristo Trendev wrote:
TCP is not really an option for me. I have tried using different sofia profile for that and set:
<param name="timer-T1X64" value="1000" />
This works the way I want and INVITEs to dead gateways are disconnected with [RECOVERY_ON_TIMER_EXPIRE], but: 1. It affects all calls sent via this "custom timer" profile 2. I need to use one more SIP port to bind to (I need keep the "default timers" profile as well) 3. The timer is used by transactions other than the initial invite message and that may cause unexpected problems.
Obviously originate_timeout doesn't work the way it's supposed to (according to the wiki) so I will report it as bug.
The profile trick above actually solves my problem and may happen to be a better solution after all, but I will need to test it for some time before I know.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
It does use SIP OPTIONS. Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca On 18-Aug-09, at 2:40 PM, Hristo Trendev wrote:
I've seen this parameter when I started testing, but the name suggest that it will do icmp ping to detect failed gateways (haven't really tried it though). I need to detect sip service failure as well - the case where the destination server is up (ping replies are received), but the sip process is down and there is no response to sip requests.
If the ping parameter uses sip-based ping (like OPTIONS ping) this may be a solution for me as well.
On Tue, Aug 18, 2009 at 9:30 PM, Brian West<brian@freeswitch.org> wrote:
setup gateways and turn on the ping option. /b
On Aug 18, 2009, at 1:24 PM, Hristo Trendev wrote:
TCP is not really an option for me. I have tried using different sofia profile for that and set:
<param name="timer-T1X64" value="1000" />
This works the way I want and INVITEs to dead gateways are disconnected with [RECOVERY_ON_TIMER_EXPIRE], but: 1. It affects all calls sent via this "custom timer" profile 2. I need to use one more SIP port to bind to (I need keep the "default timers" profile as well) 3. The timer is used by transactions other than the initial invite message and that may cause unexpected problems.
Obviously originate_timeout doesn't work the way it's supposed to (according to the wiki) so I will report it as bug.
The profile trick above actually solves my problem and may happen to be a better solution after all, but I will need to test it for some time before I know.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Thanks. I guess I will try that as well and see which one works better for me then. On Tue, Aug 18, 2009 at 9:42 PM, Mathieu Rene<mrene_lists@avgs.ca> wrote:
It does use SIP OPTIONS.
Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca
On 18-Aug-09, at 2:40 PM, Hristo Trendev wrote:
I've seen this parameter when I started testing, but the name suggest that it will do icmp ping to detect failed gateways (haven't really tried it though). I need to detect sip service failure as well - the case where the destination server is up (ping replies are received), but the sip process is down and there is no response to sip requests.
If the ping parameter uses sip-based ping (like OPTIONS ping) this may be a solution for me as well.
On Tue, Aug 18, 2009 at 9:30 PM, Brian West<brian@freeswitch.org> wrote:
setup gateways and turn on the ping option. /b
On Aug 18, 2009, at 1:24 PM, Hristo Trendev wrote:
TCP is not really an option for me. I have tried using different sofia profile for that and set:
<param name="timer-T1X64" value="1000" />
This works the way I want and INVITEs to dead gateways are disconnected with [RECOVERY_ON_TIMER_EXPIRE], but: 1. It affects all calls sent via this "custom timer" profile 2. I need to use one more SIP port to bind to (I need keep the "default timers" profile as well) 3. The timer is used by transactions other than the initial invite message and that may cause unexpected problems.
Obviously originate_timeout doesn't work the way it's supposed to (according to the wiki) so I will report it as bug.
The profile trick above actually solves my problem and may happen to be a better solution after all, but I will need to test it for some time before I know.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Why would it make you think its ICMP? Weird. Its a sip based options ping. /b On Aug 18, 2009, at 1:40 PM, Hristo Trendev wrote:
I've seen this parameter when I started testing, but the name suggest that it will do icmp ping to detect failed gateways (haven't really tried it though). I need to detect sip service failure as well - the case where the destination server is up (ping replies are received), but the sip process is down and there is no response to sip requests.
If the ping parameter uses sip-based ping (like OPTIONS ping) this may be a solution for me as well.
Hi, originate_timeout does exactly what it is supposed to do, cancel the new call if originate doesnt return within X seconds. In my opinion, I would keep state wether the gateway is alive or not, and have a reasonable t1x64 timeout value (5000 should be enough). This way it'll only timeout the first time the call is attempted. Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca On 18-Aug-09, at 2:24 PM, Hristo Trendev wrote:
TCP is not really an option for me. I have tried using different sofia profile for that and set:
<param name="timer-T1X64" value="1000" />
This works the way I want and INVITEs to dead gateways are disconnected with [RECOVERY_ON_TIMER_EXPIRE], but: 1. It affects all calls sent via this "custom timer" profile 2. I need to use one more SIP port to bind to (I need keep the "default timers" profile as well) 3. The timer is used by transactions other than the initial invite message and that may cause unexpected problems.
Obviously originate_timeout doesn't work the way it's supposed to (according to the wiki) so I will report it as bug.
The profile trick above actually solves my problem and may happen to be a better solution after all, but I will need to test it for some time before I know.
On Tue, Aug 18, 2009 at 9:00 PM, Brian West<brian@freeswitch.org> wrote:
use TCP then if you get an ICMP unreachable it'll move on instantly.
/b
On Aug 18, 2009, at 12:48 PM, Hristo Trendev wrote:
progress_timeout will wait for media (tried it, but I don't need that). I want to detect the case when the destination gateway is down and there is no response (not even 100, 407, etc) to the initial INVITE sent by FS.
According to the wiki, this is exactly what originate_timeout is used for. Actually the wiki gives as example for originate_timeout exactly what I'm trying to accomplish.
It seems to me that FS ignores 100 and alike messages, which are sent as response to initial INVITE and doesn't cancel originate_timeout timer if such message is received.
The more I look into this, the more I start to think that it's a bug.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
That's exactly what I'm trying to do. This used to be implemented with openser and on timeout it will mark destination as inactive so subsequent calls don't get sent to dead gateways. If originate_timeout is intended for something else, then maybe the example given in the wiki can be changed, because may be a bit misleading for someone trying to do failover. On Tue, Aug 18, 2009 at 9:32 PM, Mathieu Rene<mrene_lists@avgs.ca> wrote:
Hi,
originate_timeout does exactly what it is supposed to do, cancel the new call if originate doesnt return within X seconds. In my opinion, I would keep state wether the gateway is alive or not, and have a reasonable t1x64 timeout value (5000 should be enough). This way it'll only timeout the first time the call is attempted.
Mathieu Rene Avant-Garde Solutions Inc Office: + 1 (514) 664-1044 x100 Cell: +1 (514) 664-1044 x200 mrene@avgs.ca
On 18-Aug-09, at 2:24 PM, Hristo Trendev wrote:
TCP is not really an option for me. I have tried using different sofia profile for that and set:
<param name="timer-T1X64" value="1000" />
This works the way I want and INVITEs to dead gateways are disconnected with [RECOVERY_ON_TIMER_EXPIRE], but: 1. It affects all calls sent via this "custom timer" profile 2. I need to use one more SIP port to bind to (I need keep the "default timers" profile as well) 3. The timer is used by transactions other than the initial invite message and that may cause unexpected problems.
Obviously originate_timeout doesn't work the way it's supposed to (according to the wiki) so I will report it as bug.
The profile trick above actually solves my problem and may happen to be a better solution after all, but I will need to test it for some time before I know.
On Tue, Aug 18, 2009 at 9:00 PM, Brian West<brian@freeswitch.org> wrote:
use TCP then if you get an ICMP unreachable it'll move on instantly.
/b
On Aug 18, 2009, at 12:48 PM, Hristo Trendev wrote:
progress_timeout will wait for media (tried it, but I don't need that). I want to detect the case when the destination gateway is down and there is no response (not even 100, 407, etc) to the initial INVITE sent by FS.
According to the wiki, this is exactly what originate_timeout is used for. Actually the wiki gives as example for originate_timeout exactly what I'm trying to accomplish.
It seems to me that FS ignores 100 and alike messages, which are sent as response to initial INVITE and doesn't cancel originate_timeout timer if such message is received.
The more I look into this, the more I start to think that it's a bug.
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (3)
-
Brian West
-
Hristo Trendev
-
Mathieu Rene