



Network Working Group                                        R. Anderson
Internet-Draft                                                S. Berkson
Intended status: Informational             Jolly Roger Telephone Company
Expires: 8 November 2026                                        P. Askew
                                                              7 May 2026


                 Caller-ID Vouching and Vetting (CIDVV)
                     draft-anderson-askew-cidvv-00

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.

About This Document

   This note is to be removed before publishing as an RFC.

   The latest revision of this draft can be found at https://cidvv.org/
   draft-anderson-askew-cidvv.html.  Status information for this
   document may be found at https://datatracker.ietf.org/doc/draft-
   anderson-askew-cidvv/.

   Source for this draft and an issue tracker can be found at
   https://github.com/Jolly-Roger-Telephone-Company/cidvv-spec.







Anderson, et al.         Expires 8 November 2026                [Page 1]

Internet-Draft                    CIDVV                         May 2026


Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 8 November 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Motivation and Advantages . . . . . . . . . . . . . . . .   6
   3.  Design Principles . . . . . . . . . . . . . . . . . . . . . .   7
   4.  Number Normalization  . . . . . . . . . . . . . . . . . . . .   7
     4.1.  Protocol Overview . . . . . . . . . . . . . . . . . . . .   8
     4.2.  Vouching vs. Vetting Response Patterns  . . . . . . . . .  10
     4.3.  Response Semantics  . . . . . . . . . . . . . . . . . . .  10
       4.3.1.  "100" Prefix (Primary Verification) . . . . . . . . .  11
       4.3.2.  "101" Prefix (Secondary Verification) . . . . . . . .  11
       4.3.3.  Combined Verification . . . . . . . . . . . . . . . .  11
       4.3.4.  Failure Handling  . . . . . . . . . . . . . . . . . .  12
   5.  Protocol Operation  . . . . . . . . . . . . . . . . . . . . .  12
     5.1.  Vouching Procedure  . . . . . . . . . . . . . . . . . . .  12
       5.1.1.  Primary Verification ("100")  . . . . . . . . . . . .  12



Anderson, et al.         Expires 8 November 2026                [Page 2]

Internet-Draft                    CIDVV                         May 2026


       5.1.2.  Secondary Verification ("101")  . . . . . . . . . . .  13
       5.1.3.  Combined Verification Behavior  . . . . . . . . . . .  13
     5.2.  Correlation Model . . . . . . . . . . . . . . . . . . . .  14
     5.3.  Hash Function for Vetting and State Storage . . . . . . .  14
       5.3.1.  Multi-Tenant Considerations . . . . . . . . . . . . .  15
     5.4.  Vetting Procedure . . . . . . . . . . . . . . . . . . . .  15
   6.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . .  16
     6.1.  Successful Vouch Call Flow (Baseline) . . . . . . . . . .  16
       6.1.1.  Successful Vouch (Baseline) Step-by-step
               description . . . . . . . . . . . . . . . . . . . . .  17
     6.2.  Successful Vouch Call Flow (Enhanced) . . . . . . . . . .  18
       6.2.1.  Enhanced Successful Vouch Step-by-step description  .  19
     6.3.  Unsuccessful Vouch  . . . . . . . . . . . . . . . . . . .  21
     6.4.  Vetting a Caller-ID Number  . . . . . . . . . . . . . . .  22
       6.4.1.  First Vetting Call  . . . . . . . . . . . . . . . . .  22
       6.4.2.  Second Vetting Call . . . . . . . . . . . . . . . . .  22
       6.4.3.  Successful Caller-ID Vetting Flow . . . . . . . . . .  23
   7.  Deployment Considerations . . . . . . . . . . . . . . . . . .  25
     7.1.  Behavior of Non-CIDVV Systems . . . . . . . . . . . . . .  25
     7.2.  Handling of CIDVV Signaling Calls . . . . . . . . . . . .  25
     7.3.  Response Variability  . . . . . . . . . . . . . . . . . .  25
     7.4.  Short-Term State Management . . . . . . . . . . . . . . .  26
   8.  Operational Considerations  . . . . . . . . . . . . . . . . .  26
     8.1.  Protocol Operation - Vouching . . . . . . . . . . . . . .  26
     8.2.  Failure and Restart Behavior  . . . . . . . . . . . . . .  26
     8.3.  Prefix Preservation . . . . . . . . . . . . . . . . . . .  26
     8.4.  Interaction with Call Analytics and Fraud Detection . . .  26
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  27
     9.1.  Trust Model . . . . . . . . . . . . . . . . . . . . . . .  27
     9.2.  Replay Attacks  . . . . . . . . . . . . . . . . . . . . .  27
     9.3.  Spoofing Resistance . . . . . . . . . . . . . . . . . . .  28
     9.4.  Denial of Service . . . . . . . . . . . . . . . . . . . .  28
     9.5.  Amplification and Reflection  . . . . . . . . . . . . . .  28
     9.6.  Response Code Manipulation  . . . . . . . . . . . . . . .  28
     9.7.  Data Privacy  . . . . . . . . . . . . . . . . . . . . . .  29
     9.8.  Hash-Based Token Security (Vetting) . . . . . . . . . . .  29
     9.9.  Failure Modes . . . . . . . . . . . . . . . . . . . . . .  29
     9.10. Interoperability Risks  . . . . . . . . . . . . . . . . .  29
     9.11. Residual Risk . . . . . . . . . . . . . . . . . . . . . .  29
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  30
   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  30
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  30









