<!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 Daniel,
  </div> 
  <div>
    
  </div> 
  <div>
   I´ve patched the code and found that the return value of the 'sleep' command is - as expected - differing in the scenarios. For scenario 1 (no provisional response), the return value is '0' and for scenario 2, the return value is '2' (see log output):
  </div> 
  <div>
    
  </div> 
  <div>
   scenario 1:
  </div> 
  <div>
   Nov  7 12:40:51 sipsrvnode1 kamailio33[10974]: INFO: -<|XLOG|>-:  <FAILRELAY>      s l e e p      2000ms / 2s 
   <br/>Nov  7 12:40:51 sipsrvnode1 kamailio33[10974]: DEBUG: cfgutils [cfgutils.c:650]: sleep 2 seconds 
   <br/>Nov  7 12:40:53 sipsrvnode1 kamailio33[10974]: DEBUG: cfgutils [cfgutils.c:652]: sleep-rc 0 
   <br/>Nov  7 12:40:53 sipsrvnode1 kamailio33[10974]: INFO: -<|XLOG|>-:  <FAILRELAY>      s l e p t      2000ms / 2s 
   <br/> 
  </div> 
  <div>
   scenario 2:
  </div> 
  <div>
   Nov  7 12:41:38 sipsrvnode1 kamailio33[10975]: INFO: -<|XLOG|>-:  <FAILRELAY>      s l e e p      2000ms / 2s 
   <br/>Nov  7 12:41:38 sipsrvnode1 kamailio33[10975]: DEBUG: cfgutils [cfgutils.c:650]: sleep 2 seconds 
   <br/>Nov  7 12:41:38 sipsrvnode1 kamailio33[10975]: DEBUG: cfgutils [cfgutils.c:652]: sleep-rc 2 
   <br/>Nov  7 12:41:38 sipsrvnode1 kamailio33[10975]: INFO: -<|XLOG|>-:  <FAILRELAY>      s l e p t      2000ms / 2s 
   <br/> 
  </div> 
  <div>
   This means that the sleep command is interrupted (in scenario 2) by a signal, as the return value is representing the "number of seconds left to sleep, if the call was interrupted by a signal handler.".
  </div> 
  <div>
    
  </div> 
  <div>
   Which signal is interrupting "sleep" in this scenario (only)   :-(   ?
  </div> 
  <div>
    
  </div> 
  <div>
   Klaus
  </div> 
  <blockquote style="position: relative; margin-left: 0px; padding-left: 10px; border-left: solid 1px blue;" type="cite">
   Daniel-Constantin Mierla <miconda@gmail.com> hat am 7. November 2013 um 10:36 geschrieben: 
   <br/> 
   <br/> Hello, 
   <br/> 
   <br/> can you try to see if sleep_us() works? 
   <br/> 
   <br/> It is rather strange because sleep() from cfgutils just uses sleep() from system library, nothing special internally... sleep is interrupted by signals as well. Can you patch the function in kamailio to log the return code from sleep()? 
   <br/> 
   <br/> Cheers, 
   <br/> Daniel 
   <br/> 
   <br/> 
   <div class="moz-cite-prefix">
    On 11/7/13 8:40 AM, klaus.lists#inode.at wrote:
   </div> 
   <blockquote type="cite"> 
    <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> 
    <br/> 
    <br/> 
    <pre>_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
<a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a>
</pre> 
   </blockquote> 
   <br/> 
   <pre class="moz-signature">-- 
Daniel-Constantin Mierla - <a href="http://www.asipto.com">http://www.asipto.com</a>
<a href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio Advanced Trainings - Berlin, Nov 25-28
  - more details about Kamailio trainings at <a href="http://www.asipto.com">http://www.asipto.com</a> -
</pre> 
  </blockquote> 
  <div>
   <br/> 
  </div>
 
</body></html>