Posts made by Skyetel

Thanks @JaredBusch

The alarm company calls when the signal gets interrupted after a period of time. Just like the would if the fire took out the router/fiber.

I strongly recommend switching your alarm and elevator phones to using SIM Cards. Most alarm companies and elevator companies offer this for a vanishingly small amount of money (like $30/yr or something tiny).

I do currently have one ATA in "testing" mode that starts having issue around page 40-45. Anything less seems to have a 90% success rate.

We are about to launch support for HTTPS fax, which should give SkyeFax a nearly 100% delivery success rate. Our ATAs that use T38 are about ~93% successful. That 7% is up to the Fax machine, not us.

@jaredbusch great meeting you too! That picture came out much more "crazy eyes" than I was going for!

More Details:
https://support.skyetel.com/hc/en-us/articles/4402279765911

Hey Guys

We're looking for two or three beta testers to help us test our new Postcards for Slack:

When you connect Postcards to your Slack, it will create a new channel with your Skyetel DID:

Inbound SMS messages will automatically create a new SMS Thread with the source phone number, and any replies inside that thread will send a reply to the cell phone:

(Please note that in the production release version, it will say "Postcards" and not "Skyetel SMS")

I am looking for 2 or 3 Beta testers who are able to give this a good test and report back on what they find. To be a part of the Beta, you will need to send me credentials to a Slack account that can install an App in your Slack Workspace (the authentication is not live yet, and needs to be done by an engineer). You can create a dummy account for just this purpose.

Who is interested in helping?

Here's a preview:

It's still in development, but we're really excited about it.

Hm.

A carrier should quitely build an integration with Slack and Microsoft Teams that lets them send & receive SMS/MMS using their company numbers, and then surprise everyone with it as a replacement to an open source project. It would be so cool if you could create a channel for each company number (which you can make private to certain people), then each conversation with someone by SMS would create a thread. It would even be cooler if someone made that whole thing free.

That would be awesome...

@JaredBusch We are intentionally being vague on this because the technical stuff on the backend isn't solid yet. We may be able to attest those calls depending on the circumstances. So the vagueness is simply because the product is still in motion.

@JaredBusch Ah, same rules apply though.

If the DID is not a Skyetel DID, and you did not specify a DID you want us to Attest at Level A, then it will be attested to at Level B or C depending on who the Skyetel customer is. We can't attest phone numbers that are not specifically enumerated and verified either by it being on our network or via a manual attestation process.

You will have to enumerate what numbers you want us to attest at a Level A. Otherwise, forwarded cell phone numbers will be attested at a Level B or C depending on our relationship with the customer.

Hey Guys

We just (quietly) released support for Faxing via ATAs. We are releasing this in Beta and making it known to our technical friends so they can trial it. If you have any ATAs and are interested in trying this out - check it out: https://support.skyetel.com/hc/en-us/articles/1500003980502-SkyeFax-Beta-

SkyeFax is in Beta - so don't judge us too harshly

Would you guys give this a whirl? I'd like to get some of your feedback.

We just published this on our status page, but here's what happened:

From approximately 7:45am to 8:45am PST, we were impacted by a routing issue with one of our carrier partners. This caused inbound phone calls to fail before hitting the Skyetel network, and resulted in callers greeted with error tones.

One of the pillars of the Skyetel architecture is our redundant routing, and many of our customer's have asked why it failed today. We do our best to be transparent, and so here’s what happened.

As part of our interconnection agreements with our carrier partners, we require multiple redundant connections from physically separate networks that automatically redirect call flows from an unhealthy region to a healthy one on a call-by-call basis. Ordinarily, this would mean that if a carrier partner was having an issue in one of their data centers, Skyetel's traffic would be automatically shifted into a different data center instantly.

Unfortunately, the routing table that we established with our partner that dictates how calls should be routed was mistakenly deleted by an authorized member of our carrier partner's team. This prevented our routing tables from being followed and resulted in the call failures observed this morning. As soon as this routing table was reestablished, we were able to reenable our call routing and service was immediately restored.

We have been, and will continue to be, in talks at the highest level with our carrier partner about how this happened, and what safeguards are available to prevent this from happening again. Skyetel’s President is addressing this personally, and all options are on the table. He’s, uh, pretty upset.

