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 <mico...@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@10.16.48.226:5678> ,
> > > From:<sip:1101015555@10.16.48.71> , To:<sip:115300@10.16.48.44> , Method:
> > > INVITE, Call-ID: 1107651805@10.16.48.71 <mailto:1107651805@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@10.16.48.71> To:<sip:115300@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@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@10.16.48.226:7001> ,
> > > From:<sip:1101015555@10.16.48.71> , To:<sip:115300@10.16.48.44> , Method:
> > > INVITE, Call-ID: 1107651805@10.16.48.71 <mailto:1107651805@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@10.16.48.226:5678> ,
> > > From:<sip:1101015555@10.16.48.71> , To:<sip:115300@10.16.48.44> , Method:
> > > INVITE, Call-ID: 553330101@10.16.48.71 <mailto:553330101@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@10.16.48.71> To:<sip:4000@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@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@10.16.48.44> ,
> > > From:<sip:5555@10.16.48.71> , To:<sip:4000@10.16.48.44> , Method: INVITE,
> > > Call-ID: 553330101@10.16.48.71 <mailto:553330101@10.16.48.71>
> > >
> > > > >
> >
> >
> >
> >
> > _______________________________________________
> > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> > sr-users@lists.sip-router.org <mailto:sr-users@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> -
>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
