<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I never said STIR/SHAKEN would be used to ‘look up’ for call routing.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></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<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div id="mail-editor-reference-message-container">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Peter Beckman <beckman@angryox.com><br>
<b>Date: </b>Wednesday, October 25, 2023 at 12:04 PM<br>
<b>To: </b>Matthew Crocker <matthew@corp.crocker.com><br>
<b>Cc: </b>Pinchas Neiman <neimanpinchas@gmail.com>, Jawaid Bazyar <jawaid@bazyar.net>, voiceops <voiceops@voiceops.org><br>
<b>Subject: </b>Re: [VoiceOps] Voice Peering<o:p></o:p></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 <neimanpinchas@gmail.com><br>
> Date: Wednesday, October 25, 2023 at 11:18 AM<br>
> To: Jawaid Bazyar <jawaid@bazyar.net><br>
> Cc: Matthew Crocker <matthew@corp.crocker.com>, voiceops <voiceops@voiceops.org><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 <voiceops@voiceops.org<mailto:voiceops@voiceops.org>> 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 <voiceops@voiceops.org<mailto:voiceops@voiceops.org>> wrote:<br>
><br>
><br>
>> On Oct 24, 2023, at 9:13 PM, Peter Beckman via VoiceOps <voiceops@voiceops.org<mailto:voiceops@voiceops.org>> 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>
>>> voiceops@voiceops.org<mailto:voiceops@voiceops.org>> 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>
>>>> voiceops@voiceops.org<mailto:voiceops@voiceops.org>> wrote:<br>
>>>><br>
>>>>> On Tue, Oct 24, 2023 at 8:49 AM Mike Hammett via VoiceOps <<br>
>>>>> voiceops@voiceops.org<mailto:voiceops@voiceops.org>> 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>
>>>>> VoiceOps@voiceops.org<mailto:VoiceOps@voiceops.org><br>
>>>>> <a href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
>>>>><br>
>>>> _______________________________________________<br>
>>>> VoiceOps mailing list<br>
>>>> VoiceOps@voiceops.org<mailto:VoiceOps@voiceops.org><br>
>>>> <a href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
>>>><br>
>>><br>
>><br>
>> ---------------------------------------------------------------------------<br>
>> Peter Beckman Internet Guy<br>
>> beckman@angryox.com<<a href="mailto:beckman@angryox.com">mailto:beckman@angryox.com</a>>
<a href="https://www.angryox.com/">https://www.angryox.com/</a><br>
>> ---------------------------------------------------------------------------<br>
>> _______________________________________________<br>
>> VoiceOps mailing list<br>
>> VoiceOps@voiceops.org<mailto:VoiceOps@voiceops.org><br>
>> <a href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
>> _______________________________________________<br>
>> VoiceOps mailing list<br>
>> VoiceOps@voiceops.org<mailto:VoiceOps@voiceops.org><br>
>> <a href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
> _______________________________________________<br>
> VoiceOps mailing list<br>
> VoiceOps@voiceops.org<mailto:VoiceOps@voiceops.org><br>
> <a href="https://puck.nether.net/mailman/listinfo/voiceops">https://puck.nether.net/mailman/listinfo/voiceops</a><br>
> _______________________________________________<br>
> VoiceOps mailing list<br>
> VoiceOps@voiceops.org<mailto:VoiceOps@voiceops.org><br>
> <a href="https://puck.nether.net/mailman/listinfo/voiceops">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>
beckman@angryox.com <a href="https://www.angryox.com/">
https://www.angryox.com/</a><br>
---------------------------------------------------------------------------<o:p></o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>