Freeze one lookup and classify the first divergence
Record timestamp and timezone, installed Asterisk and libcurl versions, loaded func_curl, dialplan revision, context, extension and priority, caller channel identifiers, redacted URL components, method, effective channel and global option names, start and finish time, result classification, parse target and fallback branch.
Classify the first divergence: module or function unavailable, wrong dialplan loaded, destination not approved, raw input changed the URL, DNS or connection did not complete, TLS verification failed, redirect changed the destination, HTTP policy rejected the status, body was empty or too large, JSON was malformed, key was missing, or the fallback branch was wrong.
Prove the loaded function and effective scope first
Use the Asterisk CLI to confirm the running instance exposes CURL and CURLOPT and that the disputed context and priority are loaded. Compare the channel-specific settings with global settings; the documented precedence means an inherited global value can affect a channel that did not set its own option.
Do not begin by changing a global timeout, redirect or TLS control. That widens the experiment and can alter unrelated calls before the original option owner is known.
Separate URL authorization from URI encoding
Reconstruct the redacted URL from its fixed scheme, host, port and path plus each dynamic component. Confirm dynamic values were encoded with URIENCODE and that the final destination, including any redirect, remained inside the approved policy.
Encoding makes a component URI-safe; it does not make the host trusted, the request authorized or the returned body safe. Rotate any exposed credential and remove sensitive query, header or body data from diagnostic output.
Split name resolution, connection and total elapsed time
Preserve the configured conntimeout and httptimeout, then correlate Asterisk warning output with authorized DNS, network, proxy and remote-service evidence. The reviewed implementation maps those settings to libcurl connection and total-transfer controls; libcurl documents that the total limit includes connection time.
A total timeout can therefore include DNS, connection, handshake, request and response time. Do not attribute it to the remote application until the earlier phases are independently observed.
Keep HTTP acceptance and body parsing separate
Record whether redirects were enabled, the bounded maximum, and which response codes were listed in failurecodes. Preserve only a redacted body classification and length unless an authorized secure capture is required. Then validate content type and schema before calling JSON_DECODE.
Because JSON_DECODE returns an empty string for a missing key, compare the original response state, parse success, key presence and resulting value separately. Never treat arbitrary remote text as a dial string, application name, file path or executable command.
Correct the earliest owner and repeat controlled failures
Correct only the earliest demonstrated boundary: module load, active priority, fixed destination, URI component encoding, channel option, global default, DNS, egress rule, proxy, certificate trust, redirect policy, HTTP failure-code policy, body limit, schema parser or fallback. Keep a rollback.
Repeat the original lookup plus one refused connection, one timeout, one rejected HTTP status and one missing-key control. Restore temporary logging. No PBX, module, dialplan, credential, DNS answer, proxy, certificate, remote service, response, packet, media stream or live call was inspected or tested.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Asterisk CURL dialplan function ↗
- Asterisk CURLOPT dialplan function ↗
- Asterisk JSON_DECODE dialplan function ↗
- Asterisk URIENCODE dialplan function ↗
- Asterisk command-line interface ↗
- Asterisk func_curl implementation ↗
- libcurl CURLOPT_TIMEOUT reference ↗
- libcurl CURLOPT_CONNECTTIMEOUT reference ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.