- VoiceOps - lists.voiceops.org

Numbers listed as spam by Hiya
by dovid＠telecurve.com Aug. 24, 2022

Aug. 24, 2022

Hi, We primarily purchase numbers from Telnyx and Peerless. Lately any number that we purchase is automatically listed as spam. I searched through both of their stocks for random numbers in random area codes (50+ numbers) and every time Hiya says it's likely SPAM. I presume they are marking any carrier where it's easy to get numbers spam. Has anyone fought back against this or are people just going with larger carriers like inteliquent/VZ etc? Regards, Dovid

4 5

Numbers listed as spam by Hiya
by caalvarez＠gmail.com Aug. 24, 2022

Aug. 24, 2022

How? I have no idea, all I can tell you is the experience we see. Maybe Fred's comment has some merit if Peerless is either allowing actual spam, or re-assigning numbers too quickly (for new numbers). Your porting experience is something I haven't seen, but we haven't mass-moved numbers in a long time. If Peerless is the common denominator... Oh, wait, have you checked the attestation level for these calls? Are the calls with a Peerless DID going out via Peerless? On Wed, Aug 24, 2022 at 7:33 AM Dovid Bender <dovid at telecurve.com> wrote: > How is Bandwidth on top of this? We currently have about 18k DID?s with > peerless. The issue is since most are DID?s that were allocated to > Peerless, even if we port them out they will still be spam. Two interesting > numbers come to mind > 1) My personal number (which I never use for CLI) was form RNK. I ported > the number to a LEC in NYC and then eventually to Peerless. Once RNK went > away the range it was in was re-assigned to Peerless. That number is listed > as spam. > 2) I have another personal number that started at Verizon and was ported > to Peerless. That number is NOT listed as spam. > > The short term solution seems to be to get DIDs whose range is not > defaulted as spam and then port them to Peerless/Telnyx etc. > > On Wed, Aug 24, 2022 at 10:16 Carlos Alvarez via VoiceOps < > voiceops at voiceops.org> wrote: > >> We've had a lot of numbers from thinQ show up as spam right away, and a >> small number from Bandwidth. Generally though, Bandwidth is pretty good on >> this. It's possible (not an accusation) that the aggregators are recycling >> numbers quickly. We have a couple of customers who do legit outbound >> business dialing and get marked as spam, so they rotate a lot of numbers. >> This creates the problem if we or our carrier were to sell any of those to >> others too soon. >> >> I don't know what your volume is, but for us Bandwidth was far less >> expensive than Telnyx. Around 8k DIDs and half a million minutes. Pretty >> small, but within the BW minimums. >> >> >> On Wed, Aug 24, 2022 at 7:04 AM Dovid Bender via VoiceOps < >> voiceops at voiceops.org> wrote: >> >>> Hi, >>> >>> We primarily purchase numbers from Telnyx and Peerless. Lately any >>> number that we purchase is automatically listed as spam. I searched through >>> both of their stocks for random numbers in random area codes (50+ numbers) >>> and every time Hiya says it's likely SPAM. I presume they are marking any >>> carrier where it's easy to get numbers spam. Has anyone fought back against >>> this or are people just going with larger carriers like inteliquent/VZ etc? >>> >>> Regards, >>> >>> Dovid >>> >>> >>> >>> _______________________________________________ >>> VoiceOps mailing list >>> VoiceOps at voiceops.org >>> https://puck.nether.net/mailman/listinfo/voiceops >>> >> _______________________________________________ >> VoiceOps mailing list >> VoiceOps at voiceops.org >> https://puck.nether.net/mailman/listinfo/voiceops >> >

2 1

Splitting voice and SMS
by caalvarez＠gmail.com Aug. 19, 2022

Aug. 19, 2022

We had an odd customer request, via a vendor trying to provide them with automated scheduling services via SMS. They are asking us to "release the SSID" to allow them to do SMS on the number, but we keep the voice. I'm unaware of this ability, and they even said that so far, most carriers won't even discuss it with them. Their service rides on the Twilio API, and I *think* Twilio uses Bandwidth. This number is currently with Bandwidth. So I don't know if that might make a difference.

5 6

MVNO Porting, Port Protection/Freeze vs PIN Rejection
by nathana＠fsr.com Aug. 3, 2022

Aug. 3, 2022

Maybe socially-engineered SIM hijacks are on the rise, and this is some kind of an attempt by them to curb it? -- Nathan -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Peter Beckman via VoiceOps Sent: Monday, August 1, 2022 10:55 PM To: VoiceOps Subject: [VoiceOps] MVNO Porting, Port Protection/Freeze vs PIN Rejection I do a couple hundred ports per month. Most go through without an issue, though most are with larger carriers. Lately Verizon (and maybe other) MVNOs have this terrible process: 1. Submit the request to move the number 2. Reject it, send the customer a "new PIN", then give that to us 3. We resubmit with the new PIN, magically the "freeze" is removed and we get FOC The fact that we have to give specific instructions for every single carrier and that each carrier is constantly changing the process AND not documenting the process is infuriating to both customers and the winning carriers. This whole MVNO reject-then-generate-PIN BS is pretty bad. Straight Talk, SafeLink, Total Wireless ... ARGH Anyone know what's up with this assinine process? Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------

1 0

MVNO Porting, Port Protection/Freeze vs PIN Rejection
by beckman＠angryox.com Aug. 2, 2022

Aug. 2, 2022

I do a couple hundred ports per month. Most go through without an issue, though most are with larger carriers. Lately Verizon (and maybe other) MVNOs have this terrible process: 1. Submit the request to move the number 2. Reject it, send the customer a "new PIN", then give that to us 3. We resubmit with the new PIN, magically the "freeze" is removed and we get FOC The fact that we have to give specific instructions for every single carrier and that each carrier is constantly changing the process AND not documenting the process is infuriating to both customers and the winning carriers. This whole MVNO reject-then-generate-PIN BS is pretty bad. Straight Talk, SafeLink, Total Wireless ... ARGH Anyone know what's up with this assinine process? Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------

1 0

Anti-robocall/compliance solutions
by calvin.ellison＠voxox.com July 29, 2022

July 29, 2022

Not an ad, just context: We're offering our internal anti-robocall filter as a compliance solution for other transit carriers and gateway/point of entry carriers. This includes DNO filtering, reputation/fraud/compliance scoring, LNP-adjusted neighbor spoofing, and some other magic. It is implemented as a SIP or API endpoint that is dipped as early as possible in the call flow. Our internal tool works well for our own purposes, but that doesn't mean it is fit for others as-is. For example, we put all the data in a search index to perform ad-hoc queries, create visualizations, and build dashboards. Is that useful to anyone else? Would other carriers prefer file-based reports sent by email or alerts via webhook, or want the data sent to their own backend? What would others expect from a user interface? Does anyone care what technologies are used internally? What about latency, pricing, and on-premise versus cloud? The list goes on. There's plenty of information online about product design in general, but not so much about what transit carriers actually need or want from a product like this. I'd especially like to hear from anyone that is still shopping for a solution, doesn't like the one they chose, or absolutely loves theirs and wants to share the reasons why. If anyone is interested in beta-testing our existing in-house solution to give feedback, please contact me off-list. Calvin Ellison Systems Architect calvin.ellison at voxox.com +1 (213) 285-0555 <http://voxox.com> <https://www.facebook.com/VOXOX/> <https://www.instagram.com/voxoxofficial/> <https://www.linkedin.com/company/3573541/admin/> <https://twitter.com/Voxox> The information contained herein is confidential and privileged information or work product intended only for the individual or entity to whom it is addressed. Any unauthorized use, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify me immediately.

2 1

9-8-8 dialing when an outside line access code (9) is being used
by David.Zilk＠cdk.com July 20, 2022

July 20, 2022

It turns out the FCC has already covered this in their rulemaking for 9-8-8<https://www.federalregister.gov/documents/2020/09/16/2020-16908/implementat…>. ?We decline to adopt a proposal to require multi-line telephone systems (MLTS) to allow callers to reach the Lifeline by dialing 988 and no other digits.? (I believe that ?allow? in the quote above should really be ?require?.) They go on to explain that they are given the authority to require this for 9-1-1 by Kari?s Law, but that they lack a similar authority with regard to 9-8-8. So, while it is not required for MLTS to support both 9-988 and 988. I still feel that it is a good idea to do so if feasible. David Zilk From: Brandon Svec <bsvec at teamonesolutions.com> Sent: Friday, July 15, 2022 9:21 AM To: Zilk, David <David.Zilk at cdk.com> Cc: VoiceOps at voiceops.org Subject: [EXTERNAL] Re: [VoiceOps] 9-8-8 dialing when an outside line access code (9) is being used CAUTION: This email originated from outside of the CDK organization. Exercise caution when clicking links or opening attachments, especially from unknown senders. It shouldn't be much different than 911. 9911 and 911 can both work just as 9988 and 988 can both work fine with most any PBX that can translate dial plan digits. There is potential conflict with systems that can't handle inter-digit timeouts to allow both 988 and 9888-555-1212, I guess. But in that case I suppose the expectation would be to dial 9988 and 9911 already.. Brandon On Fri, Jul 15, 2022 at 8:10 AM Zilk, David <David.Zilk at cdk.com<mailto:David.Zilk at cdk.com>> wrote: How are folks dealing with allowing calls to 9-8-8 when an access code of 9 is used. Does this not cause a conflict when calling toll free numbers beginning with an NPA of 88x? David _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops<https://urldefense.proofpoint.com/v2/url?u=https-3A__puck.nether.net_mailma…>

1 0

Mailman 'Reply-To' munging (was: Re: 9-8-8 dialing [...])
by nathana＠fsr.com July 20, 2022

July 20, 2022

Did you actually read the discussion that I linked to? https://mail.python.org/pipermail/mailman-users/2014-August/077673.html To quote from it: > > [...] Outlook sends Reply All to the original sender and anyone > > else that was Cc'd, but not the list. > > > > Is there a fix? Which other variables affect this? > > No, there is no fix. Both behaviors are arguably RFC conforming (the > RFC doesn't specify "Reply to All" behavior of MUAs, so the MUAs can > do whatever they want), and Outlook's is arguably more conformant to > the spirit of the RFC, since according to the RFC the configuration > > From: list at example.com > Reply-To: person at example.org > > has the semantics "the entity using the mailbox 'list at example.com' > requests that you address mail intended for the entity to the mailbox > 'person at example.org'". -- Nathan -----Original Message----- From: J. Hellenthal [mailto:jhellenthal at dataix.net] Sent: Wednesday, July 20, 2022 7:29 AM To: Nathan Anderson Cc: Voice Ops Subject: Re: [VoiceOps] Mailman 'Reply-To' munging (was: Re: 9-8-8 dialing [...]) "Reply-To in different ways" ? It means one thing... am I missing a mail client that does not follow this ? > On Jul 20, 2022, at 06:24, Nathan Anderson via VoiceOps <voiceops at voiceops.org> wrote: > > "Reply-To" in different ways -- J. Hellenthal The fact that there's a highway to Hell but only a stairway to Heaven says a lot about anticipated traffic volume.

1 0

Mailman 'Reply-To' munging (was: Re: 9-8-8 dialing [...])
by nathana＠fsr.com July 20, 2022

July 20, 2022

Nathan Anderson wrote: > (Quick off-topic note: did some setting on VoiceOps mailman get changed > halfway through the morning? "From:" now shows voiceops list address > instead of original sender's -- which I'm fine with -- but then > "Reply-To" is getting added and set to sender. So I now have to add > voiceops address to "To:" or "CC:" manually if I want my reply to go to > the list. Not cool.) $%@#$%!#$ https://mail.python.org/pipermail/mailman-users/2014-August/077673.html Sounds to me like 'from_is_list' now == 'munged', and this is how Outlook behaves in this situation. Rrrrgh, -- Nathan

4 5

Mailman 'Reply-To' munging (was: Re: 9-8-8 dialing [...])
by nathana＠fsr.com July 20, 2022

July 20, 2022

Since it appears that various mail clients deal with the existence of "Reply-To" in different ways, it's honestly a bit frustrating that this isn't configurable per-subscriber within Mailman, instead of implemented strictly as a list-wide setting. Otherwise I could just log into my member options page for this list & configure it in a way that works for me. -- Nathan -----Original Message----- From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Alex Balashov via VoiceOps Sent: Tuesday, July 19, 2022 4:38 PM To: Carlos Alvarez Cc: voiceops at voiceops.org Subject: Re: [VoiceOps] Mailman 'Reply-To' munging (was: Re: 9-8-8 dialing [...]) Indeed. The default destination of a reply should be the list, which is accomplished by the following Mailman config options: from_is_list = 0 reply_goes_to_list = 1 ??? Alex > On Jul 19, 2022, at 7:29 PM, Carlos Alvarez via VoiceOps <voiceops at voiceops.org> wrote: > > If I do a reply on this list, it always puts the sender as the recipient, not the list. This is remarkably stupid. If I do a reply-all then it puts the list on CC and the sender in TO. > > > On Tue, Jul 19, 2022 at 1:03 AM Nathan Anderson via VoiceOps <voiceops at voiceops.org> wrote: > Nathan Anderson wrote: > > > (Quick off-topic note: did some setting on VoiceOps mailman get changed > > halfway through the morning? "From:" now shows voiceops list address > > instead of original sender's -- which I'm fine with -- but then > > "Reply-To" is getting added and set to sender. So I now have to add > > voiceops address to "To:" or "CC:" manually if I want my reply to go to > > the list. Not cool.) > > $%@#$%!#$ > > https://mail.python.org/pipermail/mailman-users/2014-August/077673.html > > Sounds to me like 'from_is_list' now == 'munged', and this is how Outlook > behaves in this situation. > > Rrrrgh, > > -- Nathan > > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops > _______________________________________________ > VoiceOps mailing list > VoiceOps at voiceops.org > https://puck.nether.net/mailman/listinfo/voiceops -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops

2 1