SIP Response Codes

Provenant's SIP redirect servers for signing and verification both define 5 standard VVP call routing outcomes for infrastructure that handles calls. They use numeric SIP response codes (e.g., 302, 307, 603, etc.) to distinguish these outcomes. Each outcome has a standard response code, but the numbers can be overridden by caller policy to meet the needs of different SBCs.

SIP status lines in responses from SIP redirect services include the numeric code, plus a label for one of these 5 outcomes, and then a hex encoding of a 32-bit reason code:

SIP/2.0 306 branded 0xReason

The reason code at the end is NOT for processing during routing, but rather to snapshot evidence state for recording in logs, for troubleshooting by developers, etc. It can be ignored or omitted by entities that don't wish to use it. All routing decisions are made by looking at the SIP status code.

The 5 standard outcomes are:

1. branded: Call should be connected. Brand and CLI should be displayed. Brand attributes, legal identity of caller, TN and its RTU, and delegated signing authority were verified and remain verifiable everywhere. Default SIP response code for this outcome: 306. (A custom redirect code that says to continue routing with brand.)

2. accountable: Brand should be suppressed, but CLI should be displayed. Brand attributes are omitted from the evidence, but the other evidence was verified and remains verifiable, and the caller is therefore accountable to regulators and service providers even if the handset doesn't display the brand. Default SIP response code: 307. (A custom redirect code that says to continue routing without brand.)

3. unknowable: CLI should be suppressed, ideally with a message that says "Caller identity and number withheld" or similar. Dipping CNAM is strongly discouraged, as it would constitute a guess that could invite undeserved trust. No caller attributes are verifiable, so the caller suppressed the VVP mechanism and made no claim about such attributes. This is not an error condition, just an honest acknowledgement that what's known about the caller is near zero and guesses shouldn't be trusted to move the needle. Default SIP response code: 302 (because existing, unsigned traffic needs this outcome and should trigger a no-op, "keep going but I've nothing to say" response to the verifier).

4. dangerous: Call should be rejected. The evidence is definitely broken in ways that are unreasonable — malformed data, missing or invalid signature, a signature from someone who shouldn't be signing, or a dossier that doesn't cover the orig TN. Innocent VVP software should never emit (sign) calls with dangerous evidence. (If a service provider connects the call anyway, brand and CLI must be suppressed, and a warning should be displayed; something like "Caller is dangerous, either due to fraud or misconfigured software.") Default SIP response code: 608

5. policy needed: This is an intermediate rather than a final outcome. It signals that evidence is well formed and complete, but some of it has expired or been revoked since it was created; whether it still proves enough to satisfy a verifier is therefore a subjective question. The specifics are described in the reason code. Each verifier should configure a policy to decide how to react to particular reason codes; until they do so, the call should be rejected (response code 608, reason label "policy needed"; details in code).