Re: [VoiceOps] Nextiva & Poly ZTP

[Mike Johnston via VoiceOps]

On 2024-07-16 13:43, Mark Wiater via VoiceOps wrote:
My issue was resolved a short bit after I sent this email to the list. 
If the timing is not coincidence, thank you to whoever nudged it.


Good to hear it!
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Nextiva & Poly ZTP

[Mike Johnston via VoiceOps]

On 2024-07-16 07:45, Mark Wiater via VoiceOps wrote:
I've got a former customer of theirs wanting to bring phones and need 
them removed from the Nextiva ZTP instance, support seems to not know 
what I'm talking about.


If you are self-hosting the config for the Poly configs, then you 
arguably would not "need" to have Nextiva do anything.  You could do a 
factory reset of each phone and then provision the phones how you 
normally would.


We do not use ZTP with our Poly phones, so the next paragraph is just 
speculation...


I'm assuming Poly won't allow a phone to be in more than one ZTP 
instance at a time.  So if you want to have the phones in your ZTP 
instance, then I suppose Nextiva needs to release them from their ZTP 
instance, first.  Thus, your request for Nextiva support makes perfect 
sense, at least to me.



i was hoping to find a clueful person at Nextiva


Unfortunately, I do not have any contacts for you.

Good luck, though!
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Nortel Equipment

[Mike Johnston via VoiceOps]

Maybe check with the Connections Museum in Seattle?  With their recent 
acquisition of a DMS-10, they might be interested.


https://www.telcomhistory.org/connections-museum-seattle/



On 2024-02-26 15:34, Ronald Loneker via VoiceOps wrote:

Hi Everyone -

Not sure where to find a home for this, but we still have our old 
Nortel Meridian PBX system we moved off of in 2016.


Not sure if there's a market for this or a recycler who would take it 
so I'm reaching out to see if anyone on this list might have ideas 
that I can present to our administration..


We still have components hanging in IDF closets as well.

Ron Loneker, Jr.
Director, IT Special Projects
Saint Elizabeth University
Mahoney Library
2 Convent Road
Morristown, NJ  07960

e-mail: rlone...@steu.edu


/*Saint Elizabeth University's IT department will never ask for your 
password, social security number or other personal information in an 
e-mail message.

*/
/*Please do not share any information with others!*/






___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Spike in customers numbers showing SPAM?

[Mike Johnston via VoiceOps]

We had two reports on 2024-01-25.  Both were reporting that Verizon 
cellphone recipients would see "Potential Spam" if they called from 
their main number.


One is a manufacturer in one of our ILEC exchanges, OCN 1505. The other 
is a school in one of our CLEC exchanges, OCN 914F.


These are A attested and signed SIP calls via Inteliquent.

Later on 2024-01-25, I asked Inteliquent, in a ticket, if they knew of 
any changes with their interconnect(s) with Verizon, or anything else 
that might be causing the change.  They did not have any insight for 
us.  Instead, they suggested the subscribers go to 
https://voicespamfeedback.com/vsf/
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] troubleshooting RTP loss - and does anyone use webair/opti9?

[Mike Johnston via VoiceOps]

mtr
https://en.wikipedia.org/wiki/MTR_(software)

It isn't specific to VoIP.  But it is still a very good first step in 
troubleshooting which hop the packet loss begins at.  Unlike the basic 
traceroute tools that come with Linux or Windows, it can run 
continuously for however long you need, even days.  This can be 
especially useful if the packet loss is intermittent.

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Voice Peering

[Mike Johnston via VoiceOps]

Who can source email from a domain is more-or-less a solved problem by 
using DNS SPF records.


An SPF record is a list of IP addresses[1] that is allowed to send email 
for a domain.  When an email server receives an email, best practice is 
to do a DNS lookup for the SPF of the alleged sender domain.  If the 
server attempting to send the email is not mentioned in the SPF, then 
you can reject the incoming email.


Does anybody know if something like SPF has been adapted to voice?

For example, say anything from 54.239.16.0/24 is allowed as that is 
where your phone switches are.  And 20.112.88.88/29 can also make calls, 
as that is one of those School Auto-Dialer services[2].  (Or whatever, 
make up your own scenarios.)


When you receive calls, you would need to do a DNS lookup to get the 
list of allowed senders.  If it's not in the list, reject the call.


The exact query, and who we are querying, is a good question, though. 
Who owns the phone number?


Anyways, say your system is getting a call from 555-555-1234.  So you do 
a DNS query against...I do not know.


  dig TXT 4.3.2.1.5.5.5.5.5.5.i-do-not-know.

And say you got this back from the DNS query:

  "v=spf1 ip4:54.239.16.0/24 ip4:20.112.88.88/29 -all"

If the server sending you the call is not in 54.239.16.0/24 or 
20.112.88.88/29, then reject the call.


[1] An SPF record can have more than just IP addresses, but can also 
"include" other domain names.
[2] You might do your DNS in such a way, that 20.112.88.88/29 is only 
returned for the specific number(s) that you expect them to be sending 
from, not ALL of your numbers.


Further reading:
https://en.wikipedia.org/wiki/Sender_Policy_Framework
https://www.cloudflare.com/learning/dns/dns-records/dns-spf-record/
https://support.google.com/a/answer/10685031?hl=en
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] SS7 Landscape

[Mike Johnston via VoiceOps]

On 2023-10-24 15:11, Mike Hammett wrote:

Recommend\don't recommend?
Anything to watch out for?

The offer I got was attractive, but not everything that's attractive 
is what it seems.




We used to have Onvoy/Inteliquent SS7 via TDM, which was reliable.  Two 
A-Links, to two geographically diverse STPs.  When faults did occur, it 
was almost always with a carrier in the middle (e.g., a fiber cut).



We are trying to move away from T1s.  But some telcos that we 
interconnect with have not yet realized the benefits of SIP.  As such, 
we still need SS7, in some form or another.  Also, our LNP lookups are 
over SS7.



Several months ago we migrated to SIGTRAN, staying with Inteliquent, now 
called Sinch.  They helped us through the migration process, which went 
quite smooth overall.



The IP connections are over VPN tunnels, to two geographically diverse 
VPN endpoints.  We connect to two geographically diverse STPs through 
those VPN tunnels (one STP per VPN tunnel).  One thing that I don't 
like, though, is that the VPN endpoints are not located near the STPs.  
The STPs are located somewhat near me (same state & next state over), 
but the VPN endpoints are multiple states away, meaning the IP traffic 
trombones around the US.  This has not caused us any actual problems, 
though.



In general, yes, I would recommend Inteliquent/Since for SS7/SIGTRAN.  
They have been good to us, and reliable.



