[Freeswitch-users] failover based on initial INVITE timeout

Hristo Trendev dist.lists at gmail.com
Tue Aug 18 11:50:01 PDT 2009


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 at 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 at 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 at 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 at 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 at 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 at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>




More information about the FreeSWITCH-users mailing list