Re: [VoiceOps] Voice Peering

[Peter Beckman via VoiceOps]

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
 and/or phone number into a Domain Name, and then query it?

 If you get a domain name, you now automatically trust that the incoming call is
 worthy of your trust, because I can set up "allyourbase.com" and send a
 call to you and you check my SPF record and I say "totally ip4:0.0.0.0/24"
 (the entire internet) and you go "Cool! I'll take the call!"

 Yet what entity is actually sending you the call?

 SPF works because what you are sending (email) is also part of the domain
 name. And even if you added a SIP header with a domain, all you are doing
 is looking up a SPF/TXT record for the domain the call says they are
 coming from, but now you have to implement DKIM-signing so someone cannot
 pretend to be calling from a different domain. Then YOU the call receiver
 have to decide if you trust the entity that is sending the call!!! And you
 still haven't solved the problem of how the caller found out your Endpoint
 in the first place to make the SIP call.


There are DNS SRV records, which tell you HOW to access a certain service
given a domain name.

e.g.

--> dig srv _sip._udp.srv.lcr.thinq.com

; <<>> DiG 9.10.6 <<>> srv _sip._udp.srv.lcr.thinq.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27421
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;_sip._udp.srv.lcr.thinq.com.INSRV

;; ANSWER SECTION:
_sip._udp.srv.lcr.thinq.com. 20384 INSRV100 50 5060 
lcr-lb02.rdu.thinq.com.
_sip._udp.srv.lcr.thinq.com. 20384 INSRV200 50 5060 
lcr-lb02.dfw.thinq.com.
_sip._udp.srv.lcr.thinq.com. 20384 INSRV200 50 5060 
lcr-lb01.dfw.thinq.com.
_sip._udp.srv.lcr.thinq.com. 20384 INSRV100 50 5060 
lcr-lb01.rdu.thinq.com.

;; Query time: 5 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Wed Oct 25 18:47:53 EDT 2023
;; MSG SIZE  rcvd: 224

That's great, so I know where to send a call, if I know that Thinq is the
endpoint of record for a phone numbe . But how do I take +1 202 456 
and authoritatively know what endpoint/domain/entity to reach out to? And
how does that endpoint know to trust me?

Due to Number Porting and a lack of any way for any leasee of a number to
publish such information with the blessing of NANPA ($govt-entity) and the
assigned Tier 0 carrier, or have any fallback if your endpoint is offline or
unavailable, there's no hierarchy to implement.

I suppose something like this could work:

NANPA (root) gets request for 1202456, tells you to check with IQ 
at a
certain hostname

IQ (delegate) gets request for 1202456, tells you to check with
FrogTele at a certain hostname

FrogTele gives you a response that confirms that one can call them and
reach the endpoint

A SRV query is made to determine what host(s) within FrogTele can
handle a UDP SIP call

You place the call

If it fails, maybe you can go to IQ as a backup and call through them.

If FrogTele says "no I do not service that number," then what do you do, go
back to IQ?


For ANY of this to work, NANPA and Tier 0 carriers who get numbers directly
from NANPA (NANPA only knows about its direct customers, not resellers, or
Tier 1+ carriers) would have to build it and participate.

Even if they did, currently all this is implemented either through security
through obscurity (which this model breaks) or IP firewalls & whitelists.
Most of the authentication stuff is weak or static, which is another
security risk.

Now that all the Internet knows what carrier is handling a specific phone
number, which potentially discloses PII, which an attacker could then use
to target the website and web account of the target with a re-used password
from another hack, and your customer loses their account (granted because
of their bad security practices) because you wanted to save a few tenths of
a cent per minute.

TRUST is the problem. MONEY is the problem.

NANPA has no financial nor governmental incentive to do this.

Tier 0 carriers have a negative financial incentive to do this.

Without NANPA and Tier 0 carriers involvement, anyone can self-publish a
record somewhere saying "Call me here!" and nobody will know if that can be
trusted, because the trust chain is non-existent without NANPA and Tier 0
carriers involvement.

Like Alex said, Technically this is achievable.

