Best posts made by Skyetel

How about I make this easy: Use 43717 for the promo code and any member of this forum will get free port ins for the next 30 days

Hey Guys,

We’re going to be reviewing this first thing on Monday. @JaredBusch had a strong argument about Microsoft in his email.

I can say that we will be removing the 1 cell phone number per account limit and allowing a certain number of new accounts per month instead (so you can create 5 or so accounts per month before our system stops you). We’re also going to be reviewing the credit card idea but that may take more time.

I’ll update you all once we have a new policy in place and it’s deployed.

Hi All

We have decided to introduce SIP Registration support in a forthcoming update on Skyetel. Our goal it to roll it out in Mid-Late November, but it may come sooner or later than that depending on our testing period. I am posting this because I would like to see if anyone here is interested in acting as a beta tester for us when its further along in development.

While it is in Beta, there will be some limitations:

1. International Calling will not be supported
2. You will be limited to 30 concurrent calls on our network (15 per SIP Region - more on that later)
3. You will be limited to 1 call per second

Our SIP Registration deployment will support 2/4 regions - NW and NE. Your PBX will need to be configured to register to both regions and we will round robin from our regions to support multi-region redundancy. If we do decide to roll it out to all 4, your PBX would need to register to 4 regions in the config (which would be a pita to configure).

It is our intention to still strongly encourage the use of IP Authorization instead of SIP Registration. So we will probably have a few limitations for SIP Registration that do not exist with IP Auth. We also will not support connecting a desk phone or ATA directly to our network, even though technically it will be possible to do so.

A few things we're still thinking about:

