]> Jolly Roger Telephone Company

US roger@jollyrogertelephone.com

Jolly Roger Telephone Company

US steveb@jollyrogertelephone.com

US phillip.askew@theaskewcrew.com

telephony, callerid, spoofing, PSTN Caller-ID spoofing remains a significant problem in telephony, particularly across inter-domain and international call paths where identity frameworks may not yet be fully deployed. This document defines Caller-ID Vouching and Vetting (CIDVV), a lightweight verification mechanism that lets the called party ask a simple question:

• "Will the party responsible for this number vouch for this call right now?"

CIDVV uses short-lived signaling exchanges encoded within the Calling Party Number to confirm that the calling party controls the Asserted Caller-ID. It is designed to operate across heterogeneous SIP and SS7/TDM networks without requiring new protocol extensions or persistent identity infrastructure. It relies on existing call routing behavior and intentionally leverages failure responses as a signaling mechanism. CIDVV is complementary to STIR/SHAKEN and other identity frameworks. It provides an incrementally deployable tool that can operate across call paths where a complete cryptographic attestation signal is not available to the terminating side, while being designed to tolerate common forms of intermediate network modification. By requiring demonstrable real-time control of the Asserted Caller-ID, CIDVV strengthens resistance to spoofing in a practical, low-overhead manner. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction CIDVV supports two closely related functions: Vouching (real-time verification that the party responsible for the Asserted Caller-ID vouches for a specific call) and Vetting (confirmation that a number is controlled by its expected owner, useful for branding, trust programs, and registries). The primary focus of this document is the vouching mechanism, which directly addresses Caller-ID spoofing for individual calls. Caller-ID spoofing remains a widespread problem in modern telephony. Fraudulent and nuisance callers frequently impersonate legitimate numbers, eroding trust and complicating call screening for recipients. At the signaling layer, legitimate Caller-ID use and malicious impersonation can appear identical. Originating networks routinely assert a Caller-ID on behalf of a calling party, but intermediate carriers and terminating networks generally cannot infer the intent behind that assertion from ordinary PSTN signaling alone. Without a reliable identity signal, the network may be unable to distinguish legitimate use from malicious impersonation. This document defines Caller-ID Vouching and Vetting (CIDVV), a lightweight, incrementally deployable mechanism that allows the called party, or a platform acting on its behalf, to ask a simple real-time question:

• "Will the party responsible for this number vouch for this call right now?"

CIDVV verifies Caller-ID control through network reachability rather than relying solely on asserted identity. It requires that a party asserting a Caller-ID demonstrate control of that number by being able to receive a short return signaling call within a brief Validity Window. CIDVV operates by encoding signaling information within the Calling Party Number and leveraging existing call routing behavior to perform a challenge-response exchange. The protocol requires no new SIP headers, protocol extensions, response codes, or changes to SS7 signaling. It is designed to function across mixed SIP and TDM networks, including international paths. CIDVV is complementary to STIR/SHAKEN and other identity frameworks. It provides an additional reachability-based verification signal in environments where a complete cryptographic attestation signal is not available to the terminating side, while being designed to tolerate common signaling modifications by intermediate networks. It intentionally uses distinct failure-response behaviors as part of its signaling mechanism and does not require universal adoption to deliver benefit. The mechanism leverages two key elements of the existing telephone ecosystem:

• Authoritative PSTN routing: Calls to a telephone number are generally routed to the provider, service, or party responsible for that number. CIDVV uses this existing routing behavior to test whether the party responsible for an Asserted Caller-ID can receive and respond to a return verification call.
• Calling Party Number encoding: CIDVV carries its signaling state in compact numeric values placed in the Calling Party Number. The prefixes "100" and "101" identify CIDVV verification calls while preserving ordinary routing to the Asserted Caller-ID.

CIDVV operates entirely within standard PSTN routing behavior and requires no media exchange. While it does not provide absolute identity assurance, it delivers strong, real-time evidence of Caller-ID control in a practical and low-overhead manner.

Terminology

• Caller-ID: The telephone number presented to the called party (what the end user sees).
• Asserted Caller-ID: The Caller-ID value that is being vouched or vetted by this protocol. This is the number whose control the calling party claims, and it is used for state management, token computation, and correlation.
• Calling Party Number: The value carried in the signaling protocol (e.g., SIP From header or ISUP Calling Party Number parameter). In many deployments this is the same as the Caller-ID presented to the called party, but the signaling value and user-visible Caller-ID are not always identical.
• Alice: An example participant in CIDVV flows. In vouching flows, Alice is the calling party asserting a Caller-ID. In vetting flows, Alice is the verifier of Bob's number.
• Bob: An example participant in CIDVV flows. In vouching flows, Bob is the called party whose platform requests a vouch. In vetting flows, Bob is the number owner whose number is being vetted.
• CIDVV Platform: A system that implements the vouching and vetting procedures defined in this document.
• CIDVV-aware Network Element: A network element (typically an SBC or proxy) that recognizes CIDVV signaling prefixes ("100" and "101") in the Calling Party Number and routes those calls to a CIDVV platform. In some deployments, it may also forward initial INVITEs for new dialogs to a CIDVV platform and handle local responses that allow the original call to continue.
• Vouch: The act of a CIDVV platform asserting that it has verified control of a telephone number through the challenge-response mechanism described in this document, which may consist of one or more verification calls. A successful vouch provides strong evidence that the calling party controls the Asserted Caller-ID.
• Vet (or Vetting): The process by which a CIDVV platform confirms that a party controls a telephone number via the three-call challenge-response sequence. Vetting may be performed on behalf of third parties such as Caller-ID branding services, Vetting Agents, law enforcement agencies, trade organizations, or enterprise trust programs.
• Vouching Call: A short signaling call used in the CIDVV protocol. CIDVV defines Phase 1 ("100" prefix) and Phase 2 ("101" prefix) verification calls.
• Phase 1 Vouch ("100" prefix): The initial Vouch verification step. Expected response behavior is a Busy-class response (e.g., SIP 486 Busy Here).
• Phase 2 Vouch ("101" prefix): The secondary Vouch step. Expected response behavior is a Rejection-class response (e.g., SIP 603 Decline).
• Successful Vouch: Requires both Phase 1 and Phase 2 to complete with the expected behaviors within the Validity Window.
• Verification Not Performed: A condition where verification could not be completed due to system or network conditions.
• Validity Window: The time interval during which the originating CIDVV platform will accept and correlate a vouch attempt (return call) from the called party. This is typically on the order of 10-30 seconds.
• Unsuccessful Vouch: A verification result indicating that the vouch did not complete successfully, including cases involving missing state, unexpected response behavior, timeout, altered signaling, or incomplete verification phases.
• Vouch-Call Timeout: A local timer used by the platform that initiates a Phase 1 or Phase 2 verification call to limit how long it waits for a response. This is typically 3-6 seconds for domestic calls and longer (e.g., 8-20 seconds) for international calls. It is distinct from the Validity Window.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 and RFC 8174 when, and only when, they appear in all capitals, as shown here.

Motivation and Advantages CIDVV was designed in response to practical constraints observed in real-world telephony deployments. Earlier design alternatives included carrying verification data in Real-Time Text (RTT), media, SIP headers, or SDP bodies. These approaches were not selected because they either required media-path establishment, depended on SIP-specific behavior, or were likely to be removed, rewritten, or ignored by back-to-back user agents, gateways, or interworking functions in mixed SIP, SS7/TDM, and ISDN environments. CIDVV instead carries short-lived verification state in the Calling Party Number and uses distinguishable non-success response behaviors as the verification signal. This design favors information elements and response semantics that are commonly preserved across heterogeneous telephone networks, including inter-provider and international paths. The result is a mechanism that can be deployed incrementally without defining new SIP headers, new SIP response codes, new media behavior, or new SS7/ISDN protocol elements. CIDVV is not intended to replace STIR/SHAKEN. STIR/SHAKEN provides important cryptographic caller identity assurance and remains a key part of the telephone identity ecosystem. CIDVV adds a complementary reachability-based signal: whether the party responsible for the Asserted Caller-ID can receive and correctly respond to verification calls for this call attempt within the Validity Window. The primary advantages of CIDVV are:

• Uses existing telephony behavior: CIDVV relies on existing call routing, Calling Party Number delivery, and non-success response behavior rather than new protocol extensions.
• Provides reachability-based anti-spoofing evidence: A successful vouch gives strong evidence that a party controlling the Asserted Caller-ID is participating in the call attempt during the Validity Window.
• Works across mixed network environments: CIDVV is designed for SIP, SS7/TDM, ISDN, and interworking environments, including paths where SIP-specific identity information may not survive end-to-end.
• Requires no media exchange: Verification calls are short signaling-only exchanges and are not intended to establish media.
• Supports incremental deployment: CIDVV can be implemented by enterprises, service providers, or third-party CIDVV platforms. Universal deployment is not required for cooperating parties to obtain benefit.
• Provides operational visibility: Number owners and their providers can gain telemetry about attempted use of their numbers in suspicious or spoofed calling scenarios.
• Supports flexible operational models: CIDVV can be deployed by the originating provider, terminating provider, enterprise SBCs, hosted platforms, or third-party services, depending on local policy and routing arrangements.

By avoiding dependence on centralized authorities or end-to-end SIP feature preservation, CIDVV lowers the barrier to deployment while providing a practical additional tool for detecting and reducing Caller-ID spoofing.

