@Dashrender

We wanted the limit to be high enough to where you wouldn't have to worry about hitting it unintentionally, but low enough to where you wouldn't get a crushingly hard credit card bill. We figured that $1,000 for a business was a safe balance between high enough and low enough. We also needed to account for customers who suddenly have a big burst in their traffic (which happens more often than I would have guessed). Believe it or not, we actually have many more tickets around people unexpectedly hitting it instead of people hitting it due to fraud.

The Top Up limit is only part of our auto-recharge fraud prevention. For international, we have very strict dollar limits you can spend (that you specify in our portal), a maximum outbound channel limit, and dedicated international gateways. So far this has effectively blocked all of the international fraud on our network and protected huge amounts of money with our customers.

For domestic traffic, you can specify concurrent channel limits in our portal that will SMS you if your channel counts suddenly spike.

Taken together, we are pretty proud of our success rate in keeping fraud down on our network

Its funny that this came up - we're actually working on a big update to Postcards now. This is what is on our development list for the next version (1.1):

Upload Contacts via CSV
Search - Ability to search through messages & contacts
Automated image scaling for images that run larger than 1.5Mb
Giphy Integration - Send Giphys in SMS!
Send Emojis - Send Emojis!
Templates - Have pre-set messages that can be sent with a click of a mouse
Archive Conversations - Ability to close a conversation and hide it from view
Bulk SMS Sending - Ability to send 1 message to multiple recipients via some kind of Queue.
Auto Replies - Be able to automatically reply to a new message
Schedule Sending SMS - Ability to deliver an SMS at a pre-set time
Email Notifications - Ability to notify users that they’ve received an SMS by email using end-user supplied SMTP servers
Postcards Updater - Add the ability to update from one version of Postcards to the next version

The installation installs Docker on the server when you run the script, but with version 1.1 we intend on releasing an OVF and have it as a preconfigured application with both AWS and DigitalOcean to make the install easier. We're even looking at making it so you can deploy it here: https://www.digitalocean.com/products/kubernetes/ (this will make it easier to update and manage for our users)

Hey Guys,

I'm giving you all first notice about this since a lot of you guys have helped us with bugs and provided us with other feedback.

We are going to be adding our 4th Region to our routing tables in June. Most of you guys are already good to go, but for those of you who aren't, please have a quick look at this: https://support.skyetel.com/hc/en-us/articles/360046703354-Skyetel-s-4th-Region

Would you guys be willing to test na.skyetel.com with your PBXs to verify that they are indeed routing outbound calls to all 4 of our IPs?

Thanks!

(edit - updated with na.skyetel.com)

@JaredBusch lol, yes. yes we did lol.

Well - it looks like we have to issue an update about this.

Unfortunately, 4.skyetel.com clashes with some systems that do not support numerical values in DNS entries (yes, thats a real thing) and so please use na.skyetel.com instead. We will be sending out an email tomorrow asking everyone to please use na.skyetel.com instead of 4.skyetel.com. Sorry for the headache guys.

@Dashrender Here you go:
https://mangolassi.it/topic/19453/skyetel-relationship-pricing

Below is the link for Chime's pricing

DID: $1.00

Inbound Calling:
United States of America $0.002216

Outbound Calling:
United States of America $ 0.004800

https://aws.amazon.com/chime/pricing/

Friendly reminder that Chime prices do not include support, and that is an additional (high) charge, whereas our pricing includes support.

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.

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.

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...

Here's a preview:

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

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?

So it turns out that srv records above 512 bytes is not supported by Freeswitch, so we had to remove these records. I'll update you guys on a different DNS strategy shortly.

I think the answer is, in the rare circumstance that SIP / T.38 is working perfectly, you would not change. We have big customers doing tons of faxing and they desperately need this solution because they can't get SIP / T.38 to an acceptable failure rate.

If you have an ideal setup - modern fax machine, fiber internet, correctly configured ATA (which is, by far, the biggest problem we've had - people just won't read the guides thoroughly), your expected failure rate is about 8% on a T.38 ATA. For small offices who send/receive a fax once in a couple of months, this is a fine solution.

HTTPS ATAs only fail when the party on the other end of the fax fails; which makes them at least as reliable as traditional POTS lines. They are probably more reliable because we will retry the fax 9 times before failing it. So if you need near 100% reliability, you need to use the HTTPS ATAs.

The reason we are charging monthly for the ATAs is because that is how we are charged for them. We have to buy software for these things to work, and its expensive. Most of our competitors who offer HTTPS ATAs charge north of $15/mo.

I put this on another forum, but I figured you guys would like to read this too:

For those interested, Our network operates in 4 AWS regions that we keep siloed from one another (meaning no region knows about the existence of another one). When the connectivity issues started, we disabled the network connectivity for all Skyetel assets in the two impacted AWS regions which caused our network to fully failover. (Because the impacted regions had partial connectivity, our network did not fully fail over and tried to limp along with all 4. This is by design; we don't want to automate disabling network routers of our network for obvious reasons... so an engineer needed to click the buttons).

The impact of this was some calls failed to establish, but if they did establish, they would work normally. This is because we are not in the audiopath of the calls. Once the distressed regions were fully down, our network could fully fail over and 100% of all calls completed normally.

The total impact time was 19 minutes, and we estimate about 7% of our calls failed to establish during that period. Sorry for the inconvenience

@JaredBusch I should clarify - IPO is not the plan. IPO being thrown around is because our volumes are now equivalent to publicly traded companies. Sorry for the confusion.

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.

Oops - my bad. I thought it should go into news. @scottalanmiller can I move this? or should I delete and recreate it?

To answer your question - it uses 80 and 443.

@travisdh1 The two main reasons we don't publish our wholesale rates are:

1. It prevents fraud. Having customers call into out sales line and talk to a person is a fantastic way to reduce our toll fraud exposure.
2. It lets us make sure we're the right fit for you. If you call in and need SIP Registration, we'd tell out right then and there that we aren't the provider for you.

Since we don't lock you into a contract or require any minimums, our sales process is pretty simple. We find out what you are paying now and discount your rates so our prices are cheaper. If we can't save you money, we'll tell you on the spot. If you don't have any technical questions and already signed up online, the entire call can take less than 5 mins. There's no back-and-forth or annoying approval process involved.

@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.