<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"/>
 </head><body style="">
 
 
  <div>
   Hello,
  </div> 
  <div>
    
  </div> 
  <div>
   I have an update:
  </div> 
  <div>
    
  </div> 
  <div>
   today I´ve tested with kamailio version 4.0.4, but the behaviour is still the same:  it is working fine only when no response has been received; as soon as a provisional response is received, the failure route is ignoring the "sleep" function.
  </div> 
  <div>
    
  </div> 
  <div>
   Klaus
  </div> 
  <blockquote style="position: relative; margin-left: 0px; padding-left: 10px; border-left: solid 1px blue;" type="cite">
   Hello list,
   <br/> 
   <br/> I have troubles using the function "usleep(x)" or "sleep(x)" (the behaviour is the same) of the "cfgutils" module (
   <a href="http://kamailio.org/docs/modules/3.2.x/modules_k/cfgutils.html#idp76968">http://kamailio.org/docs/modules/3.2.x/modules_k/cfgutils.html#idp76968</a>) in the failure_route. According documentation, this function could be used in any route, including the failure_route, too. However, when I call this function, it does not show any reaction, if a transaction was already answered with a provisional response. It is still working fine, when a transaction is timing out, as no target socket is reachable. This is confusing me!
   <br/> 
   <br/> Please find below some xlog messages from my configuration file in two scenarios (function "t_set_fr(20000, 10000);" is identic in both scenarios):
   <br/> (1) scenario 1 is including a primary target, looked up in the registrar DB, which is unreachable; after transaction timeout I have inserted the function "sleep()" in the failure_route for forcing a delay
   <br/> => here it is working fine (see timestamp)
   <br/> 
   <br/> (2) scenario 2 is including a primary target which is responding, but not establishing the session; after transaction timeout the procedure is still the same as in scenario (1)
   <br/> => here is no delay visible in the log and practically detectable
   <br/> 
   <br/> From my point of view, this is a malfuntion! Does anybody see it different? I´ve tested these scenarios with kamailio-3.2.x and kamailio-3.3.x - no difference.
   <br/> 
   <br/> Thanks for any hints!
   <br/> 
   <br/> Klaus
   <br/> 
   <br/>################# SCENARIO (1)  ORIG TARGET IS UNREACHABLE  ########################## 
   <div class="moz-forward-container"> 
    <div class="WordSection1">
     Nov  6 15:58:25 sipsrvnode1 /usr/sbin/kamailio[28879]: INFO: -<|XLOG|>-:  <RELAY> is reached for RU: 
     <a href="sip:117002@10.16.48.226:5678">sip:117002@10.16.48.226:5678</a>, From: 
     <a href="sip:1101015555@10.16.48.71">sip:1101015555@10.16.48.71</a>, To: 
     <a href="sip:115300@10.16.48.44">sip:115300@10.16.48.44</a>, Method: INVITE, Call-ID: 
     <a href="mailto:1107651805@10.16.48.71">1107651805@10.16.48.71</a>  
     <p class="MsoNormal">Nov  6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -<|XLOG|>-:  <FAILRELAY> is reached with Code: 408 From: <a href="sip:1101015555@10.16.48.71">sip:1101015555@10.16.48.71</a> To: <a href="sip:115300@10.16.48.44">sip:115300@10.16.48.44</a></p> 
     <p class="MsoNormal">Nov  6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -<|XLOG|>-:  failure_route <FAILRELAY> is reached because of a BRANCH_TIMEOUT of RU: <a href="sip:117002@10.16.48.226:5678">sip:117002@10.16.48.226:5678</a></p> Nov  6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -<|XLOG|>-:  <FAILRELAY>      s l e e p      2000ms / 2s 
     <p class="MsoNormal">Nov  6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO: -<|XLOG|>-:  <FAILRELAY>      s l e p t      2000ms / 2s</p> Nov  6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28879]: INFO: -<|XLOG|>-:  <RELAYFB> is reached for RU: 
     <a href="sip:117003@10.16.48.226:7001">sip:117003@10.16.48.226:7001</a>, From: 
     <a href="sip:1101015555@10.16.48.71">sip:1101015555@10.16.48.71</a>, To: 
     <a href="sip:115300@10.16.48.44">sip:115300@10.16.48.44</a>, Method: INVITE, Call-ID: 
     <a href="mailto:1107651805@10.16.48.71">1107651805@10.16.48.71</a>
     <br/> 
     <br/>################# SCENARIO (2) ORIG TARGET IS REACHABLE  ########################## 
     <p class="MsoNormal">Nov  6 16:02:14 sipsrvnode1 /usr/sbin/kamailio[29034]: INFO: -<|XLOG|>-:  <RELAY> is reached for RU: <a href="sip:117002@10.16.48.226:5678">sip:117002@10.16.48.226:5678</a>, From: <a href="sip:1101015555@10.16.48.71">sip:1101015555@10.16.48.71</a>, To: <a href="sip:115300@10.16.48.44">sip:115300@10.16.48.44</a>, Method: INVITE, Call-ID: <a href="mailto:553330101@10.16.48.71">553330101@10.16.48.71</a></p> Nov  6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -<|XLOG|>-:  <FAILRELAY> is reached with Code: 408 From: 
     <a href="sip:5555@10.16.48.71">sip:5555@10.16.48.71</a> To: 
     <a href="sip:4000@10.16.48.44">sip:4000@10.16.48.44</a> 
     <p class="MsoNormal">Nov  6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -<|XLOG|>-:  failure_route <FAILRELAY> is reached because of a BRANCH_TIMEOUT of RU: <a href="sip:117002@10.16.48.44">sip:117002@10.16.48.44</a></p> Nov  6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -<|XLOG|>-:  <FAILRELAY>      s l e e p      2000ms / 2s 
     <p class="MsoNormal">Nov  6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -<|XLOG|>-:  <FAILRELAY>      s l e p t      2000ms / 2s</p> Nov  6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO: -<|XLOG|>-:  <RELAYFB> is reached for RU: 
     <a href="sip:117003@10.16.48.44">sip:117003@10.16.48.44</a>, From: 
     <a href="sip:5555@10.16.48.71">sip:5555@10.16.48.71</a>, To: 
     <a href="sip:4000@10.16.48.44">sip:4000@10.16.48.44</a>, Method: INVITE, Call-ID: 
     <a href="mailto:553330101@10.16.48.71">553330101@10.16.48.71</a> 
    </div> 
   </div> 
  </blockquote> 
  <div>
   <br/> 
  </div>
 
</body></html>