7 Nov
2013
7 Nov
'13
2:08 p.m.
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(a)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:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)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> -
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(a)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(a)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(a)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(a)10.16.48.71 <mailto:553330101@10.16.48.71>
> >