Anderson, et al.         Expires 8 November 2026                [Page 3]

Internet-Draft                    CIDVV                         May 2026


1.  Introduction

   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:

   *  Existing routing databases and numbering plans, which provide
      authoritative routing ownership for telephone numbers.

   *  Digit sequences chosen to minimize conflict with valid numbering
      plans (e.g., "100" and "101").

   The mechanism operates entirely within standard PSTN routing behavior
   and requires no media exchange.

2.  Terminology

   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.



Anderson, et al.         Expires 8 November 2026                [Page 4]

Internet-Draft                    CIDVV                         May 2026


   *  *Alice*: The calling party and verifier.  In vouching flows Alice
      asserts a number; in vetting flows Alice verifies Bob's number.

   *  *Bob*: The called party.  In vetting flows Bob is the owner whose
      number is being vetted.

   *  *Mallory*: An attacker attempting to spoof a Caller-ID.

   *  *CIDVV Platform*: A system that implements the vouching and
      vetting procedures defined in this document.

   *  *CIDVV-aware Network Element*: An SBC or intermediary that
      recognizes CIDVV signaling prefixes and interprets associated
      responses, but does not implement the full CIDVV platform logic.

   *  *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 the relevant party controls the Asserted Caller-ID via
      the two-call challenge-response sequence.  Vetting may be
      performed by the number owner directly or on behalf of third
      parties such as Caller-ID branding services, Google Business
      Profiles, trade organizations, or enterprise trust programs.

   *  *Vouching Call*: A short verification call used in the CIDVV
      protocol.  CIDVV defines a primary vouching call ("100") and an
      optional secondary vouching call ("101").

   *  *Successful Vouch*: A verification result indicating that a
      matching cache entry was found.

   *  *Unsuccessful Vouch*: A verification result indicating that no
      matching cache entry was found.

   *  *Verification Not Performed*: A condition where verification could
      not be completed due to system or network conditions.

   *  *Validity Window*: A short time interval during which CIDVV
      signaling state is considered valid for correlation purposes,
      typically on the order of 10 seconds.






Anderson, et al.         Expires 8 November 2026                [Page 5]

Internet-Draft                    CIDVV                         May 2026


   *  *Asserted Caller-ID*: The Caller-ID value that is being vouched or
      vetted (i.e., the number whose control is being verified).  This
      is the value used as the basis for the CIDVV Token payload and as
      the cache lookup key in the tuple (Asserted-Caller-ID, CIDVV-
      Token).

   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.