Note: I was not involved in any of the money conversations.  Just the 
technical conversations.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] SS7 Landscape

[Mike Johnston via VoiceOps]

Yes.  Any particular questions?


On 2023-10-24 08:18, Mike Hammett via VoiceOps wrote:

Any experience with Inteliquent for SS7\SIGTRAN services?



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com



Midwest Internet Exchange
http://www.midwest-ix.com




*From: *"Mike Hammett" 
*To: *"voiceops" 
*Sent: *Saturday, January 22, 2022 9:00:04 AM
*Subject: *SS7 Landscape

We currently get our SS7 via TNS. I (maybe incorrectly) understand 
them to be a big dog in that space.


I've had two major problems with them in six months.

What are my alternatives? Are they less pleasant?



-
Mike Hammett
Intelligent Computing Solutions
http://www.ics-il.com



Midwest Internet Exchange
http://www.midwest-ix.com





___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] A2P-aaS

[Mike Johnston via VoiceOps]

That's what we use for automated notifications to on-call techs of P1 
tickets.  We wrote code to email a short message to the appropriate 
domain.  This list we use is Inteliquent's:


https://help.inteliquent.com/sending-emails-to-sms-or-mms

For example:
  AT: num...@txt.att.net (SMS), num...@mms.att.net (MMS)
  T-Mobile: num...@tmomail.net (SMS & MMS)
  Verizon: num...@vtext.com (SMS), num...@vzwpix.com (MMS)

We do an LRN lookup on the number, to know which one to use.

I'm not sure if we cache the LRN or not for this very specific 
application, since the ticket might be informing the tech that LRN 
lookups are broken/timing out.  And besides, our on-call employees are 
not changing their cell provider very often.


-Mike


On 2023-09-10 09:14, Jay Taylor via VoiceOps wrote:

Alex,

Would a smtp to sms gateway solve the sms delivery issue?

https://support-en.wd.com/app/answers/detailweb/a_id/44431/~/gateway-addresses-for-mobile-phone-carrier-text-message

Here's a list of quite a few smtp-sms gateway servers by cell provider.

I've not used it much but for the one time I did test it with t-mobile, I could 
even reply to an sms and have it come back to my email account.  I assumed it 
was just a one way service but I guess not always.

Good Luck!

Jay

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Directory Listings

[Mike Johnston via VoiceOps]

