Asterisk PJSIP 438 Invalid Identity Header: trace PASSporT verification

Bind 438 to one request and verifier

Record timestamp and timezone, endpoint or trunk, Call-ID, CSeq, Request-URI, From, P-Asserted-Identity, Date, every Identity field, responder, complete 438 and any STIR Reason field. Establish whether Asterisk generated 438 while verifying an inbound INVITE or received it from a remote verifier on an outbound leg. Correlate back-to-back user-agent legs without assuming their headers are identical.

A request-level 438 requires all applicable Identity fields to lack a valid supported PASSporT. Preserve field-level results; the first invalid field is not enough when a trusted sibling validates. Protect telephone numbers, certificate URLs and PASSporT content in shared captures.

Prove the active Asterisk verification path

Record core show version, loaded STIR/SHAKEN modules, the PJSIP endpoint's stir_shaken_profile, effective eprofile, endpoint_behavior and failure_action. A source-file setting is not proof that the running endpoint loaded it. In FreePBX, retain GUI and generated-configuration ownership instead of editing generated PJSIP files directly.

Confirm that the credential was acquired, supported and trusted before entering signature diagnosis. Retrieval failures remain 436 and trust or algorithm failures remain 437. Preserve certificate validity and revocation evidence independently from PASSporT validation.

Compare the signed and received identities

For each Identity field, preserve compact or full form, supported ppt, origin and destination claims, SIP Date, PASSporT iat, signature result and caller-ID comparison. Compare the request at the signer, every transforming boundary and Asterisk. Do not rewrite From, P-Asserted-Identity or Date during capture, and do not assume a normalized dashboard value is the signed value.

Current Asterisk documentation includes max_date_header_age; newer supported branches can also expose ignore_sip_date_header. Record the exact branch and option availability. Ignoring a missing or invalid SIP Date is a policy change, not a generic signature repair, and does not validate mismatched claims or an invalid signature.

Preserve continuation and per-identity evidence

Asterisk can reject, continue, or continue with a Reason header according to failure_action; use_rfc9410_responses affects the Reason protocol token. When the call continues, use STIR_SHAKEN() to retain identity count, identity, attestation and verification results without treating continuation as successful verification or authorization.

A stale Date or iat and a cryptographic mismatch are not interchangeable. Keep the exact verifier reason, status and profile setting. If a remote provider generated 438, its verification policy and evidence remain authoritative for that leg even when local Asterisk reports a broader dialplan result.

Repair once, then stop and assign ownership

If the authentication service sent compact form, coordinate the RFC 8224 bounded retry with full form and do not retry more than once. Otherwise correct only the proven owner: signer inputs, required extension claims, certificate-key pairing, caller-ID canonicalization, Date handling or a transit transformation. Do not strip Identity, weaken signature checks or regenerate a third party's assertion.

Use an authorized non-emergency identity and provider procedure. Confirm credential retrieval, trust, each PASSporT result, any bounded retry and later authorization separately. No PBX, verifier, provider, PASSporT, Identity header, signature or live call was tested for this guide.

core show version
module show like stir
stir_shaken show eprofiles
pjsip show endpoint <endpoint>
pjsip set logger on
# Reproduce one authorized non-emergency request and capture every Identity result.
pjsip set logger off

Treat certificate retrieval as a constrained verification dependency

Use the STIR/SHAKEN operations guide to preserve x5u restrictions, DNS and fetch evidence, configured CA and CRL material, cache state, time windows and Asterisk's documented verification limits before changing rejection policy.