2.1.  Motivation and Advantages

   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.




Anderson, et al.         Expires 8 November 2026                [Page 6]

Internet-Draft                    CIDVV                         May 2026


   *  *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*:

      -  Enterprises can deploy their own CIDVV platform using open-
         source tools such as Kamailio or Asterisk.

      -  Service providers or third-party vendors (e.g., TransUnion,
         TNS, First Orion, Hiya, Numeracle, Numhub, or others) can
         operate cloud-based vouching and vetting services.

      -  Customers can easily switch between providers, fostering real
         competition and driving down costs.

   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.

3.  Design Principles

   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.

4.  Number Normalization

   All telephone numbers used in CIDVV operations MUST be normalized to
   a digit string as follows:

   1.  Remove any leading "+" or other punctuation.

   2.  Use the full E.164 representation (country code + national
       significant number) as a plain digit string.

   No padding is performed.  Truncation (when required for the 15-digit
   limit) always removes leading digits of the telephone number,
   preserving the rightmost digits.



Anderson, et al.         Expires 8 November 2026                [Page 7]

Internet-Draft                    CIDVV                         May 2026


4.1.  Protocol Overview

   CIDVV uses special Caller-ID prefixes to signal protocol operations:

   *  "100" prefix - Primary Verification Call

   *  "101" prefix - Secondary Verification Call / Vetting Call

   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 Section 4).

   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.



Anderson, et al.         Expires 8 November 2026                [Page 8]

Internet-Draft                    CIDVV                         May 2026


   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:

   *  Calls using the "100" prefix MUST result in SIP 486 Busy Here.
      Any other response, timeout, call progression, or successful call
      completion MUST be treated as an unsuccessful vouch.

   *  Calls using the "101" prefix are expected to result in SIP 404 Not
      Found.  However, in the context of an active vetting procedure, a
      "101" call carrying a valid token MAY result in SIP 486 Busy Here.

   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.



Anderson, et al.         Expires 8 November 2026                [Page 9]

Internet-Draft                    CIDVV                         May 2026


   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.

4.2.  Vouching vs. Vetting Response Patterns

   CIDVV uses the same signaling prefixes for both operations but with
   distinct expected behaviors.  The table below summarizes the
   differences:

   +========+=============+============================+==============+
   | Prefix | Vouching    | Vetting (pre-shared        | Notes        |
   |        | (live call) | secret)                    |              |
   +========+=============+============================+==============+
   | 100    | Expect 486  | Not used                   | Primary      |
   |        | Busy Here   |                            | vouch signal |
   +--------+-------------+----------------------------+--------------+
   | 101    | Expect 404  | First call: 404 (deposit), | Secondary /  |
   |        | Not Found   | Second call: 486           | vetting      |
   +--------+-------------+----------------------------+--------------+

                                 Table 1

   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.

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



Anderson, et al.         Expires 8 November 2026               [Page 10]

Internet-Draft                    CIDVV                         May 2026


4.3.1.  "100" Prefix (Primary 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.

4.3.2.  "101" Prefix (Secondary Verification)

   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.

4.3.3.  Combined Verification

   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:

   *  The "100" verification produces the expected "Busy"-class
      behavior, AND

   *  The "101" verification produces the expected "Not Found"-class
      behavior

   within the Validity Window.

   Implementations MUST NOT require the two verification calls to occur
   in any specific order.




Anderson, et al.         Expires 8 November 2026               [Page 11]

Internet-Draft                    CIDVV                         May 2026


4.3.4.  Failure Handling

   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.

5.  Protocol Operation

5.1.  Vouching Procedure

   Alice's CIDVV platform receives an attempted call from Alice to Bob.
   It MUST construct a CIDVV token as defined in Section Section 4.1 by
   prefixing "100" to the dialed number.

   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.

5.1.1.  Primary Verification ("100")

   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.




Anderson, et al.         Expires 8 November 2026               [Page 12]

Internet-Draft                    CIDVV                         May 2026


   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.

5.1.2.  Secondary Verification ("101")

   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 Section 5.4).

   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.

