- VoiceOps - lists.voiceops.org

Vitelity / Voyant Colorado Outage
by beckman＠angryox.com Feb. 10, 2020

Feb. 10, 2020

START: 02-09-2020 20:31:39 UTC END: ongoing Vitelity is experiencing some sort of network issue. While the Voyant NOC says they are aware, their portal is unstable due to the 40-50% packet loss and jump from 40-50ms to 375ms round trip times. This is affecting all services AFAICT: API endpoints, Portal, incoming and outgoing calls. We have moved most of our traffic away from Vitelity, except for phone numbers they host, as there is no ETA and 375ms plus 40-50% packet loss means pretty terrible call quality. I'll update as I learn more. --------------------------------------------------------------------------- Peter Beckman Internet Guy beckman at angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------

2 2

Toll Free provider
by kiddfilby＠gmail.com Feb. 7, 2020

Feb. 7, 2020

Its been a long time since I fished in these waters but, its that time. I'm looking to see who are great providers of both 8YY and 8XX traffic. I'm looking for a diverse route from my current carrier. Thank you for any help you can provide. -- Kidd Filby <http://www.linkedin.com/in/kiddfilby>

2 1

Provider CDRs
by voiceops＠ics-il.net Feb. 5, 2020

Feb. 5, 2020

While working to migrate billing systems, I asked our consultant to do X, Y, and Z because that's all I thought was involved. Metaswitch FTPs the info to the billing server, Perl script runs, dumps it into a database. Apparently, there are other scripts on there that do a variety of other things I didn't know about. One of them FTPs into one of our termination providers, pulls down a file, and puts it into a database. Great, except they only set up that process for one termination provider, not the other one. It also hasn't worked in five years (probably due to M&A and deprecated systems), so whatever it was doing, we're not getting the benefit of anymore. Is anyone keeping CDRs from all providers you connect to? I don't mean CDRs your system generates, but ones they generate. The only reason I could think of is to verify your invoices, but I'm not sure that's a big deal or worth it. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com

3 2

RAY BAUMS Act - How are people planning on complying?
by David.Zilk＠cdk.com Feb. 4, 2020

Feb. 4, 2020

For those that don't know, RAY BAUMS Act is a new regulation that impacts Emergency Calling. It mandates that a "Dispatchable Location" be included with information to the PSAP when a 9-1-1 call is made in the US. The deadline for compliance is August 1, 2020 (or August 1, 2021 for some scenarios). Dispatchable Location is defined as "the street address of the calling party, and additional information such as room number, floor number, or similar information necessary to adequately identify the location of the calling party." How are people planning on complying with this? Particularly: 1) When several lines at a site don't have DIDs, and uses a common site phone number for their CLID. How do you provide different location information for them. 2) When there are shared lines on devices in different locations at a site using the same DID. How do you distinguish the correct location of an emergency call made from one of them. 3) When the caller uses a softphone that doesn't have a fixed location. David ---------------------------------------------------------------------- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.

8 12

STIR/SHAKEN implementation - CLI tool, HTTP API server and C library
by miconda＠gmail.com Jan. 30, 2020

Jan. 30, 2020

Hello, I noticed the discussion about STIR/SHAKEN that happened on this forum a few weeks ago and for quite some time I had in my todo list the task to add support for those extensions to Kamailio SIP server, but with no real pressure to deploy them here in Europe, I kept postponing for a while (also, some people did it already for Kamailio using embedded scripting languages Lua or Python). Anyhow, as I saw the discussion here, it became fresh again and I searched the web, but I could not find any free/open tools to test/validate implementations, so it looked a bit like chicken-egg problem, therefore I created recently such a project, written in Go language, with option to build a C static or shared library. It is still very fresh code, not much tested, now with ES256 signing algorithm based on golang native support, no interoperability done with other applications. The project is available at: ? * https://github.com/asipto/secsipidx To be able to enable older versions of PBX/SIP servers to support STIR/SHAKEN extensions, besides the C library exports, there is an application that can run as CLI tool or HTTP API server to check or generate Identity headers. I haven't tested at all on Windows, but I expect that golang ensures good portability, not using anything OS specific in the code. I thought it worth announcing it here, in case someone wants to play with, suggest improvements or even contribute to make it easier to use on their specific deployments. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com Kamailio World Conference - April 27-29, 2020, in Berlin -- www.kamailioworld.com