On 2023-08-21 17:16, Mike Hammett via VoiceOps wrote:
We've come across some legacy customers that have directory listings 
through us (or, well, at least we're paying Frontier for them).


 1. Are those a thing in the VoIP space? Can I go to {insert SIP
provider here} and they can place directory listings, unpublish
numbers, etc.?


I don't know.  But, see also: whatever 411 is/does/used to be.


 1. Are directories a thing anywhere anymore? I haven't seen a new one
in probably 15 years. I understand that I'm not the target
demographic, but I'm not even sure where I'd go (short of
Googling) to get one. Are we paying for something that has no
benefit anymore?

My employer has published a phone book every year for many decades.  
It's fun to look through old ones to find your childhood phone number, 
relatives, businesses that used to exist, etc. Every year they put a few 
pictures of employees around the book, which is fun for us.  Well, 
unless a full color photo of you doing "work" in a CO is featured on the 
back cover.  I've heard talk that the last one they published, might be 
the last.  Or maybe it won't be /every/ year any more.


I use mine at least weekly.  But I'm also referencing information other 
than phone numbers.  For example, we have a few pages discussing our * 
codes, with a handy table.


___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Carriers that support cic codes

[Mike Johnston via VoiceOps]

On 2023-08-04 09:37, Jeff Anderson via VoiceOps wrote:
If a SIP carrier wanted to support equal access, is there 
anything like a SIP tandem provider that can accept any Carrier 
Identification Code (cic=) and route to the appropriate LD carrier?


The TDM equivalent might be something like Neutral Tandem.


Yes, Inteliquent does this.  They will honor a cic= in your SIP INVITE, 
and route to the appropriate LD carrier.


___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Call term misrouting?

[Mike Johnston via VoiceOps]

On 2023-07-26 17:43, Paul Timmins via VoiceOps wrote:

I wouldn't be surprised to see carriers dumping these calls via a GSM gateway, 
this is really common in europe with gray routes. It'd explain why you get 
weird cellular voicemail, if they sent the number to the cell phone wrong to 
actually dial out.


I've heard of this!
In one instance, the call would come through every one in a dozen or so 
attempts.  And it would often have the wrong calling number.  Generally 
belonging to a cell provider.  Audio was not great and there was 
noticeable latency.  The call would only go for a few minutes before 
dropping.


I have on a couple occasions had the opportunity to have both phones 
sitting side-by-side.  A phone from a telco with "unlimited" shady long 
distance, and a phone from my telco.  I kept detailed logs of each call, 
with audio recordings of the fake voicemails, fake person talking 
through static, and so on.  They only have so many fake recordings, so 
they eventually repeat themselves.  We packaged up the logs and the 
audio files and sent it all to our PUC.  Got fixed real fast.  But just 
for that one company.

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Call term misrouting?

[Mike Johnston via VoiceOps]

I serve a rural area.  I do the technical "make it work" stuff.  I'm 
generally only involved in the business dealings insofar as determining 
technical incompatibilities (draw 7 red lines, all perpendicular, some 
with green ink and some with transparent).  That said, please forgive 
any errors in what I say, and feel free to correct me.


On 2023-07-26 08:28, Nathan Anderson via VoiceOps wrote:

...by which I mean, we send a call to a term provider via SIP, who then *seems* 
to terminate the call to the wrong callee entirely.

What the heck actually causes this?


A long distance carrier, generally an intermediate one, being shady. 
Here at my workplace, we call that carrier something like, "Bob's Shady 
Long Distance Shack."  Bob probably charges 1 cent per minutes, or less, 
as a flat rate.  When he gets calls for cellphones or urban areas, the 
calls might cost him 0.1 of a cent per minute, and Bob is doing good. 
But when Bob gets calls to rural areas that cost more than one 1 cent 
per minute, he doesn't like that.  It cuts into his profits.  So he does 
shady stuff.



Whenever I have experienced it, it inevitably involves a rural carrier of some 
kind, one that likely charges a lot to accept traffic.


"Charges a lot to accept traffic," makes it seem like a troll under a 
bridge, making up whatever rate they want to pass.  My understanding is 
that these rates were set by a process that involved distance, to help 
cover fixed infrastructure costs.  Thus, rural areas cost more to call.



Over the course of a few days, we just went through twelve rounds of having a 
wholesale term provider blacklist various carriers from their LCRs for calls 
headed to this particular exchange, before the problem stopped happening.


It seems that Bob's Shady Long Distance Shack is popular.  Either that, 
or there are multiple intermediate carriers in play.  For example, if 
you route a call to carrier A, they route the call to carrier I, who 
routes the call to carrier BOB.  If you try a different carrier, they 
might also send the call to carrier I, who will still send the call to 
carrier BOB.



"Is it working yet?"  "Nope."  "How about now?"  "Still nope."  And it's random 
and sporadic enough that I have to place a lot of test calls (as well as continue to field feedback from our end-users) 
before I can be sure that the problem is actually fixed.  It's aggravating...


I try to find numbers that go to IVRs, fax numbers, automated airport 
weather numbers, etc.  Anything that doesn't involve bothering a human 
over and over.  It has to be with the same OCN though, and generally 
needs to be in the same NPA-NXX too.


We have a test number with an announcement in every one of our assigned 
blocks.  It is the last number, such as  or 2999.  If you want to 
test, look up OCN 1505 and OCN 194F.  If you would like an exhaustive 
list of those numbers, email me off list.



It doesn't seem to be the final destination carrier that's screwing up the call routing 
after having received the call: I can call the same number over and over again through a 
"reputable" carrier, or via my personal cell (but I repeat myself), and get 
connected to the right destination every time.  Based on my experiences, I highly doubt 
the misdirected calls are even getting as far as the CO's switch for that exchange.


Correct.  If I had received the call, I would have routed the call.  I 
can't imagine why any rural telephone company would route calls to fake 
voicemails, fake announcements, static noises, etc.


I've even worked with my upstream on some calls, and they don't receive 
them either.  If they received the call, they would have sent it to me.



So I have to hypothesize that some sketch carrier getting is picked from an LCR 
table, one who just doesn't like sending the call to a rural carrier who either 
charges that much


The FCC has a page about this, by the way.

https://www.fcc.gov/general/rural-call-completion-problems-long-distance-or-wireless-calling-rural-areas

When working with your carriers, using the exact phrase "Rural Call 
Completion" should help.  And please, file reports with the FCC!  There 
isn't much the rural telephone companies can do at the receiving end, 
since we don't know about the calls we don't receive.



or that they suspect is engaging in fraud.


It's possible you are referring to this:
https://en.wikipedia.org/wiki/Traffic_pumping
Is that a thing that some rural telcos are still doing?


But...WHY *misroute* it?  I'd rather you just reject the call if you don't want 
to carry it.


I also want to know!  Don't offer to route calls you can't complete, right?


The misrouted calls in this latest case more often than not seemed to be hitting a 
foreign voicemail system that sounded an awful lot like AT Mobility's default 
voicemail greeting.


These are generally fake voicemails.  Just a recording of some voicemail 
intro, to make you think you hit a voicemail box.  The call hasn't 

Re: [VoiceOps] No-commit international calling

[Mike Johnston via VoiceOps]

On 2023-07-13 14:34, Ross Tajvar via VoiceOps wrote:
Looks like voip.ms  is one option. Does anyone have 
any other suggestions?


I use voip.ms for my personal tinkering.  I don't have much of a /need/ 
for them, since I operate an entire telephone company of my own (my 
employer's).  But I do use voip.ms on my FreeSWITCH server at home for 
some call scenarios.  For example, I have an 8xx number with them, to my 
house.  I have been happy with voip.ms.


I had a UK number with voip.ms for a few months, for testing purposes.  
It worked reliably, at least in the limited testing scenario we were 
using it for.


Other than that, most all of my voip.ms calls have been to US destinations.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] STIR/SHAKEN warning!

[Mike Johnston via VoiceOps]

On 2023-07-12 16:37, Nathan Anderson via VoiceOps wrote:
By the way, love your test tool service.  Thanks for putting it 
together and maintaining it...what a gift to the community. There are 
a handful of S/S testing tools out there, but yours is easily the most 
comprehensive...most just audibly read back to you whether or not your 
call was attested, and if so at what level.  Nothing about who signed 
it, whether the backing cert and entire chain of trust is valid or 
not, and so on, as yours does.  And since most other tests only 
provide one call-in number, if the call path between you and that 
testing tool happens to go through an intermediate carrier that strips 
out our PASSporT and either replaces it with their own or drops it 
entirely, tough noogies.  Whereas you provide multiple call-in numbers 
across multiple carriers, which not only provides opportunity to work 
around such issues, but gives you some idea of call paths that might 
be breaking transmission of your PASSporT and which ones are okay.  
Super helpful!


Yes!  I would like to second this!

Also, the ZipDX HD audio test number has been amazing!  The first time I 
was able to get G722 over a PSTN call, I was so excited, I called over 
coworkers to show them.  It's sad that interest in HD codec support is 
so sparse across carriers.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] dynect oracle end of life

[Mike Johnston via VoiceOps]

Wherever possible, we use RFC 2136, to the primary authoritative name 
server.  pfSense firewalls, for example, support RFC 2136 for Dynamic 
DNS (tracking the WAN IP when DHCP changes it) and for Acme Certificates 
(demonstrate control of the FQDN).  RFC 2136 is also a nice method for 
internal devices to get Let's Encrypt certs.


But you're not going to find RFC 2136 support very common.  You probably 
won't find it on many NVR units or cheap Netgear routers.

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] 911 Records of Inbound-Only TNs

[Mike Johnston via VoiceOps]

A maybe simpler example to what you are asking would be TEEN lines, 
where calling the TEEN number makes the parent station ring with a 
distinctive pattern.  The subscriber has no way of making an outbound 
call with that TEEN number.  Should we bother setting up a 911 record 
for that TEEN number?  You could argue either way.  If systems are 
automated and storing the extra records has little to no costs, then 
might as well create a 911 record for it.


We have some numbers where it's hard to determine what the 911 location 
would even be.  For example, a DN you call that just reads you back what 
phone number you are calling from.  The address of the building that has 
that server?  But that number will never call me back, and will 
certainly never call 911.  It sounds defensible to not create a 911 
record for a number like that.


Remote Call Forwarding numbers would be another example.  All they ever 
do is forward a call to another pre-determined number.

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Rate Center Geodata

[Mike Johnston via VoiceOps]

Nice work, Paul!  I spot checked a few that are in my area.  The 
coordinates are not perfect, but are close.  In general, the coordinates 
are within a mile of the central office.

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Call recording and single party versus all party consent states

[Mike Johnston via VoiceOps]

Good question!  I would love to see some sort of matrix (calling 
state/called state).  It might also depend on which side is the 
originator.  For example, AZ->CA might be different than CA->AZ. 
Everything will get even more complicated if a call involves a transfer, 
or a conference bridge.