Politically and Financially this is Dead on Arrival, at least until the
incentives change.

On Wed, 

Re: [VoiceOps] Voice Peering

[Jawaid Bazyar via VoiceOps]

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 say that
question is still unresolved.

On Wed, Oct 25, 2023 at 5:08 PM Peter Beckman  wrote:

> 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 
> > Date: Wednesday, October 25, 2023 at 12:04 PM
> > To: Matthew Crocker 
> > Cc: Pinchas Neiman , Jawaid Bazyar <
> jaw...@bazyar.net>, voiceops 
> > 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 
> >> Date: Wednesday, October 25, 2023 at 11:18 AM
> >> To: Jawaid Bazyar 
> >> Cc: Matthew Crocker , voiceops <
> voiceops@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@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@voiceops.org> wrote:
> >>
> >>
> >>> On Oct 24, 2023, at 9:13 PM, Peter Beckman via VoiceOps <
> voiceops@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 

Re: [VoiceOps] Voice Peering

[Matthew Crocker via VoiceOps]

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, October 25, 2023 at 5:08 PM
To: Matthew Crocker 
Cc: Pinchas Neiman , Jawaid Bazyar 
, VoiceOps 
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.


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 
> Date: Wednesday, October 25, 2023 at 12:04 PM
> To: Matthew Crocker 
> Cc: Pinchas Neiman , Jawaid Bazyar 
> , voiceops 
> 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 
>> Date: Wednesday, October 25, 2023 at 11:18 AM
>> To: Jawaid Bazyar 
>> Cc: Matthew Crocker , voiceops 
>> 
>> 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 
>> mailto:voiceops@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 
>> mailto:voiceops@voiceops.org>> wrote:
>>
>>
>>> On Oct 24, 2023, at 9:13 PM, Peter Beckman via VoiceOps 
>>> mailto:voiceops@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 

Re: [VoiceOps] Voice Peering

[Peter Beckman via VoiceOps]

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 
Date: Wednesday, October 25, 2023 at 12:04 PM
To: Matthew Crocker 
Cc: Pinchas Neiman , Jawaid Bazyar , 
voiceops 
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 
Date: Wednesday, October 25, 2023 at 11:18 AM
To: Jawaid Bazyar 
Cc: Matthew Crocker , voiceops 
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 
mailto:voiceops@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 
mailto:voiceops@voiceops.org>> wrote:



On Oct 24, 2023, at 9:13 PM, Peter Beckman via VoiceOps 
mailto:voiceops@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 

Re: [VoiceOps] Voice Peering

[Ross Tajvar via VoiceOps]

>  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 the regulatory process and get their own OCN.

Similarly, I wouldn't peer with a business that used an internet connection
but didn't have their own ASN/IPs. It's just not worth it for me. If they
have that kind of need, they can participate the same way the grown-ups do.

On Tue, Oct 24, 2023 at 9:13 PM Peter Beckman  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 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@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@voiceops.org> wrote:
> >>
> >>> On Tue, Oct 24, 2023 at 8:49 AM Mike Hammett via VoiceOps <
> >>> voiceops@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@voiceops.org
> >>> https://puck.nether.net/mailman/listinfo/voiceops
> >>>
> >> ___
> >> VoiceOps mailing list
> >> VoiceOps@voiceops.org
> >> https://puck.nether.net/mailman/listinfo/voiceops
> >>
> >
>
> ---
> Peter Beckman  Internet Guy
> beck...@angryox.com
> https://www.angryox.com/
>
> ---___
> VoiceOps mailing list
> VoiceOps@voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Voice Peering

[Alex Balashov via VoiceOps]

> 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, and their various proprietary and semi-proprietary cousins (e.g. 
Open Settlement Protocol).

But when you actually needed to make phone calls, holla at the Bell tandem and 
SS7 A-links.

That's been changing, but not at all because of Internet-native voice peering.

-- Alex

-- 
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Voice Peering

[Michael Graves via VoiceOps]

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 Alex Balashov via 
VoiceOps
Sent: Wednesday, October 25, 2023 2:01 PM
To: VoiceOps 
Subject: 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) 
> Practically implementing STIR/SHAKEN has bureaucracy involved.

