- VoiceOps - lists.voiceops.org

[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

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

July 20, 2022

What mail client are you using? Prior to Monday afternoon, "Sender" was voiceops-bounces@ (as it still is), "From" was the actual sender, "To" was (as you'd expect) voiceops@, and "Reply-To" was not set (unless perhaps the sender set it in their mail client? not sure if that was getting preserved or stripped). In this configuration, Outlook would reply to the sender if I hit Reply, or to both the sender AND the list if I Reply To All. Okay, fine. At least there is a one-button solution to auto-filling the list as one of the destination addresses. Since Monday afternoon, though, "From" is now getting overwritten to voiceops@, and "Reply-To" is being set to the original sender. A sign that "Reply-To munging" is occuring. In this configuration, as described in the post I linked to earlier, Outlook apparently honors the "Reply-To" header and *only* that header, as it doesn't matter if I hit Reply or Reply To All: only the original sender's address gets filled in the To field. I have to now manually backspace that out, and replace with the voiceops list address (assuming I even notice it and am not running on autopilot). (I suppose Outlook's behavior From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Carlos Alvarez via VoiceOps Sent: Tuesday, July 19, 2022 4:30 PM To: voiceops at voiceops.org Subject: Re: [VoiceOps] Mailman 'Reply-To' munging (was: Re: 9-8-8 dialing [...]) 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

1 0

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

July 19, 2022

Jay Hennigan wrote: > Kinda, sorta. 7-digit local dialing is supposed to have been phased out, > with all NANP numbers represented as 1+NPA-NXX-XXXX. Whathuh? Maybe I misunderstand you, but assuming not & in my experience, copper POTS trunks in NANP areas with mandatory *10* digit dialing (which should be virtually everywhere by this point) and where long-distance billing is still a thing not only allow local calls to be dialed without the 1 prefix, but even mandate it. Indeed, the old convention of "dialing a 1 implicitly means domestic long-distance" is still in full force on many POTS subscriber lines nationwide: if you try to dial a local number with a 1, the call won't be connected & instead you'll get back SIT + intercept message instructing you to re-dial *without* the 1. (And likewise dialing a long-distance call as 10-digits will present intercept with instructions to re-dial *with* the 1.) This convention is handy for those who still get charged for long-distance, as you can't accidentally dial long-distance unknowingly and get surprised by extra charges: the 1 is essentially you approving of the charges that you know you'll incur if the call goes through. That said, *we* don't distinguish between or charge our customers differently for local / intra-LATA / long-distance, so we do set things up for them such that any domestic call will connect either with or without the 1 as a convenience (much like most mobiles allow for)...especially since many of them are coming to us *from* old POTS trunks, and have that dialing habit very much ingrained. But 10-digit dialing (vs. 11-digit) is absolutely a thing. And since even intra-LATA long-distance has itself existed for decades, and always required dialing the full 11 digits even if the destination number is in the same NPA as the caller's, the only actual change was going from 7 to 10 digits for local calls. > On 7/18/22 08:36, Carlos Alvarez wrote: > > OP makes his own points against it, and none for. As we add more and > > more short numbers and possibly NPAs, the 9 becomes more problematic. > > And is there really a switch out there in use today that needs it? > > Pretty much any conventional PBX where you have conventional phones and > don't want a timeout. Even most SIP phones don't have a SEND button even > though the INVITE is en-banc under the hood, so you need a dialplan with > a timeout. > > IMHO, 9-8-8 is a boneheaded idea as it breaks NANP and causes ambiguity. > In addition now that it's law look for all kinds of other mandated > service codes. Lost your cat, dial 9-7-7. Need a jump start, 9-6-6, > Alcoholics Anonymous 9-5-5, etc. Exactly & here we are in complete agreement. Carlos seems to be approaching this discussion from a perspective where modern endpoints are ubiquitous, which is fine and all, but it's simply not reality. The number of old key systems and PBXes out in the wild that are still in active use is not inconsequential and cannot be ignored. We routinely come in to a new customer's facilities *only* to replace existing dialtone, because all they are after is better pricing / better support / etc. and their existing phone system "still works fine and we have no desire to forklift it out at present, thank-you-very-much". This often means handing off to it via multi-port ATA or (best-case but rare) PRI. (And just between you and me, these customers are actually my favorite, since the support load is much reduced: Need something changed or fixed on your PBX? Then call your phone system guy. Not our problem. Also, no lengthy re-training/re-learning process, since everything continues to work the same way that they're already used to. Hook service up, port numbers over, start billing.) Carlos Alvarez wrote: > Our user instructions have been telling them to dial like a cell phone > for over ten years. So they do have a defacto send button; dial and > then pick up the handset or press the speaker or headset button. > Acceptance and adoption has been great. It was harder to get people to > do this in 2005, but everyone gets it now. Hah well (genuinely) good for you. IME it is hard to break people of some of these habits. And without the outside line prefix, those who insist on picking up the handset first to get the (simulated) dialtone have to face the interminable dialing timeouts. I suppose you just take the position that if they want to avoid that, it's a simple matter of being willing to change how one does things, and that's how you've re-trained end users, but I guess we just tend to get the stubborn complainers?... Most IP handsets will allow you to craft a digit map that inserts digits before the INVITE is sent to the PBX. So to achieve the "best of both worlds", in instances where we install IP handsets, we usually continue to use 9 as outside line prefix, but have the phone insert the 9 for the user if the NANP number is pre-dialed before user picks up the handset. That way, you still get quick intercom dialing for those who insist on picking up the handset first, but anybody who is willing to change their habits automatically receives the benefit of not having to dial the 9 anymore. Anyway. All this to say that offering 988 (vs. 9-988) on just about any modern system, with or without an outside line prefix, is no problem. But doing so without a lengthy dialing timeout for those users who insist on picking up the handset first is not practical, given the digits that overlap with valid NPAs. But I don't really see this as a problem, since waiting a few extra seconds for a 988 call to connect is not in the same league as waiting for a 911 connection. -- Nathan

6 6

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

July 19, 2022

(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.) Hunter Fuller wrote: > Look. I get that the dial-9 thing is not how you would build a system > today, but what I'm trying to say is this: > If the current way worked for decades, through multiple phone system > forklifts, enabling us to not retrain our users; and if 988 is the > first time we have ever had any issue with it; then at what point > Exactly were we "supposed to" have "seen the light" and migrated away > from it? And what value would it have brought us at that time? > > It's not like our users are constantly getting confused by this. We > dispatch an email to new employees with basics on using the phone, and > not once has anyone ever found it confusing or difficult. Some of > these users will have dialed their desk phone the exact same way for > THIRTY YEARS (not an exaggeration). What value does it bring me to > shake it up, aside from giving them the ability to dial 988 without a > delay? Is there even one other benefit? I am genuinely grasping here. I'm generally sympathetic with this position, actually. As I said before, I prefer *not* to replace customers' existing phone systems, and that way there is no re-training nor taking on the role of supporting a replacement system. And if/when we do replace somebody's aging PBX, I want to remove as much friction as possible and add as few things to the canned training spiel as possible: get in, install the thing, show somebody the basic ropes as quickly as possible and with as few disclaimers as possible, and get out. We have a tough enough time just with things like "this is how voicemail now works" and "sorry no, we are *not* going to try to emulate your outgoing key system: you must now either do extension-to-extension transfer, or call parking", heh. So if it is relatively easy to accommodate older (and established/habitual) usage patterns alongside newer ones all without creating tons of extra work for us, we will. Carlos Alvarez wrote: > Right, and their switch traps the 9 so you don't have to route it. I > may be mistaken, but thought the original question was about routing on > a modern switch, where the 9 is not relevant. I went back & read through the prior posts, and can't find anything that affirms your assumption. Yes agreed, in the particular scenario I laid out there, we don't have to worry about the 9. What I was responding to, though, was your rhetorical question re: whether "there [is] really a switch out there in use today that needs [an outside line prefix]", and pointing out that at least anecdotally, yeah: there are plenty. I gather that there are many "operators" of all stripes that subscribe to this list: systems integrators, service providers, a little of columns A and B, etc. And though the OP himself didn't say one way or the other, there are clearly people responding to this thread who are actively supporting older systems. > Weird, pretty much every old PBX I ran into had the fax lines on it, > and sometimes even alarm lines on it. One of my early trainings with > alarm panel integration, in the 90s, was all about coordinating the > dial-9 rules. > > I'm old, and maybe you mean more recently. I know we did a dial 9 in > the early 2000s, now I can't remember when most people dropped it. I am mostly talking about customers whose dialtone we took over servicing within the last 10 years. But these were also phone systems that had been installed 5-10 years or more prior to when we got there, sooo... I guess I should clarify that the vast, vast majority of these are small businesses in a fairly rural context. Typically with maybe 3-4 POTS trunks, including the fax line. (And yes, often we will see alarm circuit sharing a line with fax. Just that neither are touching the main KSU at all, and [thus] have no shared line appearances on any of the handsets.) Heck, at our own office, before we moved over to all-IP, our prior system which had been installed in the early 2000s was a Nortel MICS with roughly 16 POTS trunks (why it wasn't T1, no clue...this whole thing was installed well before my time). Same situation: fax line completely separate. -- Nathan

