7 Nov
2013
7 Nov
'13
4:36 a.m.
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
--
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 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>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users