— abstract
Caller-ID spoofing remains a significant problem in telephony, particularly across inter-domain and international call paths where identity frameworks may not be consistently applied.
This document defines Caller-ID Vouching and Vetting (CIDVV), a lightweight verification mechanism that uses short-lived signaling exchanges encoded within the Calling Party Number to confirm that a calling party can receive calls at the Asserted Caller-ID.
CIDVV 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, using failed call attempts as evidence of number control rather than successful call completion.
The mechanism improves resistance to Caller-ID spoofing by requiring demonstrable control of the Asserted Caller-ID, while remaining incrementally deployable and tolerant of intermediate network modification.
— middle
Caller-ID spoofing is widely used in fraudulent and nuisance calling, particularly in environments where calls traverse multiple administrative domains and heterogeneous network technologies. Although mechanisms such as STIR/SHAKEN provide cryptographic attestation of caller identity, their effectiveness is limited by partial deployment and challenges in international interconnection.
This document defines Caller-ID Vouching and Vetting (CIDVV), a mechanism that verifies caller identity through network reachability rather than asserted identity. CIDVV requires that a party asserting a Caller-ID be able to receive a return call at that number within the 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 does not require new SIP headers, protocol extensions, or changes to SS7 signaling, and is designed to function across mixed SIP and TDM networks.
CIDVV is incrementally deployable and does not require universal adoption to provide benefit. It tolerates modification of signaling by intermediate networks and relies on signaling calls and distinct failure-response behaviors traversing the network path.
CIDVV provides strong, real-time evidence of Caller-ID validity by requiring that a party asserting a Caller-ID be able to receive and respond to a return call at that number within the Validity Window. While it does not provide absolute identity assurance, it offers a practical and robust signal of trust in the presented identity.
CIDVV leverages two key elements of the existing telephone ecosystem:
The mechanism operates entirely within standard PSTN routing behavior and requires no media exchange.
In this document, the term “Caller-ID” refers to the identity presented to users, while “Calling Party Number” refers to the signaling field used to convey that identity.
Once successfully vouched, an Asserted Caller-ID may be referred to informally as a “vouched number,” but the formal term used in this document is “Asserted Caller-ID.”
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.
The CIDVV vouching and vetting mechanism is designed to operate with minimal new infrastructure while providing strong protection against Caller-ID spoofing. Its primary advantages are:
Leverages existing PSTN infrastructure: The mechanism uses existing numbering plans and routing databases to direct calls without requiring additional infrastructure.
Strong anti-spoofing protection: A successful vouch provides strong evidence that the Asserted Caller-ID is controlled by the legitimate owner, because only the real owner can generate the correct challenge-response sequence. Spoofed calls are typically rejected early, often resulting in failure responses such as 404 Not Found.
Visibility into spoofing activity: Telephone number owners gain direct insight into how often (and from where) their numbers are being spoofed worldwide through logged vetting attempts.
Low signaling overhead: The two short vetting calls replace what would otherwise be a completed fraudulent call, resulting in lower overall network load.
Full TDM/SS7 compatibility: The mechanism works natively across legacy SS7 and ISDN networks. SIP is not required.
International applicability: The solution functions across international boundaries without relying on country-specific frameworks.
Independent of STIR/SHAKEN: It provides an effective alternative (or complement) in environments where STIR/SHAKEN is unavailable, not deployed, or insufficient.
Enterprise and service-provider flexibility:
This design lowers the barrier to entry and encourages broad adoption while avoiding the single points of failure and high coordination costs associated with centralized solutions. These properties make the vouching mechanism particularly suitable for service providers, enterprises, and end users who need robust Caller-ID validation today, using only existing telephone infrastructure.
CIDVV is designed to operate under the assumption that intermediate networks may normalize, truncate, or otherwise modify signaling information. The protocol therefore encodes all required signaling in a numeric Calling Party Number that can survive traversal of mixed SIP and SS7/TDM networks.
CIDVV relies on the ability to distinguish between classes of call rejection behavior (e.g., “busy” vs. “not found”), rather than requiring specific numeric response codes to be preserved end-to-end.
All telephone numbers used in CIDVV operations MUST be normalized to a digit string as follows:
No padding is performed. Truncation (when required for the 15-digit limit) always removes leading digits of the telephone number, preserving the rightmost digits.
CIDVV uses special Caller-ID prefixes to signal protocol operations:
CIDVV Calling Party Numbers are numeric signaling values carried in the Calling Party Number field. They are not represented as E.164 numbers and are shown without a leading “+” in this document.
Ordinary subscriber telephone numbers (e.g., +12125550100) are shown in E.164 format for clarity, while CIDVV signaling values (e.g., 10019495550199) are shown as digit strings.
CIDVV signaling Calling Party Numbers MUST fit within the 15-digit Calling Party Number limit commonly encountered in SS7 and ISDN networks. For this reason, CIDVV uses a three-digit prefix followed by a payload derived from the Asserted Caller-ID:
CIDVV-CPN (CIDVV Calling Party Number) = Prefix || Payload
where CIDVV-CPN means CIDVV Calling Party Number, Prefix is “100” or
“101”, and the payload is derived from the Asserted Caller-ID
(normalized per Section
For vouching operations, the payload is derived from the called number associated with the verification. For vetting operations, the payload may be derived from computed token values.
In the common case where the Asserted Caller-ID has 12 or fewer digits, the Payload is used in full, so the CIDVV-CPN is simply the three-digit prefix directly concatenated with the full Asserted Caller-ID digits.
If the resulting CIDVV-CPN would exceed 15 digits (i.e., the asserted Caller-ID has more than 12 digits), the leading digits of the asserted Caller-ID are removed until the total length is exactly 15 digits, consistent with SS7 and ISDN Calling Party Number constraints. This truncation preserves the rightmost digits of the telephone number, which typically provide greater distinguishing information between individual subscribers than leading digits.
A CIDVV-aware element generating a CIDVV verification call MUST apply this construction. A CIDVV platform MAY cache and compare the complete 15-digit CIDVV Calling Party Number (including the prefix) rather than reconstructing it for comparison.
Because CIDVV payloads may be truncated to the rightmost 12 digits, distinct telephone numbers can, in rare cases, produce identical payload values. Correlation is therefore additionally scoped by the called number and the Validity Window.
In such cases, multiple call attempts may be indistinguishable to the CIDVV platform and treated as a single correlation event. As a result, a successful verification may apply to more than one call attempt within the Validity Window.
CIDVV verification consists of observing the behavior of one or more verification calls using distinct CIDVV prefixes.
A successful vouch requires that a verification call using the “100” prefix produce the expected response behavior. Additional verification calls (e.g., using the “101” prefix) MAY be used to achieve higher assurance.
The expected behavior is:
A CIDVV-aware network element MUST NOT treat a single response as sufficient evidence of a successful vouch unless it corresponds to the expected behavior for the “100” prefix.
Additional verification calls (e.g., using the “101” prefix) MAY be used to increase assurance but are not required for a valid vouch.
The two verification calls MAY be sent in any order or in parallel. Implementations MUST NOT assume ordering.
If either expected response is missing, altered, delayed, replaced by call progression, or inconsistent with the expected pattern, the result MUST be treated as unsuccessful or indeterminate.
CIDVV exchanges occur using short signaling dialogs and do not require media establishment.
CIDVV signaling is encoded entirely within numeric Calling Party Number values to maximize survivability across heterogeneous SIP and SS7/TDM networks.
Vetting procedures MAY use full telephone numbers or truncated forms as input to cryptographic operations, independent of the CIDVV Calling Party Number encoding.
CIDVV operations rely on state within the Validity Window.
CIDVV uses the same signaling prefixes for both operations but with distinct expected behaviors. The table below summarizes the differences:
| Prefix | Vouching (live call) | Vetting (pre-shared secret) | Notes |
|---|---|---|---|
| 100 | Expect 486 Busy Here | Not used | Primary vouch signal |
| 101 | Expect 404 Not Found | First call: 404 (deposit), Second call: 486 | Secondary / vetting |
Implementations distinguish context (vouching vs. vetting) primarily by the presence of a pre-agreed vetting Caller-ID and shared secret for the Asserted Caller-ID. Because vetting uses a specific Caller-ID designated for the procedure, overlap with ordinary vouching calls on the same number is expected to be rare. A CIDVV platform MUST treat calls using a known vetting Caller-ID according to the vetting response pattern (even if a live vouch cache entry exists) and MUST NOT treat a 101->404 response as a successful vouch when an active vetting procedure is in progress for that number.
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. “Not Found”-class) rather than exact numeric values.
Implementations SHOULD use SIP 486 (Busy Here) and 404 (Not Found) as the canonical representations of these behaviors where possible.
CIDVV requires that these two rejection behaviors remain distinguishable across the signaling path. Environments that cannot preserve this distinction may not support enhanced verification.
A call using the “100” prefix is considered successful only if it results in an immediate rejection consistent with a “Busy”-class response (e.g., SIP 486 Busy Here).
A CIDVV implementation MUST treat any response other than this expected behavior - including ringing, call completion, timeout, or alternative error responses - as an unsuccessful verification.
A successful “100” verification provides a baseline level of confidence that the Asserted Caller-ID is routable and under the control of the originating party.
A call using the “101” prefix is used as an optional secondary validation signal.
The expected behavior is an immediate rejection consistent with a “Not Found”-class response (e.g., SIP 404 Not Found).
In the context of an active vetting procedure, a “101” call carrying a valid vetting token MAY instead result in a “Busy”-class response (e.g., SIP 486 Busy Here).
Because such responses are relatively common in the PSTN, a “101” verification alone MUST NOT be treated as evidence of a successful vouch.
Implementations MAY perform both “100” and “101” verification calls to achieve a higher level of assurance.
In this case, a stronger validation result is obtained when:
within the Validity Window.
Implementations MUST NOT require the two verification calls to occur in any specific order.
If the expected behavior for a given prefix is not observed, the verification for that prefix MUST be treated as unsuccessful.
If only the “100” verification succeeds, the result MAY be treated as a valid but lower-assurance vouch.
If both “100” and “101” verifications succeed (i.e., “100” -> 486 and “101” -> 404), the result MAY be treated as a higher-assurance vouch.
If neither verification succeeds, or if results are inconsistent or ambiguous, the vouch MUST be treated as unsuccessful or indeterminate.
Alice’s CIDVV platform receives an attempted call from Alice to Bob.
It MUST construct a CIDVV token as defined in Section
The CIDVV platform MUST cache the call attempt using the tuple:
(Called Number, CIDVV Token)
for the Validity Window.
The CIDVV platform then rejects the call with SIP response 486 (Busy Here).
Alice’s SBC receives the 486 and advances the original call through the PSTN toward Bob using the original Caller-ID.
When Bob’s system receives the call, a CIDVV-aware network element (e.g., SBC) initiates a verification call toward Alice.
Bob’s CIDVV-aware element constructs the CIDVV token using the same method (prefix “100” plus the rightmost 12 digits of the dialed number) and initiates a verification call toward Alice 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 the CIDVV platform.
Upon receiving the verification call, Alice’s CIDVV platform MUST look up the tuple:
(Called Number, CIDVV Token)
cached for the Validity Window.
If a matching cache entry exists, the CIDVV platform MUST reject the verification call with SIP response 486 (Busy Here).
If no matching cache entry exists, the CIDVV platform MUST reject the verification call with SIP response 404 (Not Found).
A successful “100” verification (i.e., receipt of 486) indicates that the originating party can receive calls at the Asserted Caller-ID and constitutes a valid baseline vouch.
Bob’s CIDVV-aware element MAY initiate a second verification call using a CIDVV token constructed by prefixing “101” to the same 12-digit payload.
When Alice’s SBC receives a call with a Calling Party Number beginning with “101”, it MUST route the call to the CIDVV platform.
Upon receiving such a call, the CIDVV platform MUST reject the call
with SIP response 404 (Not Found), unless the call corresponds to an
active vetting procedure (see Section
A “101” verification call does not require cache lookup for vouching purposes and MUST NOT be used as a standalone indicator of a successful vouch.
Implementations MAY perform only the primary (“100”) verification or MAY perform both primary and secondary verification.
A successful “100” verification alone provides a valid vouch with baseline assurance.
If both verification calls are performed, a higher-assurance vouch is obtained when:
“100” -> 486, and “101” -> 404
are both observed within the Validity Window.
The two verification calls MAY occur in any order or in parallel. Implementations MUST NOT assume ordering.
If the “100” verification fails, the vouch MUST be treated as unsuccessful regardless of any “101” result.
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.
If multiple calls with the same Asserted Caller-ID and called number occur within the cache interval, implementations MAY treat them as a single aggregate vouching state or MAY maintain a count of pending attempts.
A successful vouch indicates that at least one matching call attempt occurred during the Validity Window, rather than proving a one-to-one correspondence between specific call legs.
The same deterministic algorithm MUST be used for:
Algorithm (normative)
normalized-calling-number || "|" || normalized-called-number || "|" || shared-secretExample (for illustration only):
| Concatenated: “12125550100 | 19495550199 | hamburger” |
Implementations MUST use the identical normalization and concatenation order for both vetting calls and any Redis (or equivalent) cache lookups. The token is valid only inside the Validity Window.
CIDVV platforms that perform vouching on behalf of multiple independent customers MUST ensure that correlation state is scoped per customer. This prevents unintended interaction between unrelated vouching operations that may produce identical CIDVV payload values.
Implementations MAY use separate storage, partitioning, or customer-specific identifiers to achieve this isolation.
This requirement does not apply to vetting operations, which are already scoped by the shared secret.
Vetting a remote number requires two separate calls (distinct SIP dialogs) using a pre-agreed shared key. 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 two calls to Bob’s number in order to vet Bob’s number.
Before vetting begins, Alice and Bob agree on a shared secret, Bob’s vetting Caller-ID, and a Validity Window.
Alice places a vetting call to Bob using a Caller-ID beginning with the digits “101”.
When Bob’s CIDVV platform receives the first vetting 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 vetting token using the algorithm
defined in Section
Alice performs the same SHA-256 calculation and places a second vetting call to Bob. This second call uses a Caller-ID beginning with the Vetting Token Check prefix of “101” followed by the computed numeric code.
When Bob’s CIDVV platform receives the Vetting Token Check call, it removes the “101” prefix and compares the remaining numeric code to the recently cached value.
If the numeric code matches, Bob’s CIDVV platform MUST reject the call with SIP response 486 (Busy Here). Alice’s platform treats this response as a successful vet.
Any other response, timeout, code mismatch, expired cache entry, or unexpected Caller-ID MUST be treated as an unsuccessful vet.
The following diagram shows a baseline successful vouch using only the primary “100” verification call. This provides a valid vouch with baseline assurance.
Alice CIDVV_A SBC_A PSTN SBC_B Bob
| | | | | |
|------- INVITE ------->| | | |
| | | | | |
| |<- INVITE -| | | |
| | | | | |
| |--- 486 -->| | | |
| | |- INVITE ->| | |
| | | |- INVITE ->| |
| | | | | |
| | | |<- VFY100 -| |
| | |<- VFY100 -| | |
| |<- VFY100 -| | | |
| | | | | |
| |--- 486 -->| | | |
| | |--- 486 -->| | |
| | | |--- 486 -->| |
| | | | |- INVITE ->|
| | | | | |
In the diagram, “VFY100” represents a verification call whose Calling Party Number is the CIDVV token formed as “100” followed by the rightmost 12 digits of the dialed number.
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 and CIDVV-aware elements.
The originating user (Alice, Caller-ID +12125550100) initiates a
call to the destination user (Bob, dialed number +19495550199).
The call is routed from Alice’s User Agent to her SBC, which forwards it to the originating CIDVV platform (CIDVV_A).
19495550199, resulting in the token 10019495550199.(Called: +12125550100, Token: 10019495550199)
for the Validity Window.Alice’s SBC receives the 486 and advances the original call toward the PSTN using the original Caller-ID.
The call reaches Bob’s SBC via the PSTN.
+19495550199),
resulting in 10019495550199.+12125550100) using the Caller-ID 10019495550199.The verification call arrives at Alice’s SBC via the PSTN.
To: +12125550100
From: 10019495550199(Called: +12125550100, Token: 10019495550199)
cached for the Validity Window.Bob’s SBC receives the 486 via the PSTN, recognizes it as a successful primary verification, and advances the original call to Bob’s User Agent.
This mechanism allows the originating CIDVV platform to confirm that the Asserted Caller-ID is valid without completing the initial call.
The following diagram shows a successful vouch (Enhanced) using both the primary “100” verification call and an optional secondary “101” verification call. The “101” call provides additional assurance by producing a distinct response pattern when combined with a successful “100” verification. The “100” verification alone is sufficient for a baseline successful vouch.
For clarity, the verification calls are shown sequentially. In practice, the two verification calls MAY occur in any order or in parallel.
Alice CIDVV_A SBC_A PSTN SBC_B Bob
| | | | | |
|------- INVITE ------->| | | |
| | | | | |
| |<- INVITE -| | | |
| | | | | |
| |--- 486 -->| | | |
| | |- INVITE ->| | |
| | | |- INVITE ->| |
| | | | | |
| | | |<- VFY100 -| |
| | |<- VFY100 -| | |
| |<- VFY100 -| | | |
| | | | | |
| |--- 486 -->| | | |
| | |--- 486 -->| | |
| | | |--- 486 -->| |
| | | | | |
| | | |<- VFY101 -| |
| | |<- VFY101 -| | |
| |<- VFY101 -| | | |
| | | | | |
| |--- 404 -->| | | |
| | |--- 404 -->| | |
| | | |--- 404 -->| |
| | | | |- INVITE ->|
| | | | | |
In the diagram, “VFY100” and “VFY101” represent verification calls whose Calling Party Numbers are formed using the CIDVV token construction defined in Protocol Overview.
The diagram above shows an enhanced vouch using both the primary “100” verification call and an optional secondary “101” verification call. The following steps describe the detailed behavior.
The originating user (Alice, Caller-ID +12125550100) initiates a
call to the destination user (Bob, dialed number +19495550199).
The call is routed from Alice’s User Agent to her SBC, which forwards it to the originating CIDVV platform (CIDVV_A).
19495550199), resulting in
10019495550199.(Called: +12125550100, Token: 10019495550199)
for the Validity Window.Alice’s SBC receives the 486 and advances the original call toward the PSTN using the original Caller-ID.
The call reaches Bob’s SBC via the PSTN.
10019495550199.+12125550100) using the Caller-ID 10019495550199.The primary verification call arrives at Alice’s SBC via the PSTN.
(Called: +12125550100, Token: 10019495550199) cached for the Validity WindowBob’s SBC receives the 486 and recognizes a successful primary verification.
10119495550199.10119495550199.The secondary verification call arrives at Alice’s SBC via the PSTN.
To: +12125550100
From: 10119495550199Bob’s SBC receives the 404 and recognizes the expected secondary verification behavior.
Bob’s SBC treats this as a higher-assurance successful vouch.
Bob’s SBC advances the original call to Bob’s User Agent.
A vouch attempt is considered unsuccessful or indeterminate if the expected verification behavior is not observed.
Specifically:
If a verification call using the “100” prefix does not result in SIP 486 (Busy Here), the vouch MUST be treated as unsuccessful.
Implementations MUST fail closed. Any ambiguity, unexpected response, timeout, or call progression MUST result in an unsuccessful or indeterminate outcome.
Vetting uses two 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
| | | | |
|-- VFY101 -->| | | |
| |-- VFY101 -->| | |
| | |-- VFY101 -->| |
| | | |-- VFY101 -->|
| | | | |
| | | |<--- 404 ----|
| | |<--- 404 ----| |
| |<--- 404 ----| | |
|<--- 404 ----| | | |
| | | | |
CIDVV_A SBC_A PSTN SBC_B CIDVV_B
| | | | |
|-- VFY101 -->| | | |
| |-- VFY101 -->| | |
| | |-- VFY101 -->| |
| | | |-- VFY101 -->|
| | | | |
| | | |<--- 486 ----|
| | |<--- 486 ----| |
| |<--- 486 ----| | |
|<--- 486 ----| | | |
| | | | |
Vetting a remote number requires two separate calls (distinct SIP dialogs) using a pre-agreed shared key. The process confirms that the called party (Bob) controls the target telephone number and possesses the correct shared secret.
Alice and Bob agree on a shared secret (e.g., hamburger) and Alice’s vetting Caller-ID (+12125550100, or its rightmost 12 digits for matching purposes).
Both parties enter the shared secret, Alice’s vetting Caller-ID, and an optional Validity Window (e.g., one week) into their respective CIDVV platforms.
Alice’s CIDVV platform (CIDVV_A) initiates the first vetting call with Caller-ID 10112125550100 toward Bob’s number (+19495550199). The call traverses the PSTN.
Bob’s SBC recognizes the leading 101 prefix on the incoming Caller-ID and forwards the call to Bob’s CIDVV platform (CIDVV_B).
101, recovering Alice’s Caller-ID.normalized-calling-number, normalized-called-number, and shared-secret, where telephone numbers are represented as digit strings without separators or leading “+”.b0092191), converts to decimal (2953388433), pads to 10 digits, and prepends 1, yielding 12953388433.CIDVV_A receives the 404 and performs the identical hash calculation to derive 12953388433.
CIDVV_A immediately places a second vetting call to +19495550199 using the Vetting Token Check Caller-ID 10112953388433.
Bob’s SBC recognizes the 101 prefix on the Caller-ID and forwards the call to CIDVV_B.
101.12953388433) matches a recently cached vetting token.Use of the rightmost 12 digits is sufficient because collisions within the Validity Window are expected to be rare.
A vetting attempt may fail for the following reasons:
In all such cases, the vetting attempt MUST be treated as unsuccessful.
This two-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.
Systems that do not implement CIDVV are not expected to recognize CIDVV signaling prefixes. Such systems will typically process CIDVV 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 (see Section
Networks that recognize CIDVV SHOULD NOT present calls with Calling Party Numbers beginning with “100” or “101” to end users.
Such calls SHOULD be intercepted by network elements or CIDVV platforms and SHOULD result in a non-success response (e.g., 4xx, 5xx, or 6xx class response codes). Implementations commonly use responses such as 404 (Not Found), 486 (Busy Here), or 603 (Decline).
Call analytics, labeling, and fraud detection systems SHOULD recognize CIDVV signaling prefixes (“100” and “101”) and treat such calls as protocol signaling rather than ordinary subscriber calls.
CIDVV-aware elements SHOULD recognize and internally route CIDVV signaling calls using the Asserted Caller-ID without user presentation.
CIDVV signaling calls are not intended to complete. Implementations SHOULD minimize call duration and signaling load and SHOULD avoid any media establishment.
Implementations SHOULD interpret responses based on behavioral class (e.g., success vs. immediate rejection) rather than relying solely on exact numeric values, as intermediate networks may translate or modify response codes.
CIDVV relies on short-lived state for the (Asserted Caller-ID, CIDVV-Token)
tuple, valid only for the Validity Window. Implementations MUST expire this state automatically and
MUST fail closed: on restart or state loss, treat all verification
requests as unsuccessful until fresh state has been deposited. The
same hash algorithm defined in Section
If a vouching call results in a provisional response (e.g., 180 Ringing) or a successful response (200 OK), the originating system SHOULD immediately cancel the call and treat the remote system as not implementing CIDVV.
CIDVV platforms rely on short-lived state. Upon restart or loss of state, implementations SHOULD continue accepting new call deposits but MUST treat all verification requests as unsuccessful until sufficient state has been rebuilt.
Implementations SHOULD return a non-success response (e.g., 4xx, 5xx, or 6xx). A 603 (Decline) response is commonly used to indicate that verification could not be performed.
Implementations SHOULD fail closed (treating requests as unverified) rather than risk false-positive validation.
SIP intermediaries and SBCs that support CIDVV SHOULD preserve the Calling Party Number digits used for CIDVV signaling, including the leading “100” or “101” prefix, across trusted interfaces unless local policy explicitly rejects the call.
CIDVV does not rely on Type-of-Number (TON) preservation and assumes that intermediate networks may normalize or reinterpret numbering format.
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.
CIDVV verification is probabilistic and based on reachability. It does not provide cryptographic identity guarantees and is intended to complement, not replace, mechanisms such as STIR/SHAKEN.
Its security properties derive from the inability of an attacker to receive calls at the Asserted Caller-ID (the number being vouched).
CIDVV does not provide per-call correlation and instead validates reachability within the Validity Window. This may result in multiple calls being validated by a single successful vouch.
The use of distinct response patterns across multiple verification calls (e.g., “100” -> 486 and “101” -> 404) increases resistance to false-positive validation arising from common network behaviors.
CIDVV assumes that:
CIDVV does not assume that Caller-ID values are trustworthy; instead, it verifies control through network reachability.
CIDVV uses short-lived state (typically on the order of seconds) to correlate signaling exchanges. This limits the effectiveness of replay attacks.
Implementations MUST:
Replay within the Validity Window remains theoretically possible but requires
precise timing and routing alignment (see Section
CIDVV prevents spoofing by requiring the party asserting a Caller-ID to successfully receive and respond to a return call routed via the PSTN. An attacker (Mallory) who does not control the corresponding number cannot receive the verification call and therefore cannot complete the vouching process.
CIDVV introduces additional signaling traffic, which may be abused for denial-of-service (DoS) purposes.
Implementations MUST:
Implementations SHOULD:
CIDVV generates return calls as part of its operation. Care MUST be taken to ensure that this behavior cannot be exploited for amplification or reflection attacks.
Implementations SHOULD:
CIDVV does not require specific SIP response codes to be preserved end-to-end, but it does require that distinct rejection behaviors (e.g., “busy” vs. “not found”) remain distinguishable.
Implementations MUST interpret responses based on behavioral class (e.g., “Busy”-class vs. “Not Found”-class) rather than exact numeric values.
CIDVV exchanges inherently expose calling and called numbers within signaling messages.
Implementations SHOULD:
Temporary state MUST be short lived and automatically expired.
Vetting operations use shared secrets and derived tokens.
Implementations MUST:
Implementations SHOULD:
CIDVV implementations MUST fail closed. If verification cannot be completed due to:
the result MUST be treated as unverified.
CIDVV operates across heterogeneous networks, including SIP and SS7/TDM environments. Intermediate systems may:
These behaviors may cause verification to fail but MUST NOT result in false-positive validation.
CIDVV improves resistance to Caller-ID spoofing but does not provide absolute identity assurance. It reduces the effectiveness of spoofing attacks rather than eliminating them and relies on probabilistic verification based on reachability and response behavior, not cryptographic identity binding.
This document has no IANA actions.
— back
The authors thank contributors to telephony security research and PSTN infrastructure development.