5.1.3.  Combined Verification Behavior

   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.



Anderson, et al.         Expires 8 November 2026               [Page 13]

Internet-Draft                    CIDVV                         May 2026


   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.

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

   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.

5.3.  Hash Function for Vetting and State Storage

   The same deterministic algorithm MUST be used for: 1.  Vetting token
   computation. 2.  Any short-term cache (e.g., Redis) that stores
   vouching or vetting state.

   *Algorithm (normative)*

   1.  Normalize both numbers: E.164 digit string, no leading "+", no
       punctuation (see Section Section 4).

   2.  Concatenate as UTF-8 bytes: normalized-calling-number || "|" ||
       normalized-called-number || "|" || shared-secret

   3.  Compute SHA-256 digest of the concatenated bytes.

   4.  Take the first 8 hexadecimal characters of the digest.

   5.  Convert that 8-hex string to a decimal integer.

   6.  Left-pad with zeros to 10 digits if needed, then prepend '1' to
       produce an 11-digit token.

   Example (for illustration only): - calling = 12125550100, called =
   19495550199, secret = "hamburger" - Concatenated:
   "12125550100|19495550199|hamburger" - SHA-256 first 8 hex -> decimal
   -> padded/prepended token = 12953388433 (or similar)



Anderson, et al.         Expires 8 November 2026               [Page 14]

Internet-Draft                    CIDVV                         May 2026


   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.

5.3.1.  Multi-Tenant Considerations

   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.

5.4.  Vetting Procedure

   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 Section 5.3 and store the resulting token for the
   Validity Window.  It then rejects the call with SIP response 404 (Not
   Found).

   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.





Anderson, et al.         Expires 8 November 2026               [Page 15]

Internet-Draft                    CIDVV                         May 2026


   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.

6.  Examples

6.1.  Successful Vouch Call Flow (Baseline)

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

               Figure 1: Example Successful Vouch (Baseline)

   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.







Anderson, et al.         Expires 8 November 2026               [Page 16]

Internet-Draft                    CIDVV                         May 2026


