[Freeswitch-users] call timeout and failover

[fs]

Thank you Francois, that was my thoughts also,  I will experiment and post my findings.  I just thought if someone else had pursued this, I might save some time.  This feature would put the freeswitch in the same league as some of the major products such as the Metaswitch which does support this, although they do it more with a notify message and putting the trunk group out of service if there is no response, I actually like that better. 

Darcy
  ----- Original Message ----- 
  From: François 
  To: FreeSWITCH Users Help 
  Sent: Saturday, November 09, 2013 5:19 PM
  Subject: Re: [Freeswitch-users] call timeout and failover


  I see, well it's the SIP standard that defines this type of behavior (timeout and retransmissions when not receiving a response).

  It might be possible to do what you want by tweaking the SIP timers (sofia profile param "timer-T1", "timer-T2", ...). Otherwise you would probably need to modify the sofia stack.

  François.

  On Fri, 2013-11-08 at 22:51 -0500, fs wrote:

     
    Yes I did, but again, that times out on a progress message,  if you have a dead carrier you are sending the message to, it waits for the leg timeout which in our case needs to be set to about 12 seconds to allow for cell phones etc.  So it takes quite a while to switch, the calling party usually hangs up or the call completion time is just to long. 
     
    Darcy 
      ----- Original Message ----- 
      From: François 
      To: FreeSWITCH Users Help 
      Sent: Friday, November 08, 2013 3:54 PM 
      Subject: Re: [Freeswitch-users] call timeout and failover 



      Did you try with the "leg_progress_timeout" variable?

      François.

      On Fri, 2013-11-08 at 15:06 -0500, fs wrote: 

        I wonder if anyone has any thoughts on this.   Using continue on fail works fine for failover but to the best of my knowledge it only works if you do not get an answer or session progress.  The trouble with this is if you are calling cell phones etc, it can take up to 12 seconds to get the messages.  I would like to explore if failover could be instituted by not receiving a Trying message.  This is usually returned immediately and does stop the freeswitch from sending more invites.  That way, a 4 second timer could be used and switch to an alternate route early and still give reasonable completion times.  
        The tcap trace below shows a typical call to a cell in our area,  the trying is almost immediate while the cell in this case took 5.5 seconds.  I have seen this quite frequently take as long as 12 seconds. 
        Also, when calling internationally, longer times are quite common. 
        Perhaps this is already implemented but I have not been able to find it. 
        449.776291  SIP/SDP Request: INVITE sip:1613802xxxx at xxx.xxx.xxx.xx, with session description
        449.782429  SIP Status: 100 Trying
        456.211562  SIP/SDP Status: 183 Session Progress, with session description


        Darcy Primrose 
        voice2net 
_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting at freeswitch.org
http://www.freeswitchsolutions.com




Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

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




--------------------------------------------------------------------------


      _________________________________________________________________________
      Professional FreeSWITCH Consulting Services:
      consulting at freeswitch.org
      http://www.freeswitchsolutions.com

      
      

      Official FreeSWITCH Sites
      http://www.freeswitch.org
      http://wiki.freeswitch.org
      http://www.cluecon.com

      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



--------------------------------------------------------------------------


      No virus found in this message.
      Checked by AVG - www.avg.com
      Version: 2014.0.4158 / Virus Database: 3615/6799 - Release Date: 11/01/13


_________________________________________________________________________
Professional FreeSWITCH Consulting Services:
consulting at freeswitch.org
http://www.freeswitchsolutions.com




Official FreeSWITCH Sites
http://www.freeswitch.org
http://wiki.freeswitch.org
http://www.cluecon.com

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




------------------------------------------------------------------------------


  _________________________________________________________________________
  Professional FreeSWITCH Consulting Services:
  consulting at freeswitch.org
  http://www.freeswitchsolutions.com

  
  

  Official FreeSWITCH Sites
  http://www.freeswitch.org
  http://wiki.freeswitch.org
  http://www.cluecon.com

  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



------------------------------------------------------------------------------


  No virus found in this message.
  Checked by AVG - www.avg.com
  Version: 2014.0.4158 / Virus Database: 3615/6799 - Release Date: 11/01/13
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20131109/2967580c/attachment-0001.html