Related Work and Prior Dialback Mechanisms CIDVV is related to prior work on telephone-number authorization, dialback authentication, and out-of-band caller-identity verification. The STIR framework defines mechanisms for signing and verifying telephone calling-party information. STIR and STIR/SHAKEN are important parts of the telephone identity ecosystem, and CIDVV is not a replacement for them. CIDVV provides a complementary signal based on reachability. It asks whether the party reached through ordinary telephone routing for the Asserted Caller-ID will vouch for a specific call attempt within a short Validity Window. This signal can be useful where a terminating platform does not have a complete or usable cryptographic attestation signal for a particular call path, or where such information is not available across the full path. It can also be used alongside STIR verification results, call analytics, traceback processes, reputation systems, and local call-handling policy. Prior STIR-related work has also considered callback-based verification. For example, describes a callback mechanism intended to help bootstrap telephone-number validation for STIR. That approach relies on STIR-specific mechanisms, SIP behavior, certificate handling, and new SIP response codes. CIDVV differs by avoiding new SIP headers, new SIP response codes, media establishment, and end-to-end SIP dependencies. CIDVV instead carries compact state in the Calling Party Number and uses distinguishable non-success response behavior as the verification signal. Caller ID Verification (CIV) is another related dialback mechanism. CIV uses a reverse verification call and a challenge-response exchange involving DTMF. CIDVV differs from CIV by avoiding media and DTMF entirely. CIDVV verification calls are signaling-only and are expected to terminate with non-success responses. This avoids the operational cost, complexity, and delay of establishing media paths solely for verification, especially at terminating platforms that may need to evaluate large volumes of inbound calls. This design is intended to improve deployability across heterogeneous SIP, SS7/TDM, ISDN, and international interworking environments where media behavior, SIP extensions, or end-to-end signaling features may not be reliably preserved. STIR out-of-band work, including and , addresses delivery of PASSporT objects outside the ordinary SIP signaling path. CIDVV addresses a different part of the problem space. It does not transport PASSporTs and does not attempt to prove legal ownership or all delegated rights to use a telephone number. Instead, CIDVV provides a real-time reachability signal tied to a specific call attempt. Number-routing asymmetry remains an important deployment consideration. In many real-world deployments, the party authorized to use a number, the provider from which the number is obtained, the originating service provider, and the platform that receives calls for that number may be different entities. CIDVV does not eliminate this operational reality. Rather, it requires the responsible party, provider, enterprise SBC, or delegated CIDVV platform to participate in the vouching process and maintain the state needed to answer verification calls correctly. Delegated or authorized use of an Asserted Caller-ID, such as an enterprise application, healthcare calling service, contact-center platform, or contracted calling provider, can be supported when that service is integrated with the responsible CIDVV platform for the Asserted Caller-ID. For example, the delegated service, the enterprise, the enterprise's provider, or another authorized platform can deposit the short-lived call state needed for vouching. If no such state is deposited, CIDVV does not determine whether the call is malicious; it only indicates that the responsible platform did not vouch for that specific call attempt. Like other dialback mechanisms, CIDVV needs to address reflection and amplification risk. CIDVV treats this as both a deployment and security consideration: each verification event is bounded and signaling-only, while both initiating deployments and the party responsible for an Asserted Caller-ID need controls appropriate to their roles. Section Signaling Load and Operational Telemetry and Section Amplification and Reflection discuss these issues in more detail.

Design Principles CIDVV was designed with the following core principles:

• Maximal compatibility with existing infrastructure: The protocol must work across SIP, SS7/TDM, ISDN, and mixed networks - including international paths - without requiring changes to signaling protocols, new headers, response codes, or media support.
• Resilience to intermediate network behavior: Intermediate networks may normalize, truncate, or otherwise modify signaling information. Therefore, all protocol state is encoded in a compact numeric form within the Calling Party Number field, which has the highest chance of surviving end-to-end.
• Use of existing failure semantics: CIDVV relies on distinguishable classes of non-success response behavior (e.g., Busy-class vs. Rejection-class behavior) rather than requiring specific end-to-end response codes.
• Minimal new infrastructure: No persistent identity infrastructure or central authorities are required. Vouching requires no cryptographic key management, and vetting can use locally configured shared secrets.
• Incremental deployability: The protocol provides benefit even with partial adoption and is designed to coexist cleanly with STIR/SHAKEN and other identity solutions.
• Practical and low-overhead operation: Verification uses very short signaling-only calls with no media exchange, keeping network impact minimal while still providing strong real-time evidence of number control.

These principles ensure CIDVV can be deployed quickly and broadly while delivering meaningful protection against Caller-ID spoofing today.

Simple Overview CIDVV defines two related operations:

• Vouching - Allows the called party (or their provider) to verify in real time whether the party responsible for the Asserted Caller-ID vouches for this specific call.
• Vetting - Allows confirmation that a telephone number is under the control of its expected owner. This is useful for Caller-ID branding services, enterprise trust programs, industry registries, and similar applications.

Vouching Operation (Primary Use Case) When Alice wants to place a call to Bob while asserting a particular Caller-ID:

1. Alice places a normal call to Bob using the Asserted Caller-ID. Alice's CIDVV platform is notified of the outbound call attempt.
2. Bob's CIDVV platform intercepts the incoming call before ringing Bob's phone.
3. Bob's platform initiates two short signaling-only verification calls back to Alice's Asserted Caller-ID (these may be performed in parallel):
   • Phase 1 verification call using Calling Party Number prefix "100".
   • Phase 2 verification call using Calling Party Number prefix "101".
4. Alice's CIDVV platform recognizes the special prefixes on the incoming verification calls and responds with the expected non-success response behavior for each phase. This provides evidence that it controls the Asserted Caller-ID and that Alice has an active call in progress to Bob.
5. Bob's CIDVV platform evaluates the verification result. If both Phase 1 and Phase 2 succeed within the Validity Window, the vouch is successful. If either phase fails, times out, or produces an unexpected response, the vouch is unsuccessful or indeterminate. The handling of the original call is implementation-specific; the platform may allow the call, label it, route it differently, send it to voicemail, or reject it according to local policy.

The two verification calls use reachability testing to confirm that Alice (or her service provider) genuinely controls the Asserted Caller-ID she is presenting for this specific call.

Vetting Operation Vetting allows a party (Alice) to confirm that another party (Bob) controls a specific telephone number. It is particularly useful for Caller-ID branding services, trust programs, and registries. Vetting uses a three-call challenge-response sequence consisting of a Wake Call, Recognize Call, and Auth Call, all protected by a pre-shared secret. The sequence is designed to prevent an attacker from goading the number owner into placing return calls (e.g., by spoofing well-known vetting numbers). When Alice wants to vet that Bob controls a particular telephone number:

1. Alice and Bob share a secret (e.g., a passphrase such as "elephant").
2. Alice initiates a Wake Call to Bob using the 101 prefix and an agreed vetting Caller-ID.
3. Bob's platform recognizes the vetting Caller-ID, computes a short-lived Recognize Token, and responds to the Wake Call with SIP 603 Decline.
4. Alice's platform computes the same Recognize Token and sends a Recognize Call using the Recognize Token in the Calling Party Number.
5. Bob's platform verifies the Recognize Token, proving that Alice knows the shared secret. Bob then responds to the Recognize Call with SIP 486 Busy Here and initiates an Auth Call using an Auth Token.
6. Alice's platform verifies the Auth Token, proving that Bob knows the shared secret, and responds to the Auth Call with SIP 486 Busy Here.
7. After Alice verifies the Auth Token and Bob receives the expected SIP 486 Busy Here response to the Auth Call, both sides consider the vetting successful.

This design ensures that the initial Wake Call reveals nothing useful to an attacker, while the subsequent Recognize and Auth steps provide mutual authentication between parties that share the secret. All calls remain short signaling-only exchanges with no media. Note: The shared secret and token exchange details are defined in Section Token Computation Algorithm.

CIDVV Mechanisms

Vouching Mechanism CIDVV uses two distinct signaling prefixes in the Calling Party Number for vouching:

• "100" - Phase 1 Verification Call
• "101" - Phase 2 Verification Call

A successful Vouch requires both Phase 1 and Phase 2 to complete with their expected responses within the Validity Window. The two phases MAY be performed in any order or in parallel. Expected behaviors: * Phase 1 ("100" prefix): MUST receive a Busy-class response (e.g., SIP 486 Busy Here). * Phase 2 ("101" prefix): MUST receive a Rejection-class response (e.g., SIP 603 Decline). If either phase fails to produce the expected response within the vouch-call timeout (or is missing, altered, or inconsistent), the entire vouch MUST be treated as unsuccessful or indeterminate.

Vetting Mechanism CIDVV uses a three-step handshake for vetting. All calls use the 101 prefix in the Calling Party Number.

• Wake Call (Alice -> Bob): Alice initiates using her vetting Caller-ID.
• Recognize Call (Alice -> Bob): Alice uses the 101 prefix followed by the Recognize Token as the Calling Party Number.
• Auth Call (Bob -> Alice): Bob uses the 101 prefix followed by the Auth Token as the Calling Party Number.

A successful Vet requires all three steps to complete successfully within the Validity Window. The Recognize Call serves as critical anti-goading protection. Bob's platform will only initiate the final Auth Call if it has recently received a valid Wake Call and the Recognize Token matches what it computed. This prevents an attacker from tricking Bob's platform into calling Alice. Both sides independently compute the short-lived Recognize Token and Auth Token from the shared secret and the two telephone numbers involved. The tokens are valid only within the Validity Window.

Token Computation Algorithm (Normative) CIDVV vetting uses two derived numeric tokens:

• Recognize Token: Computed by Alice and verified by Bob.
• Auth Token: Computed by Bob and verified by Alice.

Both tokens are computed using the same processing steps, but with different input ordering. This prevents the Recognize Token and Auth Token from being interchangeable.

1. Normalize both telephone numbers to E.164 digit strings with no leading "+" and no punctuation, as defined in Section Number Normalization.
2. For the Recognize Token, concatenate the following values as UTF-8 bytes: normalized-calling-number || "|" || normalized-called-number || "|" || shared-secret In this context, normalized-calling-number is Alice's vetting Caller-ID and normalized-called-number is Bob's number being vetted.
3. For the Auth Token, concatenate the following values as UTF-8 bytes: shared-secret || "|" || normalized-called-number || "|" || normalized-calling-number
4. Compute the SHA-256 digest of the concatenated bytes.
5. Take the first 8 hexadecimal characters of the digest.
6. Convert that 8-character hexadecimal string to a decimal integer.
7. Left-pad the decimal value with zeros to 10 digits if needed, then prepend the digit "1" to produce an 11-digit token.

Example (for illustration only)

• Alice vetting Caller-ID: +12125550100
• Bob's number: +19495550199
• Shared secret: elephant

Recognize Token input: 12125550100|19495550199|elephant Auth Token input: elephant|19495550199|12125550100 Recognize Token calculation:

• SHA-256 digest begins with: b86a096e
• First 8 hexadecimal characters: b86a096e
• Decimal value: 3093956974
• 10-digit decimal value: 3093956974
• Final 11-digit Recognize Token: 13093956974

Auth Token calculation:

• SHA-256 digest begins with: 9f6b0648
• First 8 hexadecimal characters: 9f6b0648
• Decimal value: 2674591304
• 10-digit decimal value: 2674591304
• Final 11-digit Auth Token: 12674591304

The resulting Recognize Token and Auth Token differ because the input ordering is different. Implementations MUST use identical normalization, input ordering, digest processing, decimal conversion, zero-padding, and prefixing on both sides of the vetting exchange. Tokens are valid only within the Validity Window or, for multivetting, within the refreshed Validity Window. Hosted or multi-tenant CIDVV services MUST ensure that shared secrets, configuration, token state, and cached vetting state are scoped to the appropriate customer or tenant. A tenant-specific value MAY be included as an additional token-computation input only when both sides of the vetting relationship are explicitly configured to use the same value. Otherwise, tenant isolation MUST be enforced by provisioning, storage, and access-control boundaries rather than by changing the token algorithm.

Detailed Vouching Procedure When Alice wants to place a call to Bob using her Asserted Caller-ID, the following steps are performed:

1. Alice's CIDVV platform is notified of her outbound call attempt to Bob using her Asserted Caller-ID. The notification mechanism is implementation-specific. For example, Alice's SBC or gateway might send an INVITE to the CIDVV platform before advancing the original call toward the PSTN, or the platform might be notified through an API, routing policy, STIR signing workflow, or other local mechanism. Upon receiving this notification, Alice's CIDVV platform records the attempted call state for the Validity Window so that it can respond to subsequent Phase 1 and Phase 2 verification calls.
2. Bob's CIDVV platform intercepts the incoming call from Alice and holds it (does not yet alert Bob's phone).
3. Bob's CIDVV platform initiates two short verification calls back to Alice (in either order or in parallel): a. One verification call with Calling Party Number prefixed by +100. b. One verification call with Calling Party Number prefixed by +101. Both calls are directed to Alice's Asserted Caller-ID.
4. A CIDVV-aware network element serving Alice's Asserted Caller-ID recognizes the +100 or +101 prefix in the Calling Party Number and routes the verification call to Alice's CIDVV platform.
5. Alice's CIDVV platform receives each verification call and performs the following actions: a. For the call with +100 prefix: Looks up the cached call state and responds with SIP 486 Busy Here if matching state exists. b. For the call with +101 prefix: Responds with SIP 603 Decline for vouching purposes, unless the call corresponds to an active vetting procedure as described in Section Vetting Procedure.
6. Bob's CIDVV platform evaluates the responses to both verification calls.
7. If both verification calls receive the expected responses (SIP 486 Busy Here for +100 and SIP 603 Decline for +101) within the Validity Window, Bob's CIDVV platform: a. Considers the vouching successful. b. Applies local call-handling policy to the original call.
8. If either verification call fails to receive the correct response, times out, or does not complete within the Validity Window, Bob's CIDVV platform: a. Considers the vouching unsuccessful or indeterminate. b. May take any of the following actions on the original call (implementation-specific):
   • Reject the call (e.g., with SIP 603 Decline).
   • Route the call to Bob's voicemail.
   • Allow the original call to continue with an indication that the Caller-ID was not verified (e.g., "Unverified Caller-ID").

Detailed Vetting Procedure When Alice wants to confirm that Bob controls a particular telephone number, the following protocol is used:

1. Alice and Bob share a secret (e.g., "elephant").
2. Alice and Bob agree on the Caller-ID that Alice will use to vet Bob's number.
3. Alice's CIDVV platform initiates a "Wake Call" to Bob's number using a Calling Party Number consisting of the 101 prefix followed by Alice's agreed vetting Caller-ID.
4. Bob's CIDVV platform performs the following actions: a. Intercepts the incoming call. b. Recognizes Alice's vetting Caller-ID and identifies this as a "Wake Call". c. Computes a short-lived "Recognize Token" derived from Alice's number + Bob's number + the shared secret (example: 13093956974). d. Stores this token temporarily in memory. e. Responds with SIP 603 Decline. f. Considers this a successful "Wake Call" from Alice to Bob (step 1 of 3). The Wake Call alone does not authenticate Alice and does not cause Bob's platform to initiate an Auth Call. Alice's vetting Caller-ID may be known or reused across multiple vetting relationships, so Bob's platform waits for a valid Recognize Call proving knowledge of the shared secret before placing any return call to Alice. This prevents an attacker from spoofing Alice's vetting Caller-ID in a Wake Call in order to goad Bob's platform into calling Alice.
5. Alice's CIDVV platform performs the following actions upon receiving SIP 603 Decline: a. Considers Bob's CIDVV platform "Awake". b. Independently calculates the same "Recognize Token" (example: 13093956974). c. Calculates an "Auth Token" using the Auth Token input ordering defined in Section Token Computation Algorithm (example: 12674591304). d. Stores the Auth Token temporarily in memory. e. Initiates a "Recognize Call" (step 2 of 3) to Bob using the Recognize Token as the Caller-ID, prefixed with +101 (example: +10113093956974).
6. Bob's CIDVV platform performs the following actions upon receiving the Recognize Call: a. Intercepts the call. b. Verifies that the received Caller-ID matches the previously stored Recognize Token. c. Considers this a successful "Recognize Call" from Alice to Bob (step 2 of 3). d. Treats Alice's CIDVV platform as authenticated for this vetting exchange. e. Responds with SIP 486 Busy Here. f. Computes the corresponding "Auth Token" (example: 12674591304). g. Initiates an "Auth Call" (step 3 of 3) to Alice using the Auth Token as the Caller-ID, prefixed with +101 (example: +10112674591304).
7. Alice's CIDVV platform performs the following actions upon receiving the Auth Call: a. Intercepts the call. b. Verifies that the received Caller-ID matches the previously stored Auth Token. c. Considers this a successful "Auth Call" from Bob to Alice (step 3 of 3). d. Treats Bob's CIDVV platform as authenticated for this vetting exchange. e. Responds with SIP 486 Busy Here. f. Considers the vetting procedure complete and successful.
8. Bob's CIDVV platform receives SIP 486 Busy Here from Alice and also considers the vetting procedure successful.

Only a party that can receive calls for Bob's number and that knows the shared secret can complete the expected token and response sequence.

Signaling Prefixes and Call Types CIDVV uses the following special prefixes in the Calling Party Number:

Prefix	Call Type	Direction	Purpose	Expected Response (by callee)
+100	Vouch Phase 1	Bob -> Alice	Vouching verification (Phase 1)	486 Busy Here
+101	Vouch Phase 2	Bob -> Alice	Vouching verification (Phase 2)	603 Decline
+101	Wake Call	Alice -> Bob	Initiate vetting and trigger token generation	603 Decline
+101	Recognize Call	Alice -> Bob	Alice proves knowledge of shared secret	486 Busy Here
+101	Auth Call	Bob -> Alice	Bob proves knowledge of shared secret	486 Busy Here

Note: All vetting-related calls use the +101 prefix. Context is determined by the Caller-ID used (vetting Caller-ID vs. token value) and the current state maintained by the CIDVV platform.

Response Semantics Because intermediate SIP and SS7/TDM networks may translate, modify, or replace response codes, implementations MUST interpret responses based on behavioral class (e.g., Busy-class vs. Rejection-class) rather than exact numeric values. Implementations SHOULD use SIP 486 Busy Here and SIP 603 Decline as the canonical representations of these behaviors where possible. For calls with the "101" prefix, a CIDVV platform normally responds with a Rejection-class response, such as SIP 603 Decline. The platform responds with a Busy-class response, such as SIP 486 Busy Here, only when the "101" call matches an active vetting token-confirmation step. CIDVV requires that these response behaviors remain distinguishable across the signaling path. Environments that cannot preserve this distinction may not support CIDVV vouching.

Phase 1 Verification ("100" Prefix) A call using the "100" prefix is the Phase 1 verification call. It succeeds only if it receives a Busy-class response (e.g., SIP 486 Busy Here).

