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

[Henning Schulzrinne <[e-mail]>]

Verifying that you (carrier) has assigned a number to a customer (A
attestation) seems much simpler than verifying that the company is
authorized to use a particular DBA trade name. Anybody can submit a
corporate registration PDF - proving that this is your company is
unfortunately harder. (Much of this could be simplified if the state
secretaries were to provide the equivalent of proof-of-control in ACME, but
that's a separate issue.)

On Wed, Oct 8, 2025 at 1:19 AM Roman Shpount <[e-mail]> wrote:

> 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
> ZjQcmQRYFpfptBannerStart
>
> ZjQcmQRYFpfptBannerEnd
> 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://urldefense.com/v3/__https://www.numeracle.com/__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxNBXJUgl$>
>>
>> Empowering Calls with
>> Identity Management
>> <https://urldefense.com/v3/__https://www.numeracle.com/insights/entity-identity-management-to-empower-your-calls__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxGDI1Gsq$>
>>
>>
>>
>> * 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://urldefense.com/v3/__https://aka.ms/LearnAboutSenderIdentification__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxHkIpe8T$>
>> 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
>> <https://urldefense.com/v3/__http://www.shockey.us/__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxLLsp087$>
>>
>> www.sipforum.org
>> <https://urldefense.com/v3/__http://www.sipforum.org/__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxJnbiopn$>
>>
>> richard<at>shockey.us
>> <https://urldefense.com/v3/__http://shockey.us/__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxDCzfs2p$>
>>
>> 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
>> <https://urldefense.com/v3/__https://docs.fcc.gov/public/attachments/DOC-415059A1.pdf__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxAnK5mca$>
>>
>>
>> Richard Shockey
>> Shockey Consulting LLC
>> Chairman of the Board SIP Forum
>> www.shockey.us
>> <https://urldefense.com/v3/__http://www.shockey.us/__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxLLsp087$>
>>  <http://www.shockey.us
>> <https://urldefense.com/v3/__http://www.shockey.us/__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxLLsp087$>
>> >
>> www.sipforum.org
>> <https://urldefense.com/v3/__http://www.sipforum.org/__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxJnbiopn$>
>>
>> richard<at>shockey.us
>> <https://urldefense.com/v3/__http://shockey.us/__;!!BDUfV1Et5lrpZQ!QDrvH8RGmwgdq0eGUrODxeCbQzE9qRykBPR4UctnUWg8MFJgbte4yU8MWTx2VyUeS30HYLsbxDCzfs2p$>
>> 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]
>>
>> _______________________________________________
> art mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>