I am not a lawyer.  Do not interrupt anything I say as legal advice.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Neustar SOA Archives

[Mike Johnston via VoiceOps]

On 2023-02-22 17:28, Paul Timmins via VoiceOps wrote:
Ask to get a BDD set up from the NPAC and you'll have a copy of the 
regional LNP database every morning, piping fresh. You'l want to write 
a script or something because the files are a lot too big for 
something like excel, but a comparison is easy at that point.


I didn't know that was a thing.  Today I learned.  That will help us 
with all sorts of automated processes.  Thank you!


___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Passing the Voiceops torch

[Mike Johnston via VoiceOps]

On January 2, 2023, David Hiers wrote:

Hi everyone,

Thank you all for your contributions to voiceops over the years, you 
quite literally make the voiceops distro what it is.


With the coming of 2023, it’s about time to pass the voiceops torch to 
the next generation.  If you’d like to pick up the domain name and such, 
please contact me off list.


Happy New Year to all,

David Hiers


The torch has been passed.  David has transferred the voiceops.org 
domain name over to me, and I am now hosting the DNS and landing page on 
$DAYJOB servers.  The actual mailing list is still hosted at 
puck.nether.net.


And thank you, David, for your years of work to the voiceops list.  Much 
of what we do is so niche, it can be hard to find the resources we need 
anywhere else.  Just look at the DTMF thread from yesterday!


So let's all give a big thanks to David!


I'll leave you with a few quotes from way way back in the archives.

On July 30, 2009, David Hiers wrote:
"Mr. Watson -- come here -- I want to see you." 


On August 5, 2009, Mark R Lindsey wrote:
At IPTComm a couple of years ago, Jonathan Rosenberg stood up and said  
the big problem was the walled gardens that are telcos and ITSPs. We  
carriers just aren't passing traffic via VoIP. Even Cisco customers  
aren't passing traffic within their own company; you'd have a BTS over  
here and a BTS over there, owned by the same Cable MSO, passing  
traffic via ISUP.


That was back in 2009.  That is, sadly, still the case for many telcos, 
both large and small.


And here are some excellent words from anorexicpoodle, written on 
October 21, 2009:

Since we, collectively, are steering one of the industries driving up
individual utilization of the IPV4 address space as well as being one of
the most sensitive to NAT which is the only way through which IPV4 has
been sustained as long as it has; it seems like a worthy exercise to
discuss our own, and the industries preparedness to adopt IPV6. 


Has anyone out there had any experience using any of the open source
platforms (OpenSIPS, Asterisk, SIPPY etc) with native IPV6? It seems
like these projects are the best equipped right now to handle this move
since they rely heavily on the network stack of the underlying OS. 


Are there any endpoints or other CPE that anybody has had luck getting
to work over native IPV6?

So far I am unaware of any carrier grade (meaning it costs a lot of
money) softswtch platforms that are ready for this, or seem like they
would be without a multi-year effort. Anybody out there that can
enlighten us on this one?



Sincerely,
Mike Johnston
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] test

[Mike Johnston via VoiceOps]

DNS test looks good.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Abandoned Ported Numbers

[Mike Johnston via VoiceOps]

Can anybody reference any regulations that would /require/ such numbers 
be returned?  Something from say, the FCC's website? I'm looking to 
provide for something more than just, "common practice".


I appreciate everybody's help!
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

[VoiceOps] Abandoned Ported Numbers

[Mike Johnston via VoiceOps]

Say a subscriber ports a number to/from a different telco.  Then, after 
some time, the subscriber decides they no longer want the phone number 
(or phone service in general).  What should be done with this abandoned 
number?


Should the number immediately be returned to the donor telco?

Should the number be returned to the donor telco after aging?

Is it permissible for the recipient telco to add this number to their 
inventory and then re-assign the number to a different subscriber?

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Lack of Sandbox

[Mike Johnston via VoiceOps]

I wish more 911 systems had a 933 number.  I've made actual 911 calls 
for testing purposes more times than I can remember.  I always call the 
Sheriff's Office admin line first, asking if this is an alright time. 
But sometimes my 911 call is routed to a different county than I 
expected, and that doesn't always go so well with the dispatcher.  But 
that sort of proves why we need to do the test calls.


On a related note, we sometimes setup a 977 number on PBX systems.  This 
will read back the number that will be outpulsed if you were to call 
911.  There are scenarios where what you would normally want to use as 
the outbound calling number is not the same as what you want to use when 
calling 911 (for E911 location, callback, etc.).  Our 977 number helps 
us verify we have at least that much configured correctly.


But we still would need to call 911 so a dispatcher can verify the rest.
"Does your console say which room I am in, or which floor I am on?"
"Room 207, Floor 2, Entrance 4"
"Perfect.  I'll call you back in a minute from the next room."
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] 9-8-8 dialing when an outside line access code (9) is being used

[Mike Johnston]

On 2022-07-15 10:19, Carlos Alvarez wrote:

We stopped the useless "outside line" concept almost a decade ago.


I would like to second that.  There is no need to dial a "9" (or 8, or 
whatever) to seize an outside line anymore.  We are no longer using 
mechanical step switches, and as such, are able to more elegantly figure 
out what the user is trying to dial


Sometimes this requires using timeouts.  Sometimes you can avoid the 
timeouts by carefully selecting the extensions.  For example, if you are 
in US/Canada and using 3-digit dialing, the extensions 100 through 119 
are never ambiguous (with NPAs, NXXs, ERCs, etc) and would not require a 
timeout.  If all of the extensions on the phone system are 100 through 
119, then this is a clear case of where a "9" to get an "outside line" 
makes no technical sense.


Possible pro tip: If setting up a phone system for a very small 
business, and you doubt they will ever grow beyond 20 extensions, 
consider using extensions 100 through 119.  They will never need to 
endure timeouts for station-to-station calling.


This all assumes you are bothering to setup digitmaps on the phones/ATAs.

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] SIP Trunk Failover

[Mike Johnston]

On 2022-06-09 14:42, Peter Beckman wrote:

Maybe a better question: When providing SIP Trunk Failover as a feature,
what do customer accounts use more often -- per TN or everything?


Everything.  It is rare for the customer to request different failover 
behaviors for different DIDs.  At least that is my experience.

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] SIP Trunk Failover

[Mike Johnston]

I agree with Jay, it is very customer specific.  We offer all varieties 
of failover to meet their needs.