6.1.1.  Successful Vouch (Baseline) 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 and CIDVV-aware elements.

   1.   The originating user (Alice, Caller-ID +12125550100) initiates a
        call to the destination user (Bob, dialed number +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*:

        *  Constructs a CIDVV token by prefixing "100" to the rightmost
           12 digits of the dialed number.  In this case, the payload is
           19495550199, resulting in the token 10019495550199.

        *  Caches the call attempt using the tuple: (Called:
           +12125550100, Token: 10019495550199) for the Validity Window.

        *  Rejects the call with *486 Busy Here*.

   4.   Alice's SBC receives the 486 and advances the original call
        toward the PSTN using the original Caller-ID.

   5.   The call reaches Bob's SBC via the PSTN.

   6.   *Bob's SBC (CIDVV-aware element)*:

        *  Constructs the same CIDVV token by prefixing "100" to the
           rightmost 12 digits of the dialed number (+19495550199),
           resulting in 10019495550199.

        *  Initiates a verification call toward Alice's number
           (+12125550100) using the Caller-ID 10019495550199.

   7.   The verification call arrives at Alice's SBC via the PSTN.

   8.   *Alice's SBC*:

        *  Detects the leading "100" prefix on the Caller-ID.

        *  Routes the call to CIDVV_A for vouch verification.

   9.   *CIDVV_A*:

        *  Receives the call with: To: +12125550100 From: 10019495550199



Anderson, et al.         Expires 8 November 2026               [Page 17]

Internet-Draft                    CIDVV                         May 2026


        *  Looks up the tuple: (Called: +12125550100, Token:
           10019495550199) cached for the Validity Window.

        *  Finds a matching entry from step 3.

        *  Considers this a successful primary verification and returns
           *486 Busy Here*.

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

   11.  Bob's telephone rings.

   This mechanism allows the originating CIDVV platform to confirm that
   the Asserted Caller-ID is valid without completing the initial call.

6.2.  Successful Vouch Call Flow (Enhanced)

   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.






















Anderson, et al.         Expires 8 November 2026               [Page 18]

Internet-Draft                    CIDVV                         May 2026


      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.

6.2.1.  Enhanced Successful Vouch Step-by-step description

   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.

   1.   The originating user (Alice, Caller-ID +12125550100) initiates a
        call to the destination user (Bob, dialed number +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*:






Anderson, et al.         Expires 8 November 2026               [Page 19]

Internet-Draft                    CIDVV                         May 2026


        *  Constructs a CIDVV token by prefixing "100" to the rightmost
           12 digits of the dialed number (19495550199), resulting in
           10019495550199.

        *  Caches the call attempt using the tuple: (Called:
           +12125550100, Token: 10019495550199) for the Validity Window.

        *  Rejects the call with *486 Busy Here*.

   4.   Alice's SBC receives the 486 and advances the original call
        toward the PSTN using the original Caller-ID.

   5.   The call reaches Bob's SBC via the PSTN.

   6.   *Bob's SBC (CIDVV-aware element)*:

        *  Constructs the CIDVV token 10019495550199.

        *  Initiates a primary verification call toward Alice's number
           (+12125550100) using the Caller-ID 10019495550199.

   7.   The primary verification call arrives at Alice's SBC via the
        PSTN.

   8.   *Alice's SBC*:

        *  Detects the leading "100" prefix.

        *  Routes the call to CIDVV_A for verification.

   9.   *CIDVV_A*:

        *  Looks up (Called: +12125550100, Token: 10019495550199) cached
           for the Validity Window

        *  Finds a matching entry.

        *  Rejects the call with SIP response *486 Busy Here*.

   10.  Bob's SBC receives the 486 and recognizes a successful primary
        verification.

   11.  *Bob's SBC (optional secondary verification)*: - Constructs a
        second CIDVV token by prefixing "101" to the same 12-digit
        payload, resulting in 10119495550199.  - Initiates a secondary
        verification call toward Alice's number using the Caller-ID
        10119495550199.




Anderson, et al.         Expires 8 November 2026               [Page 20]

Internet-Draft                    CIDVV                         May 2026


   12.  The secondary verification call arrives at Alice's SBC via the
        PSTN.

   13.  *Alice's SBC*: - Detects the leading "101" prefix.  - Routes the
        call to CIDVV_A for processing.

   14.  *CIDVV_A*: - Receives the call with: To: +12125550100 From:
        10119495550199 - Performs no matching cache lookup for this
        prefix in the vouching context.  - Rejects the call with *404
        Not Found*.

   15.  Bob's SBC receives the 404 and recognizes the expected secondary
        verification behavior.

   16.  Having observed:

        *  "100" -> 486, and

        *  "101" -> 404 within the Validity Window,

        Bob's SBC treats this as a higher-assurance successful vouch.

   17.  Bob's SBC advances the original call to Bob's User Agent.

   18.  Bob's telephone rings.

6.3.  Unsuccessful Vouch

   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.

   *  If both verification calls are performed, and the expected pattern
      of:

      -  "100" -> 486, and

      -  "101" -> 404 is not observed within the Validity Window, the
         vouch MUST be treated as unsuccessful or indeterminate.

   *  A "101" verification result alone MUST NOT be treated as evidence
      of a successful vouch.





Anderson, et al.         Expires 8 November 2026               [Page 21]

Internet-Draft                    CIDVV                         May 2026


   Implementations MUST fail closed.  Any ambiguity, unexpected
   response, timeout, or call progression MUST result in an unsuccessful
   or indeterminate outcome.

6.4.  Vetting a Caller-ID Number

   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.

6.4.1.  First Vetting Call

      CIDVV_A        SBC_A          PSTN         SBC_B        CIDVV_B
         |             |             |             |             |
         |-- VFY101 -->|             |             |             |
         |             |-- VFY101 -->|             |             |
         |             |             |-- VFY101 -->|             |
         |             |             |             |-- VFY101 -->|
         |             |             |             |             |
         |             |             |             |<--- 404 ----|
         |             |             |<--- 404 ----|             |
         |             |<--- 404 ----|             |             |
         |<--- 404 ----|             |             |             |
         |             |             |             |             |

      Figure 2: First vetting call with 101 - creates cache entry and
                             responds with 404

6.4.2.  Second Vetting Call

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

     Figure 3: Vetting token check call with 101 - confirms vouch with
                               486 Busy Here






Anderson, et al.         Expires 8 November 2026               [Page 22]

Internet-Draft                    CIDVV                         May 2026


6.4.3.  Successful Caller-ID Vetting Flow

   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.

   1.   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).

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

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

   4.   Bob's SBC recognizes the leading 101 prefix on the incoming
        Caller-ID and forwards the call to Bob's CIDVV platform
        (CIDVV_B).

   5.   *CIDVV_B*:

        *  Strips the leading 101, recovering Alice's Caller-ID.

        *  For matching purposes, CIDVV_B MAY use only the rightmost 12
           digits of the Caller-ID, consistent with CIDVV payload
           constraints.

        *  Recognizes this as a pre-agreed Vetting Caller-ID

        *  Computes the SHA-256 digest over the UTF-8 string formed by
           concatenating normalized-calling-number, normalized-called-
           number, and shared-secret, where telephone numbers are
           represented as digit strings without separators or leading
           "+".

        *  Takes the first 8 hexadecimal characters (b0092191), converts
           to decimal (2953388433), pads to 10 digits, and prepends 1,
           yielding 12953388433.

        *  Caches this value for the Validity Window.

        *  Rejects the call with *404 Not Found*.





Anderson, et al.         Expires 8 November 2026               [Page 23]

Internet-Draft                    CIDVV                         May 2026


   6.   CIDVV_A receives the 404 and performs the identical hash
        calculation to derive 12953388433.

   7.   CIDVV_A immediately places a second vetting call to +19495550199
        using the Vetting Token Check Caller-ID 10112953388433.

   8.   Bob's SBC recognizes the 101 prefix on the Caller-ID and
        forwards the call to CIDVV_B.

   9.   *CIDVV_B*:

        *  Strips the leading 101.

        *  Observes that the remaining Caller-ID (12953388433) matches a
           recently cached vetting token.

        *  Responds with *486 Busy Here* to signal a successful vet.

   10.  CIDVV_A receives the 486 Busy Here and reports a successful vet
        to Alice.

   Use of the rightmost 12 digits is sufficient because collisions
   within the Validity Window are expected to be rare.

6.4.3.1.  Vetting Failure Cases

   A vetting attempt may fail for the following reasons:

   *  Bob does not have a participating CIDVV platform - the first call
      will not return 404, or the second call will not return 486.

   *  The shared secret, Alice's vetting Caller-ID, or time window does
      not match - the two calls will not produce the expected 404 + 486
      sequence.

   *  Network or policy restrictions prevent one or both calls from
      reaching the remote CIDVV platform.

   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.







Anderson, et al.         Expires 8 November 2026               [Page 24]

Internet-Draft                    CIDVV                         May 2026


7.  Deployment Considerations

7.1.  Behavior of Non-CIDVV Systems

   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 Section 4.1 for response patterns).

