[Home]

Summary:ASTERISK-07636: CURL() does not timeout
Reporter:Nick Barnes (bcnit)Labels:
Date Opened:2006-08-31 04:11:41Date Closed:2006-09-20 10:08:53
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Functions/func_curl
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I'm not sure whether this is classed as a bug or not - certainly it causes problems the way it works at the moment.....

The CURL() function does not impose any timeout restrictions on the connection it makes. If, for whatever reason, the server it connects to doesn't respond in a timely fashion, the last thing I need to do is keep a caller holding for ever and a day.

I have hardcoded "curl_easy_setopt(curl, CURLOPT_TIMEOUT, 5);" into apps/app_curl.c which works for what I need, but it would be better (I think) to pass timeout as a parameter to the function call and maybe have status returned in a variable too.
Comments:By: Serge Vecher (serge-v) 2006-08-31 08:40:23

can't you use a dialplan timeout ?
By: Nick Barnes (bcnit) 2006-08-31 09:40:34

Nope - absolute timeouts don't apply when CURL() is running (isn't this a bug in itself?) To prove this:

(Note that the script at http://testserver/cgi-bin/timeouttest just waits for 10 seconds and then returns a blank page and that the curl function has been hacked to timeout after 5 seconds as per the description above)

----------------

[from-test]

exten => 11,1,Answer
exten => 11,n,NoOp(Starting at ${TIMESTAMP})
exten => 11,n,Set(TIMEOUT(absolute)=2)
exten => 11,n,Set(DUMMY=${CURL(http://testserver/cgi-bin/timeouttest)})
exten => 11,n,NoOp(Didn't timeout - ${TIMESTAMP})

exten => 12,1,Answer
exten => 12,n,NoOp(Starting at ${TIMESTAMP})
exten => 12,n,Set(TIMEOUT(absolute)=2)
exten => 12,n,Wait(10)
exten => 12,n,NoOp(Didn't timeout - ${TIMESTAMP})

exten => T,1,NoOp(TIMEOUT at ${TIMESTAMP})
exten => T,n,Hangup

------------------

When 11 is dialed:

   -- Executing Answer("SIP/667-08164150", "") in new stack
   -- Executing NoOp("SIP/667-08164150", "Starting at 20060831-153208") in new stack
   -- Executing Set("SIP/667-08164150", "TIMEOUT(absolute)=2") in new stack
   -- Channel will hangup at 2006-08-31 14:32:10 UTC.
   -- Executing Set("SIP/667-08164150", "DUMMY=") in new stack
   -- Executing NoOp("SIP/667-08164150", "Didnt timeout - 20060831-153213") in new stack
 == Auto fallthrough, channel 'SIP/667-08164150' status is 'UNKNOWN'



And when 12 is dialed:

   -- Executing Answer("SIP/667-08166d70", "") in new stack
   -- Executing NoOp("SIP/667-08166d70", "Starting at 20060831-153414") in new stack
   -- Executing Set("SIP/667-08166d70", "TIMEOUT(absolute)=2") in new stack
   -- Channel will hangup at 2006-08-31 14:34:16 UTC.
   -- Executing Wait("SIP/667-08166d70", "10") in new stack
 == Spawn extension (from-test, 12, 4) exited non-zero on 'SIP/667-08166d70'
   -- Executing NoOp("SIP/667-08166d70", "TIMEOUT at 20060831-153416") in new stack
   -- Executing Hangup("SIP/667-08166d70", "") in new stack
 == Spawn extension (from-test, T, 2) exited non-zero on 'SIP/667-08166d70'


------------------------

Even if you could use absolute timeouts, it would mean that large chunks of code would have to be broken into several contexts and where absolute timeouts are already being used, it gets complicated!!
By: Serge Vecher (serge-v) 2006-09-05 09:37:24

bcnit: I believe this was addressed in r41900 in trunk. Can you please test the trunk? If you have to have it for 1.2.x, looks like a backport of the patch will be easy to make.
By: Serge Vecher (serge-v) 2006-09-20 10:08:53

Fixed in trunk as of r41900, please make your own patch for 1.2.x. Thanks.