Asterisk PJSIP_PARSE_URI: extract SIP URI parts without inventing trust

Preserve the source value before parsing it

PJSIP_PARSE_URI(uri,type) returns one documented part of a URI. Record the complete original value, channel, message direction, header or variable owner and intended policy before asking for display, scheme, user, passwd, host, port or one of the listed URI parameters.

A parsed component is derived data. It does not replace the received header, prove which endpoint owns the value or establish that the value is safe to use as a destination.

Choose literal-value and variable-name paths deliberately

PJSIP_PARSE_URI() receives the URI value directly. PJSIP_PARSE_URI_FROM() instead receives the name of a variable whose contents contain the URI. The variable-based function is documented since Asterisk 18.24.0, 20.9.0 and 21.4.0, while the direct function is documented since 13.24.0 and 16.1.0.

Do not interchange a variable name with its expanded contents. Confirm the installed branch and loaded function before choosing the newer path, and keep an explicit failure branch when the function is unavailable or the source is empty.

Interpret the documented selectors exactly

The functions document display, scheme, user, passwd, host, port, user_param, method_param, transport_param, ttl_param, lr_param and maddr_param. The documented absence values matter: port can return zero, ttl_param can return -1 and lr_param can return zero.

Do not collapse absent, empty, zero, invalid and unsupported-selector outcomes into one test. Preserve the selector and raw URI alongside the returned value so a later branch can distinguish syntax from policy.

Keep SIP name-address and URI structure visible

RFC 3261 distinguishes a name-address form from a bare address specification and gives SIP URIs separate user, host, port, URI-parameter and header components. A From or To header can therefore contain display text and header parameters in addition to its URI.

When the source came from PJSIP_HEADER(), retain the complete header value and confirm what substring the dialplan intends to parse. Do not use a display name, a header tag or one returned URI field as a substitute for the complete message evidence.

Separate parsing from routing and authorization

A successful host or transport_param read does not prove endpoint identification, authentication, dialplan authorization, DNS resolution, connection reuse, selected PJSIP transport or delivery. RFC 3261 also treats an omitted port differently from an explicitly written default port when comparing URIs, and address resolution can use DNS procedures.

Apply allowlists and authorization at the policy boundary that consumes the result. Asterisk warns that dialplan security controls who can access PBX services; parsing an untrusted value is not that authorization decision.

Validate the consumer, not only the parser result

Trace the returned component into the exact comparison, lookup, log field, route or generated value that consumes it. If a restricted character set is part of that policy, Asterisk documents FILTER() as retaining only explicitly allowed characters; filtering is still not identity proof and silently changing a value may be worse than rejecting it.

Prefer an explicit reject or quarantine branch for malformed or unauthorized input. Redact passwords and sensitive addressing from logs, preserve rollback and test accepted and rejected examples on the installed branch. This guide is documentation-derived; no parser, header, route or call was tested.

Separate URI parsing from channel-header mutation

The PJSIP_HEADER_PARAM guide shows when to read or set one active-channel From parameter instead of parsing a copied URI value.

Preserve the channel-owned URI before parsing it

Use the channel-context guide to decide whether the value is a dialog URI, target or original Request-URI, then parse one component without changing its evidence owner.

Parse MESSAGE identity without confusing it with routing

The MessageSend guide keeps the destination-derived Request-URI separate from MESSAGE To and From values before any component is extracted or trusted.