Some have multiple sites with us and want the entire trunk to failover 
to a trunk at an alternate site.  This requires the alternate site to be 
prepared to accept all of the DIDs of the first site, serve the 
appropriate IVRs, attempt to ring phones (possibly at the first site if 
they still have connectivity to it), etc.  Or they might choose to 
simply redirect all such DIDs to the main number of the alternate site.  
Either way, the customer has a lot of control over happens without 
having to coordinate with me.


Sometimes they want it to failover to a phone number, like a cellphone, 
an answering service, or like before, an alternate location.  If the 
alternate location is not served by me, or maybe they just don't want to 
configure all of the DIDs of the first site into their alternate site's 
PBX, then it makes sense to failover to the main number of the alternate 
site.


If the customer were to request different behaviors for different DIDs, 
then I would do that.  For example, a school might want different 
failover behaviors for the Elementary Office DID, the High School Office 
DID, and all the other DIDs.  That would make sense and I would 
certainly set that up for them.


We have some where the failover is POTS lines in a small hunt group, 
that we preferably deliver as traditional copper loops.


If the customer did not request a failover, then the default will be a 
busy signal.


___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] STI-CA average pricing

[Mike Johnston]

On 2022-06-06 16:13, Mary Lou Carey wrote:
I'm not sure what type of switch you have, but this only works with 
VOIP. If you still use your SS7 network then it doesn't apply because no 
one has figured out how to make it work properly with SS7.


We have Ribbon C15 switches.  We have a mix of TDM and SIP.  We push to 
convert trunks to SIP as feasible.  Our primary toll trunks are SIP.  We 
still maintain TDM toll trunks to fall back to.

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] STI-CA average pricing

[Mike Johnston]

On 2022-06-03 22:22, Nathan Anderson wrote:

To put my response to this pricing in context, we are a relatively small 
regional broadband provider, and voice is a fraction of a fraction of our 
business.  I'd wager just about everyone else here has a larger voice 
subscriber base than we do, and most of you probably didn't blink when you saw 
the price-tag on what it would take to become part of the STIR/SHAKEN 
ecosystem...just the cost of doing business, right?


The telco I work for is rural, starting 75 years ago with party lines, 
etc.  Telephone is still very important to us, but of course, Internet 
is where more of the action is these days.  We still operate our own 
telephony switches geographically placed throughout our network and take 
pride in being able to withstand all sorts of failure scenarios.  That 
is to say, we are still investing a lot of resources to maintain a good 
telephone experience for our subscribers.


And yet, we still fell out of chairs when we saw just how much money 
various vendors were charging for the various portions of the 
STIR/SHAKEN implementation.


Just the cost of doing business, you ask?  I feel that vendors realize 
that this is something we are being FORCED into, and can charge accordingly.

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Arbitration or Peering?

[Mike Johnston]

Not sure if this is related or not, but I have been receiving an 
increase in complaints of calls not getting to my subscribers. The 
originators says they get ringing forever, ring a couple times then a 
tone and silence, and other such non-sense.  This is typical rural call 
completion issues.


Inteliquent handles all of my toll calls, inbound and outbound. In 
almost every case the originator is a VoIP provider that has no physical 
presence in my LATA.  Inteliquent says they have no record of the call.  
Of course they don't, I already assumed that, but I sometimes check with 
Inteliquent anyways.


I serve mostly rural portions of Northwest Minnesota.

The frequency of these complaints wax and wane over time.  Point being, 
I feel there has been a significant increase over the past several months.


___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] CNAM Storage

[Mike Johnston]

OpenCNAM from Telo was the ultimate answer to all things CNAM, at least 
in my opinion.  They would actually PAY YOU for your storage, since they 
make money off of selling it to others.  But, they were acquired by Neustar.

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] DIDWW API DNS Issue

[Mike Johnston]

Losing millions of dollars.  Very nicely said.

Then there are those that move their website, with their DNS, to a 
different provider, and are then confused as to why their email is 
broken.  Of course it is the email providers fault, and they have no 
comprehension that it might somehow be related to the recent changes 
with their website.



On 2022-01-20 20:03, Alex Balashov wrote:

That’s all good and fine for your DNS, but it did nothing for me when Peter 
from www.BeckmanPimpsStereos.com was calling every 3 minutes screaming that his 
web site has been down for a day and that he’s losing “millions of dollars”, 
all because we just had to migrate his ColdFusion site off a yellowing-beige 
NT4 box running vintage IIS to PrimeHostOutsourcerOne and now all the locals on 
DopeCable can’t access it…

—
Sent from mobile, with due apologies for brevity and errors.


On Jan 20, 2022, at 8:50 PM, Peter Beckman  wrote:

Hahaha yeah, thanks Residential ISPs, your DNS sucks. I always found a
better caching resolver, like UUNET, until Verizon got better at it, and
then Google DNS came along.

The caches have cleared.

Beckman


On Thu, 20 Jan 2022, Alex Balashov wrote:

Why, back in my day, residential ISPs would ignore your TTLs and cache for 3 
days no matter what you did…
Kids these days.
— Alex


On Jan 20, 2022, at 7:54 PM, Peter Beckman  wrote:

Please, y'all -- when doing a DNS migration, ensure 1000% that your DNS
records on your old DNS provider match your DNS records on your new DNS
provider, and plan your DNS migration early by setting the TTL for your NS
records at least to 5 minutes (300 seconds) if allowed, 30 seconds if you
can.
Assume all caching servers will cache for 5 minutes even if you set it to
30 seconds.
At least that way if things go wrong, your outage horizon is 5 minutes, not
1 hour or more!!!


--
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@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops


---
Peter Beckman  Internet Guy
beck...@angryox.comhttps://www.angryox.com/
---

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Vendor Pros\Cons

[Mike Johnston]

I feel I should also mention that even though the C15's CLI is a 
bit...old school, the platform is quite robust.  Especially if you are 
using SIP, there are very few failure modes that would cause a service 
impacting event.  Everything is redundant and can generally shift the 
call flows around failing hardware on the fly.  We've performed major 
software upgrades of the C15s while holding an uninterrupted SIP phone 
call during the entire upgrade.  From the day it's powered on, until the 
day it is replaced with something else, you can expect the C15s to be 
constantly operational (except for that time a tech dropped a wrench 
across the battery terminals).


They also have great TDM support, but some hardware failures, of course, 
will take down in-progress TDM calls.  That is, if the call is on a T1 
that is connected to a port module that just died, then that call will 
need to be re-established on a different T1 that is a port module that 
is still working.  I feel that this sort of concern is nothing new to 
people who are used to working with TDM, though.