Just this. The technical specs are the easy part. Actually implementing is 
mostly a clerical and bureaucratic chore. 
There is also widespread misunderstanding of what it does and does not 
accomplish. It does not prevent spam calls. 

-- Alex

--
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Voice Peering

[Alex Balashov via VoiceOps]

> 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 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.

Bingo. In addition to that, how many resellers or end-users have the technical 
means or inclination to "peer" with anyone? What's that? Who cares.

This reminds me of the direction of crypto. In a small echo chamber of 
enthusiasts, there were some really starry-eyed, big and dreamy 
computer-sciency conversations about decentralised ledgers and this and that, 
tyranny and sticking it to autocracy and so forth, but in the real world, 
crypto needs to be mediated by the same old centralised financial institutions 
to be even faintly useful to just about anyone in the general population.

-- Alex

-- 
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Voice Peering

[Alex Balashov via VoiceOps]

> 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)
> Practically implementing STIR/SHAKEN has bureaucracy involved.

Just this. The technical specs are the easy part. Actually implementing is 
mostly a clerical and bureaucratic chore. 
There is also widespread misunderstanding of what it does and does not 
accomplish. It does not prevent spam calls. 

-- Alex

-- 
Alex Balashov
Principal Consultant
Evariste Systems LLC
Web: https://evaristesys.com
Tel: +1-706-510-6800

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Voice Peering

[Mike Johnston via VoiceOps]

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 domain.  If the 
server attempting to send the email is not mentioned in the SPF, then 
you can reject the incoming email.


Does anybody know if something like SPF has been adapted to voice?

For example, say anything from 54.239.16.0/24 is allowed as that is 
where your phone switches are.  And 20.112.88.88/29 can also make calls, 
as that is one of those School Auto-Dialer services[2].  (Or whatever, 
make up your own scenarios.)


When you receive calls, you would need to do a DNS lookup to get the 
list of allowed senders.  If it's not in the list, reject the call.


The exact query, and who we are querying, is a good question, though. 
Who owns the phone number?


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.

And say you got this back from the DNS query:

  "v=spf1 ip4:54.239.16.0/24 ip4:20.112.88.88/29 -all"

If the server sending you the call is not in 54.239.16.0/24 or 
20.112.88.88/29, then reject the call.


[1] An SPF record can have more than just IP addresses, but can also 
"include" other domain names.
[2] You might do your DNS in such a way, that 20.112.88.88/29 is only 
returned for the specific number(s) that you expect them to be sending 
from, not ALL of your numbers.


Further reading:
https://en.wikipedia.org/wiki/Sender_Policy_Framework
https://www.cloudflare.com/learning/dns/dns-records/dns-spf-record/
https://support.google.com/a/answer/10685031?hl=en
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Voice Peering

[Michael Graves via VoiceOps]

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 Neiman via 
VoiceOps
Sent: Wednesday, October 25, 2023 11:54 AM
To: Matthew Crocker 
Cc: voiceops 
Subject: 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 
mailto:matt...@corp.crocker.com>> 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 mailto:beck...@angryox.com>>
Date: Wednesday, October 25, 2023 at 12:04 PM
To: Matthew Crocker mailto:matt...@corp.crocker.com>>
Cc: Pinchas Neiman mailto:neimanpinc...@gmail.com>>, 
Jawaid Bazyar mailto:jaw...@bazyar.net>>, voiceops 
mailto:voiceops@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 mailto:neimanpinc...@gmail.com>>
> Date: Wednesday, October 25, 2023 at 11:18 AM
> To: Jawaid Bazyar mailto:jaw...@bazyar.net>>
> Cc: Matthew Crocker 
> mailto:matt...@corp.crocker.com>>, voiceops 
> mailto:voiceops@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 
> mailto:voiceops@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 
> mailto:voiceops@voiceops.org>>>
>  wrote:
>
>
>> On Oct 24, 2023, at 9:13 PM, Peter Beckman via VoiceOps 
>> mailto:voiceops@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?
>>
>
> 