3 4

RAY BAUMS Act - How are people planning on
by ajp26＠buffalo.edu Jan. 23, 2020

Jan. 23, 2020

There's a 140+ page document from the FCC on how they plan to interpret and enforce Ray Baum's and Kari's Law which discusses a lot of this. IIRC, and, not being a lawyer, it said that it wouldn't bother with the stickers due to the burden. It also made a point that if the phone were capable of placing a call, that it should be expected that the device can call 911. To me that says an E911 disclaimer is not sufficient to prevent a 911 call from being routed to a national centre or some other PSAP, but, I don't really know. There was not a point there that said, "If you can comply with this now, you must make changes" that I saw clearly. There are those that say systems must do these things and those which changed substansively past a point or which require money to be spent to implement need to . More or less it is pretty hazy but I did get out of it that if my softphone client has a 9 and a 1 on it that pressing the right combination of those should do something. Perhaps we can go back to rotary phones where we can put the lock on the 9. > > At some point, some ruling body had said those stickers were non-compliant > and meaningless. So I think the assumption is that they still see it that way. I > think it was the FCC, but not sure. I think to them if it's on a desk and is shaped > like a phone, it better work properly for 911. >

1 0

Post-Port Activation Delay
by voiceops＠ics-il.net Jan. 23, 2020

Jan. 23, 2020

I would like to preface this email by saying that I know that iconnectiv is managing ports now, but we just have the old Neustar portal working as the front end because I haven't had time to learn how all this stuff works so that I can properly train our employees on how to use the new portal. Undo business. Our people that manage the porting currently go into the neustar portal and activate a port. At that time, some carriers immediately start using bus. However, some carriers will still send traffic to the losing provider for some amount of time after that. Sometimes that is okay, sometimes it is not. I assume that there is not a darn thing that I can do about how quickly someone else decides to look up the number to see that it has been ported. However, can someone explain to me how common this is and what providers arnone for being sloppy? For example, last night we did a port at 9 pm. A test call that we did to a forwarding number that would have bounced through AT&T ILEC went through fine every time. Calls that would have gone through a variety of cell providers was extremely Hit or Miss, Even from the same operator. I apologize for any misused words. I was using voice to text and editing that on my phone can be difficult. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com

5 4

Call Overflow Handling
by dmcduffie＠socket.net Jan. 10, 2020

Jan. 10, 2020

An HTML attachment was scrubbed... URL: <https://puck.nether.net/pipermail/voiceops/attachments/20200110/c86fc2cd/at…>

7 9

NANPA Resource Management
by voiceops＠ics-il.net Jan. 9, 2020

Jan. 9, 2020

For those of you with NANPA resources, how are you managing them? There are a variety of reports one has to file and I'm not sure of a good way of keeping track of what's used, other than attempting to keep track of it in an Excel sheet... which seems error-prone. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com

3 4

SBC E800
by kuylenj＠eastex.com Jan. 8, 2020

Jan. 8, 2020

We are getting jibberish back from the old SBC E800 whenever we do a dip on some 844 numbers. Anyone have a contact for SWB E800. All the numbers I'm finding from my predecessor are no longer in service. Thanks in advance! Important/Confidential: This communication and any files or documents attached to it are intended only for the use of the person(s) or entity to which it is addressed. It contains information that may be confidential and exempt from disclosure under applicable law. If you are not the intended recipient of this communication, you are hereby notified that the copying, disclosure, distribution, storage, retransmission or other use of this communication is strictly prohibited. If you have received this communication by mistake, please notify the sender immediately and destroy all forms of this communication (electronic or paper).

1 0