Inter-telco trunks aren’t all SIP, you might be surprised how much “traditional” trunking there still is.
> On Oct 4, 2022, at 3:18 PM, Michael Thomas <m...@mtcc.com> wrote: > > > > >> 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> >>>> To: "Michael Thomas" <m...@mtcc.com> >>>> Cc: "Mike Hammett" <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> >>>>> To: "Michael Thomas" <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 >>>>>> > > >>>>>> > >>>>>> > >>>>> >>>>