Phase 2 Verification ("101" Prefix) A call using the "101" prefix is the Phase 2 verification call. It succeeds only if it receives a Rejection-class response, with SIP 603 Decline as the canonical example.

Vouch Success Response Requirements A successful vouch requires both Phase 1 and Phase 2 to complete with their expected behaviors within the Validity Window. Implementations MUST NOT treat a single phase as sufficient for a successful vouch. If either phase fails, is missing, altered, delayed, or inconsistent, the vouch result MUST be treated as unsuccessful or indeterminate. Vetting success is defined separately by the Wake, Recognize, and Auth procedure in Section Vetting Procedure.

Protocol Operation

Vouching Procedure In this procedure, Alice places a call to Bob using an Asserted Caller-ID. Bob's CIDVV platform uses the vouching procedure to determine whether the party responsible for Alice's Asserted Caller-ID will vouch for this specific call attempt. The result of the vouching procedure is a verification signal; handling of the original call is implementation-specific. The following subsections define the required behavior for vouching. Alice initiates a call to Bob using her Asserted Caller-ID. Alice's CIDVV platform receives a notification of an attempted call from Alice to Bob using Alice's Asserted Caller-ID. The notification mechanism is implementation-specific. For example, Alice's SBC or gateway might send an INVITE to the CIDVV platform before advancing the original call toward the PSTN. Upon receiving this notification, Alice's CIDVV platform MUST cache the attempted call using the tuple: (Asserted Caller-ID, Called Number) for the Validity Window. The response used for this local notification is outside the inter-domain CIDVV verification exchange. Implementations MAY use any local behavior that allows Alice's SBC or gateway to continue routing the original call toward Bob. When Bob's CIDVV platform receives the original call, it holds the call and initiates two short signaling-only verification calls toward Alice's Asserted Caller-ID. These calls MAY be performed in either order or in parallel.

Phase 1 Verification ("100") Bob's CIDVV platform constructs a verification Calling Party Number by prefixing "100" to the rightmost 12 digits of Bob's called number after number normalization. It then initiates a verification call toward Alice's Asserted Caller-ID using that value as the Calling Party Number. When Alice's SBC receives a call with a Calling Party Number beginning with "100", it MUST route the call to Alice's CIDVV platform. Upon receiving the Phase 1 verification call, Alice's CIDVV platform MUST determine whether the call matches cached state for the Asserted Caller-ID that received the verification call and the called-number value encoded in the verification Calling Party Number. If a matching cache entry exists within the Validity Window, Alice's CIDVV platform MUST respond to the Phase 1 verification call with a Busy-class response, such as SIP 486 Busy Here. If no matching cache entry exists, Alice's CIDVV platform MUST NOT respond with a Busy-class response for the Phase 1 verification call. It MAY respond with a Rejection-class response, such as SIP 603 Decline.

Phase 2 Verification ("101") Bob's CIDVV-aware element initiates a second verification call using a Calling Party Number constructed by prefixing "101" to the same 12-digit payload used for Phase 1. When Alice's SBC receives a call with a Calling Party Number beginning with "101", it MUST route the call to Alice's CIDVV platform. For vouching purposes, Alice's CIDVV platform does not need to perform a vouching cache lookup for the Phase 2 call. Unless the call corresponds to an active vetting procedure, Alice's CIDVV platform MUST respond to the Phase 2 verification call with a Rejection-class response, such as SIP 603 Decline. A Phase 2 verification call does not, by itself, prove that Alice has an active call in progress to Bob. Phase 2 is used together with Phase 1 to distinguish a CIDVV-aware platform from ordinary network behavior and to reduce false-positive vouches. A "101" call that corresponds to an active vetting procedure is handled according to Section Vetting Procedure.

Combined Phase Behavior (Required for Vouch Success) A successful vouch requires both Phase 1 and Phase 2 to complete with their expected behaviors within the Validity Window. Implementations MUST NOT treat a single phase as sufficient for a successful vouch. If either phase fails, is missing, altered, delayed, or inconsistent, the vouch result MUST be treated as unsuccessful or indeterminate. Vetting success is defined separately by the Wake, Recognize, and Auth procedure in Section Vetting Procedure.

Vouch Call Timers The Validity Window controls how long cached vouching state remains valid at the originating CIDVV platform. Independently, the platform that initiates a Phase 1 or Phase 2 verification call SHOULD implement a configurable local timer that controls how long it waits for a signaling response to that verification call. A default timeout of 3-6 seconds is reasonable for domestic calls. For international destinations, longer timeouts (typically 8-20 seconds) are recommended to accommodate higher Post-Dial Delay (PDD). The two vouch calls (Phase 1 and Phase 2) may be initiated sequentially or simultaneously.

Correlation Model CIDVV vouching correlates calls using the Asserted Caller-ID, the called number, and a Validity Window. It does not attempt to identify individual call legs across the PSTN. A successful vouch indicates that at least one matching call attempt occurred during the Validity Window. It does not prove a one-to-one correspondence between a specific original call leg and a specific verification call. When multiple calls with the same Asserted Caller-ID and called number occur within the Validity Window, implementations MAY treat the tuple as active state rather than requiring strict one-to-one correlation. This case is discussed further in Section Multiple Simultaneous Calls from the Same Caller-ID.

State Storage and Multi-Tenant Isolation CIDVV implementations maintain short-lived state for vouching and vetting. The representation of that state is implementation-specific and is not carried on the wire. For vouching, implementations commonly store state associated with the Asserted Caller-ID, the called number, and the Validity Window. For vetting, implementations store temporary state associated with the Wake, Recognize, and Auth steps, including any pending Recognize Token or Auth Token. Implementations MAY use hashes, derived keys, database keys, in-memory objects, or other local mechanisms for state storage. These internal storage keys MUST NOT alter the externally visible token computation defined in Section Token Computation Algorithm. All temporary state MUST expire automatically. Loss of state, expiration of state, or inability to retrieve state MUST cause the corresponding vouching or vetting operation to fail closed. CIDVV platforms that operate on behalf of multiple independent customers MUST ensure that all vouching and vetting state is scoped per customer or tenant. This prevents unrelated customers from interacting through shared state, identical telephone-number tuples, identical token values, or misconfigured shared secrets. Implementations MAY use separate storage, partitioning, customer-specific configuration, tenant identifiers, or access-control boundaries to achieve this isolation.

Vetting Procedure Vetting a remote number requires three separate calls (distinct SIP dialogs) using a pre-agreed shared secret. The process confirms that the called party (Bob) controls the target telephone number and possesses the correct shared secret. In the examples below, Alice is the verifier who initiates the vetting procedure for Bob's number. Before vetting begins, Alice and Bob agree on a shared secret, Alice's vetting Caller-ID, and a Validity Window. Alice places a Wake Call to Bob using a Calling Party Number consisting of the "101" prefix followed by Alice's agreed vetting Caller-ID. When Bob's CIDVV platform receives the Wake Call, it removes the "101" prefix and verifies that the resulting Caller-ID is expected for the current vetting attempt. Bob's platform MUST compute the Recognize Token using the algorithm defined in Section Token Computation Algorithm and store the resulting token for the Validity Window. It then responds to the Wake Call with SIP 603 Decline. Alice computes the same Recognize Token and places a Recognize Call to Bob using a Calling Party Number consisting of the "101" prefix followed by the Recognize Token. When Bob's CIDVV platform receives the Recognize Call, it removes the "101" prefix and compares the remaining numeric value to the recently cached Recognize Token. If the Recognize Token matches, Bob's CIDVV platform MUST respond to the Recognize Call with SIP 486 Busy Here. Alice's platform treats this response as a successful Recognize. Bob's CIDVV platform then computes the Auth Token using the algorithm defined in Section Token Computation Algorithm and places an Auth Call to Alice using a Calling Party Number consisting of the "101" prefix followed by the Auth Token. When Alice's CIDVV platform receives the Auth Call, it removes the "101" prefix and compares the remaining numeric value to the expected Auth Token. If the Auth Token matches, Alice's CIDVV platform MUST respond to the Auth Call with SIP 486 Busy Here. Bob's platform treats this response as a successful Auth. Any other response, timeout, token mismatch, expired cache entry, or unexpected Caller-ID MUST be treated as an unsuccessful vet.

Examples

Successful Vouch Call Flow The following diagram shows a successful vouch.

Example Successful Vouch | | | | | | |<-INVITE-| | | | | | |- 404 -->| | | | | | | |-INVITE->| | | | | | | |-INVITE->| | | | | | | |-INVITE->| | | | | | |<- +100 -| | | | | |<- +100 -| | | | | |<- +100 -| | | | | |<- +100 -| | | | | | |- 486 -->| | | | | | | |- 486 -->| | | | | | | |- 486 -->| | | | | | | |- 486 -->| | | | | | |<- +101 -| | | | | |<- +101 -| | | | | |<- +101 -| | | | | |<- +101 -| | | | | | |- 603 -->| | | | | | | |- 603 -->| | | | | | | |- 603 -->| | | | | | | |- 603 -->| | | | | | |<- 302 --| | | | | | |----- INVITE ----->| ]]>

In the diagram:

• "404" is only an example of how Alice's CIDVV platform might respond to a local notification from Alice's SBC or gateway. The response used for this local notification is implementation-specific and is not part of the inter-domain CIDVV verification exchange.
• "+100" represents a verification call whose Calling Party Number begins with the prefix "100" (or "+100") followed by Bob's called number.
• "+101" represents a verification call whose Calling Party Number begins with the prefix "101" (or "+101") followed by Bob's called number.
• "302" is only an example of call advancement after a successful vouch. CIDVV does not require use of SIP 302; implementations may use any local method to continue, redirect, or otherwise handle the original call.

