- VoiceOps - lists.voiceops.org

Call recording and single party versus all party consent states
by caalvarez＠gmail.com March 19, 2023

March 19, 2023

Our servers are in AZ. We have customers who are based in AZ, but also have satellite locations in CA and other all-party consent states. I believe that in the case of a CA caller reaching an employee in CA, then that state?s laws would apply. Does anyone here know for sure? Does it matter if the DID is AZ based or CA based?

2 1

Off-Net Numbers
by voiceops＠ics-il.net March 18, 2023

March 18, 2023

Historically, we used multiple entities to get us off-net numbers. Who, what, when, I don't know. I have off-net numbers configured in my Metaswitch where I don't know who our upstream was, if we still have them, who they belonged to, etc. I can easily figure out what CLEC has them now, but we all know that there was probably someone between me and them, I just don't know who. Is there any likelihood of being able to determine that? I assume the different CLECs that "own" these numbers are not going to tell me who their reseller was, for me to then follow up with. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com

4 4

Neustar SOA Archives
by voiceops＠ics-il.net March 17, 2023

March 17, 2023

How many of you are still using Neustar SOA? Any better ways of getting this information? After some personnel changes, we're cleaning up our systems. Things haven't been maintained properly over the years. We're going through disabled (but not ported away or deleted) numbers in Metaswitch to see what their fate should be. I ran an SV search for all ported out numbers, exported to Excel, and then had my staff compare that to what we had configured in Metaswitch, along with seeking their recommendation as to whether we set it to ported out, keep it as-is, or delete the entry entirely. That recommendation would be with our guidance as to when to do what. I spot checked their recommendations and found some messes. One of which is that the SOA export just managed to skip one line from 2018, so that was fun. Another is that a number that a former customer had doesn't show up on that list for ported out, but does show up on the ported in list. When I do an SV Query, it shows up as someone else. How can that be congruent? Is there a way to get more that current and 1st prior? Is the SV search supposed to include everyone that ported away from us, or just those that had us as their first prior carrier? I'd like to not have them issue an SV query for each potentially ported away number. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com

3 9

Bell Canada wholesale SIP outage?
by jbilyk＠gmail.com March 9, 2023

March 9, 2023

Hello, Currently, we cannot register trunks or receive calls on TNs on Bell Canada wholesale SIP service. Their support portal is also down. Anyone have any insights into the outage? Jeff

2 2

Wireless Canada Porting, the CRTC, and the Stupid Process
by beckman＠angryox.com Feb. 24, 2023

Feb. 24, 2023

I'm finding that Canada Ports, due to the CRTC actions, are increasingly costly. In November 2021, without much notice to the industry AFAICT, the CRTC changed the process for Wireless Canada Ports: - Upon receiving a Port Out Request, the Losing Carrier sends an SMS to the End User - The End User has 90 minutes to reply affirmatively to the SMS - If they fail to do so, the Port Request is automatically canceled For most Canada carriers I can find, they seem to charge you both to submit the Port Request, and then to Cancel the Port Request. Add to this what happens when the End User is NOT PHYSICALLY in Canada. - MAYBE the Canada Carrier is able to indicate when they send the Port Request to the Losing Carrier - Customer must be notified to start calling the Losing Carrier, but we all might not know when the 90 minute clock starts/started - Customer MUST call LSP to approve Port - Sometimes they are on hold longer than the 90 minute window - The SMS is sent from a Canada-only Short Code, so even if they can receive it while roaming, the roaming carrier does not know how to route the SMS destination back to the LSP for approval Overall I give the CRTC an F for this process. What are others here doing for Canada Ports? Are the costs similar to what I'm finding, USD$3-6 per TN, USD$3-6 to cancel the order, then another USD$3-6 to resubmit? Is there a carrier that does this extremely well? Must be automated too. Is it just exponentially more expensive when the End User cannot gain approval on the first Request? I'm also finding that getting a webhook or notification when the request is actually sent to the LSP is also difficult, and so notifying the End User of when to call is also difficult/impossible. Beckman --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com https://www.angryox.com/ ---------------------------------------------------------------------------

2 2

New Hosted PBX Platform?
by voiceops＠ics-il.net Feb. 18, 2023

Feb. 18, 2023

We have been using 3CX for our hosted PBX platform. It's come time for us to find something else. I chose 3CX at the time because it had the best user-facing UI. I've had a lot of platforms suggested to me by other ISPs, but I thought I'd come here to see what you all have to say. 3CX didn't scale well, but that was secondary to having a product that customers found easy to learn and easy to use. We currently use Metaswitch and are considering adding their Max UC, but have open minds at this time. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com