The C15 support from Ribbon is amazing.  The technicians are very 
friendly, very patient, very accommodating, and always very 
understanding of what it is you are trying to accomplish.  I've had a 
couple times where I've had a feature request (or maybe you could argue 
a bug/non-RFC compliant behavior), and they fixed the issue.  However, 
for one of them, that fix took quite a while.  But, they want changes to 
their code to be very thoughtful and well tested.  This keeps their 
platform stable, very stable (see my first paragraph).


If you want to have a Hosted PBX offering, I do not feel the C15 is good 
fit for that.   We use FreeSWITCH for Hosted PBX, and link each virtual 
customer to the C15 with a SIP trunk (the C15 calls it a SIP PRI).

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Vendor Pros\Cons

[Mike Johnston]

On 2021-12-23 08:08, Shawn L wrote:
The C15/20 series is still pretty much all CLI, despite the fact that 
they've been saying they've had a GUI for years (awful, awful 
java-based thing).


The C15's CLI is not very intuitive, being a living relic of its DMS 
heritage.  There are different overlays you need to load to get into 
different administration areas of the C15.  I believe this comes from 
the era when RAM was limited and only one overlay/program could be 
loaded from the tape drive at a time. Much of that same paradigm still 
exists in the C15's current CLI. The CLI is accessible via serial and 
telnet, with no sign of ever being upgraded to use SSH.  There is no "up 
arrow" support.  That is, you can not press the up arrow key to get the 
previous command.  There is also no left/right arrow key support to 
assist you in modifying your current command.  Depending on your 
terminal settings, you may not have backspace support either.  There is 
no API, and it is very tedious to automate with expect scripts via the 
CLI.  Almost everything is in 3 or 4 character long keywords. You will 
eventually memorize many of them (CNAM, CND, CNB, CFW, etc), but you 
will forever be looking up many of these abbreviations in the manual 
(what is the difference between TR TTYP TERL, TRAL, TRAO, and TRAP?  How 
do these interact with the THGP or STN PICL setting?).


As for the GUI, as Shawn said, it is Java based.  As such, just assume 
it doesn't exist.


___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Carriers Keeping Acquired Defunct Company Names

[Mike Johnston]

I see situations up here in Minnesota where it appears that CenturyLink 
is essentially CLECing themselves.  An simple example would be Warroad, MN.

https://www.telcodata.us/search-area-code-exchange-by-ratecenter-state?ratecenter=WARROAD=MN
CENTURYTEL OF MINNESOTA, INC. (CenturyLink, Inc) OCN 1445 is the 
original ILEC in Warroad with 218-386.
CENTURYLINK COMMUNICATIONS, LL (CenturyLink, Inc) OCN 508J has CLECed 
Warroad with 218-986-6.


The same sort of thing exists for Roseau 
, 
Baudette 
, 
and Humbolt 
.


Over in Thief River Falls, MN, the original ILEC is 218-681, shown as 
QWEST CORPORATION OCN 9631.

https://www.telcodata.us/search-area-code-exchange-by-ratecenter-state?ratecenter=THIFRIVFLS=MN
CENTURYLINK COMMUNICATIONS, LL (CenturyLink, Inc) OCN 508J is also 
present in this exchange with 218-684-7.
As a bonus, LEVEL 3 COMMUNICATIONS, LLC - (CenturyLink, Inc) OCN 5256 is 
here too with 218-416-8.


We have a nickname for this company where we try to slur all the names 
together.  It sounds something like:

Qwest-tree-Tel-Link
But trying to add Level 3 and Lumen to the mix is somewhat challenging.  
Maybe make the "tree" sound into a "three"?  I'm open to suggestions on 
this clearly very important topic.

Qwest-3-Tel-Link ???
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] STIR/SHAKEN concerns

[Mike Johnston]

2. If your network is partially TDM and partially VOIP, have you experienced any issues with either of them? What are your future concerns since STIR/SHAKEN does not work with TDM? 


We have a mix of TDM and SIP.  We are continuing to work towards an all 
SIP network.  However, our aging management is still stuck in the legacy 
mindset where TDM made us money (subsidies).  There are other reasons as 
well, such as simply a resistance to change, lack of knowing how 
something works can lead to a fear of it, etc.  I am hoping and praying 
that STIR/SHAKEN _NEVER_ works with TDM, so it forces our hand to an all 
SIP environment.


We have both SIP and TDM trunking with Inteliquent for toll sort of 
stuff.  All of our EAS trunks with neighboring telcos is still TDM only.


10. I tried to keep my list simple but I would love to hear your thoughts on anything I missed. 


For whatever reason, some telcos are simply marking everything as "A".
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Call Quality

[Mike Johnston]

On 2021-06-16 16:42, Jared Geiger wrote:

Does Ribbon/Sonus charge extra for it even in passthrough modes


On my Ribbon C15s, there is no extra charge/license for G722. However, 
we do need to pay licenses for SIP trunks in general, which is by far 
the largest barrier towards modernizing our phone network.  We already 
have TDM hardware for the needed capacity. We also have IP hardware for 
the needed capacity.  But, since those SIP trunk licenses (RTUs) from 
Ribbon are fairly expensive, it can be hard to convince manglement why 
we need them.  If a call has to cross a T1 in my network, then it 
negotiates to only G711. Manglement doesn't seem to have any interest in 
HD calling, at least not that they have expressed to me.


___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Call Quality

[Mike Johnston]

On 2021-06-14 12:07, Richard Jobson wrote:

before going to the PSTN which is clamped at G.711 narrowband


This is starting to get a /little/ bit better, but progress is painfully 
slow.  For example, Inteliquent supports G722, you just need to ask for 
it to be enabled on your SIP trunks with them.  They won't transcode, 
just allow the negotiation to pass through.  Within my telco we enable 
G722 wherever possible and encourage SIP PBX subscribers to also support 
it all the way through to their phones.  We now have hundreds of 
endpoints that will negotiate G722 over the PSTN via Inteliquent.


___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Malformed Caller ID

[Mike Johnston]

The first thing I thought of was Least Cost Routing to a rural area.  My 
telco is rural.  We see issues like that now and then.  Setup the same 
call over and over again and you will probably get a handful of 
different CID/CNAM results at the recipient end.


Not saying this is your issue, but it is something we have experienced 
over the past decade or so.


For those not familiar, here is a quick overview from the FFC:
https://www.fcc.gov/general/rural-call-completion-problems-long-distance-or-wireless-calling-rural-areas
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] False 911 calls and old abandoned DID

[Mike Johnston]

On 2021-01-22 12:44, Carlos Alvarez wrote:
The number in question is not with us, and never has been.  We believe 
the customer abandoned the number long ago.  They have been with us 5+ 
years, and we had never seen that number before.  So it's probably 
abandoned with the old carrier


I can /totally/ see how that situation would have occurred.


and we can't do anything about it.


