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

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.