Asterisk PJSIP_HEADER_PARAM: From URI and header parameter boundaries

Freeze the exact parameter contract before editing

Record the parameter name, required value, whether it belongs inside the From URI or after the closing angle bracket, the applicable call direction, carrier or application source, endpoint and expected request. PJSIP_HEADER_PARAM() does not decide whether a parameter is authorized, meaningful or accepted by a peer.

Current Asterisk documentation supports only the From header. Do not transfer the example to To, Contact, P-Asserted-Identity or another header, and do not treat the documented isup-oli=27 example as a universal carrier requirement.

Keep URI parameters and header parameters separate

Asterisk exposes uri and header parameter types. A URI parameter is inside the URI enclosed by angle brackets; a header parameter is after the closing bracket. The default parameter type is header, so omitting the type is a material decision rather than harmless shorthand.

A parameter with the right name and value in the wrong location is different SIP. Preserve the complete sanitized From field and the parsed target parameter instead of searching the packet text for a matching substring.

Select the caller or callee channel deliberately

In ordinary dialplan execution the function operates on the current caller channel. Asterisk directs outbound callee changes to a pre-dial handler. Lowercase b() executes on each newly created callee channel before its outbound request; uppercase B() executes on the caller.

With multiple dial destinations, each callee is a separate channel. A successful write on the caller, a Local-channel half or one fork does not prove the parameter reached every outbound INVITE.

Use the narrow function for the narrow job

PJSIP_HEADER_PARAM() gets or sets one From parameter. PJSIP_HEADER() reads an inbound header or adds, updates and removes outbound headers. PJSIP_PARSE_URI_FROM() parses parts of a URI stored in a variable. Those functions overlap in subject but not in evidence.

Do not rebuild the whole From header merely to change one documented parameter unless the actual requirement and identity policy demand that larger mutation. Preserve display name, URI, tag handling and system-owned identity behavior.

Separate emitted syntax from identity and policy

A well-formed From field is not proof of authentication, asserted identity, verified caller ID, attestation, billing identity or carrier acceptance. A proxy or SBC can also normalize or replace a parameter after Asterisk sends the request.

Correlate the exact PJSIP channel with a bounded outbound SIP trace, the next-hop observation and the peer response. Keep signaling identity and connected-party presentation separate from the parameter mutation.

Prove one request and retain a rollback

Use an authorized test destination and one documented parameter. Capture the installed Asterisk release, loaded module, current endpoint, pre-dial execution, callee channel, emitted From field, next-hop copy, response and final call result. Repeat a control call without the mutation.

Remove the scoped write if the contract is absent, the peer rejects it or another component owns the field. Redact telephone numbers, domains, tokens and identity data in shared evidence. This guide is documentation-derived; no PBX, channel, packet or call was tested.

[set-from-param]
exten => s,1,Set(PJSIP_HEADER_PARAM(From,uri,isup-oli)=27)
 same => n,Return()

[from-lab]
exten => _X.,1,Dial(PJSIP/${EXTEN}@lab-endpoint,,b(set-from-param^s^1))

Choose parameter mutation, ordinary headers or inheritable headers deliberately

Use the inheritable-header guide when a calling channel must pass a whole controlled header to outbound PJSIP children; keep that use distinct from one From parameter or one ordinary callee header.