[stir] Re: [art] Re: For those of you who follow this kind of stuff.

[Roman Shpount <[e-mail]>]

Brett,

FCC was very deliberate in not specifying the KYC requirements. This being
said, all carriers introducing traffic to the US phone network should have
a KYC policy described in the RMD database. Carriers that did not provide
an adequate policy have been removed from the RMD database and are no
longer permitted to originate traffic. Additionally, if, as a carrier, I
can set the A-level attestation for the call based on my KYC policy, I
should be able to specify the Rich Call Data accordingly, especially if
this is required when A-level attestation is provided.

I have a strong feeling that certain providers care more about creating new
sources of revenue for themselves through regulatory arbitrage than about
creating a healthy infrastructure to prevent robocalls. A glaring example
is iConnectiv providing SPC tokens, but not the signing certificates, which
artificially creates business for specialized certificate authorities.
Ironically, this business opportunity is so small and labour-intensive that
no one actually wants to do it, trying to shepherd carriers towards the
hosted signing solution.

To summarize, if, as a carrier, I am entrusted with an SPC token, I should
be trusted to provide the Rich Call Data. If I am not trusted to provide
Rich Call Data into the network, I should not be introducing any traffic
into it. If the FCC mandates Rich Call Data, it should mandate that
carriers accept it without creating walled gardens, with each carrier
charging a fee to actually accept the data.

Finally, if we intend to mandate the transmission of personally
identifiable data with every call, we need to update SIP with a scalable
and secure transport protocol. Most current carrier SIP implementations
still use UDP. SIP-over-TLS suffers from head-of-the-line congestion
issues. SIP is in dire need of a secure datagram-based protocol, such as
QUIC. I am surprised that no one from the STIR group brought this to the
SIPCore, so that a more scalable and secure protocol capable of carrying
Rich Call Data could be standardized.

Best Regards,
_____________
Roman Shpount


On Tue, Oct 7, 2025 at 8:42 PM Brett Nemeroff <[e-mail]>
wrote:

> Hello Roman,
>
> In my opinion, US Carriers are unlikely to accept vanilla RCD data because
> of the lack of defined KYC.  RCD is a very good vehicle for delivering the
> RCD, but it depends upon implicit trust of the originating service
> provider. “Vanilla” RCD offered like this to terminating service providers
> gives no assurance to the terminating service provider that the originator
> performed any specific KYC.
>
> CTIA’s BCID is based on RCD but details an ecosystem with specific KYC
> requirements. Participating in this ecosystem will allow for the delivery
> and native presentation of RCD.
>
> It’s worth noting that without a defined ecosystem for RCD such as BCID,
> RCD provides little (trust)  benefit over traditional CNAM other than the
> fingerprints of the originating service provider for enforcement purposes.
>
> -Brett
>
>
>
> Brett Nemeroff
> VP of Engineering - Voice
> [e-mail] <%7BE-mail%7D> | 1-512-203-3884
>
> [image: Logo.png] <https://www.numeracle.com/>
>
> Empowering Calls with
> Identity Management
> <https://www.numeracle.com/insights/entity-identity-management-to-empower-your-calls>
>
>
>
> * CONFIDENTIAL From: *Roman Shpount <[e-mail]>
> *Date: *Tuesday, October 7, 2025 at 7:24 PM
> *To: *Richard Shockey <[e-mail]>
> *Cc: *IETF STIR Mail List <[e-mail]>, [e-mail] <[e-mail]>
> *Subject: *[stir] Re: [art] Re: For those of you who follow this kind of
> stuff.
>
> You don't often get email from [e-mail]. Learn why this is
> important <https://aka.ms/LearnAboutSenderIdentification>
> In my day job, I see a lot of robocalls coming through the LEC local
> switches as TDM, as local re-origination with spoofed ANI.
>
> I would also love to sign Rich Call Data with my SPC token and not have
> wireless carriers discard this data. If I provide the information about my
> customer, I am unsure why I need to pay someone else to sign this
> information.
> _____________
> Roman Shpount
>
>
> On Tue, Oct 7, 2025 at 8:11 PM Richard Shockey <[e-mail]> wrote:
>
>
>
> It wont . You mean the legacy TDM/SS7 crap…this is the beginning of
> mandating all SIP in the US realtime US voice network as the British have
> done.
>
>
>
> I would not want to own a Tandem Access network.
>
>
>
> The US industry is pretty clear on this.  You only need to read the FCC
> 17-97 docket at the FCC ECFS website to understand where the players
> actually are.
>
>
>
> This again is my day job.
>
>
>
>
>
> Richard Shockey
>
> Shockey Consulting LLC
>
> Chairman of the Board SIP Forum
>
> www.shockey.us
>
> www.sipforum.org
>
> richard<at>shockey.us
>
> Skype-Linkedin-Facebook –Twitter  rshockey101
>
> PSTN [phone]
>
>
>
>
>
> *From: *Roman Shpount <[e-mail]>
> *Date: *Tuesday, October 7, 2025 at 7:37 PM
> *To: *Richard Shockey <[e-mail]>
> *Cc: *IETF STIR Mail List <[e-mail]>, <[e-mail]>
> *Subject: *[art] Re: [stir] For those of you who follow this kind of
> stuff.
>
>
>
> How would this work with PSTN links?
>
> _____________
> Roman Shpount
>
>
>
>
>
> On Tue, Oct 7, 2025 at 6:59 PM Richard Shockey <[e-mail]> wrote:
>
>
> The United States government is going to mandate Rich Call Data in the
> network.
>
> https://docs.fcc.gov/public/attachments/DOC-415059A1.pdf
>
>
> Richard Shockey
> Shockey Consulting LLC
> Chairman of the Board SIP Forum
> www.shockey.us <http://www.shockey.us>
> www.sipforum.org
>
> richard<at>shockey.us
> Skype-Linkedin-Facebook –Twitter rshockey101
> PSTN [phone]
>
>
>
>
>
>
> _______________________________________________
> stir mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________ art mailing list --
> [e-mail] To unsubscribe send an email to [e-mail]
>
>