Successful Vouch Step-by-Step Description The diagram above shows the high-level message flow. The following numbered steps provide the detailed behavior, including Caller-ID manipulation performed by CIDVV platforms. Note that the two verification calls (Phase 1 and Phase 2) MAY be performed in either order or in parallel.

1. The originating user (Alice, Asserted Caller-ID +12125550100) initiates a call to Bob (+19495550199).
2. The call is routed from Alice's User Agent to her SBC, which forwards it to the originating CIDVV platform (CIDVV_A).
3. CIDVV_A:
   • Caches the call attempt using the tuple (Calling: 12125550100, Called: 19495550199) for the Validity Window.
   • Releases the local notification leg using implementation-specific behavior, such as a SIP final response, so that the original call can continue toward Bob.
4. After the local notification leg is released, Alice's SBC or gateway continues routing the original call toward the PSTN using Alice's original Caller-ID.
5. The call reaches Bob's SBC via the PSTN. Because this is a new dialog (initial INVITE), Bob's CIDVV-aware SBC forwards the call to the terminating CIDVV platform (CIDVV_B).
6. CIDVV_B initiates Phase 1 and Phase 2 verification calls toward Alice's number (+12125550100):
   • Phase 1: Caller-ID = +10019495550199
   • Phase 2: Caller-ID = +10119495550199
7. Each verification call arrives at Alice's SBC via the PSTN.
8. Alice's SBC detects the leading +100 or +101 prefix and routes the call to CIDVV_A.
9. CIDVV_A:
   • For a +100 prefix: Looks up the cached tuple for the Validity Window and responds with SIP 486 Busy Here if matching state exists.
   • For a +101 prefix: Responds with SIP 603 Decline for vouching purposes unless the call corresponds to an active token-confirmation step.
10. CIDVV_B receives the expected responses for both phases. Once both Phase 1 and Phase 2 have succeeded, it considers the combined result a Successful Vouch.
11. CIDVV_B determines the vouch result and applies its local call-handling policy. If the call is to be advanced, CIDVV_B may release or redirect the held call using implementation-specific behavior, such as returning SIP 302 Moved Temporarily to Bob's SBC.
12. Bob's SBC or serving network element advances the original call according to that local behavior, for example by routing the call to Bob's User Agent.
13. Bob's telephone rings.

This mechanism allows Bob's CIDVV platform to verify Alice's Asserted Caller-ID before deciding how to handle the original call.

Unsuccessful Vouch A successful vouch requires both verification phases to complete with the expected response behavior within the Validity Window. If either phase fails, times out, produces an unexpected response, or cannot be completed, the vouch MUST be treated as unsuccessful or indeterminate. An implementation MAY stop the verification procedure early after any phase has already failed. For example:

• If the Phase 1 verification call using the "100" prefix does not result in a Busy-class response, such as SIP 486 Busy Here, the vouch MUST fail. The implementation MAY omit the Phase 2 verification call.
• If the Phase 1 verification succeeds but the Phase 2 verification call using the "101" prefix does not result in a Rejection-class response, such as SIP 603 Decline, the vouch MUST fail.

Implementations MUST fail closed. Any ambiguity, unexpected response, timeout, provisional response, successful response, media establishment, or other verification-call progression MUST result in an unsuccessful or indeterminate outcome.

Vetting a Caller-ID Number Vetting uses three independent verification calls that form a challenge-response sequence. For clarity, the calls are shown separately, but together they constitute a single vetting operation.

First Vetting Call (Wake) using known Vetting number as Caller-ID

Wake vetting call with 101 - Bob creates Recognize Token and responds with SIP 603 Decline | | | | | |-- WAKE101 ->| | | | | |-- WAKE101 ->| | | | | |-- WAKE101 ->| | | | | | | | | |<--- 603 ----| | | |<--- 603 ----| | | |<--- 603 ----| | | |<--- 603 ----| | | | | | | | | ]]>

Second Vetting Call using Recognize Token as Caller-ID

Recognize Call (101 prefix) - Alice proves knowledge of the shared secret using the Recognize Token | | | | | |-- RECG101 ->| | | | | |-- RECG101 ->| | | | | |-- RECG101 ->| | | | | | | | | |<--- 486 ----| | | |<--- 486 ----| | | |<--- 486 ----| | | |<--- 486 ----| | | | | | | | | ]]>

Third Vetting Call (Auth) using Auth Token as Caller-ID

Auth Call (101 prefix) - Bob proves knowledge of the shared secret using the Auth Token | | | | | |---- 486 --->| | | | | |---- 486 --->| | | | | |---- 486 --->| | | | | | ]]>

Successful Caller-ID Vetting Flow Vetting a remote number requires three separate calls (distinct SIP dialogs) that together form a single challenge-response operation protected by a pre-agreed shared secret. The process confirms that the called party (Bob) controls the target telephone number and possesses the correct shared secret.

1. Alice and Bob agree on a shared secret (e.g., elephant) and Alice's vetting Caller-ID (e.g., +12125550100).
2. Both parties configure their CIDVV platforms with the shared secret, Alice's vetting Caller-ID, and an optional authorization lifetime (e.g., "one week"). This allows the number owner (Bob) to limit how long the vetting authorization remains active.
3. Alice's CIDVV platform (CIDVV_A) initiates the Wake Call to Bob's number (+19495550199) with Caller-ID +10112125550100.
4. Bob's SBC, gateway, or other CIDVV-aware network element recognizes the 101 prefix in the Calling Party Number and routes the call to CIDVV_B.
5. CIDVV_B:
   • Strips the 101 prefix to recover Alice's vetting Caller-ID.
   • Recognizes it as a pre-agreed vetting number.
   • Computes the Recognize Token.
   • Caches the token for the Validity Window.
   • Responds with SIP 603 Decline.
6. CIDVV_A receives SIP 603 Decline and computes the same Recognize Token.
7. CIDVV_A immediately places the Recognize Call to Bob using Caller-ID +101 followed by the Recognize Token (e.g., +10113093956974).
8. Bob's SBC, gateway, or other CIDVV-aware network element recognizes the 101 prefix in the Calling Party Number and routes the call to CIDVV_B.
9. CIDVV_B:
   • Strips the 101 prefix.
   • Verifies the token matches the cached value.
   • Responds with SIP 486 Busy Here.
10. CIDVV_A receives SIP 486 Busy Here and computes the Auth Token.
11. CIDVV_B:
    • Computes the Auth Token.
    • Initiates the Auth Call to Alice's vetting Caller-ID using Caller-ID +101 followed by the Auth Token (e.g., +10112674591304).
12. Alice's SBC, gateway, or other CIDVV-aware network element recognizes the 101 prefix in the Calling Party Number and routes the call to CIDVV_A.
13. CIDVV_A:
    • Strips the 101 prefix.
    • Verifies the Auth Token.
    • Responds with SIP 486 Busy Here.
    • Declares the vetting successful.
14. CIDVV_B receives SIP 486 Busy Here and also declares the vetting successful.

All calls are short signaling-only exchanges. The entire operation MUST complete within the Validity Window.

Multi-Number Vetting Optimization (Multivetting) To reduce signaling load when vetting multiple numbers controlled by the same party (Bob), a single Wake call MAY establish shared state. Subsequent Recognize/Auth pairs for additional numbers can then proceed, with the Validity Window refreshed after each successful individual vet. In this optimization:

1. Alice performs one Wake Call to any of Bob's numbers (or a designated primary vetting number) using her pre-agreed vetting Caller-ID prefixed with +101. CIDVV_B creates and caches a session context (tied to Alice's vetting Caller-ID + shared secret).
2. For each number to vet (including the first if desired):
   • Alice sends the Recognize Call using the per-number Recognize Token.
   • CIDVV_B verifies the token against the current call (using calling number, called number, and the shared secret) and responds with SIP 486 Busy Here if successful.
   • The per-number Auth Call proceeds as in the base flow.
   • Upon successful completion of each individual vet, including the expected SIP 486 Busy Here responses, both sides refresh/restart the Validity Window for the ongoing session.

Implementations SHOULD enforce a configurable maximum session lifetime for a multivetting operation, independent of per-vet Validity Window refreshes. This optimization is OPTIONAL. Implementations MUST support the base three-call-per-number sequence. Multivetting requires Bob's platform to maintain per-Alice session state. The Wake call establishes "Bob is awake and shares the secret"; Recognize/Auth pairs confirm per-number control. All other requirements, including token computation as defined in Section Token Computation Algorithm, per-vet failure handling, and state isolation as described in Section State Storage and Multi-Tenant Isolation, remain unchanged. Rationale: This balances efficiency for bulk vetting (e.g., enterprise portfolios or service-provider batch validation) with strong per-number security properties and operational flexibility.

Vetting Failure Cases A vetting attempt may fail for the following reasons:

• Bob does not have a participating CIDVV platform; Alice's platform may not receive the expected SIP 603 Decline response to the Wake Call or the expected SIP 486 Busy Here response to the Recognize Call, and Bob will not initiate a valid Auth Call back to Alice.
• The shared secret, Alice's vetting Caller-ID, or Validity Window does not match; the three-call sequence will not produce the expected SIP 603 + SIP 486 + SIP 486 response pattern.
• Network or policy restrictions prevent one or more calls from reaching the remote CIDVV platform.