It’s is important to note that we do not use this carrier partner for a lot of Skyetel's transit. As such, only 7-8% of our DIDs were impacted. Furthermore, no outbound calling or other features were impacted by this.

We know that issues like this are frustrating and we sincerely apologize for any inconvenience this may have caused.

@JaredBusch said in Miscellaneous Tech News:

@JaredBusch said in Miscellaneous Tech News:

The most cost effective Caller ID source is gone.

And there is no way to sign up for a new account.

So, @Skyetel any chance of this being a new service offering?

Telnyx offers it https://telnyx.com/pricing/id-services-and-data

Not in the way OpenCNAM did it I'm afraid. Telo was last place to buy it independently and Nuester is moving to neuter anyone from selling CNAM services that aren't attached to DIDs with large volumes. I suspect that most places, including Telnyx, will eventually be forced to stop selling it independently too. This industry died with Telo and I was extremely upset about it. (We ourselves were a Telo Carrier customer).

The main reason that Neustar is neutering everyone is because end users and small firms have a habit of caching the records to save money - something explicitly prevented in everything remotely connected to Neustar data. If providers who are selling CNAM data cannot 100% guarantee to Neustar that their data is not being cached (even by their end users), they'll be liable for a nasty lawsuit; and by extension so too would end users. Telo was the only place that had lax caching policies and, most importantly, an independent dataset. Everyone else now is just reselling Neustar and are plebs in their kingdom.

@JasGot said in Does this IP mean anything to anyone? 192.168.99.184:

@scottalanmiller said in Does this IP mean anything to anyone? 192.168.99.184:

That's a non-routable number. It's part of the private 192.168.0.0/16 range that anyone can use, but can't go out to the Internet.

I know. And that's really the basis for why I am asking. "Is it a default IP used (for some vendors) when there is no known destination?"

https://router-network.com/ip/192-168-99-184
https://forums.grandstream.com/t/issue-setting-up-new-skyetel-trunk-to-ucm-pbx/35731

And here's a packet capture showing this IP as the destination for the RTP traffic (from Skyetel)

We don't use it when there is no destination, we use it to communicate with our load balances and other routing gizmos. The stuff in "line=sr-...." gibberish is the actual data that we care about, not the IP.

Its basically a way for us to securely communicate across multiple routers that are unaware of each other's existence on a call-by-call basis.

The .99 IP is used by carriers (like us!) to signal to our routers that the subsequent bit after the ";" is important. Typically that gibberish is encrypted and contains routing information used for internal call routing. Here soon, it will also be part of our STIR/SHAKEN. So it is important internally, but worthless externally. Older PBXs can create headaches if your PBX thinks it should use it to route.

@JasGot said in Recording calls on a SIP Trunk to a local Recorder/Logger:

@Skyetel Is there an API or other method to automate the downloading of the recordings? Are they available through FTP or RSync?

They are available via API. Check that out here: https://api.docs.skyetel.com/

@JasGot said in Recording calls on a SIP Trunk to a local Recorder/Logger:

Forgot to add this above, it may require two recording methods: since it is an in house pbx. Ext to Ext recording is required.

Oh - in that case It would depend on what PBX you are using. @JaredBusch would probably know about that than I would. However - most PBXs support call recording internally. That would be the best option if you can do it

If you plan on switching to us - you can just enable our own Call Recording:
https://support.skyetel.com/hc/en-us/articles/360040711534-Call-Recording

For Comment 1 - I would suggest against the idea of a "Conference Call" recording system because that won't preserve the channels of the call. They will get muxed together and you'll loose the ability to fun things like Transcription. It can also create issues where the recorder will drop the call.

For Comment 2 - If you need to use this system for internal reasons, this would be the better option. It's better to fork the audio the recorder instead of having it record inside the live call path. If the recorder is in the live call path, and it fails, or runs out of disk, you will loose your ability to place/receive calls. (Though that may be preferred depending on the industry you are in. I know a lot of debt collectors work like this).

@ing-joserivera26 said in VitalPBX 3:

@JaredBusch In that case you must put the host in the match field. I guess you must put: srv.skyetel.com

Skytel said in your blog:

SkyEtel