You and/or your subscriber should try contacting the PSAP record keeping 
people.  I can tell you who that would be for me in Minnesota 
. Maybe somebody else can chime in with more useful 
terminology here.


___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] False 911 calls and old abandoned DID

[Mike Johnston]

On 2021-01-21 17:42, Pete Mundy wrote:
on the PoTS equipment I'm familiar with (others can chime in and 
correct me if I'm wrong on a larger scale) the numbers are reversed


According to Wikipedia 
:


In most switching systems one pulse is used for the digit 1, two 
pulses for 2, and so on, with ten pulses for the digit 0; this makes 
the code unary, excepting the digit 0. Exceptions to this are: Sweden 
(example dial), with one pulse for 0, two pulses for 1, and so on; 
*_and New Zealand with ten pulses for 0, nine pulses for 1, etc_*. 
Oslo, the capital city of Norway, used the New Zealand system, but the 
rest of the country did not. Systems that used this encoding of the 
ten digits in a sequence of up to ten pulses, are known as decadic 
dialing systems. 


So you're in New Zealand :)

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] False 911 calls and old abandoned DID

[Mike Johnston]

On 2021-01-21 17:25, Brandon Svec wrote:

but it also seems just as likely for*any*  number to be dialed as it does for 
911 so I am still not 100% convinced, but am open to knowing more. Certainly 0 
for the operator being 10 pulses should happen at least as often if not more 
than 911 since it would just need 10 correct pulses and no perfectly placed 
longer pauses twice after the first 9 digits which seems  would be much more 
rare.


GREAT QUESTION!

The stations I am speaking of are suspended in our equipment, which 
means they can only dial a few things: 911, 611, and in our case 777. 
The first one is probably obvious.  611 is so the subscriber can call 
the telephone company to re-active their service.  (For example, a 
stations is sometimes suspended for non-payment, so they need a way to 
call to pay their bill.)  777 is what my telco uses for line 
identification (it reads you back your telephone number).


Suspended lines are generally not maintained as well as lines for paying 
subscribers.  Thus, this issue most often occurs on lines that are not 
able to call the operator, or anything but 911, 611, and 777.  Any other 
combination would not go through.


Now you may be thinking, wouldn't there be roughly as many calls to 611 
as calls to 911?  Wouldn't the staff in my company's billing office be 
getting these calls as well?  Yes, they do get these sorts of calls, but 
we haven't logged them like we do the 911 calls, so I can't give you 
exact figures.  Also, unlike the dispatchers at the sheriff's office, 
the telephone company staff can hang up on these calls, and are only 
open M-F 8-5, thus it is not nearly as impactful.


If we had such a faulty line on a non-suspended station, which could 
call any number, then yes, it would surely be calling all sorts of 
destinations.  And I agree, calling the operator seems more likely in 
this situation, since, as you point out, it just needs 10 identical 
pulses, probably followed by a long pause.



How do you explain the intercept message in the background of a call dialing 
911?  That sounds to me like the result of a double punched line or crosstalk.


It wasn't dialing 911 at that exact moment.  To be more specific, my 
logs showed it had called 911 eight times over the proceeding three days.



Do you care to share what make/model of equipment was alerting you to the "MORE 
THAN 10 DIAL PULSES WERE RECEIVED” message?  Just curious to learn more.


We have four Ribbon C15 units, formally Genband C15, formally Genband 
CS1500, which replaced four Nortel DMS-10 units.  We still have a bunch 
of legacy LCE bays, which I despise because T1s, but also appreciate 
because they have emergency stand alone capabilities.  The message it 
will produce on the terminals is something like:


LIN015  LCE 01 1 03 23

where  is the site/LCE name, and the numbers represents the LCE 
position.  If you do a lookup on LIN015, you get:


LIN015  MORE THAN 10 DIAL PULSES WERE RECEIVED IN DP ANALYSIS
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] False 911 calls and old abandoned DID

[Mike Johnston]

Some of my equipment will show a notice, hinting at a possible issue, 
when "MORE THAN 10 DIAL PULSES WERE RECEIVED".  A couple years ago, the 
responsibility of our switching gear was being transitioned to me as the 
previous guy was retiring.  During that period of time, I noticed a 
station in particular would throw that message a lot, up to 50 times a day.


There is also an entry every time somebody calls 911.

One late night I saw somebody call 911 multiple times.  I looked up the 
line and found it was the one with all the MORE THAN 10 DIAL PULSES WERE 
RECEIVED issues.  I called the sheriff's office. I asked if they had any 
weird 911 calls from that number.  They replied, ecstatically, "YES, 
like seven times!"  They said it would be static for a long period of 
time and eventually hang up. I suppose the dispatchers really shouldn't 
be quick to hang up their end, just in case.  So they have to wait out 
the call...listening to the static.


I promptly unwired it and put in a trouble.  I thought, surely this 
isn't a common issue, right?  Lines with static on them don't just call 
911 by themselves!  Do they?  Well, in my phone call with the Sheriff's 
Office, they said this is NOT an out of the ordinary event for them.


I audited some more.  One of them, with a butt set in monitor mode, I 
heard a lot static with, "If you'd like to make a call please hang up 
and try again," in the background.  Looking at our logs, that one had 
called 911 too.  We keep those logs for 6 months.  In that 6 month 
period, my analysis found 16 "left-in" stations that had presumably 
self-dialed 911 a total of 35 times.


Since I stumbled across that, we keep a much closer eye on these sorts 
of things.  Basically, any line that frequently or repeatably throws the 
MORE THAN 10 DIAL PULSES WERE RECEIVED notice, we do an audit on.


A little more background on what causes this:

Pulse dialing is performed by rapidly interrupting the telephone circuit 
for each digit dialed.  This method was sometimes referred to as loop 
disconnect dialing.  When you think of pulse dialing, you might 
immediately think of rotary phones.  You might also have visions of 
stepping switches.


One interrupt represents the digit "1" being dialed.  Two rapid 
interrupts represents the digit "2", and so on.  You need to have at 
least a brief timeout between the digits to indicate you are done with 
that digit and starting the next.  The exact timing is relatively loose, 
leaving a lot of wiggle room.  Any sort of interference that is creating 
a make/break cycle has the potential to pulse dial.  Multiple makes and 
breaks with the right timing (and again, the timing is pretty loose) 
could conceivably call anywhere...with no human being involved!  The odd 
thing isn't having it happen - it's having it happen to a specific number.


For 911, you simply need:
  - 9 rapid interruptions
  - pause
  - 1 interruption
  - pause
  - 1 interruption

For lines that are shorting out, arcing, in water, or whatever, it is 
only a matter of time.