Re: [VoiceOps] Voice Peering

[Pinchas Neiman via VoiceOps]

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’ 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 
> *Date: *Wednesday, October 25, 2023 at 12:04 PM
> *To: *Matthew Crocker 
> *Cc: *Pinchas Neiman , Jawaid Bazyar <
> jaw...@bazyar.net>, voiceops 
> *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 
> > Date: Wednesday, October 25, 2023 at 11:18 AM
> > To: Jawaid Bazyar 
> > Cc: Matthew Crocker , voiceops <
> voiceops@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@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@voiceops.org> wrote:
> >
> >
> >> On Oct 24, 2023, at 9:13 PM, Peter Beckman via VoiceOps <
> voiceops@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

Re: [VoiceOps] Voice Peering

[Matthew Crocker via VoiceOps]

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 
Date: Wednesday, October 25, 2023 at 12:04 PM
To: Matthew Crocker 
Cc: Pinchas Neiman , Jawaid Bazyar 
, voiceops 
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 
> Date: Wednesday, October 25, 2023 at 11:18 AM
> To: Jawaid Bazyar 
> Cc: Matthew Crocker , voiceops 
> 
> 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 
> mailto:voiceops@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 
> mailto:voiceops@voiceops.org>> wrote:
>
>
>> On Oct 24, 2023, at 9:13 PM, Peter Beckman via VoiceOps 
>> mailto:voiceops@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 

Re: [VoiceOps] Voice Peering

[Peter Beckman via VoiceOps]

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 
Date: Wednesday, October 25, 2023 at 11:18 AM
To: Jawaid Bazyar 
Cc: Matthew Crocker , voiceops 
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 
mailto:voiceops@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 
mailto:voiceops@voiceops.org>> wrote:



On Oct 24, 2023, at 9:13 PM, Peter Beckman via VoiceOps 
mailto:voiceops@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@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@voiceops.org> wrote:


On Tue, Oct 24, 2023 at 8:49 AM Mike Hammett via VoiceOps <
voiceops@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 

Re: [VoiceOps] Voice Peering

[Matthew Crocker via VoiceOps]

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 
Date: Wednesday, October 25, 2023 at 11:18 AM
To: Jawaid Bazyar 
Cc: Matthew Crocker , voiceops 
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 
mailto:voiceops@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 
mailto:voiceops@voiceops.org>> wrote:


> On Oct 24, 2023, at 9:13 PM, Peter Beckman via VoiceOps 
> mailto:voiceops@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@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@voiceops.org> wrote:
>>>
 On Tue, Oct 24, 2023 at 8:49 AM Mike Hammett via VoiceOps <
 voiceops@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
 

Re: [VoiceOps] Voice Peering

[Pinchas Neiman via VoiceOps]

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@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@voiceops.org> wrote:
>
>>
>>
>> > On Oct 24, 2023, at 9:13 PM, Peter Beckman via VoiceOps <
>> voiceops@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@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@voiceops.org> wrote:
>> >>>
>>  On Tue, Oct 24, 2023 at 8:49 AM Mike Hammett via VoiceOps <
>>  voiceops@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@voiceops.org
>>  https://puck.nether.net/mailman/listinfo/voiceops
>> 
>> >>> ___
>> >>> VoiceOps mailing list
>> >>> VoiceOps@voiceops.org
>> >>> https://puck.nether.net/mailman/listinfo/voiceops
>> >>>
>> >>
>> >
>> >
>> ---
>> > Peter Beckman  Internet
>> Guy
>> > beck...@angryox.com
>> https://www.angryox.com/
>> >
>> ---
>> > ___
>> > VoiceOps mailing list
>> > VoiceOps@voiceops.org
>> > https://puck.nether.net/mailman/listinfo/voiceops
>> > ___
>> > VoiceOps mailing list
>> > VoiceOps@voiceops.org
>> > https://puck.nether.net/mailman/listinfo/voiceops
>> ___
>> VoiceOps mailing list
>> VoiceOps@voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>>
> ___
> VoiceOps mailing list
> VoiceOps@voiceops.org
>