On 10/4/22 11:58 AM, Tom Beecher wrote:
Honestly the root of a lot of the problems here is the bellheaded
insistence of still using E.164 addresses in the first place. With
SIP they are complete legacy and there is no reason that my
"telephone number" can't be m...@mtcc.com.
You can do that all you want. You just don't get to interact with the
PSTN.
What is the "PSTN" these days? It's a bunch of interconnected SIP
proxies where there is nothing special about the identifiers used. With
end to end SIP (or middle to middle, etc), the routing is not being done
with e.164 addresses like in the legacy PSTN. It's just bellheaded
thinking that e.164 addresses mean anything these days.The only time
they make any difference is if they need to off ramp to legacy signaling
which is becoming rarer and rarer.
Mike
On Tue, Oct 4, 2022 at 2:53 PM Michael Thomas <m...@mtcc.com> wrote:
On 10/4/22 11:31 AM, Mike Hammett wrote:
What's regulated or implemented is rarely the best course of
action. Does this cause more good or harm?
Honestly the root of a lot of the problems here is the bellheaded
insistence of still using E.164 addresses in the first place. With
SIP they are complete legacy and there is no reason that my
"telephone number" can't be m...@mtcc.com. In fact, that would be
a huge win since I could just use my email address book to make a
call. You could tell that STIR/SHAKEN really went off the rails
when it has heuristics on how to scrape E.164 addresses in the
From: field. At this point we should be mostly ignoring legacy
signaling, IMO.
Mike
-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
Midwest-IX
http://www.midwest-ix.com
------------------------------------------------------------------------
*From: *"Shane Ronan" <sh...@ronan-online.com>
<mailto:sh...@ronan-online.com>
*To: *"Michael Thomas" <m...@mtcc.com> <mailto:m...@mtcc.com>
*Cc: *"Mike Hammett" <na...@ics-il.net>
<mailto:na...@ics-il.net>, nanog@nanog.org
*Sent: *Tuesday, October 4, 2022 1:21:41 PM
*Subject: *Re: FCC chairwoman: Fines alone aren't enough (Robocalls)
Except the cost to do the data dips to determine the
authorization isn't "free".
On Tue, Oct 4, 2022 at 2:18 PM Michael Thomas <m...@mtcc.com> wrote:
On 10/4/22 6:07 AM, Mike Hammett wrote:
I think the point the other Mike was trying to make was
that if everyone policed their customers, this wouldn't
be a problem. Since some don't, something else needed to
be tried.
Exactly. And that doesn't require an elaborate PKI. Who is
allowed to use what telephone numbers is an administrative
issue for the ingress provider to police. It's the equivalent
to gmail not allowing me to spoof whatever email address I
want. The FCC could have required that ages ago.
Mike
-----
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com
Midwest-IX
http://www.midwest-ix.com
------------------------------------------------------------------------
*From: *"Shane Ronan" <sh...@ronan-online.com>
<mailto:sh...@ronan-online.com>
*To: *"Michael Thomas" <m...@mtcc.com> <mailto:m...@mtcc.com>
*Cc: *nanog@nanog.org
*Sent: *Monday, October 3, 2022 9:54:07 PM
*Subject: *Re: FCC chairwoman: Fines alone aren't enough
(Robocalls)
The issue isn't which 'prefixes' I accept from my
customers, but which 'prefixes' I accept from the people
I peer with, because it's entirely dynamic and without a
doing a database dip on EVERY call, I have to assume that
my peer or my peers customer or my peers peer is doing
the right thing.
I can't simply block traffic from a peer carrier, it's
not allowed, so there has to be some mechanism to mark
that a prefix should be allowed, which is what
Shaken/Stir does.
Shane
On Mon, Oct 3, 2022 at 7:05 PM Michael Thomas
<m...@mtcc.com> wrote:
The problem has always been solvable at the ingress
provider. The
problem was that there was zero to negative incentive
to do that. You
don't need an elaborate PKI to tell the ingress
provider which prefixes
customers are allow to assert. It's pretty analogous
to when submission
authentication was pretty nonexistent with email...
there was no
incentive to not be an open relay sewer. Unlike email
spam, SIP
signaling is pretty easy to determine whether it's
spam. All it needed
was somebody to force regulation which unlike email
there was always
jurisdiction with the FCC.
Mike
On 10/3/22 3:13 PM, Jawaid Bazyar wrote:
> We're talking about blocking other carriers.
>
> On 10/3/22, 3:05 PM, "Michael Thomas"
<m...@mtcc.com> wrote:
>
> On 10/3/22 1:54 PM, Jawaid Bazyar wrote:
> > Because it's illegal for common carriers to
block traffic otherwise.
>
> Wait, what? It's illegal to police their own
users?
>
> Mike
>
> >
> > On 10/3/22, 2:53 PM, "NANOG on behalf of
Michael Thomas"
<nanog-bounces+jbazyar=verobroadband....@nanog.org on
behalf of m...@mtcc.com> wrote:
> >
> >
> > On 10/3/22 1:34 PM, Sean Donelan wrote:
> > > 'Fines alone aren't enough:' FCC
threatens to blacklist voice
> > > providers for flouting robocall rules
> > >
> > >
https://www.cyberscoop.com/fcc-robocall-fine-database-removal/
> > >
> > > [...]
> > > “This is a new era. If a provider
doesn’t meet its obligations under
> > > the law, it now faces expulsion from
America’s phone networks. Fines
> > > alone aren’t enough,” FCC chairwoman
Jessica Rosenworcel said in a
> > > statement accompanying the
announcement. “Providers that don’t follow
> > > our rules and make it easy to scam
consumers will now face swift
> > > consequences.”
> > >
> > > It’s the first such enforcement
action by the agency to reduce the
> > > growing problem of robocalls since
call ID verification protocols
> > > known as “STIR/SHAKEN” went fully
into effect this summer.
> > > [...]
> >
> > Why did we need to wait for STIR/SHAKEN
to do this?
> >
> > Mike
> >
>
>
