[VoiceOps] Voice Peering
Peter Beckman
beckman at angryox.com
Wed Oct 25 17:08:36 EDT 2023
This whole conversation, and topic, is "Voice Peering" -- ORIGINATING CALLS
directly to the endpoint rather than me passing to Level3 who passes to IQ
who passes to their customer who passes to their customer who has a VoIP
device that I could reach directly if I only had the ability to do so.
This has nothing to do with rejecting incoming calls signed with
STIR/SHAKEN.
The call cannot start until I know where to send the call. <-- problem that we are discussing
Beckman
On Wed, 25 Oct 2023, Matthew Crocker 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>
> Date: Wednesday, October 25, 2023 at 12:04 PM
> To: Matthew Crocker <matthew at corp.crocker.com>
> Cc: Pinchas Neiman <neimanpinchas at gmail.com>, Jawaid Bazyar <jawaid at bazyar.net>, voiceops <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>
>> Date: Wednesday, October 25, 2023 at 11:18 AM
>> To: Jawaid Bazyar <jawaid at bazyar.net>
>> Cc: Matthew Crocker <matthew at corp.crocker.com>, voiceops <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>> 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>> wrote:
>>
>>
>>> On Oct 24, 2023, at 9:13 PM, Peter Beckman via VoiceOps <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>> 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>> wrote:
>>>>>
>>>>>> On Tue, Oct 24, 2023 at 8:49 AM Mike Hammett via VoiceOps <
>>>>>> 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>
>>>>>> https://puck.nether.net/mailman/listinfo/voiceops
>>>>>>
>>>>> _______________________________________________
>>>>> VoiceOps mailing list
>>>>> 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> https://www.angryox.com/
>>> ---------------------------------------------------------------------------
>>> _______________________________________________
>>> VoiceOps mailing list
>>> 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>
>>> https://puck.nether.net/mailman/listinfo/voiceops
>> _______________________________________________
>> VoiceOps mailing list
>> 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>
>> 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 https://www.angryox.com/
> ---------------------------------------------------------------------------
>
---------------------------------------------------------------------------
Peter Beckman Internet Guy
beckman at angryox.com https://www.angryox.com/
---------------------------------------------------------------------------
More information about the VoiceOps
mailing list