What the SIP Identity header is for
The SIP Identity header carries a cryptographically signed assertion about the calling party's identity, allowing a receiving network to verify that the caller ID presented hasn't been altered or spoofed in transit. This is the SIP-level mechanism that underlies STIR/SHAKEN-style caller-ID authentication frameworks used in some networks (notably for calls terminating on the US PSTN, though the underlying SIP mechanism is not US-specific).
The four related error codes
| Code | Meaning | Typical cause |
|---|---|---|
| 428 Use Identity Header | The receiving server requires a signed Identity header, and the request didn't include one. | The originating side isn't sending Identity headers at all — often a signing/attestation gap upstream of where the call entered your path. |
| 436 Bad Identity Info | An Identity header was present, but the information it referenced (e.g. the certificate it points to) couldn't be retrieved or didn't validate. | A broken or unreachable certificate reference, or a genuinely invalid signature. |
| 437 Unsupported Credential | The Identity header used a credential type or certificate the receiving server doesn't support or trust. | A certificate authority or credential format the receiving network doesn't recognize. |
| 438 Invalid Identity Header | The Identity header itself is malformed, or otherwise fails validation independent of the credential-retrieval issues covered by 436/437. | Malformed header syntax, or a signature that doesn't match the call's actual content. |
Diagnosing which one applies
- Capture a SIP trace and confirm the exact response code and which device in the path generated it.
- Check whether the request that triggered it actually included an Identity header at all (428 specifically means it didn't).
- If an Identity header was present, the specific 436/437/438 distinction points to where in the validation process it failed — credential retrieval, credential trust, or header validity respectively — which narrows where upstream to investigate.
- Confirm whether this is a per-call condition (a specific upstream source not signing calls correctly) or a systemic one (every call from a given trunk fails the same way).
Where the fix actually needs to happen
These errors originate from a mismatch in how a call was signed (or not signed) upstream of where the receiving network checks it — the fix is not something the terminating side (you) can typically resolve by changing local configuration, since the Identity header is generated earlier in the call path, closer to where the call originated. If you're consistently seeing these on calls you originate, the conversation needs to go to whichever carrier or platform is responsible for signing the call before it reaches the receiving network.
What this is not
These codes are about caller-ID verification failing — they are not a caller-ID formatting problem in the way a malformed E.164 number would be, and they are not resolved by simply changing what caller ID is sent. CallCenterBoost does not provide instructions for bypassing or evading caller-ID authentication — doing so is both a compliance risk and, on many networks, technically ineffective, since the whole point of the mechanism is to detect exactly that.
Where to go from here
For CLI-route-specific caller-ID questions (not the same as SIP Identity/STIR-SHAKEN verification, though related), see CLI & NCLI Routes or CLI vs Non-CLI (NCLI) routes explained. For route-level SIP troubleshooting generally, see SIP Termination.