[sipnoc25-attendees] BOF - Today’s Real-World Obstacles & Speed Bumps

Wed Sep 17 14:49:29 UTC 2025

Thanks to all of you who attended our great BoF last night on current pain points in STIR/SHAKEN Authentication, or Verification, or other related factors.

Here's a summary of items that were mentioned:

- Risk associated with using a single certificate across multiple lines of business, leading to decisions to break up certificates by business unit to mitigate exposure.

- Implementation friction for small providers, including complexity and high costs.

- High implementation costs for large providers, with a sense of limited value to the business. 

- STIR/SHAKEN requirements and policies keep changing, leading to ongoing development costs and difficulty securing internal buy-in for continuous projects.)

- Challenges in performing reasonable Know Your Customer (KYC) processes, with a need for standardized guidelines.

- Absence of official KYC guidelines, making accurate attestation challenging, especially for providers with many business lines.

- Difficulty re-KYCing existing business customers to determine connections and usage.

- Navigating whether customers should sign calls themselves versus the provider signing on their behalf. (It's like we're stuck at a "midway" point where carriers do the authentication, rather than pushing authentication to the edge.)

- Wholesale providers who were able to do Third-Party Signing in the past are changing attestation policies (e.g., from A to B to C for unsigned calls from resellers), leading to ongoing painful customer conversations.

- Customers unable to obtain an Operating Company Number (OCN) or file Form 499, complicating compliance.

- Voice Providers being asked to give legal advice to customers, which they cannot provide.

- Complexity of international STIR/SHAKEN implementations, including variations in policy and requirements. (Generally touches providers subject to Canadian, French, Brazilian differences, etc.). Inability to implement the same STIR/SHAKEN approach uniformly across every country.

- New display delegation specifications requiring delegation of ownership and rights to display numbers in a centralized database, which arrived unexpectedly and are complicated.

- Improper use of attestation levels (e.g., blindly signing with A attestation), leading to issues like impersonation.

- Lack of a governing or reporting mechanism in the ecosystem for improper attestations. (Can STI-GA really handle tracking feedback information for every provider who's consistently not signing properly?)

- Loose relationships in reselling voice services, where downstream entities do not view themselves as offering VoIP services for sale.

- Customers viewing themselves as software providers (e.g., CRM with call integration) rather than telecom providers, leading to resistance in obtaining OCNs, filing forms, or implementing KYC.

- Multiple interpretations of attestation levels, originally intended as a simplification but becoming a default with honor system issues.

- False sense of security from A-level attestation, which may not indicate a safe call.

- Long, drawn-out process for defining delegation (e.g., lemon drop or twist proposals), with initial expectations of delegate certificates not materializing, requiring future re-implementation.

- Different interpretations of passport formats (e.g., E.164 numbers vs. 10-digit or +1 prefixes), causing verification failures due to number normalization in transit.

- Limited usefulness of attestation in official U.S. tracebacks, as they require hop-by-hop information rather than direct use of signer data. (Why doesn't the Industry Traceback Group ITG rely more on the certificate?)

- Unfair "one neck to choke" burden on providers signing unsigned traffic with C attestation, making them the primary traceback point.

- Challenges in using analytics for automated tracebacks (e.g., via SNMP traps), due to political and technical hurdles.

- Spam labeling of legitimate calls (e.g., Social Security Administration or U.S. Air Force campaigns), sometimes due to incomplete SIP implementations or backup TDM gateways.

- Enterprises wanting to sign calls but lacking software support (e.g., Asterisk or Kamailio not supporting Rich Call Data (RCD)).

- Friction with Canadian implementations, including handling Canadian certs, operations with international traffic, and differences in attestation preferences (e.g., U.S. aversion to B attestation).

- Lack of belief among some service providers that they need to take action, especially small ones accustomed to third-party signing.

- Difficulty for small providers in monitoring FCC press releases or notices, leading to last-minute awareness of changes.

- Challenges identifying affected customers in FCC notices or Robocall Mitigation Database (RMD) removals, due to lack of identifiers like addresses or OCNs.

- Need for additional identifiers (e.g., RMD IDs) in customer CRMs to track compliance. E.g., "Zoom Co" was removed from Robocall mitigation Database (RMD) but it can be hard to tell "which one."

- Call forwarding scenarios, including non-traditional forwards where an inbound leg triggers an outbound leg with "spoofed"  (reused) numbers, causing attestation issues because it took several seconds and allowed the PASSporT validity to expire. Time delays in forwarding (e.g., via mini-IVR or auto-attendants), making timestamps too old and leading to verification failures.

- Decisions on reusing identity headers in forwarding vs. dropping and re-signing with C, potentially causing confusion (e.g., Verizon receiving a Verizon number coming in with Bandwidth C attestation).

- Lack of full solutions for customers whose only outbound use case is redirects or forwarding, who resist implementing STIR/SHAKEN.

- Differences in handling forwards in IMS environments vs. others that change the B-number or URI, leading to failures.

- Complexity in transiting traffic without modifying identity headers, especially when malformed, leading to "garbage in, garbage out" issues.

- Third-party signing software configured only for one attestation level, requiring re-implementation to handle multiple levels.

- Potential future friction from short-lived certificates and Online Certificate Status Protocol (OCSP), if made mandatory, adding complexity for many providers.

Don't forget you can signup for our iPad drawing and get my report on integrating SIP providers with cloud developers! We'll be giving it away at SIPNOC before lunch on Thursday.
https://info.ecg.co/sipnoc-2025-ipad-entry

Mark R Lindsey | +1-229-316-0013 | mrl at ecg.co <mailto:mrl at ecg.co> | LinkedIn <https://www.linkedin.com/in/markrlindsey/>

> On Sep 11, 2025, at 11:52, Mark R Lindsey, ECG <lindsey at e-c-group.com> wrote:
> 
> Proposed Tuesday-Evening BOF (informal special interest meeting): 
> What are the real-world frictions experienced in implementing, and maintaining, Authentication and Verification by voice service providers today?
> Assuming those obstacles can be overcome, it would be nice to hear where the greatest pain points were so the industry can help smooth the process. 
> There’s a ton of new activity because of the changes in third party authentication - mostly from very small service providers 
> Vendors and smaller Service Providers would have great insight
> 
> —
> Mark R Lindsey
> Member of Technical Staff / VP
> +1-229-316-0013
> https://info.ecg.co/lindsey

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.sipforum.org/pipermail/sipnoc25-attendees/attachments/20250917/f333ba6a/attachment-0001.html>