[VoiceOps] Voice Peering
Peter Beckman
beckman at angryox.com
Wed Oct 25 12:04:01 EDT 2023
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/
---------------------------------------------------------------------------
-------------- next part --------------
_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
More information about the VoiceOps
mailing list