7.2.  Handling of CIDVV Signaling Calls

   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.

7.3.  Response Variability

   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.











Anderson, et al.         Expires 8 November 2026               [Page 25]

Internet-Draft                    CIDVV                         May 2026


7.4.  Short-Term State Management

   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 Section 5.3 MUST be used for any vetting-related state.

8.  Operational Considerations

8.1.  Protocol Operation - Vouching

   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.

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

8.3.  Prefix Preservation

   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.

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




Anderson, et al.         Expires 8 November 2026               [Page 26]

Internet-Draft                    CIDVV                         May 2026


   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.

9.  Security Considerations

   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.

9.1.  Trust Model

   CIDVV assumes that: - The PSTN routes calls to the correct
   terminating service provider for a given telephone number. - The
   terminating service provider has authoritative control over the
   number and can originate return calls. - Intermediate networks may
   modify signaling but will generally preserve sufficient information
   to allow correlation of requests and responses.

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

9.2.  Replay Attacks

   CIDVV uses short-lived state (typically on the order of seconds) to
   correlate signaling exchanges.  This limits the effectiveness of
   replay attacks.






Anderson, et al.         Expires 8 November 2026               [Page 27]

Internet-Draft                    CIDVV                         May 2026


   Implementations MUST: - Expire cached state quickly (e.g., within ~10
   seconds) - Reject verification attempts that do not match recent
   state

   Replay within the Validity Window remains theoretically possible but
   requires precise timing and routing alignment (see
   Section Section 5.3 for vetting tokens).

