Summary:	ASTERISK-09208: [feature request] CURL function has no apparent timeout on unreachable host
Reporter:	sohosys (sohosys)	Labels:
Date Opened:	2007-04-06 01:25:42	Date Closed:	2011-06-07 14:02:35
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Functions/func_curl
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	When CURL is used as a step in a dialplan, such as to retrieve caller ID name on an inbound call, if the host specified in the URL is not reachable the dialpan execution freezes. example; add this line to the dialplan; exten => _1[2-9]XXXXXXXXX,n,set(CALLERID(name)=${CURL(http://cnam.provider.com/?number=${CALLERID(num)})}) where cnam.provider.com returns a caller ID name for the nu,mber spoeciifec by the number= querystring now block network access to cnam.provider.com to simmulate a host or netork failure. Call prgogress freezes indefintely. ****** ADDITIONAL INFORMATION ****** Seems that func_curl needs a configurable timeout value to be safe to use, otherwise you are at the mercy of the cnam database operator for call progress. I guess this could be called a feaure request, but the fact that it breaks call progress makes it a minor bug IMO.
Comments:	By: Tilghman Lesher (tilghman) 2007-04-06 08:47:14 In 1.4, a timeout is set for 3 minutes (180 seconds).  We could possibly make this configurable in trunk, but the real solution is to use websites that are only under your own control (and so will always respond quickly). By: sohosys (sohosys) 2007-04-06 09:49:22 COrydon76, I have never seen CURL used for anything other than retreiving CNAM, account nunbers, or some other very small piece of information in the middle of dialplan execution. In MOST of the cases i have seen the server was not under the control of the asterisk sever operator, and if is was that would mean the the operate also has access to the data, so there would be much cleaner methods or retrieiveing available than http. http is an internet protocol, typically used to transfer data ofer public internet links, so the liklihood of server outages or route outages is very high. This should not stop dialplan execution and break asterisk, the user needs the ability to advance the diaplan unconditionally when external influnces dictate the need. This need is not unique to the CURL function, "realtime", and many similar functions may or may not be required for the dialplan to advance successfully, but may be used to aquire external data mid-stream, and in cases where the data is not available quickly the user may elect to advance without it. Is there a way to advance the diaplan by lowering the absoulute timeout before the fucntion, and then possibly increasing it again? normally timeout would advance to the t priority, but with some creative flag setting one might be able to design a workaround for this issue. Is the timeout evaluated during a function execution? By: Tilghman Lesher (tilghman) 2007-04-06 10:26:51 In answer to your question, no, the dialplan timeout will not affect function execution. By: sohosys (sohosys) 2007-04-06 10:57:11 From the curl docs; To limit  a single  request's  maximum  time,  use  -m/--max-time.  Set this option to zero to not timeout retries. (Option added in 7.12.3). Does the asterisk CURL function use the curl package? I think I recall it being a dependency, so I assume yes. Why not just modify the CURL function to pass a literal string to curl, allowing the user to take advantage of all of curls' capabilities? is this not a trivial change? By: Tilghman Lesher (tilghman) 2007-04-06 11:40:42 func_curl uses the libcurl library, not the curl binary.  We would prefer not to add new features to release branches, due to the fact that they are release branches and are thus feature frozen. By: sohosys (sohosys) 2007-04-06 11:55:28 so perhaps this should be changed from a minor bug in 1.2.12 to a feature request in trunk? Do you not agree that dialplan execution failures as a result of CURL timeouts are a minor reproducable bug in 1.2 and 1.4? By: Tilghman Lesher (tilghman) 2007-04-06 14:46:29 No, I don't agree that it's a bug, despite it being undesireable, because it performs exactly the function advertised.  I would think that the opposite behavior (CURL randomly not returning results) would be a much greater problem. As it stands, if you need CURL to be reliably fast, then you should control the web server from which you are retrieving a URL. By: Tilghman Lesher (tilghman) 2007-04-15 22:09:59 Given that nobody has picked up this request, I am suspending it per our policy on feature requests on the bugtracker.  I invite you to post your feature request on the Wiki in the bounty section. This issue may be reopened if/when there is a prospective patch implementing the feature request.  Please ask a bug marshal if you are unable to reopen this bug at that time.