<div dir="ltr">And a pool of peers trusting themselves, could establish a mutual database where they could award or revoke trust to companies or CAs.<div><br></div><div>Then other peers could follow them read only.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 25, 2023 at 12:07 PM Matthew Crocker <<a href="mailto:matthew@corp.crocker.com">matthew@corp.crocker.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="msg2110249512530581519">
<div lang="EN-US" style="overflow-wrap: break-word;">
<div class="m_2110249512530581519WordSection1">
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I never said STIR/SHAKEN would be used to ‘look up’ for call routing.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Earlier someone mentioned an issue with open peering is spam calls. STIR/SHAKEN can solve that issue.<br>
<br>
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<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div id="m_2110249512530581519mail-editor-reference-message-container">
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(181,196,223);padding:3pt 0in 0in">
<p class="MsoNormal" style="margin-bottom:12pt"><b><span style="font-size:12pt;color:black">From:
</span></b><span style="font-size:12pt;color:black">Peter Beckman <<a href="mailto:beckman@angryox.com" target="_blank">beckman@angryox.com</a>><br>
<b>Date: </b>Wednesday, October 25, 2023 at 12:04 PM<br>
<b>To: </b>Matthew Crocker <<a href="mailto:matthew@corp.crocker.com" target="_blank">matthew@corp.crocker.com</a>><br>
<b>Cc: </b>Pinchas Neiman <<a href="mailto:neimanpinchas@gmail.com" target="_blank">neimanpinchas@gmail.com</a>>, Jawaid Bazyar <<a href="mailto:jawaid@bazyar.net" target="_blank">jawaid@bazyar.net</a>>, voiceops <<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>><br>
<b>Subject: </b>Re: [VoiceOps] Voice Peering<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal">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.<br>
<br>
<br>
STIR/SHAKEN does not delegate any authority to anyone.<br>
<br>
It merely allows me to sign a call that I originate, so that someone else<br>
can say "Oh this came from $COMPANY."<br>
<br>
Besides, STIR/SHAKEN is done at the time of an origination call, it cannot<br>
be "looked up" to see where to route a call.<br>
<br>
The suggestion that STIR/SHAKEN could be used to authoritatively assign a<br>
DID endpoint to someone demonstrates a lack of understanding in how it<br>
works and what it does and does not do.<br>
<br>
Beckman<br>
<br>
On Wed, 25 Oct 2023, Matthew Crocker via VoiceOps wrote:<br>
<br>
><br>
> 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<br>
><br>
> Open SIP proxy handles all of the SIP traffic, RTP goes directly between carriers.<br>
> All calls originated must be signed (STIRred)<br>
><br>
> * Call isn’t signed, gets rejected by the SIP peering proxy<br>
> Terminating carrier can validate the signed calls (SHAKEN)<br>
><br>
> * Don’t like the signing CA? reject the call<br>
> * Don’t like the signing carrier? Reject the call<br>
> * Carrier sending too many spam calls, adjust treatment based on customer spam settings<br>
><br>
><br>
> 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.<br>
><br>
> So terminating carriers would need to export/upload (hacked BGP?) numbers they are willing to receive calls on to the peering proxy.<br>
><br>
> Proxies can be spun up in various AWS/Azure/GoogleCloud VPS<br>
><br>
><br>
> From: Pinchas Neiman <<a href="mailto:neimanpinchas@gmail.com" target="_blank">neimanpinchas@gmail.com</a>><br>
> Date: Wednesday, October 25, 2023 at 11:18 AM<br>
> To: Jawaid Bazyar <<a href="mailto:jawaid@bazyar.net" target="_blank">jawaid@bazyar.net</a>><br>
> Cc: Matthew Crocker <<a href="mailto:matthew@corp.crocker.com" target="_blank">matthew@corp.crocker.com</a>>, voiceops <<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>><br>
> Subject: Re: [VoiceOps] Voice Peering<br>
> 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.<br>
><br>
> 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)<br>
> Practically implementing STIR/SHAKEN has bureaucracy involved.<br>
><br>
> On Tue, Oct 24, 2023 at 9:38 PM Jawaid Bazyar via VoiceOps <<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a><mailto:<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>>> wrote:<br>
> Is there a good clear document somewhere describing how STIR/SHAKEN is supposed to work?<br>
><br>
> On Tue, Oct 24, 2023 at 9:33 PM Matthew Crocker via VoiceOps <<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a><mailto:<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>>> wrote:<br>
><br>
><br>
>> On Oct 24, 2023, at 9:13 PM, Peter Beckman via VoiceOps <<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a><mailto:<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>>> wrote:<br>
>><br>
>> 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.<br>
>><br>
>><br>
>> The challenge is how do you authenticate the end "carrier" or service<br>
>> provider?<br>
>><br>
><br>
> STIR/SHAKEN<br>
><br>
><br>
>> Sure, anyone who leases numbers directly from NANPA can look up the carrier<br>
>> of record and exchange traffic directly, but any business who also leases<br>
>> numbers INDIRECTLY gets cut out and still needs to pay their upstream<br>
>> carrier(s) to place/receive calls, either by channels or per minute, even<br>
>> if their upstream is directly peered and not transiting the PSTN at all.<br>
>><br>
>> If this would be for the end user, then NANPA would have to delegate to the<br>
>> leasee, the leasee delegate to the reseller, the reseller to the end user,<br>
>> then the end user could publish their VoIP contact info, and anyone could<br>
>> call directly via VoIP, cutting out all of the middle peers.<br>
>><br>
>> But, as another person said, this is ripe for abuse, and with no motivation<br>
>> by NANPA or the larger carriers to make calls less expensive for the<br>
>> reseller or end user, I see this going nowhere. Until there is some value<br>
>> in NANPA (plus all the other country telephony organizations) and the<br>
>> direct carriers leasing numbers to do so.<br>
>><br>
>> Beckman<br>
>><br>
>>> On Tue, 24 Oct 2023, Ross Tajvar via VoiceOps wrote:<br>
>>><br>
>>> I can think of a few ways that could be adapted into a platform more like<br>
>>> an Internet exchange, but as others have said, it just doesn't seem worth<br>
>>> it.<br>
>>><br>
>>> On Tue, Oct 24, 2023, 5:31 PM Jawaid Bazyar via VoiceOps <<br>
>>> <a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a><mailto:<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>>> wrote:<br>
>>><br>
>>>> I think schemes like DUNDI (and some of the others mentioned here) suffer<br>
>>>> from a trust issue – what’s to prevent operator X from poisoning the<br>
>>>> protocol with bogus “stolen” numbers?<br>
>>>><br>
>>>><br>
>>>><br>
>>>> On Tue, Oct 24, 2023 at 5:25 PM Jared Smith via VoiceOps <<br>
>>>> <a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a><mailto:<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>>> wrote:<br>
>>>><br>
>>>>> On Tue, Oct 24, 2023 at 8:49 AM Mike Hammett via VoiceOps <<br>
>>>>> <a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a><mailto:<a href="mailto:voiceops@voiceops.org" target="_blank">voiceops@voiceops.org</a>>> wrote:<br>
>>>>><br>
>>>>>> This was in another thread, but I broke it out into it's own<br>
>>>>>> conversation. Someone had asked:<br>
>>>>>><br>
>>>>>> ---<br>
>>>>>> I am joining this thread late, but, would anyone out there be interested<br>
>>>>>> in exchanging traffic with other carriers directly over SIP?<br>
>>>>>><br>
>>>>><br>
>>>>> Just another point of VoIP history trivia at this point... but in<br>
>>>>> addition to things like ENUM and ITAD, Mark Spencer of Asterisk fame also<br>
>>>>> invented Dundi, which was an encrypted peer-to-peer protocol for route<br>
>>>>> advertisement and discovery. As far as I know, very few people besides me<br>
>>>>> ever put it in production, but it worked really well at the time. (Of<br>
>>>>> course, it's been about 17 or 18 years now since I used it in production.)<br>
>>>>><br>
>>>>> -Jared<br>
>>>>> _______________________________________________<br>
>>>>> VoiceOps mailing list<br>
>>>>> <a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><mailto:<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a>><br>
>>>>> <a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
>>>>><br>
>>>> _______________________________________________<br>
>>>> VoiceOps mailing list<br>
>>>> <a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><mailto:<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a>><br>
>>>> <a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
>>>><br>
>>><br>
>><br>
>> ---------------------------------------------------------------------------<br>
>> Peter Beckman Internet Guy<br>
>> <a href="mailto:beckman@angryox.com" target="_blank">beckman@angryox.com</a><<a href="mailto:beckman@angryox.com" target="_blank">mailto:beckman@angryox.com</a>>
<a href="https://www.angryox.com/" target="_blank">https://www.angryox.com/</a><br>
>> ---------------------------------------------------------------------------<br>
>> _______________________________________________<br>
>> VoiceOps mailing list<br>
>> <a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><mailto:<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a>><br>
>> <a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
>> _______________________________________________<br>
>> VoiceOps mailing list<br>
>> <a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><mailto:<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a>><br>
>> <a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
> _______________________________________________<br>
> VoiceOps mailing list<br>
> <a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><mailto:<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a>><br>
> <a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
> _______________________________________________<br>
> VoiceOps mailing list<br>
> <a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a><mailto:<a href="mailto:VoiceOps@voiceops.org" target="_blank">VoiceOps@voiceops.org</a>><br>
> <a href="https://puck.nether.net/mailman/listinfo/voiceops" target="_blank">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
><br>
><br>
> --<br>
> Pinchas S. Neiman<br>
> Software Engineer At ESEQ Technology Corp.<br>
> 845.213.1229 #2<br>
> [Image removed by sender.]<br>
><br>
<br>
---------------------------------------------------------------------------<br>
Peter Beckman Internet Guy<br>
<a href="mailto:beckman@angryox.com" target="_blank">beckman@angryox.com</a> <a href="https://www.angryox.com/" target="_blank">
https://www.angryox.com/</a><br>
---------------------------------------------------------------------------<u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</div></blockquote></div><br clear="all"><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><b>Pinchas S. Neiman</b></div><div>Software Engineer At ESEQ Technology Corp.</div><div>845.213.1229 #2</div><img width="200" height="68" src="https://ci3.googleusercontent.com/mail-sig/AIorK4z1Lx063u893FlkIV1C3aJbVPjgKnaA2Xu8q_iPdyFOnK_JX05usgghpAIwmPqB-1t-3fdaShNHoCPf7fFwa1twYZt-xjsBZheqmsCQrg"><br></div></div></div></div></div></div></div></div></div></div></div></div></div></div>