9.3.  Spoofing Resistance

   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.

9.4.  Denial of Service

   CIDVV introduces additional signaling traffic, which may be abused
   for denial-of-service (DoS) purposes.

   Implementations MUST: - Rate-limit CIDVV signaling requests - Detect
   and suppress repeated unsuccessful attempts - Bound resource usage
   for temporary state

   Implementations SHOULD: - Apply per-source and per-destination limits
   - Monitor for anomalous traffic patterns

9.5.  Amplification and Reflection

   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: - Only initiate return calls in response to
   valid inbound attempts - Limit the rate of outbound verification
   calls - Avoid generating multiple responses for a single triggering
   event

9.6.  Response Code Manipulation

   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.



Anderson, et al.         Expires 8 November 2026               [Page 28]

Internet-Draft                    CIDVV                         May 2026


9.7.  Data Privacy

   CIDVV exchanges inherently expose calling and called numbers within
   signaling messages.

   Implementations SHOULD: - Avoid storing telephone numbers in
   plaintext where possible - Use derived values (e.g., cryptographic
   hashes) for temporary state - Limit retention of any identifying data

   Temporary state MUST be short lived and automatically expired.

9.8.  Hash-Based Token Security (Vetting)

   Vetting operations use shared secrets and derived tokens.

   Implementations MUST: - Use cryptographically secure hash functions
   (e.g., SHA-256) - Protect shared secrets from disclosure - Ensure
   tokens are valid only within the Validity Window

   Implementations SHOULD: - Include sufficient entropy in derived
   tokens - Avoid predictable or reusable values

9.9.  Failure Modes

   CIDVV implementations MUST fail closed.  If verification cannot be
   completed due to: - network errors - state loss - unexpected
   responses

   the result MUST be treated as unverified.

9.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 signaling behavior

   These behaviors may cause verification to fail but MUST NOT result in
   false-positive validation.

9.11.  Residual Risk

   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.





Anderson, et al.         Expires 8 November 2026               [Page 29]

Internet-Draft                    CIDVV                         May 2026


10.  IANA Considerations

   This document has no IANA actions.

Appendix A.  Acknowledgments

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

Authors' Addresses

   Roger Anderson
   Jolly Roger Telephone Company
   United States of America
   Email: roger@jollyrogertelephone.com


   Steven Berkson
   Jolly Roger Telephone Company
   United States of America
   Email: steveb@jollyrogertelephone.com


   Phillip Askew
   United States of America
   Email: phillip.askew@theaskewcrew.com

























Anderson, et al.         Expires 8 November 2026               [Page 30]
