[VoiceOps] Voice Peering

[Michael Graves]

The FCC Robocall Mitigation Database could be that database. It would need to be cleaned up.

It’s supposed to be a gate mechanism.

Michael Graves
mgraves at mstvp.com<mailto:mgraves at mstvp.com>
o: (713) 861-4005
c: (713) 201-1262
sip:mgraves at mjg.onsip.com

From: VoiceOps <voiceops-bounces at voiceops.org> On Behalf Of Pinchas Neiman via VoiceOps
Sent: Wednesday, October 25, 2023 11:54 AM
To: Matthew Crocker <matthew at corp.crocker.com>
Cc: voiceops <voiceops at voiceops.org>
Subject: Re: [VoiceOps] Voice Peering

And a pool of peers trusting themselves, could establish a mutual database where they could award or revoke trust to companies or CAs.

Then other peers could follow them read only.

On Wed, Oct 25, 2023 at 12:07 PM Matthew Crocker <matthew at corp.crocker.com<mailto:matthew at corp.crocker.com>> wrote:

I never said STIR/SHAKEN would be used to ‘look up’ for call routing.

Earlier someone mentioned an issue with open peering is spam calls.  STIR/SHAKEN can solve that issue.

You can certainly use STIR/SHAKEN to reject calls from $COMPANY once you have determined you don’t like $COMPANY.  That can easily be done off line by CDR analysis.  Sure you let a couple dozen calls in but you can pretty quickly find ‘$BAD_COMPANY’ and start rejecting their calls.   The system would settle our fairly quickly

From: Peter Beckman <beckman at angryox.com<mailto:beckman at angryox.com>>
Date: Wednesday, October 25, 2023 at 12:04 PM
To: Matthew Crocker <matthew at corp.crocker.com<mailto:matthew at corp.crocker.com>>
Cc: Pinchas Neiman <neimanpinchas at gmail.com<mailto:neimanpinchas at gmail.com>>, Jawaid Bazyar <jawaid at bazyar.net<mailto:jawaid at bazyar.net>>, voiceops <voiceops at voiceops.org<mailto:voiceops at voiceops.org>>
Subject: Re: [VoiceOps] Voice Peering
CAUTION: This email originated from outside of Crocker. Do not click links or open attachments unless you recognize the sender and know the content is safe.


STIR/SHAKEN does not delegate any authority to anyone.

It merely allows me to sign a call that I originate, so that someone else
can say "Oh this came from $COMPANY."

Besides, STIR/SHAKEN is done at the time of an origination call, it cannot
be "looked up" to see where to route a call.

The suggestion that STIR/SHAKEN could be used to authoritatively assign a
DID endpoint to someone demonstrates a lack of understanding in how it
works and what it does and does not do.

Beckman

On Wed, 25 Oct 2023, Matthew Crocker via VoiceOps wrote:

>
> With STIR/SHAKEN (in theory) all calls will be signed, authenticated so you can trace the originating carrier.  In an open peering environment you can use it to accept/reject calls
>
> Open SIP proxy handles all of the SIP traffic,  RTP goes directly between carriers.
> All calls originated must be signed (STIRred)
>
>  *   Call isn’t signed, gets rejected by the SIP peering proxy
> Terminating carrier can validate the signed calls (SHAKEN)
>
>  *   Don’t like the signing CA?  reject the call
>  *   Don’t like the signing carrier? Reject the call
>  *   Carrier sending too many spam calls,  adjust treatment based on customer spam settings
>
>
> Routing is handled between terminating carrier and SIP peering proxy.  Originating carrier sends all calls to peering proxy first, if proxy doesn’t have the route it sends a 4XX error back and originating carrier can continue routing on other paths.
>
> So terminating carriers would need to export/upload (hacked BGP?) numbers they are willing to receive calls on to the peering proxy.
>
> Proxies can be spun up in various AWS/Azure/GoogleCloud VPS
>
>
> From: Pinchas Neiman <neimanpinchas at gmail.com<mailto:neimanpinchas at gmail.com>>
> Date: Wednesday, October 25, 2023 at 11:18 AM
> To: Jawaid Bazyar <jawaid at bazyar.net<mailto:jawaid at bazyar.net>>
> Cc: Matthew Crocker <matthew at corp.crocker.com<mailto:matthew at corp.crocker.com>>, voiceops <voiceops at voiceops.org<mailto:voiceops at voiceops.org>>
> Subject: Re: [VoiceOps] Voice Peering
> CAUTION: This email originated from outside of Crocker. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>
> By reading the RFCs I was able to grasp 75% of it, it's well written and covers your clear constraint, at least on how to verify the SIP header comes from a trustworthy authority (If you agree on the root authority)
> Practically implementing STIR/SHAKEN has bureaucracy involved.
>
> On Tue, Oct 24, 2023 at 9:38 PM Jawaid Bazyar via VoiceOps <voiceops at voiceops.org<mailto:voiceops at voiceops.org><mailto:voiceops at voiceops.org<mailto:voiceops at voiceops.org>>> wrote:
> Is there a good clear document somewhere describing how STIR/SHAKEN is supposed to work?
>
> On Tue, Oct 24, 2023 at 9:33 PM Matthew Crocker via VoiceOps <voiceops at voiceops.org<mailto:voiceops at voiceops.org><mailto:voiceops at voiceops.org<mailto:voiceops at voiceops.org>>> wrote:
>
>
>> On Oct 24, 2023, at 9:13 PM, Peter Beckman via VoiceOps <voiceops at voiceops.org<mailto:voiceops at voiceops.org><mailto:voiceops at voiceops.org<mailto:voiceops at voiceops.org>>> wrote:
>>
>> CAUTION: This email originated from outside of Crocker. Do not click links or open attachments unless you recognize the sender and know the content is safe.
>>
>>
>> The challenge is how do you authenticate the end "carrier" or service
>> provider?
>>
>
> STIR/SHAKEN
>
>
>> Sure, anyone who leases numbers directly from NANPA can look up the carrier
>> of record and exchange traffic directly, but any business who also leases
>> numbers INDIRECTLY gets cut out and still needs to pay their upstream
>> carrier(s) to place/receive calls, either by channels or per minute, even
>> if their upstream is directly peered and not transiting the PSTN at all.
>>
>> If this would be for the end user, then NANPA would have to delegate to the
>> leasee, the leasee delegate to the reseller, the reseller to the end user,
>> then the end user could publish their VoIP contact info, and anyone could
>> call directly via VoIP, cutting out all of the middle peers.
>>
>> But, as another person said, this is ripe for abuse, and with no motivation
>> by NANPA or the larger carriers to make calls less expensive for the
>> reseller or end user, I see this going nowhere. Until there is some value
>> in NANPA (plus all the other country telephony organizations) and the
>> direct carriers leasing numbers to do so.
>>
>> Beckman
>>
>>> On Tue, 24 Oct 2023, Ross Tajvar via VoiceOps wrote:
>>>
>>> I can think of a few ways that could be adapted into a platform more like
>>> an Internet exchange, but as others have said, it just doesn't seem worth
>>> it.
>>>
>>> On Tue, Oct 24, 2023, 5:31 PM Jawaid Bazyar via VoiceOps <
>>> voiceops at voiceops.org<mailto:voiceops at voiceops.org><mailto:voiceops at voiceops.org<mailto:voiceops at voiceops.org>>> wrote:
>>>
>>>> I think schemes like DUNDI (and some of the others mentioned here) suffer
>>>> from a trust issue – what’s to prevent operator X from poisoning the
>>>> protocol with bogus “stolen” numbers?
>>>>
>>>>
>>>>
>>>> On Tue, Oct 24, 2023 at 5:25 PM Jared Smith via VoiceOps <
>>>> voiceops at voiceops.org<mailto:voiceops at voiceops.org><mailto:voiceops at voiceops.org<mailto:voiceops at voiceops.org>>> wrote:
>>>>
>>>>> On Tue, Oct 24, 2023 at 8:49 AM Mike Hammett via VoiceOps <
>>>>> voiceops at voiceops.org<mailto:voiceops at voiceops.org><mailto:voiceops at voiceops.org<mailto:voiceops at voiceops.org>>> wrote:
>>>>>
>>>>>> This was in another thread, but I broke it out into it's own
>>>>>> conversation. Someone had asked:
>>>>>>
>>>>>> ---
>>>>>> I am joining this thread late, but, would anyone out there be interested
>>>>>> in exchanging traffic with other carriers directly over SIP?
>>>>>>
>>>>>
>>>>> Just another point of VoIP history trivia at this point... but in
>>>>> addition to things like ENUM and ITAD, Mark Spencer of Asterisk fame also
>>>>> invented Dundi, which was an encrypted peer-to-peer protocol for route
>>>>> advertisement and discovery.  As far as I know, very few people besides me
>>>>> ever put it in production, but it worked really well at the time. (Of
>>>>> course, it's been about 17 or 18 years now since I used it in production.)
>>>>>
>>>>> -Jared
>>>>> _______________________________________________
>>>>> VoiceOps mailing list
>>>>> VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org><mailto:VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>>
>>>>> https://puck.nether.net/mailman/listinfo/voiceops
>>>>>
>>>> _______________________________________________
>>>> VoiceOps mailing list
>>>> VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org><mailto:VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>>
>>>> https://puck.nether.net/mailman/listinfo/voiceops
>>>>
>>>
>>
>> ---------------------------------------------------------------------------
>> Peter Beckman                                                  Internet Guy
>> beckman at angryox.com<mailto:beckman at angryox.com><mailto:beckman at angryox.com>                                https://www.angryox.com/
>> ---------------------------------------------------------------------------
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org><mailto:VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>>
>> https://puck.nether.net/mailman/listinfo/voiceops
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org><mailto:VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>>
>> https://puck.nether.net/mailman/listinfo/voiceops
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org><mailto:VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>>
> https://puck.nether.net/mailman/listinfo/voiceops
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org><mailto:VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>>
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
> --
> Pinchas S. Neiman
> Software Engineer At ESEQ Technology Corp.
> 845.213.1229 #2
> [Image removed by sender.]
>

---------------------------------------------------------------------------
Peter Beckman                                                  Internet Guy
beckman at angryox.com<mailto:beckman at angryox.com>                                https://www.angryox.com/
---------------------------------------------------------------------------


--
Pinchas S. Neiman
Software Engineer At ESEQ Technology Corp.
845.213.1229 #2
[https://ci3.googleusercontent.com/mail-sig/AIorK4z1Lx063u893FlkIV1C3aJbVPjgKnaA2Xu8q_iPdyFOnK_JX05usgghpAIwmPqB-1t-3fdaShNHoCPf7fFwa1twYZt-xjsBZheqmsCQrg]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20231025/cee54b72/attachment-0001.htm>