[asterisk-bugs] [Asterisk 0012920]: [patch] Added CURL() Function Timeout Argument

noreply at bugs.digium.com noreply at bugs.digium.com
Tue Jun 24 22:24:41 CDT 2008


A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12920 
====================================================================== 
Reported By:                davevg
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12920
Category:                   Functions/func_curl
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     feedback
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 124707 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             06-23-2008 16:12 CDT
Last Modified:              06-24-2008 22:24 CDT
====================================================================== 
Summary:                    [patch] Added CURL() Function Timeout Argument
Description: 
If you have a long running web script the CURL function is currently hard
coded to timeout after 180 seconds.  This patch adds a 3rd parameter to the
function which when set overrides the 180 second default.

Example usage:
exten => 1,1,Set(foo=${CURL(http://127.0.0.1/test.pl,,3)})
Which will set a timeout of 3 seconds on the CURL call.
====================================================================== 

---------------------------------------------------------------------- 
 sohosys - 06-24-08 22:24  
---------------------------------------------------------------------- 
We posted the bounty, and the version of the patch provided for earlier
versions is great (1.2,1.4) using the CURL_TIMEOUT channel variable as
suggested by Corydon76. Since we use CURL exclusively for CNAM queries we
needed to make sure the function returned a value before SIP timers
expired, even if that means returning a null value. The request to set
other options was made under the assumption that all of the options could
be passed in one string like it is with the command line curl, but upon
further review we learned that libcurl requires each option to be set
explicitly. When that is considered the simpler solution of just setting
the timeout better met our needs. The other options are rather obscure, and
unless someone else can show where there would be additional value I would
argue that the timeout is all that is really needed based on how I have
seen this function used in the past by others, and in our current
application. The default 180 second timer is far too long for anything that
happens in real time in any dialplan I have seen. My vote (FWIW) would be
to move forward with the single channel variable CURL_TIMEOUT. If you
consider the fact that all SIP timers can expire while the CURL function is
waiting for a hung web application, resulting in a dropped channel, many
would consider the current 180 second timer a bug. The situations where the
time is needed are few and far between. All of these conditions do not
result in a failed call because libcurl returns very quickly; failed DNS
query, no route to destination host, connection refused by remote host, any
http error, etc. The ONLY situation where we have had calls drop is when
the remote web server allows a connection to be established but does not
return data or close the connection before the channel progress timers
expire as in the case of a hung app or slow/hung underlying database. The
sample perl script shown in this thread is perfect for simulating the
problem. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
06-24-08 22:24  sohosys        Note Added: 0089193                          
======================================================================




More information about the asterisk-bugs mailing list