1. We have not decided yet if we want to add registration to all 4 of our regions, or only support it in two.
2. We have not decided if we want to include SIP Registration in our SLA or leave it as a "Best effort" service. (TBH, I'm leaning toward including it in the SLA)
3. We have not decided on the Registration timeouts - some carriers enforce a full 1800 seconds and won't let you re-register faster than that. We're leaning toward a 6 minute Registration timeout, and providing guidance that you should re-register every 5 mins.
4. We are worried about fraud risk with SIP Registration. Since it is possible to get your carrier credentials compromised on an old PBX, it becomes possible for a Skyetel account to be compromised itself, rather than through a PBX. So we're thinking about having different balance requirements, or different verification methods, etc. We may also block SIP Registration on old PBXs (please people, stop using Trixbox for the love of god).

I'm interested in your gentle (cough Jared cough ) feedback. What have you guys had experience with, what suggestions or ideas do you have?

Hey Guys,

Behold our new sign up page!

From the feedback here, we made the following changes:

1. You can now re-use your mobile number on 5 new accounts per month (so go nuts @JaredBusch )
2. The new field "Direct Contact Number" serves as the direct phone number for the customer; this is the number we call if there is a fraud event or a porting emergency. (so please make it a real phone number)
3. We made it prettier

Thanks for everyone's feedback - feel free to take it out for a spin!

@Skyetel said in Skyetel needs to get over 11 digit numbers:

@JaredBusch said in Skyetel needs to get over 11 digit numbers:

FFS I cannot do a damned thing in their system without issues with fucking 11 digit numbers..

Today it was opening a support ticket.

1. Yes, I intentionally did not put the 1 in there. I knew that it would probably bitch.
2. Point 1 is not important though, as I do not have a DID that comes to me. That DID goes to an IVR. So I have to put an extension in there. But no, you can only ever use an 11 digit number on anything you ever do in the Skyetel portal.
3. Aside form the extension issue, like my point about the tenant contact info, the contact info for the person they need to call need not be a US based person. Just because I am working with a US based carrier on a US based number does not mean that I have to buy a US based number for you to call me when I am in Tokyo or London or WTF ever.

@Skyetel Have you all never thought about anything like this at all? Seriously?

Okay. You're right. We're over it.

Now you can use 10 digits so long as the first digit does not start with 1

... and you can add extensions into the support ticket request form

Signups will do the same tomorrow.

It is a Cloudflare outage, and it impacts about 30% of the internet. Details here: https://www.cloudflarestatus.com/

60F85B623E

Good till Saturday.

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

Come join our team!

@scottalanmiller said in Skyetel is a scam:

I think that the situation here is that Jared has discovered a fringe use case that just isn't foreseen and was overlooked (and is eleven cents so no one has thought about it before.) No one is scamming over eleven cents, that's ridiculous, and if any of us posted this, Jared would be the first to tear into us.

Should those services be mentioned somewhere so that in this bizarre edge case there is a warning that you might lose a few cents for services you didn't check? Sure, I'll bite and say that that might make sense to have it somewhere so that people aren't surprised on an edge case like that by a few cents that they had not anticipated or to know to look to go turn it off in case they aren't going to want it.

But what needs to be understood is that this is a port of active numbers. Porting an active number that you don't want to use is really odd. Nothing wrong with doing that, just totally bizarre. If you don't care about the number why bother porting it? Because this is so weird, I think it has fallen through the cracks of simply being a use case no one anticipated. I certainly would not think of it, the nature of porting a number creates the assumption (which is almost always correct) that you also plan to use it. Otherwise we'd expect that you'd get a new, immediate number rather than doing an "expensive" port.

But jumping from "someone made a mistake and didn't anticipate that anyone wouldn't want this situation because everyone else probably does, I know I do" to "it's a giant scam trying to get my eleven cents" is a crazy leap that just doesn't add up.

@scottalanmiller this edge case was never really considered. We'll be adding the following to our port in page ASAP:

• Once your number finishes porting, usage and feature costs will begin billing immediately
• Caller ID Lookups & Spam Prevention is enabled by default.`

@JaredBusch said in Skyetel needs to get over 11 digit numbers:

FFS I cannot do a damned thing in their system without issues with fucking 11 digit numbers..

Today it was opening a support ticket.

1. Yes, I intentionally did not put the 1 in there. I knew that it would probably bitch.
2. Point 1 is not important though, as I do not have a DID that comes to me. That DID goes to an IVR. So I have to put an extension in there. But no, you can only ever use an 11 digit number on anything you ever do in the Skyetel portal.
3. Aside form the extension issue, like my point about the tenant contact info, the contact info for the person they need to call need not be a US based person. Just because I am working with a US based carrier on a US based number does not mean that I have to buy a US based number for you to call me when I am in Tokyo or London or WTF ever.

@Skyetel Have you all never thought about anything like this at all? Seriously?

Okay. You're right. We're over it.

Now you can use 10 digits so long as the first digit does not start with 1

... and you can add extensions into the support ticket request form

Hey Guys,

We released this feature a little while ago, but just did a very small update that automatically turns on fraud alerting for all accounts. For those interested, please have a look at this: https://skyetel.atlassian.net/wiki/x/AYA4KQ

The original announcement can be found here:
https://skyetel.com/introducing-fraud-alerts/

We want you to be safe out there

Since @JaredBusch has been kind enough to teach everyone about our Tenant feature, I figured I'd give you guys a preview of this before anyone else - but here's a pre-alpha version of the Tenant Portal. Its still getting love by our front end team, but this is what the dashboard will more or less look like:

@JasGot @JaredBusch

Jared answered things pretty completely, but I wanted to quickly add my feelings.

We've looked a lot at ways to make 911 cheaper for our users with larger facilities (we're pretty popular with School Districts, and carry the traffic for universities everyone in this forum would know - so we deal with this a lot).

While there are ways where we could allow more than one address per phone number and allow you to change things dynamically (like with a SIP packet or a customer CID prefix), I don't have the confidence in NENA and a lot of the PSAPs to trust peoples lives with it. Additionally - even if I did, I still would strongly hesitate to allow more dynamic control of 911 simply because when you increase complexity of something you increase the error rate. Errors with 911 mean people die. A scenario where a misconfiguration sends emergency help to the wrong location without the caller or 911 operator knowing a mistake was made literally turns my stomach.

Putting aside our own liability concerns, my philosophy (speaking as Skyetel's President :D) is that with 911 we have a duty to keep things as reliable and as simple as possible until the industry at large shifts away from DID/Address association and to GPS coordination (or something easy to use that has a low failure rate). The cost of 911 is annoyingly high (its even really expensive for us, and we do a lot of it) and I would love for this whole system to be replaced with something better. However, at the end of the day, I want your 911 calls to be delivered correctly, even if that costs everyone more money. We'll let others be innovative here first and follow the pack when the industry shifts.

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.

Hi everyone!

https://media.giphy.com/media/Cmr1OMJ2FN0B2/giphy-downsized.gif

We’ve used them for years and love them. The first outage wasn’t their fault, and the second didn’t last long. We do pay for them and it’s worth every penny. Their application firewall and DDOS prevention alone are worth it.

@JasGot It was technically released today - so you should be able to install it and start using it now. We'll be doing the formal announcement on Monday (apparently there is a small known bug that our developers want to fix before we release it).

Feel free to spin one up and try it - but I'd suggest waiting until you get the formal email on Monday before putting it in production. I don't personally know what the bug was.

@JaredBusch said in Skyetel auto enables billable services without notice:

@Skyetel said in Skyetel auto enables billable services without notice:

@scottalanmiller said in Skyetel is a scam:

@DustinB3403 said in Skyetel is a scam:

It's not about sensitive. Accounting departments can be incredibly cranky about things being negative and not "due". Negative usually means past due, and can get people up in arms.

Normally the system is pay ahead only, that he was able to port with no money on the account is odd. It is, under normal circumstances (and this is pretty standard for trunk providers for many reasons) standard to only allow you to pay ahead and send a notice when you are getting low on funds so that you can "top up", either manually or automatically. Under normal conditions here, I wouldn't expect a possibility of being in the negative.

This is true - our LNP team should not have ported the number without first reaching out to him about having a $0 balance. We made a mistake and we're going to be making sure to clarify that with our team

I intentionally didn't add funds to a new account I setup (but it does have a valid CC linked) and inititated a port request.

New process FTW. Good work @Skyetel

Thanks! We work hard to listen to everyone's feedback!

PSA - We now support Shortcode SMS and are routing all Canadian traffic entirely in Canada.

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.