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