Asterisk PJSIP response headers: channel, answer and pre-bridge timing

Define the one response the functions expose

Asterisk documents PJSIP_RESPONSE_HEADER() as reading a named SIP header from the 200 response on an outbound PJSIP channel. PJSIP_RESPONSE_HEADERS() lists unique header names from the 200 response to the outbound INVITE. Neither interface is documented as a history of provisional 1xx responses, a reader for an error response after an unanswered attempt or a generic transaction archive.

Record the INVITE leg, Call-ID, CSeq, final status, answering endpoint and collection time with every value. A header observed in a 180, 183, 3xx, 4xx or 5xx message is separate evidence and should remain attached to that exact response.

Check the installed release before using the functions

Both functions are documented from Asterisk 16.28.0, 18.14.0 and 19.6.0. Confirm the installed branch, maintenance release and loaded res_pjsip_header_funcs module rather than inferring support from current online documentation or a newer development branch.

If the function is unknown, treat that as a version or module boundary first. Do not replace the dialplan with a shell or database scrape merely to imitate a missing channel function; decide whether a supported upgrade or a different documented observation path owns the requirement.

Run on the answered outbound channel

The documentation warns that a normal dialplan call commonly runs on the incoming caller channel. It shows the Dial() uppercase U Gosub so the read occurs on the called channel after answer and before Asterisk connects it to the calling channel. This is a pre-bridge handler, not the lowercase b pre-dial handler used to edit an outbound request before dialing.

The U routine starts at s,1, runs PBX services on the called channel and must Return(). Keep it short. Long work, external requests or a missing return can delay or alter call connection, and a handler log on the caller does not prove the callee response was read.

[read-answer]
exten => s,1,Set(__PEER_ROUTE=${PJSIP_RESPONSE_HEADER(read,Record-Route,1)})
 same => n,Return()

[from-example]
exten => _X.,1,Dial(PJSIP/${EXTEN}@example-trunk,30,U(read-answer))

Enumerate names, then select the intended instance

PJSIP_RESPONSE_HEADERS(prefix) returns a comma-separated list of matching names and collapses repeated names to one list entry. It does not return values or the count of instances. PJSIP_RESPONSE_HEADER(read,name,number) returns the selected matching value; the number defaults to the first instance, and a trailing wildcard can match names that begin with a prefix.

Preserve the exact name, match form and instance number. A list that contains Via once does not establish that the response had only one Via field, while an empty value does not prove the entire 200 response had no headers.

Keep request, response and party state separate

PJSIP_HEADER() reads inbound request headers or edits outbound request headers. PJSIP_HEADERS() lists names from an INVITE request. The response functions read the successful outbound INVITE response. These are different messages, channels and lifecycle points even when the same field name appears in each.

Connected-line, redirecting, Contact, route-set and identity behavior can also have dedicated Asterisk state and trust controls. A response-header string is evidence about one received message; it is not by itself proof of authenticated identity, peer policy, selected route, later in-dialog behavior or successful media.

Copy only the minimum value to its consumer

If later caller-side dialplan needs a value, copy only the approved field from the callee handler into an explicitly inherited or shared variable and document its owner and lifetime. Sanitize values before logging or passing them to an external consumer. Do not export the complete response, credentials, asserted identities or routing data by default.

Verify the value against one bounded protocol trace, then test absence, duplicate instances, a different answering peer and an unrelated route. Remove temporary logging and retain only approved metadata. This guide is documentation-derived; no PBX, response header or call was tested.

Separate request-name inventory from answer data

The inbound-header inventory guide covers names on an INVITE request. Response-header functions cover the 200 response on an answered outbound channel; neither substitutes for the other.