<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Thanks, Bogdan--great feature in 1.11.x &nbsp;I was originally looking in the 1.8.x man pages. &nbsp;<div><br></div><div>I just got 1.11.2 working here in dev and the feature works great. &nbsp;One question--any reason that if I &nbsp;xlog the $T_fr_timeout or $T_fr_inv_timeout variables they return 0 whenever they were not explicitly set in the script instead of returning the default values that were set in the mod_param section for tm module?<div><br></div><div>In any case keep up the good work!<div><br><div><div>On Jul 28, 2014, at 10:49 AM, Bogdan-Andrei Iancu &lt;<a href="mailto:bogdan@opensips.org">bogdan@opensips.org</a>&gt; wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  
  <div bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><tt>Hi,<br>
        <br>
        fr_timeout is the interval between the request and the first
        provisional reply - shortly, how long to to wait for the first
        provisional reply.<br>
        <br>
        fr_inv_timeout is the interval between the request and the final
        reply (2xx or negative) - shortly, how long to wait for
        completing the transaction.<br>
        <br>
        So you can use different values for these 2 timers for a
        transaction to get the desired behavior. <br>
        <br>
        Regards,<br>
      </tt>
      <pre class="moz-signature" cols="72">Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
<a class="moz-txt-link-freetext" href="http://www.opensips-solutions.com/">http://www.opensips-solutions.com</a></pre>
      On 19.07.2014 07:53, Jamuel Starkey wrote:<br>
    </div>
    <blockquote cite="mid:A6E32D32-1348-4B31-A9A7-5A135A00A324@hcvoip.com" type="cite">
      <pre wrap="">Hi,

From the TM module man page it would see fr_timeout should fire whenever a final reply is not received for a request but it is only limited to ACK's for negative INVITE replies? Is this correct?  Can someone be so kind as to clarify when fr_timeout is triggered.    

Is there a method to set a timeout between specific provisional replies in an INVITE?  In other words let's say we receive a 100 TRYING but then see a very long delay until the next provisional reply (specifically 183 Ringing).  Is there a way to timeout the request so that we can route advance to another gateway?

We have a carrier who is randomly prone to lengthy PDD intervals in completing calls we send to them.  On such a call our initial INVITE almost immediately sees the 100 Trying but then we might see another 25-30 seconds before we seeing another provisional response such as 183 Ringing or a final response.  

Is there a way to implement an INVITE specific provisional response timer so that if we get the 100 Trying and then don't see any other provisional response in a much shorter period of time (for example no more than 6 seconds) we could then route advance and attempt the call on another gateway.  Is this at all possible?  Serial forking to the next gateway would be fine but parallel forking would be preferred after the provisional timeout occurred.  We'd just not want to route advance if we received the 183 Ringing provisional response.

Any help or insight would be greatly appreciated.

Cheers,

JPS
</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br></div></div></div></body></html>