Re: [VoiceOps] Voice Peering

On Wed, 25 Oct 2023, Mike Johnston via VoiceOps wrote: Anyways, say your system is getting a call from 555-555-1234. So you do a DNS query against...I do not know. dig TXT 4.3.2.1.5.5.5.5.5.5.i-do-not-know. How do you take an incoming call, from an IP you do not know, turn that IP

Re: [VoiceOps] Voice Peering

Well, in any kind of fully-distributed scenario some type of security mechanism that might not look all that dissimilar from STIR/SHAKEN would be implied. What I've heard so far is many different potential implementations at just about every level of the business stack that exists today, so I'd

Re: [VoiceOps] Voice Peering

A solution (where to send the call) was offered (open peering) but then devolved into ‘how to you stop spam’ and I offered STIR/SHAKEN. There have been plenty of open routing solutions thrown about over the past 30 years, none have ever taken hold. From: Peter Beckman Date: Wednesday,

Re: [VoiceOps] Voice Peering

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.

Re: [VoiceOps] Voice Peering

> any business who also leases numbers INDIRECTLY gets cut out and still needs to pay their upstream carrier(s) to place/receive calls Yes, true...but I don't really care about retail consumers or resellers. If they are doing enough VoIP volume that they care about peering, they can go through

Re: [VoiceOps] Voice Peering

> On 25 Oct 2023, at 15:12, Michael Graves wrote: > > The apparent elegance of a technology can be entrancing. > > To quote the great Leonard Cohen, "We're blinded by the beauty of our > weapons." Indeed. I think that sums up ENUM peering, e164.org , DUNDi federations,

Re: [VoiceOps] Voice Peering

Alex, The apparent elegance of a technology can be entrancing. To quote the great Leonard Cohen, "We're blinded by the beauty of our weapons." Michael Graves mgra...@mstvp.com o: (713) 861-4005 c: (713) 201-1262 sip:mgra...@mjg.onsip.com -Original Message- From: VoiceOps On Behalf Of

Re: [VoiceOps] Voice Peering

> On 24 Oct 2023, at 21:13, Peter Beckman via VoiceOps > wrote: > > The challenge is how do you authenticate the end "carrier" or service > provider? > > Sure, anyone who leases numbers directly from NANPA can look up the carrier > of record and exchange traffic directly, but any business

Re: [VoiceOps] Voice Peering

> On 25 Oct 2023, at 11:18, Pinchas Neiman via VoiceOps > wrote: > > 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) >

Re: [VoiceOps] Voice Peering

Who can source email from a domain is more-or-less a solved problem by using DNS SPF records. An SPF record is a list of IP addresses[1] that is allowed to send email for a domain. When an email server receives an email, best practice is to do a DNS lookup for the SPF of the alleged sender

Re: [VoiceOps] Voice Peering

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 mgra...@mstvp.com o: (713) 861-4005 c: (713) 201-1262 sip:mgra...@mjg.onsip.com From: VoiceOps On Behalf Of Pinchas

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 wrote: > > > I never said STIR/SHAKEN would be used to ‘look up’

Re: [VoiceOps] Voice Peering

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

Re: [VoiceOps] Voice Peering

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

Re: [VoiceOps] Voice Peering

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

Re: [VoiceOps] Voice Peering

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,