In all such cases, the vetting attempt MUST be treated as unsuccessful. This three-call challenge-response mechanism provides strong confirmation that the remote number is both reachable via the PSTN and controlled by an entity that knows the shared secret.

Deployment Considerations

Behavior of Non-CIDVV Systems Systems that do not implement CIDVV are not expected to recognize the CIDVV signaling prefixes. Such systems will typically process these calls as ordinary calls and may return a wide range of responses. CIDVV implementations MUST treat any response that does not match the expected protocol behavior as indicating a non-participating system.

Handling of CIDVV Signaling Calls Networks and SBCs that recognize CIDVV signaling SHOULD prevent calls with Calling Party Numbers beginning with "100", "101", "+100", or "+101" from being presented to ordinary end users. When a responsible CIDVV platform is available, such calls SHOULD be routed to that platform for protocol handling. Intermediate networks SHOULD NOT generate successful CIDVV responses on behalf of a CIDVV platform unless explicitly configured to do so by the responsible administrative domain. CIDVV signaling calls SHOULD result in a non-success response, commonly SIP 486 Busy Here or SIP 603 Decline, and MUST NOT establish media. Call analytics, labeling, and fraud detection systems SHOULD recognize these prefixes and treat the calls as protocol signaling rather than ordinary subscriber traffic.

Carrier Incentives and SBC Policies CIDVV signaling calls are short-lived and do not require media exchange. They represent a small incremental signaling load compared with the network cost of fraudulent, spoofed, and nuisance calling. Carriers and service providers benefit when call participants can produce stronger evidence of Caller-ID control. Such signals can support fraud analytics, traceback, branded-calling programs, customer reputation systems, and local call-handling policy without requiring intermediate carriers to make a final identity determination for every call. Within the responsible administrative domain for a destination number, an SBC, proxy, or other CIDVV-aware network element SHOULD recognize calls where the Calling Party Number begins with +100, +101, 100, or 101 and route such calls to the appropriate CIDVV platform when one is available. If no responsible CIDVV platform is available, the call SHOULD NOT be presented to an ordinary end user. Intermediate networks SHOULD NOT block, rewrite, or specially rate-limit CIDVV signaling calls solely because the Calling Party Number contains a CIDVV prefix. Intermediate networks SHOULD NOT synthesize responses that would be interpreted as successful CIDVV behavior unless explicitly configured to do so by the responsible administrative domain. CIDVV signaling calls MUST NOT establish media. If a CIDVV signaling call would otherwise result in media establishment, the responsible network element SHOULD terminate the attempt with a non-success response in a way that does not create a false-positive CIDVV verification result.

Signaling Load and Operational Telemetry CIDVV introduces additional signaling traffic, but verification calls are short signaling-only exchanges and are not intended to establish media. This makes the verification load materially different from completing and carrying media for fraudulent, spoofed, or nuisance calls. In many deployments, rejecting or classifying unwanted calls at the signaling layer is preferable to allowing those calls to progress far enough to consume media resources, alert users, enter contact-center queues, or trigger downstream fraud-handling workflows. CIDVV gives terminating platforms an additional real-time signal that can be used before applying local call-handling policy. CIDVV verification traffic can also provide operational telemetry to the party responsible for an Asserted Caller-ID. If a telephone number is widely spoofed, verification attempts for that number are routed toward the responsible platform. This allows the responsible enterprise, service provider, or delegated CIDVV operator to observe attempted misuse of the number and identify patterns that may otherwise be difficult to see from ordinary inbound or outbound call records alone. CIDVV telemetry is not, by itself, a complete traceback mechanism and does not necessarily identify every provider in the original call path. However, it can provide high-quality traceback leads, including the Asserted Caller-ID being misused, the called-number payload associated with the verification attempt, timestamps, response outcomes, and recurring misuse patterns. Where permitted by law and applicable industry procedures, this telemetry can be used to support traceback requests, regulatory referrals, fraud investigations, customer notifications, and mitigation actions. Deployments that store or process CIDVV telemetry need to treat it as call signaling data and apply appropriate privacy, security, retention, and access-control policies. Operators should minimize retained data, limit use to operational, security, fraud-prevention, compliance, and debugging purposes, and avoid retaining CIDVV telemetry longer than necessary for those purposes. CIDVV-aware SBCs and CIDVV platforms still need appropriate protections against excessive signaling volume. Deployments SHOULD apply rate limits, source filtering, anomaly detection, concurrency limits, and capacity planning appropriate to their traffic profile. Because CIDVV is incrementally deployable and does not require a coordinated flag day, participating networks can introduce these controls as deployment grows.

Response Variability Implementations SHOULD interpret responses based on behavioral class (e.g., Busy-class behavior such as SIP 486 Busy Here versus Rejection-class behavior such as SIP 603 Decline) rather than relying on exact numeric values. Intermediate networks may translate or modify response codes, so behavioral class is the preferred signal.

Short-Term State Management CIDVV relies on short-lived state for the (Calling Number, Called Number) tuple, valid only for the Validity Window. Implementations MUST expire this state automatically after the Validity Window. State used for CIDVV verification MUST be scoped so that unrelated calls, customers, tenants, or administrative domains cannot satisfy each other's verification requests.

International and Cross-Border Operation International calls often experience higher Post-Dial Delay. Vouching call timeouts SHOULD be adaptive: 3-6 seconds is appropriate for domestic calls, while 8-20 seconds or more may be needed for international destinations based on observed PDD. Implementations SHOULD choose verification-call timing and retry behavior based on observed network conditions, especially on international routes.

Operational Considerations

Protocol Operation - Vouching If a vouching call results in a provisional response (e.g., 180 Ringing) or a successful response (200 OK), the platform that initiated the verification call SHOULD immediately cancel the call and treat the remote system as not implementing CIDVV.

Failure and Restart Behavior CIDVV platforms rely on short-lived state. Upon restart or loss of state, implementations SHOULD continue accepting new call deposits, but MUST treat verification requests as unsuccessful until fresh matching state has been deposited. Implementations SHOULD fail closed rather than risk false-positive validation. When verification cannot be performed, implementations SHOULD return a non-success response, such as a 4xx, 5xx, or 6xx response. SIP 603 Decline is commonly used for this purpose.

Number Normalization All telephone numbers used in CIDVV operations (for caching, token generation, comparison, etc.) MUST be normalized to a plain digit string in E.164 format without any leading "+" sign. CIDVV encodes signaling information in the Calling Party Number. Because some PSTN and ISDN signaling environments limit the Calling Party Number to 15 digits, CIDVV values that would exceed this limit are truncated as specified below.

1. Remove any leading "+" or other punctuation characters (parentheses, dashes, spaces, etc.).
2. Use the full E.164 representation: country code followed by the national significant number.
3. No padding is performed. If truncation is required to stay within the 15-digit limit for the Calling Party Number field, always remove leading digits, preserving the rightmost digits.

The leading + sign may be present in SIP signaling or user-facing displays. It MUST be stripped before any CIDVV processing, tuple storage, comparison, or token computation.

Prefix Preservation Because CIDVV signaling is carried entirely in the Calling Party Number (using the +100 and +101 prefixes), it is critical that these prefixes survive network traversal. SIP intermediaries, SBCs, and PSTN gateways SHOULD preserve the full Calling Party Number, including the leading 100 or 101 prefix, when forwarding CIDVV signaling calls across trusted interfaces. If a network element cannot preserve the prefix, it SHOULD respond with a non-success response, such as SIP 603 Decline, rather than forwarding a modified version that would break the protocol.

Interaction with Call Analytics and Fraud Detection CIDVV signaling calls use Calling Party Number values that may appear anomalous to call analytics, labeling, and fraud detection systems. Systems that support such analytics SHOULD recognize CIDVV signaling prefixes (e.g., "100" and "101") and treat such calls as protocol signaling rather than ordinary subscriber traffic. CIDVV signaling calls are not intended to be presented to end users and SHOULD NOT be labeled or blocked as malicious traffic when processed within cooperating networks. Failure to recognize CIDVV signaling may result in increased false positives or suppression of verification attempts.

Edge Cases and Special Handling

Multiple Simultaneous Calls from the Same Caller-ID (Fan-Out) In some scenarios, multiple calls may legitimately originate from the same Asserted Caller-ID to the same called number within a short period of time (e.g., an office full of people calling a radio contest to be the "100th caller", a call center, or a political phone bank). In such cases, the originating CIDVV platform MAY switch to "multi-call" mode for that (Asserted Caller-ID, Called Number) tuple:

• Instead of enforcing strict one-to-one correlation, the platform treats the tuple as active for the Validity Window.
• Each new outbound call for that tuple restarts or extends the expiration timer.
• The platform keeps the tuple active for the Validity Window, allowing multiple parallel or closely spaced calls to be vouched successfully.

This "multi-call" mode is an implementation-specific optimization. Platforms that do not support it MAY reject, rate-limit, or treat as indeterminate excessive concurrent calls from the same number.

Forwarded, Translated, and Mapped Numbers CIDVV operations depend on the number that the calling party attempted to reach. In some deployments, that number is not the same number on which the CIDVV platform ultimately receives the call. Examples include toll-free translation, DID forwarding, call forwarding, burner numbers, and other number-mapping services. In these cases, the CIDVV platform receiving the call needs reliable knowledge of the original called number, or a bounded configured set of possible original called numbers, in order to perform CIDVV successfully.