3 2

Passing the Voiceops torch
by David.Hiers＠cdk.com Feb. 15, 2023

Feb. 15, 2023

Hello everyone, It's honestly been an honor and a pleasure to have played my role in our industry. What started out as me trying to find some smart people that'd let me copy off their homework turned into a thriving community of professionals. I extend my heartfelt thanks to Mike and the room full of people that tossed their hats in the ring to help keep Voiceops running. I might have started it, but the true value of Voiceops came from everyone else. Best wishes to all, David -----Original Message----- From: Mike Johnston <mjohnston at wiktel.com> Sent: Tuesday, February 14, 2023 5:01 PM To: VoiceOps <voiceops at voiceops.org> Cc: Hiers, David <David.Hiers at cdk.com> Subject: [EXTERNAL] Re: [VoiceOps] Passing the Voiceops torch Caution: External email - Please use caution opening links and attachments from external senders 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

1 0

Passing the Voiceops torch
by David.Hiers＠cdk.com Feb. 15, 2023

Feb. 15, 2023

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 David.hiers at cdk.com<mailto:David.hiers at cdk.com>

6 6

Alarm panels and how they dial DTMF digits - pots migration from DMS to Metaswitch issue
by myaklin＠firstlight.net Feb. 14, 2023

Feb. 14, 2023

Hello All, I guess I have an old school question for the list. The question is we are having trouble with alarm panels dialing and our gear collecting the DTMF digits properly. Only from a company ran by a single alarm panel guy who is not terribly helpful. At least 7 different sites are having the same problem on different copper pairs/T1s. Different gear. Etc... It seems we are always migrating off old DMS switches. In this case a DMS 100 with your typical line drawers with cards in them for pots lines or GR303 groups. We are migrating to a Metaswitch using different types of connections. In this case GR303 for some and SIP for others. ADTRAN gear in this case. TA4303 and a TA5000. We have been a Metaswitch shop for quite a long time now. Pretty vanilla stuff we rely on in many regions that has always "just worked" for legacy clients. Metaswitch -> GR303 to a TA4303 -> drop T1 to a TA3000 -> build a T1 on our copper plant -> Smart jack -> TA750 at customer location -> customer fire alarm panel Or... Metaswitch -> SIP -> TA5k with RPOTS cards in SIP mode -> copper plant -> demarc -> customer fire alarm panel What I am seeing is that the DMS was collecting the digits properly before the cutover. Yet our migrated to setup is having trouble. We see missing digits in most cases or other oddities. It does appear the alarm panels are dialing within DTMF specs. Duration of the DTMF is approx 95 ms. A DTMF signal separated by a 150-200 ms pause. Any other type of customer is working flawlessly. 100s and 100s of pots line migrated with no complaints except a single guy who manages fire alarm panels of a few different types. "Contact id Edwards". " Contact id ES4 Kidde". Naturally, a tech sent on site can dial out fine with his butt set. The copper pairs test fine. T1 is error free. Hardware has been swapped out. Moved to different fxs ports. You name it we probably tried it. Does anyone have a suggestion what could be the cause for this? Something I am not aware of DMS wise when it came to fire alarm panels? Some change that can be adjusted in the fire panel configuration that might solve this? When we port/move the customer back to the DMS it just starts working again in the case of the TA5000. There is no going back for the GR303 subs which were moved all at once. Any tips are welcome! Thank you, Matt

11 25

Alarm panels and how they dial DTMF digits - pots migration from DMS to Metaswitch issue
by nathana＠fsr.com Feb. 14, 2023

Feb. 14, 2023

Matthew Yaklin wrote: > An example would be the fire alarm panel should dial 877-386-4923. Yet we collect the digits on the Metaswitch as 877-38923. That is it. The 6 and 4 are missing ...and then later wrote... > [...] and no matter what we tried those two digits in my previous example were always missing. You wrote this here, but elsewhere what you wrote seems to suggest the symptoms seem more "random" than this (sometimes all digits are correctly decoded and passed on, sometimes different digits or different numbers of digits are missing, etc.). If the mode of failure really is as consistent as you suggest here, though (or even if it happens the majority of time), have you considered recording the audio coming out of one of the fire alarm panels while it's trying to dial, so that you can take a spare Adtran, put it on the bench, configure it identically to one that you have in the field, and feed it a recording of the fire alarm panel dialing out, in order to reproduce the issue? If you can repro outside of production, then you can test & iterate much more quickly (as well as at your own convenience) than when you are forced to test on an actual customer installation. -- Nathan

3 2