VoIP.infoThe independent guide to business communications.
VoIP.info Troubleshooting

Asterisk PJSIP_PARSE_URI returns an empty or wrong component

Trace one URI from its exact SIP header or channel variable through function availability, argument form, selector, absence sentinel and the downstream policy or routing decision.

Reviewed 2026-10-13Asterisk Latest API branch 23 PJSIP_PARSE_URI, PJSIP_PARSE_URI_FROM, PJSIP_HEADER and FILTER documentation plus current Asterisk security guidance and RFC 3261 reviewed October 13, 2026; no Asterisk host, module, channel, header, variable, URI, parser result, endpoint, route, transport, DNS result, SIP message or call was inspected or testedAdvancedDocumentation based · not lab tested

Freeze the raw input and first wrong observation

Record timestamp and timezone, Asterisk branch, loaded modules and available functions, channel name and technology, SIP direction, complete redacted header or variable value, chosen function, exact arguments, selector, returned value and downstream branch.

Classify the first divergence: source missing, wrong channel or message direction, header contains a name-address form, direct value and variable name were confused, selector is wrong, documented absence sentinel was misread, parser rejected the value, or parsing succeeded but later policy or routing differed.

Prove function availability and argument form

Confirm the installed branch exposes the selected function. PJSIP_PARSE_URI() expects the URI value; PJSIP_PARSE_URI_FROM() expects the name of a variable containing that value and has later version floors. Inspect the variable immediately before the call without exposing secrets.

A blank result from an unavailable or miscalled function is not evidence that the original URI omitted the requested component. Correct the function boundary before changing SIP routing.

Compare the complete value with the selected component

Retain the full URI or name-address value and compare it with the requested display, scheme, user, passwd, host, port or URI-parameter selector. Keep header parameters such as a tag outside the URI-component claim unless separate evidence identifies them.

Do not split on @, :, ; or angle brackets and then call the result equivalent to the parser. SIP URI syntax, escaping, IPv6 literals and parameters make manual delimiter assumptions fragile.

Interpret zero, minus one and empty results separately

The documented functions can return zero for an absent port, -1 for an absent TTL parameter and zero for an absent loose-routing parameter. An empty display or user part may also be valid for the value being inspected, while malformed input or an unsupported selector is a different condition.

Branch on the documented contract for that selector. Preserve the original URI so the diagnostic does not infer validity merely from one scalar result.

Follow the parsed value into the real decision

If the component is correct but the call still uses another endpoint, transport or target, continue through endpoint identification, authentication, dialplan context, outbound proxy, DNS resolution, transport selection and the emitted Request-URI. A parsed transport_param is not proof of the transport Asterisk selected.

If the value controls access, prove the allowlist and authorization branch. Do not widen patterns or accept arbitrary hosts merely to make the parsed test pass.

Correct one boundary and retest positive and negative cases

Correct only the first proven mismatch: source channel, header selection, variable assignment, direct-versus-variable function, selector, absence handling, validation, authorization or consumer logic. Preserve the previous dialplan and loaded-state evidence.

Repeat an authorized example, an absent-component example and a rejected or malformed example on the installed branch. Confirm the returned value and final policy outcome separately, then remove temporary logging and retain redaction. No PBX, URI, parser result, route or call was inspected or tested.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Guide · Asterisk Latest API branch 23 PJSIP_PARSE_URI, PJSIP_PARSE_URI_FROM, PJSIP_HEADER and FILTER documentation plus current Asterisk security guidance and RFC 3261 reviewed October 13, 2026; no Asterisk host, module, channel, header, variable, URI, parser result, endpoint, route, transport, DNS result, SIP message or call was inspected or tested

Asterisk PJSIP_PARSE_URI: extract SIP URI parts without inventing trust

Parse a bounded SIP URI into documented components while keeping header ownership, absent-value sentinels, authorization, DNS, transport selection and final routing independently observable.

Read guide →
Guide · Current Asterisk PJSIP header, inheritable-header, header-list, header-parameter, response-header and pre-dial-handler documentation reviewed October 8, 2026; PJSIP_INHERITABLE_HEADER is documented from 20.19.0, 22.9.0 and 23.3.0, and no PBX, dialplan, channel, header, provider, endpoint, request, response, registration, authentication exchange, availability, compatibility or call was inspected or tested

Asterisk PJSIP outbound headers: channel ownership, inheritance and proof

Put a required SIP header on the channel that will send it, distinguish direct from inherited headers and verify the emitted request.

Read guide →
Guide · Current Asterisk PJSIP transport-selection, object-relationship and proxy guidance plus Asterisk 22 res_pjsip and outbound-registration references reviewed October 7, 2026; no Asterisk host, transport, socket, connection, DNS response, proxy, registrar, endpoint, certificate, request, media path or live call was inspected or tested

Asterisk PJSIP transport selection: URI, DNS, connection and object boundaries

Trace the URI scheme and transport parameter through SRV resolution, transport-object choice and TCP or TLS connection reuse without treating an endpoint field as the only selector.

Read guide →
Guide · Current Asterisk 22 dialplan, CLI, application and hangup-cause documentation reviewed October 1, 2026; no Asterisk host, dialplan, endpoint, trunk, call, media or emergency route was tested

Testing an Asterisk dialplan change safely

Prove context entry, extension matching, priority execution, call-leg outcomes and rollback without treating a successful reload as a successful call.

Read guide →
Reference · SIP standards; extension support depends on both peers

SIP URI structure: identity, routing and parameters

Parse sip and sips addresses without assuming they behave like ordinary telephone numbers.

Read guide →
Reference · SIP standards; extension support depends on both peers

Via, Contact, Route and Record-Route

Distinguish response routing, dialog targets and proxy paths in a SIP trace.

Read guide →
Guide · Operational guidance; Asterisk 22 / FreePBX 17 where applicable

Least privilege for PBX users and integrations

Separate the right to register, place calls, administer the PBX and read sensitive data.

Read guide →
Diagnostic · RFC 3261 and RFC 4504 plus current Asterisk PJSIP dialing, object, dialplan, pattern-matching, channel-cause and protocol-logging documentation reviewed September 28, 2026; no PBX, endpoint, provider, number plan, pattern, URI, route or live call tested

Asterisk PJSIP 484 Address Incomplete: trace the constructed URI

Bind SIP 484 to the exact responder and PJSIP leg, then trace endpoint input, dialplan normalization and trunk URI construction before changing digits.

Read guide →