-Mike Johnston

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Got my first inbound call with a STIR/SHAKEN checkmark

[Mike Johnston]

On 2020-09-09 23:22, Pete Mundy wrote:
I agree, and I believe it will happen somewhere around approximately 
the turn of the 22nd century.


I see you are a glass-half-full sort of guy.

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] FUSF is 26.5% for Q3 2020: Discuss

[Mike Johnston]

If you were to install new facilities to a subscriber in a green field 
deployment, what technology would you use?  Fiber, right? Once that 
fiber is installed, what speed packages are available? All the way to at 
least gigabit, right?


Yes, that means that some very rural areas are able to get gigabit while 
many urban areas can not.  But that is more-so a fault of the facilities 
in the urban areas.  They are often copper based (coax and twisted pair) 
that was installed decades ago. Copper facilities struggle to achieve 
gigabit speeds, at least past a very short distance.  More commonly the 
speeds are in just the double digits.


When ISPs are deciding where to install new fiber, un-served areas, such 
as the rural areas being discussed, are usually prioritized above those 
that are already served by cable and DSL. If you have enough resources 
to install fiber to only so many new subscribers in a given year, would 
you upgrade existing urban customers to fiber, most of which can already 
achieve 50Mbps+, or would you add new rural subscribers, most of which 
currently use satellite or dialup?  The later is a popular choice.  
However, I realize the optics are bad from the perspective of urban 
subscribers.


On 2020-08-24 16:45, Mary Lou Carey wrote:

Wow.so it sounds like maybe they are offering services but the 
donations from the government to fund it certainly don't make it all 
the way to the customer! My car loan costs less than your Gigabit 
ethernet! 


That is not a fair comparison.  Very few people currently require 
gigabit Internet.  I bet the cost for 50/50 is less than your car loan.  
Maybe a better comparison would be the cost of gigabit to the monthly 
cost of a loan for a Rolls-Royce?


___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] One-time Bulk LRN Lookup

[Mike Johnston]

We also could use such a service.  One provider suggested we just hit 
their API over and over again...even if that means we are slamming them 
with thousands of requests.  We are able to do this, but it just feels 
like the wrong solution.


On 2020-08-03 15:09, Mike Hammett wrote:
Where's a good place to just upload a CSV with a bunch of numbers and 
get back the LRN information? Most places let me do one or two through a 
web tool or they require I use an API. Developing something to hit an 
API is more work than it's worth to me.

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Trouble calling 8xx numbers

[Mike Johnston]

TL;DR: It was a fiber cut.


Subject: Inteliquent Service interruption advisory  || TT # 289412
From: Inteliquent NOC 
Date: Friday, 07/31/2020 12:48 PM
Dear customer,
Subject: Multiple DS3 outage in Minnesota
Date: 07-31-20
Time Start: 01:17 CST
Time Resolved: TBD

Issue and actions taken: Multiple DS3’s failing due to higher level
OC-48 issue on circuit vendor’s network. This is escalated to highest
levels with in our organization as well as the circuit provider.
Circuit vendor dispatch is already in route to facility.

We have opened 289412 as a master level ticket.

Additional updates will be provided as soon as they are available.

Thank you
Inteliquent NOC
Network Operations, Inteliquent
24-hr NOC: 800-933-1224 op 2
www.inteliquent.come: n...@inteliquent.com


2020-07-31 13:21, they added:
Update 1: Circuit vendor technician is on site and working the issue 


2020-07-31 13:40, Inteliquent updated my ticket:

Thank you for your incredible patience. We are currently experiencing
an issue with our circuit provider. Escalations are already at executive
levels and we are working to resolve this as soon as humanly possible. 


At 00:03 this morning, Inteliquent updated my ticket:

Our circuit vendor experienced a large fiber cut today which impacted
services.  They have recently confirmed that splice crews have completed
their work and are now hands-off.  We see that the affected services
have since restored.  Please check and let us know if any issues persist
so that our NOC may investigate ASAP.


___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

[VoiceOps] Trouble calling 8xx numbers

[Mike Johnston]

Is anybody else having issues calling 8xx destinations with Inteliquent 
since last night?  This is mostly being reported as credit card machines 
and ATMs not working.  Other than acknowledging my ticket, Inteliquent 
has been unresponsive (I'll have to start working their escalation list 
soon...sigh).  I am hearing that other telcos around me are having 
issues as well.


Mike Johnston
Wiktel
NW Minnesota
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Get ready for a weird dialplan change. 9-8-8 suicide hotline.

[Mike Johnston]

On 2020-07-19 11:21, Ryan Delgrosso wrote:
if there is any pre-9 dialing going on, i just add a 8 digit and 11 
digit check for leading 9s and drop them at ingress and then both use 
cases are gracefully managed.


Sounds like a form of permissive dialing.  Jam digits in, your 
translations will sort it out.  I like it!


So for example, if I dialed an 8-digit string starting with a 9, such as...
9-555-
...it would strip the 9 and send it out as...
555-
...?

And if I dialed an 11-digit string starting with a 9, such as...
9-619-555-
...again, it would strip the 9 and send it out as...
619-555-
...?

Do you have issues with timeouts, though?  Especially in the 7/8-digit 
case?  However, this new 988 order will require many areas to convert to 
10-digit dialing (including mine), which may make that irrelivent.

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Get ready for a weird dialplan change. 9-8-8 suicide hotline.

[Mike Johnston]

On 2020-07-19 00:10, Matthew Yaklin wrote:

they still want the 9. Sigh.


Sigh, indeed.  I have heard this from manglement on a couple occasions. 
Yet, when I remove the 9, especially when replacing a phone system, I am 
usually thanked by the individuals that actually use the phones.



Tell that to a large city customer who has 100 plus fax machines with
a 9 programmed in for all the speed dials


For at least one customer, I created two different dialplans/digitmaps; 
one that requires a 9, and one that does not.  If your equipment 
supports it, that may be a useful transition path for those fax 
machines.  The fax machines would require a 9, while all regular handset 
phones would not.


I was really hoping Kari's Law would have motivated more vendors, 
businesses, telcos, and phone administrators to remove the 9 all 
together with.  But instead, I am seeing a lot special casing for just 
911 (some Panasonic systems, for example).


On a related note, I find it sad and frustrating that for some, it 
required a law to incentivize the proper working of 911.  That is, 9-1-1 
instead of 9-9-1-1.

___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops

Re: [VoiceOps] Get ready for a weird dialplan change. 9-8-8 suicide hotline.

[Mike Johnston]

I second that.  If your phone system requires a "9", you are doing it wrong.
___
VoiceOps mailing list
VoiceOps@voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops