- VoiceOps - lists.voiceops.org

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

[External] Re: 9-8-8 dialing when an outside line access code (9) is being used
by nathana＠fsr.com July 20, 2022

July 20, 2022

Carlos Alvarez wrote: > Do your users still dial 9 from their fax machines? Not sure if serious or "haha your users probably still use fax machines" joke. So I'll give a serious answer just in case: I can't recall ever running across a single instance of someone who has their fax line routed through their "conventional" PBX. So they never dialed 9 from their fax machine to begin with. And also since nobody expects to be able to dial local extensions from their fax machine, we set up a separate dialing plan for the fax port on the ATA that does not require the external line prefix. -- Nathan

5 10

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

July 20, 2022

I have never heard of this. What LATA are you in? Can you give an example NPA where you know this to be the case? As a consumer, if I were subscribed to ILEC without bundled long-distance, I would find such an arrangement both confusing and infuriating. Especially with near-universal mandatory 10-digit dialing. So you're saying that I can dial two numbers within the same area code the exact same way, but one destination is charged as a local call and the other as long-distance? What if I fat-fingered something while dialing (intending to dial a local destination but being off by one digit in the NXX) & the call connected? What if I was simply unaware that a given destination was long-distance? This sounds like a terrible idea all the way around. Was this also the case back when 7-digit dialing was still possible? You could reach a long-distance destination within your same NPA by only dialing 7 digits? -- Nathan -----Original Message----- From: James Cloos [mailto:cloos at jhcloos.com] Sent: Tuesday, July 19, 2022 10:01 AM To: VoiceOps Cc: Nathan Anderson Subject: Re: [VoiceOps] [External] Re: 9-8-8 dialing when an outside line access code (9) is being used NA> This convention is handy for those who still get charged for NA> long-distance, as you can't accidentally dial long-distance unknowingly NA> and get surprised by extra charges: except thsat it is 10 for the same npa and 11 for other npas, irreguardless of whether the call costs anything. at least in the npas w/ which i am familiar. so the 10 instead of 11 provides no value. -JimC -- James Cloos <cloos at jhcloos.com> OpenPGP: 0x997A9F17ED7DAEA6

1 0