Caller-ID Vouching and Vetting (CIDVV)

2.1. 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.¶

2.2. 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, [I-D.rosenberg-stir-callback] 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) [I-D.hao-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 [RFC8816] and [RFC9888], 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 (Section 5.4) and Section Amplification and Reflection (Section 7.5) discuss these issues in more detail.¶

2.3. 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.¶

2.4. 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.¶

2.5. CIDVV Mechanisms

2.6. 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.¶

3.1. 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.¶

3.2. 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 (Section 6.6.1).¶

3.3. 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 (Section 2.5.3).¶

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.¶

3.4. 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 (Section 2.5.3) 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 (Section 2.5.3) 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.¶

4.1. Successful Vouch Call Flow

The following diagram shows a successful vouch.¶

  Alice    CIDVV_A    SBC_A      PSTN     SBC_B    CIDVV_B     Bob
    |----- INVITE ----->|         |         |         |         |
    |         |<-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.¶

4.2. 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.¶

4.3. 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.¶

   CIDVV_A        SBC_A          PSTN         SBC_B        CIDVV_B
      |             |             |             |             |
      |-- WAKE101 ->|             |             |             |
      |             |-- WAKE101 ->|             |             |
      |             |             |-- WAKE101 ->|             |
      |             |             |             |-- WAKE101 ->|
      |             |             |             |             |
      |             |             |             |<--- 603 ----|
      |             |             |<--- 603 ----|             |
      |             |<--- 603 ----|             |             |
      |<--- 603 ----|             |             |             |
      |             |             |             |             |

   CIDVV_A        SBC_A          PSTN         SBC_B        CIDVV_B
      |             |             |             |             |
      |-- RECG101 ->|             |             |             |
      |             |-- RECG101 ->|             |             |
      |             |             |-- RECG101 ->|             |
      |             |             |             |-- RECG101 ->|
      |             |             |             |             |
      |             |             |             |<--- 486 ----|
      |             |             |<--- 486 ----|             |
      |             |<--- 486 ----|             |             |
      |<--- 486 ----|             |             |             |
      |             |             |             |             |

   CIDVV_A        SBC_A          PSTN         SBC_B        CIDVV_B
      |             |             |             |             |
      |             |             |             |<- AUTH101 --|
      |             |             |<- AUTH101 --|             |
      |             |<- AUTH101 --|             |             |
      |<- AUTH101 --|             |             |             |
      |             |             |             |             |
      |---- 486 --->|             |             |             |
      |             |---- 486 --->|             |             |
      |             |             |---- 486 --->|             |
      |             |             |             |---- 486 --->|
      |             |             |             |             |

5.1. 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.¶

5.2. 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.¶

5.3. 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.¶

5.4. 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.¶

5.5. 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.¶

5.6. 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.¶

5.7. 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.¶

6.1. 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.¶

6.2. 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.¶

6.3. 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.¶

6.4. 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.¶

6.5. 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.¶

6.6. Edge Cases and Special Handling

7.1. 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.¶

7.2. 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.¶

7.3. 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.¶

7.4. 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.¶

7.5. 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.¶

7.6. 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.¶

7.7. 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.¶

7.8. 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 (Section 2.5.3).¶

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.¶

7.9. 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.¶

7.10. 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.¶

7.11. 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.¶

B.1. 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.¶