@Dashrender We refunded the mistake back to the credit cards if there was an auto-recharge. The refund should clear before the initial transaction does, meaning your credit card should only be charged what you should have actually paid.

Sorry about the headache this caused.

We rewrote our entire billing system and it worked perfectly... except for a single typo. Believe it or not, it was caused by a rouge "%" in a SQL query.

Full RFO to come

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

@JaredBusch said in Skyetel Acquired ...:

@scottalanmiller My only concern is that, while HFA was a simple PE firm, something is changing.

To be honest, this is actually a good thing. It's pretty hard to explain just how much I had to deal with that was completely unrelated to Skyetel's core products and services.

A lot of that crap are things I'm not great at. Dealing with HR issues, FBI subpoenas, contract reviews, changing federal regulations, etc all have nothing to do with what Skyetel actually does. I want to focus on the actual nuts and bolts of our products and services, and build cool things.

The team I'm surrounded by is really impressive. We have an attorney on staff now, a full group of HR people who know all the things about employment law, and a team of people who can help with all the other little things. It also more than tripled our development team, and quadrupled our support team (and all of those people report to me directly).

So it's scary when you read it in an email, but from my perspective, it's a huge relief. I'm just going to build cool things, and drive our innovation. Someone else can deal with regulations.

It's just some family friends of the founder and the founder joining teams.

This hits the nail on the head. HFA isn't some big greedy investment group - and I wasn't looking to retire. When we combine the traffic volumes of their holdings into Skyetel's network, we become big enough to where the letters IPO have been thrown around. It's insane.

The goal is to simply disrupt the market further. Many of Skyetel's competitors are now our customers - that's the scope of scale I'm excited about.

Shameless Plug
https://support.skyetel.com/hc/en-us/articles/360041178773-Voicemail-Transcription

We charge per VM, with no minimums or weird setups. You just use us for the PBXs SMTP server and we catch the VM in flight, transcribe it, and embed it in the email. It's one of our most popular features.

@romo said in Skyetel is Hiring:

Canada/US

Canada and US only.

@gjacobse said in Skyetel is Hiring:

@stuartjordan said in Skyetel is Hiring:

Looks like a nice position, shame i'm in the UK. I like the potato filter lol.

Item H: Remote Only Position

Though it does mention Anywhere in the US - but I don't see that as a true limiter...

We can't legally pay payroll to people in the UK without getting setup there first - so that's why it's limited to North America. There's also the timezone problem. We want to expand our support hours to include the east coast, hence this position is expected to work those hours.

"Potato" helps us insure people are actually reading the posting. Otherwise we just get SPAM

https://portland.craigslist.org/clk/sad/d/vancouver-telecom-support-tier-or/7426015530.html

Come join our team!

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

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.

@jasgot said in Skyetel has HTTPS ATAs now.:

Just got pricing from them. $175 plus $10 for shipping; and then $5/month (Plus in/out charges? They don't say anywhere.)

Too pricey, especially when their marketing says: "And, the best part, that does all that at a price that no other provider can match."

That statement instantly led me to believe it would be noticeably less than the Cisco ATA 191.

I know one is SIP / T.38 and the other is HTTPS, but if T.38 is working perfectly, why spend more for HTTPS?

Make sure you talk to your account manager about relationship pricing!

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.

Not yet...

dig _sip._udp.na.skyetel.com srv

We aren't going to publish the CIDR blocks on the A record. Only the SRV.

@jaredbusch said in Additional Skyetel IPs:

Do not see any DNS changes yet.

Try now

Hey Guys,

We're going to be announcing this in a few days, and I'm dropping this here early. We're adding additional IPs to our network because we have been adding significantly more interconnectivity to the PSTN over the last year as part of an enormous network upgrade. As part of this upgrade, we simply needed more networking capacity. (This will also help us with DDOS mitigation)

Specifically, you will need to add these IPs:
44.199.94.192/27
3.144.141.64/27
3.101.177.224/27
35.85.225.96/27
3.99.65.224/27
(These IPs will do not currently support outbound calling, but we may add that ability via the dns record below at a later date)

You will also need to update your outbound calling to use these:
First Priority - na.skyetel.com
Second Priority - 15.197.157.235
Third Priority - 3.33.143.204

I've updated the IP Address doc here:
https://support.skyetel.com/hc/en-us/articles/360041173493 (you'll need to be signed in to read this).

Anecdotally, the IPs used for outbound calling now use Anycast; so you'll be automagically connected to the region nearest you when you use those IPs.

These IPs will be required by 12/1/2021 - so the sooner you can do them the better :). We will be updating na.skyetel.com with the new IPs later this week.

Feel free to drop in a comment with feedback or questions.

The rumors we are hearing is that these attacks are state-sponsored sized, and the attackers are torching everything well before it even gets to the target network (Verizon, Bandwidth, etc). This is not an ordinary attack, and everyone's spooked.

@pete-s said in ATA sp112 behind Sonicwall to Skyetel:

One difference between different providers can be if they're using tcp or udp. I believe tcp is the newer standard so old devices might not support it.

A quick search seems to indicate that Skyetel is udp by default but can be switched to tcp.

TCP should be better for the firewall because it tracks tcp sessions but not udp. So it knows where to send a reply inside a tcp session.

I would give it a try. Switch Skyetel to tcp.

FWIW - if you are using SIP Registration, we do not support TCP, only UDP.

TCP + SIP Registration = Very Insecure + Much More Vulnerable to DDOS.

60F85B623E

Good till Saturday.