VoIP Mailing List Archives

[dist.lists at gmail.com]

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

[brian at freeswitch.org]

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:

[dist.lists at gmail.com]

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:

[brian at 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:

[dist.lists at gmail.com]

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:

[brian at freeswitch.org]

setup gateways and turn on the ping option.
/b

On Aug 18, 2009, at 1:24 PM, Hristo Trendev wrote:

[mrene_lists at avgs.ca]

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:

[mrene_lists at avgs.ca]

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:

[dist.lists at gmail.com]

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:

[brian at 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:

[dist.lists at gmail.com]

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:

[dist.lists at gmail.com]

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: