Read 436 as credential-acquisition failure
RFC 8224 defines 436 Bad Identity Info for a verification service that cannot acquire the credentials needed to validate the signature in an Identity header. Because a request can contain multiple Identity fields, the response applies only when credential URIs cannot be dereferenced or credentials cannot be acquired for all of them. Preserve every Identity value and info or x5u reference, the exact request, responder, response and time.
Do not reduce 436 to an invalid caller ID, failed certificate trust, bad signature, expired credential or unreachable PBX. It identifies the acquisition boundary, not the later decision about whether a retrieved credential or signature is acceptable.
Follow the reference without weakening it
Record the credential URI exactly, including scheme, host, port and path, then preserve DNS, connection, TLS and HTTP evidence from the verifier's network position. Redirect behavior, access controls, timeouts, caching and outbound filtering can all affect retrieval without proving that the credential itself is invalid. Do not paste private signing material or a full PASSporT into a ticket.
The authentication service may be able to repair the request by using an info reference that the verifier can access. That does not authorize publishing a credential at an arbitrary public location, disabling URL restrictions or allowing private and link-local targets. The signer remains responsible for a safe, stable credential reference.
Keep 436, 437 and 438 distinct
A 437 response means the verifier acquired or already held at least one referenced credential but did not support it, for example because the issuing CA was not trusted or the credential's signing algorithm was unsupported. A 438 response means no Identity field contained a valid, supported PASSporT. A 428 instead means no usable Identity field was available under a policy that required one.
Classify the failure at the earliest proven boundary. A credential that is reachable can still fail trust or signature validation, while a credential that is trusted in a browser or on another host can remain unreachable to the actual SIP verifier.
Preserve multi-identity and policy context
Do not discard other Identity fields when one reference fails. RFC 8224 recommends avoiding an invalid-identity conclusion when at least one trusted Identity field validates, while RFC 9410 can associate a reported error with a specific PASSporT and can carry STIR errors in Reason when local policy continues the call. Preserve that field-level evidence and the network element that applied policy.
Correct the signer, credential host, resolver, egress policy or verifier configuration only after its ownership is established. Test with an authorized non-emergency identity and the responsible provider's procedure. The Asterisk PJSIP investigation keeps retrieval, trust and signature checks separate.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 8224: Authenticated Identity Management in SIP ↗
- IETF RFC 9410: Handling Identity Header Errors for STIR ↗
- IANA SIP response-code registry ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.