Asterisk PJSIP 428 Use Identity Header: trace the signing boundary

Bind 428 to one request and PJSIP leg

Record the timestamp and timezone, user-visible symptom, Request-URI, endpoint or trunk, Call-ID, CSeq, top Via branch, From, P-Asserted-Identity, Date, every Identity header, responder, full 428 response and any STIR Reason field. Determine whether Asterisk received 428 on an outgoing request or generated it while verifying an inbound request. Do not assign the failure to the PBX, carrier or endpoint from a dashboard label alone.

With authorization, enable the PJSIP logger for one bounded reproduction, disable it immediately and protect numbers, identities, credentials, PASSporTs and certificate URLs. Asterisk can terminate one SIP leg and originate another, so correlate channels without assuming the same Identity header crossed the back-to-back user-agent boundary.

Establish the implementation and profile boundary

Asterisk's deployment guide explicitly describes the STIR/SHAKEN refactor from the first quarter of 2024 and says the earlier implementation was only partly functional and not interoperable. Record core show version, inspect the loaded STIR/SHAKEN modules and use documentation for that exact supported release. Do not assume a setting from a later branch exists on an older long-term-support installation.

Current Asterisk associates a STIR/SHAKEN profile with a PJSIP endpoint through stir_shaken_profile. Its endpoint_behavior can be off, attest, verify or on, and effective profiles combine global and profile values. Inspect the loaded endpoint and effective profile before editing source files; in FreePBX, preserve the supported GUI and generated-configuration ownership.

Trace caller ID to the TN and signing material

For an outgoing call, Asterisk uses the channel caller ID to find a TN object and then creates the Identity header from the applicable private key, public-certificate URL, attestation level and profile. Current documentation notes a release boundary at 18.23.0, 20.8.0 and 21.3.0 for canonicalizing caller IDs before TN lookup. Earlier releases required an exact TN-object match. Preserve the exact runtime value and version before changing number formatting.

Asterisk also warns that manually changed From or P-Asserted-Identity values can disagree with the channel caller ID used for signing, causing remote validation failure. Do not copy private keys into logs, expose them with the public certificate, manufacture a TN object or raise A, B or C attestation merely to clear 428. Signing authority and attestation belong to the provider and number-authorization relationship.

Separate missing Identity from failed verification

On incoming verification, confirm whether the endpoint has an active profile, verification behavior is enabled and an Identity header actually arrived. Asterisk then evaluates the credential URL, identity timestamp, SIP Date, certificate cache and retrieval, CA and CRL validation, signature and caller-ID match. Those checks can lead to other 4xx identity errors; they do not all explain 428.

Preserve failure_action: Asterisk can reject, continue with a Reason header, or continue without one. Its use_rfc9410_responses option changes the Reason protocol token from SIP to STIR and may not be supported by every participant. When a call continues, the STIR_SHAKEN() dialplan function can report identity count, identity, attestation and verification result; treat that runtime evidence separately from final call authorization.

Correct narrowly and verify the provider contract

Correct only the demonstrated owner: missing endpoint profile, disabled attestation behavior, unmatched channel caller ID and TN object, unavailable signing material, public-certificate retrieval, a wrong header transformation or an upstream signing expectation. Preserve the former configuration, certificate ownership and rollback trigger. Never paste a private key or full PASSporT into a ticket, and do not relax certificate-URL security controls to force acceptance.

Use an authorized non-emergency test identity and the carrier's current validation procedure. Confirm the exact outgoing INVITE, presence and structure of Identity, final response or STIR Reason field, and expected provider behavior without inferring production acceptance from a single call. No PBX, endpoint, provider, certificate, Identity header, policy 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
# Place one authorized non-emergency test call and capture the INVITE and 428 or STIR Reason.
pjsip set logger off

Confirm the complete loaded signer path

Use the STIR/SHAKEN operations guide to relate the attestation object, TN object and endpoint-selected profile to the effective profile and outbound INVITE. A configured key or TN row does not prove that the rejected request was signed.