Vouching Mapped Numbers If Alice calls 18005550199 and the call is delivered to Bob's CIDVV platform on 19495550199, Alice's CIDVV platform will have cached the tuple: (Alice's Asserted Caller-ID, 18005550199) In that case, Bob's CIDVV platform needs to perform the vouching procedure using 18005550199 as the called-number value encoded in the Phase 1 and Phase 2 verification Calling Party Numbers. A vouching attempt using 19495550199 may fail because Alice's CIDVV platform has no matching cached state for 19495550199. If Bob's CIDVV platform has reliable knowledge of the original called number, it SHOULD use that number for vouching. If Bob's platform has a small configured set of possible original called numbers that may have delivered the call, it MAY attempt vouching against multiple candidate called numbers, subject to local rate limits and timeout policy. If the original called number is not known, and the candidate set is not bounded or reliable, Bob's CIDVV platform SHOULD treat the vouching result as unavailable or indeterminate rather than attempting to vouch using an unrelated receiving number. Local policy may then allow, label, bypass, route differently, reject, or otherwise handle the original call.

Vetting Mapped Numbers Mapped or translated numbers can also affect vetting because the number Alice attempts to vet may differ from the number on which Bob's CIDVV platform receives the Wake Call. For example, Alice may attempt to vet Bob's toll-free number 18005550199, but the Wake Call may be translated and delivered to Bob's CIDVV platform on DID 19495550199. Vetting tokens are computed using the number being vetted, not necessarily the number on which the Wake Call is ultimately received. If Bob's CIDVV platform has reliable knowledge of the original called number 18005550199, it SHOULD compute the Recognize Token and Auth Token using 18005550199 as the called-number input. If Bob's CIDVV platform receives the Wake Call on 19495550199 and has a bounded, configured mapping from 19495550199 to one or more possible public numbers, it MAY compute and temporarily cache candidate Recognize Tokens and Auth Tokens for those mapped numbers. When Alice sends the Recognize Call, Bob's CIDVV platform matches the received token against the cached candidate Recognize Tokens. The matched candidate identifies which called number Alice is attempting to vet. Bob then uses the corresponding Auth Token for that same called number when placing the Auth Call back to Alice. If no candidate Recognize Token matches, the vetting attempt MUST fail. Candidate-token generation for mapped numbers SHOULD be limited to a small, configured, authoritative set of mappings. Implementations SHOULD NOT generate tokens for an unbounded set of possible forwarded, translated, or indirectly mapped numbers.

Call Forwarding / Diversion When the called party (Bob) has forwarded the call to a different destination, the terminating CIDVV platform at the forwarded destination may be the platform that performs the vouching procedure. In this case, the terminating CIDVV platform SHOULD use the original called number (Bob's number), when available from diversion or redirection information (e.g., SIP Diversion header or ISDN Redirecting Number field), as the called-number value encoded in the Calling Party Number of the return vouch calls. The return vouch calls are still directed to Alice's Asserted Caller-ID. However, their Calling Party Numbers encode Bob's original called number, for example:

• Phase 1: +100 followed by Bob's number.
• Phase 2: +101 followed by Bob's number.

Alice's CIDVV platform can then correlate the verification calls with the cached state for Alice's original call to Bob. The terminating CIDVV platform is responsible for performing the vouch on behalf of the forwarded call destination.

Security Considerations CIDVV verification is probabilistic and based on reachability rather than cryptographic identity. It is intended to complement, not replace, mechanisms such as STIR/SHAKEN. Important Limitation CIDVV specifically addresses Caller-ID spoofing and impersonation. It does not prevent all forms of telephone fraud. Callers who use numbers they legitimately control can still obtain successful vouches, even if the calls themselves are fraudulent, abusive, or unwanted. Similarly, a malicious or compromised CIDVV platform, carrier, or service provider could incorrectly vouch for calls using numbers under its control. However, this does not allow that platform to vouch for arbitrary third-party numbers unless it can also receive verification calls for those numbers. The scope of the failure is therefore limited to the numbers and routing authority controlled by that platform or provider. These cases are outside the scope of the spoofing protection CIDVV provides. CIDVV's security properties derive primarily from the difficulty a spoofing caller faces in receiving calls at the Asserted Caller-ID, which is the number being vouched. CIDVV validates reachability within a short Validity Window rather than providing strict per-call correlation. As a result, a successful vouch indicates that at least one matching call attempt occurred within the Validity Window, not necessarily that a specific verification call maps one-to-one to a specific original call leg. The use of distinct response patterns across the two verification calls -- Phase 1 with the "100" prefix expecting a Busy-class response, and Phase 2 with the "101" prefix expecting a Rejection-class response -- increases resistance to false-positive validation caused by common network behaviors.

Trust Model CIDVV assumes that:

• The PSTN routes calls for a telephone number to the responsible service provider, administrative domain, or platform serving that number.
• A CIDVV platform acting for the Asserted Caller-ID can receive verification calls directed to that Caller-ID and route them to the appropriate CIDVV processing function.
• A CIDVV platform performing vouching for the called party can originate short return signaling calls toward the Asserted Caller-ID.
• Intermediate networks may modify signaling but will generally preserve sufficient information to allow correlation of requests and responses.
• CIDVV verification traffic related to attempted use of a telephone number as an Asserted Caller-ID is routed toward the party responsible for that number.

CIDVV does not assume that Caller-ID values are trustworthy; instead, it verifies control through network reachability.

Replay and Ride-Along Attacks CIDVV relies on short-lived state to correlate signaling exchanges. This significantly limits the window for replay and ride-along attacks. Replay Attacks A party that observes a successful verification exchange cannot effectively replay it after the cached state expires. Implementations MUST expire cached state quickly. A recommended default is 10 seconds, although longer values (e.g., 15-30 seconds) MAY be used for international or high-latency routes. Implementations MUST reject verification attempts that do not match recent, valid cached state. Ride-Along Attacks A ride-along attack is limited to the same correlation tuple used for vouching: the Asserted Caller-ID, the called number, and the Validity Window. A successful vouch for one called number does not allow a caller to vouch calls to other destinations, and a successful vouch for one Asserted Caller-ID value does not apply to other Asserted Caller-ID values. A spoofing caller might attempt to place an additional call using the same Asserted Caller-ID to the same called number while matching cached state is still valid. Because the originating CIDVV platform controls how long cached state remains valid, implementers have flexibility in mitigation:

• An implementation MAY delete or expire the cached state immediately after successfully processing the Phase 1 ("100") verification call and responding with a Busy-class response.
• An implementation MAY keep the cached state active for the Validity Window to support legitimate parallel or closely spaced calls from the same Asserted Caller-ID to the same called number.

The choice of when to expire or delete state is left to the implementer, as it involves a trade-off between reducing ride-along opportunities and supporting legitimate simultaneous-call or fan-out behavior.

Spoofing Resistance CIDVV improves resistance to spoofing by requiring the party asserting a Caller-ID to successfully receive and respond to a return call routed via the PSTN. If a caller attempts to impersonate Alice's Caller-ID without being able to receive calls for Alice's number, the verification call will normally be routed to the party responsible for Alice's number rather than to the impersonating caller. As a result, the impersonating caller cannot complete the vouching process under normal routing conditions.

Denial of Service CIDVV introduces additional signaling traffic, and deployments need to account for the possibility of excessive or malicious verification attempts. Because CIDVV vouching traffic is related to ordinary call traffic, high call volumes may legitimately produce high verification volumes. CIDVV can also expose useful telemetry about telephone-number usage. For example, if a widely spoofed enterprise number is asserted on many calls, CIDVV verification attempts may cause the responsible enterprise or service provider to receive a large volume of return verification calls. This traffic can help identify spoofing activity, but it can also create operational load on the CIDVV platform and serving network. Denial-of-service protection is therefore a deployment responsibility shared by CIDVV platforms, SBCs, proxies, gateways, and other responsible network elements. Deployments SHOULD apply appropriate ingress controls at the SBC, proxy, or other network edge, including rate limits, source filtering, anomaly detection, and protection against repeated invalid or abusive signaling patterns. Such controls SHOULD be designed so that high-volume legitimate enterprise traffic and high-volume spoofing telemetry can be observed without overwhelming the CIDVV platform. CIDVV platforms MUST bound resource usage for temporary state. For example, implementations MUST limit the number of concurrent cache entries, expire old entries automatically, and avoid retaining state beyond the Validity Window except where explicitly required by local policy. CIDVV platforms SHOULD fail closed under resource exhaustion. If a platform cannot safely allocate state or process a verification request, it SHOULD treat the verification as unsuccessful or indeterminate rather than returning a response that could create a false-positive vouch. Deployments SHOULD monitor CIDVV signaling volume and error patterns, especially repeated unsuccessful attempts, unexpected response patterns, traffic inconsistent with normal call volume, or sudden increases in verification traffic for particular Asserted Caller-ID values.

Amplification and Reflection Like other dialback mechanisms, CIDVV creates reflection risk because a call using a spoofed Asserted Caller-ID can cause verification traffic to be directed toward the party responsible for that number. CIDVV does not eliminate this risk. Instead, it is designed to keep each verification event bounded: vouching normally generates only two short signaling-only verification calls, those calls are expected to terminate with non-success responses, and they MUST NOT establish media. Deployments that initiate CIDVV verification calls SHOULD limit their own contribution to reflection traffic through local policy, including rate limits, concurrency limits, retry limits, suppression of repeated failed attempts, and bounded candidate sets for mapped or forwarded numbers. These controls reduce the amount of verification traffic generated by any single terminating deployment, but they do not by themselves protect a number owner whose Caller-ID is being spoofed across many independent terminating networks. The party responsible for an Asserted Caller-ID therefore also needs ingress protections at its SBC, proxy, or CIDVV platform. Such protections can include recognition of CIDVV prefixes, routing CIDVV signaling calls away from ordinary users, rate limiting, source filtering, anomaly detection, capacity planning, and summarization or sampling of telemetry during high-volume spoofing events. Incremental deployment also affects this risk model. CIDVV does not require a coordinated flag day, so verification traffic is expected to grow gradually as additional terminating platforms deploy the protocol. Enterprises and service providers whose numbers are frequently spoofed may begin seeing CIDVV verification attempts before they fully participate in CIDVV themselves. This creates an incentive to recognize CIDVV prefixes, route such traffic to an appropriate platform, apply ingress controls, and use the resulting telemetry for spoofing detection and mitigation. CIDVV verification traffic can provide useful telemetry about attempted misuse of a number, but deployments need to treat that telemetry path as an operational interface that may receive abusive or high-volume traffic. These mitigations do not remove all reflection risk, but they are intended to keep CIDVV signaling bounded, non-media-bearing, observable, and manageable during incremental deployment.

Response Code Manipulation CIDVV does not require specific SIP response codes to be preserved end-to-end, but it does require that distinct response behaviors (e.g., Busy-class vs. Rejection-class behavior) remain distinguishable. Implementations MUST interpret responses based on behavioral class (e.g., Busy-class vs. Rejection-class) rather than exact numeric values. Intermediate networks and gateways SHOULD NOT translate, synthesize, or normalize responses in a way that causes an unsuccessful CIDVV response to be interpreted as successful CIDVV behavior.

Data Privacy CIDVV uses telephone numbers and related call metadata as part of normal signaling behavior. CIDVV may also create operational telemetry about attempted use of telephone numbers as Asserted Caller-ID values, including successful and unsuccessful verification attempts. Deployments SHOULD handle CIDVV signaling records, verification logs, and related telemetry according to their normal privacy, security, retention, and access-control policies for call signaling data. In jurisdictions with data-protection requirements, CIDVV telemetry may constitute personal data or communications metadata. Deployments are expected to process such telemetry under an appropriate legal basis and with suitable purpose limitation, minimization, retention, access-control, and security safeguards. Implementations SHOULD minimize retention of CIDVV telemetry where practical. Temporary state used for CIDVV verification MUST be short lived and automatically expired. Where operationally practical, access to CIDVV logs and telemetry SHOULD be limited to systems and personnel responsible for operations, security, fraud prevention, debugging, or compliance.

Token and Shared-Secret Security (Vetting) The security of the vetting mechanism depends on the shared secret and the derived Recognize and Auth Tokens. Tokens MUST be computed as specified in Section Token Computation Algorithm. Shared secrets used for vetting MAY be long-lived configuration values. For example, a vetting agent and a number owner might retain the same shared secret in order to perform periodic or recurring vetting of the same customer numbers. Implementations MUST protect shared secrets from disclosure. If a shared secret is disclosed, a third party may be able to complete vetting challenges for the vetting relationships and numbers covered by that secret. Disclosure of a vetting shared secret does not, by itself, allow the third party to successfully vouch for calls, because vouching also requires reachability and valid call state for the Asserted Caller-ID. Recognize and Auth Tokens MUST be valid only within the Validity Window and MUST be automatically expired. Implementations SHOULD use sufficiently long and random shared secrets. Deployments SHOULD scope shared secrets to the appropriate customer, tenant, number owner, or vetting relationship, and SHOULD support rotation or revocation if a secret is suspected to be disclosed.

Failure Modes CIDVV implementations MUST fail closed. If verification cannot be completed due to network errors, state loss, synchronization delay, resource exhaustion, or unexpected responses, the result MUST be treated as unverified or indeterminate rather than successful. CIDVV platforms commonly rely on short-lived state with automatic expiration. After a restart or loss of temporary state, the platform MAY continue accepting new call notifications, but it MUST NOT successfully verify calls until fresh matching state has been deposited. During this recovery interval, legitimate calls may fail to receive a successful vouch, but calls without matching state will not be falsely vouched. Distributed CIDVV deployments may include multiple ingress points, geographically diverse SBCs, or replicated state stores. If a verification call reaches a CIDVV processing node before the relevant call state has been replicated to that node, the verification MUST fail closed. Deployments that use distributed state SHOULD ensure that call-deposit state is available to all CIDVV nodes that may receive subsequent verification calls within the Validity Window. Implementations MAY delay advancing the original call briefly, use synchronous replication, use sticky routing, or apply other local mechanisms to reduce the chance that a valid verification call arrives before matching state is available.

Interoperability Risks CIDVV operates across heterogeneous networks, including SIP and SS7/TDM environments. Intermediate systems may modify Calling Party Number values, truncate digits, alter response codes, or otherwise change signaling behavior. These behaviors may cause verification to fail. Implementations MUST treat ambiguous, altered, missing, or inconsistent signaling as unsuccessful or indeterminate rather than allowing false-positive validation. Deployments SHOULD test CIDVV behavior across the specific carriers, gateways, SBCs, and interworking paths used in their environment, especially where Calling Party Number preservation, digit truncation, or response-class translation may occur.

Residual Risk CIDVV improves resistance to Caller-ID spoofing but does not provide absolute identity assurance. It reduces the effectiveness of spoofing by testing reachability and response behavior for the Asserted Caller-ID within a short Validity Window. CIDVV does not prove the intent, legitimacy, or trustworthiness of the caller. A caller using a number it legitimately controls may still place fraudulent, abusive, or unwanted calls and receive successful vouches for that number. CIDVV should therefore be treated as one verification signal among multiple inputs to call-handling, fraud-prevention, analytics, reputation, or policy systems.

IANA Considerations This document has no IANA actions.

Informative References Cisco Systems Cisco Systems Robocalling has become an increasing problem in the Public Switched Telephone Network (PSTN). A partial remedy for it is the provision of an authenticated caller ID in the PSTN, which today is lacking. Secure Telephone Identity Revisited (STIR) provides this through the usage of signed payloads in Session Initiation Protocol (SIP) calls. However, STIR deployment requires a global certificate system which allows for worldwide issuance of certifications that attest to which numbers a provider is responsible for. Such a system is likely to take years to rollout. To accelerate STIR deployment, this draft proposes a technique wherein STIR can be used without certificates that attest to number ownership. This is done through a combination of self-signed certificates, reverse callbacks and cached validations. University of Warwick Squire Technologies Ltd trueCall Ltd Birmingham City University University of Warwick This document defines an extension to the INVITE header of the Session Initiation Protocol (SIP) to support a Caller ID Verification (CIV) method. CIV authenticates the caller ID of an incoming call through a challenge-and-response process across both IP and non-IP networks without requiring a trusted third party or a public key infrastructure. When receiving a call with a claimed phone number, the called party holds the call and sends a quickly terminated INVITE request (like a flash call) to that number, carrying a short 4-digit challenge embedded as part of the caller ID. A genuine caller would receive the challenge and respond by echoing the same digits, e.g., through DTMF (Dual-Tone Multi-Frequency). The proposed extension involves two changes to the INVITE header. First, it adds a new option tag, "civ", in the Supported header field of the INVITE request. This tag allows the calling party to indicate support for CIV in the initial call. Second, it adds a special value "civ-veri- call" for the Purpose parameter of the Call-Info header field. This value allows the called party to make a verification call, indicating the purpose of the call is to transmit a challenge rather than establish a phone conversation. CIV uses the standard Session-ID header in the INVITE request to allow the calling party to explicitly match the verification call with the initial call. Whilst this document focuses on IP networks, the same CIV protocol also works with non-IP networks (e.g., SS7) by including the "civ" tag, the "civ-veri-call" value and the session ID in the User-to-User Information (UUI) parameter. The Personal Assertion Token (PASSporT) format defines a token that can be carried by signaling protocols, including SIP, to cryptographically attest the identity of callers. However, not all telephone calls use Internet signaling protocols, and some calls use them for only part of their signaling path, while some cannot reliably deliver SIP header fields end-to-end. This document describes use cases that require the delivery of PASSporT objects outside of the signaling path, and defines architectures and semantics to provide this functionality. The Secure Telephone Identity Revisited (STIR) framework defines means of carrying its Personal Assertion Tokens (PASSporTs) either in-band, within the headers of a Session Initiation Protocol (SIP) request, or out-of-band, through a service that stores PASSporTs for retrieval by relying parties. This specification defines a way that the out-of-band conveyance of PASSporTs can be used to support large service providers for cases in which in-band STIR conveyance is not universally available.

Acknowledgments The authors thank contributors to telephony security research and PSTN infrastructure development.

Appendix: Changes from Previous Version RFC Editor: Please remove this section before publication as an RFC.

Changes since draft-anderson-askew-cidvv-00 (May 2026)

• Minor editorial improvements and clarifications throughout the document.
• Made both Vouching calls required and renamed them as "Phase 1" and "Phase 2" for clarity.
• Updated termination handling so that Busy-class and Rejection-class responses, with canonical SIP 486 Busy Here and SIP 603 Decline behavior, are used for CIDVV verification signaling.
• Added a third call to the Vetting process to ensure Alice and Bob each trust that the other possesses the shared secret.
• Added optional Multi-Number Vetting optimization.
• Added Related Work, Signaling Load, Operational Telemetry, Amplication, and Reflection sections.
• Added this "Changes from Previous Version" appendix to support long-term document maintenance across multiple revisions.
• Improved Abstract, Introduction, and call flow.