[SR-Users] #cfgutils: sleep(x) does not work in failure_route

Thu Nov 7 13:08:42 CET 2013

Hello Daniel,

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):

scenario 1:
Nov  7 12:40:51 sipsrvnode1 kamailio33[10974]: INFO: -<|XLOG|>-:  <FAILRELAY>
     s l e e p      2000ms / 2s
Nov  7 12:40:51 sipsrvnode1 kamailio33[10974]: DEBUG: cfgutils [cfgutils.c:650]:
sleep 2 seconds
Nov  7 12:40:53 sipsrvnode1 kamailio33[10974]: DEBUG: cfgutils [cfgutils.c:652]:
sleep-rc 0
Nov  7 12:40:53 sipsrvnode1 kamailio33[10974]: INFO: -<|XLOG|>-:  <FAILRELAY>
     s l e p t      2000ms / 2s
scenario 2:
Nov  7 12:41:38 sipsrvnode1 kamailio33[10975]: INFO: -<|XLOG|>-:  <FAILRELAY>
     s l e e p      2000ms / 2s
Nov  7 12:41:38 sipsrvnode1 kamailio33[10975]: DEBUG: cfgutils [cfgutils.c:650]:
sleep 2 seconds
Nov  7 12:41:38 sipsrvnode1 kamailio33[10975]: DEBUG: cfgutils [cfgutils.c:652]:
sleep-rc 2
Nov  7 12:41:38 sipsrvnode1 kamailio33[10975]: INFO: -<|XLOG|>-:  <FAILRELAY>
     s l e p t      2000ms / 2s
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.".

Which signal is interrupting "sleep" in this scenario (only)   :-(   ?

Klaus

> Daniel-Constantin Mierla <miconda at gmail.com> hat am 7. November 2013 um 10:36
> geschrieben:
> 
>  Hello,
> 
>  can you try to see if sleep_us() works?
> 
>  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()?
> 
>  Cheers,
>  Daniel
> 
>  On 11/7/13 8:40 AM, klaus.lists#inode.at wrote:
> 
>      > >      Hello,
> > 
> >      I have an update:
> > 
> >      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.
> > 
> >      Klaus
> > 
> >       > > > Hello list,
> > > 
> > >       I have troubles using the function "usleep(x)" or "sleep(x)" (the
> > > behaviour is the same) of the "cfgutils" module
> > > (<http://kamailio.org/docs/modules/3.2.x/modules_k/cfgutils.html#idp76968>
> > > ) 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!
> > > 
> > >       Please find below some xlog messages from my configuration file in
> > > two scenarios (function "t_set_fr(20000, 10000);" is identic in both
> > > scenarios):
> > >       (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
> > >       => here it is working fine (see timestamp)
> > > 
> > >       (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)
> > >       => here is no delay visible in the log and practically detectable
> > > 
> > >       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.
> > > 
> > >       Thanks for any hints!
> > > 
> > >       Klaus
> > > 
> > >       ################# SCENARIO (1)  ORIG TARGET IS UNREACHABLE
> > >  ##########################
> > >       Nov  6 15:58:25 sipsrvnode1 /usr/sbin/kamailio[28879]: INFO:
> > > -<|XLOG|>-:  <RELAY> is reached for RU:<sip:117002 at 10.16.48.226:5678> ,
> > > From:<sip:1101015555 at 10.16.48.71> , To:<sip:115300 at 10.16.48.44> , Method:
> > > INVITE, Call-ID: 1107651805 at 10.16.48.71 <mailto:1107651805 at 10.16.48.71>
> > > 
> > >       Nov  6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO:
> > > -<|XLOG|>-:  <FAILRELAY> is reached with Code: 408
> > > From:<sip:1101015555 at 10.16.48.71> To:<sip:115300 at 10.16.48.44>
> > > 
> > >       Nov  6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO:
> > > -<|XLOG|>-:  failure_route <FAILRELAY> is reached because of a
> > > BRANCH_TIMEOUT of RU:<sip:117002 at 10.16.48.226:5678>
> > > 
> > >       Nov  6 15:58:35 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO:
> > > -<|XLOG|>-:  <FAILRELAY>      s l e e p      2000ms / 2s
> > > 
> > >       Nov  6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28880]: INFO:
> > > -<|XLOG|>-:  <FAILRELAY>      s l e p t      2000ms / 2s
> > > 
> > >       Nov  6 15:58:37 sipsrvnode1 /usr/sbin/kamailio[28879]: INFO:
> > > -<|XLOG|>-:  <RELAYFB> is reached for RU:<sip:117003 at 10.16.48.226:7001> ,
> > > From:<sip:1101015555 at 10.16.48.71> , To:<sip:115300 at 10.16.48.44> , Method:
> > > INVITE, Call-ID: 1107651805 at 10.16.48.71 <mailto:1107651805 at 10.16.48.71>
> > > 
> > >       ################# SCENARIO (2) ORIG TARGET IS REACHABLE
> > >  ##########################
> > > 
> > >       Nov  6 16:02:14 sipsrvnode1 /usr/sbin/kamailio[29034]: INFO:
> > > -<|XLOG|>-:  <RELAY> is reached for RU:<sip:117002 at 10.16.48.226:5678> ,
> > > From:<sip:1101015555 at 10.16.48.71> , To:<sip:115300 at 10.16.48.44> , Method:
> > > INVITE, Call-ID: 553330101 at 10.16.48.71 <mailto:553330101 at 10.16.48.71>
> > > 
> > >       Nov  6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO:
> > > -<|XLOG|>-:  <FAILRELAY> is reached with Code: 408
> > > From:<sip:5555 at 10.16.48.71> To:<sip:4000 at 10.16.48.44>
> > > 
> > >       Nov  6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO:
> > > -<|XLOG|>-:  failure_route <FAILRELAY> is reached because of a
> > > BRANCH_TIMEOUT of RU:<sip:117002 at 10.16.48.44>
> > > 
> > >       Nov  6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO:
> > > -<|XLOG|>-:  <FAILRELAY>      s l e e p      2000ms / 2s
> > > 
> > >       Nov  6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO:
> > > -<|XLOG|>-:  <FAILRELAY>      s l e p t      2000ms / 2s
> > > 
> > >       Nov  6 16:02:34 sipsrvnode1 /usr/sbin/kamailio[29036]: INFO:
> > > -<|XLOG|>-:  <RELAYFB> is reached for RU:<sip:117003 at 10.16.48.44> ,
> > > From:<sip:5555 at 10.16.48.71> , To:<sip:4000 at 10.16.48.44> , Method: INVITE,
> > > Call-ID: 553330101 at 10.16.48.71 <mailto:553330101 at 10.16.48.71>
> > > 
> > >      > > 
> > 
> > 
> > 
> > 
> >      _______________________________________________
> >      SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> >      sr-users at lists.sip-router.org <mailto:sr-users at lists.sip-router.org>
> >      <http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>
> > 
> >  > 
>  --
>  Daniel-Constantin Mierla - <http://www.asipto.com>
>  <http://twitter.com/#!/miconda> - <http://www.linkedin.com/in/miconda>
>  Kamailio Advanced Trainings - Berlin, Nov 25-28
>    - more details about Kamailio trainings at <http://www.asipto.com> -
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20131107/8529aacc/attachment.html>