1 0

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

July 18, 2022

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

8 15

Calls coming up as spam on mobile carriers
by shawn＠rmrf.us July 10, 2022

July 10, 2022

We're having a strange one at $dayjob. When one of our customers (in this case a hospital) calls a patient back on a cell phone, the calls are coming up with SPAM? in the caller id. It seems to be happening with both Verizon and AT&T. We've checked the the DIDs in question have and are sending the proper caller id, checked the Neustar database, etc. and can't find anything that's missing. These are TDM calls. They come in over multiple TDM PRIs and leave toward an AT&T tandem on a legacy TDM trunk group, so there's really no way to do STIR/SHAKEN call attesting. Our switch vendor (Ribbon / Genband / Nortel) also mentioned that they've had other clients with the issue and it seems to be limited to calls placed to mobile carriers. Another telco was able to find an AT&T portal to register the numbers as legitimate, but it only lasted for about a month before they had to do it again. I haven't researched where at AT&T they might have entered the numbers, but that doesn't seem like a valid option for a hospital with a thousand numbers. Just wondering if others have seen this, and if anyone knows of a way to resolve it. thanks

9 8

OpenLI
by jbrower＠signalogic.com July 8, 2022

July 8, 2022

Is anyone using OpenLI (https://www.openli.nz, https://github.com/wanduow/openli) ? We have added support for OpenLI generated HI2 and HI3 output and verified with a few of the LEAs (or their contractor)s we work with, but so far only with outputs provided by OpenLI guys. We're looking for CSPs using it who would like to test their setup (no charge). -Jeff

1 0

Identity Header Test Tool
by dfrankel＠zipdx.com July 7, 2022

July 7, 2022

Last week I was forwarded a note from this list regarding tools to test and debug SHAKEN Identity headers. That prompted us to stitch together some modules we already had in an attempt to help. What we have is at http://identity.legalcallsonly.org. You can call one of the test numbers listed on that page, and if we receive your header, we'll read you a six-digit code. Disconnect and then plug the code into the box on the web form, and we'll show you details of that Identity header. Perhaps most importantly, you'll be able to see if the header we received is the one you sent. In addition, we parse the header and try to tell you if it is correctly formatted and valid. Currently we have a couple of geographic DIDs and three toll-free numbers (each using different underlying providers). So far we aren't having a lot of success getting the Identity headers on the TFNs; we're working to improve that. Suggestions welcome. We hope the tool provokes more discussion about best practices regarding making the Authentication Framework as functional and useful as possible. Happy 4th of July! David Frankel ZipDX LLC St. George, UT USA

14 21

TCPA SMS Short Code Spam Violations: Recommended Law Firm for Suit?
by beckman＠angryox.com July 6, 2022

July 6, 2022

One of my customers attempted to opt-out of some SMS Short Code campaign, sent "STOP" and several other attempted keywords, all of which were ignored, until we escalated with the carrier. 164 total SMS messages were sent to the customer AFTER sending STOP to the short code over several months. $82,000 worth of fines. I'd like to ensure that the senders are fined. Can anyone recommend a firm to handle the TCPA violations law suit? I'm in the Washington DC area and would prefer local, but will take a good firm anywhere. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------

1 0