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

Thu Nov 7 10:36:26 CET 2013

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
> 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/1753e786/attachment.html>