Posts made by Skyetel

@DustinB3403 said in Skyetel is a scam:

@Skyetel said in Skyetel is a scam:

FWIW - I (obviously) vote that we should change the title

You have no vote, this isn't SpiteWorks !

lol - Thank God!

@scottalanmiller said in Skyetel is a scam:

@JaredBusch said in Skyetel is a scam:

That does not change all the quoted replies. I already stated as much.
I said I could change the title, but it will not do any good because of th

That is what it is, agreed that it doesn't change the quoted replies. But for someone coming to the thread and looking at the title as the source of "topic", I think that it will do a lot. It will make it clear that the issue was dug into, that "scam" is the wrong term, that there was something wrong that was discovered (and fixed it seems), and that while things weren't perfect, it's not a malicious activity and someone should read down the history of the thread and see what the result was. Otherwise, it is tempting to see the thread, and the title, and just assume too much.

No change is perfect, but I think fixing the title can do a lot to clarify it.

FWIW - I (obviously) vote that we should change the title

@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

@JaredBusch I can confirm that your suggested changes have been made to our Port In page. I'm sorry that you found our billing system confusing and I have refunded your $0.11. (I actually had to give you $1 - our system won't let me go lower than that lol)

I wish that we had had a chance to speak about your frustration prior to you posting this on a public forum. Creating a "Skyetel is a Scam" post seriously hurts us and I would have rather treated this as an opportunity to introduce you to our customer service team.

@scottalanmiller said in Skyetel is a scam:

@JaredBusch said in Skyetel is a scam:

I'm not surprised by the port in charge, no. But I was surprised a month later to find it still on my account as a negative amount.

Okay, just verifying that I understood what you mean. If you look at the April bill, do the charges not appear there? My current charges like number porting show up there, even before the invoice comes out.

This is correct - if you click on the month and change it to the current month, you'll see all "Transactions" we made on your account (like Port In fees or Purchasing a Phone Number)

@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 is a scam:

@FATeknollogee said in Skyetel is a scam:

@Skyetel said in Skyetel is a scam:

@JaredBusch said in Skyetel is a scam:

But this is just theft. Also why is is -$10.11? Terminating those calls most certianly does not cost that much.

@JaredBusch please note that the Port In Fee was $10, the actual usage for this number was only $0.11. So you only spent $0.11 in usage for this number for the month of April thus far.

I wasn't going to be the one that pointed that out...but calling some a "thief" without fully vetting (aka understanding) the charges...that's why I said this thread is just a "pissing" contest.

Theft. 100%. They enabled services with no authorization.

Please note - we add the phone number to your Skyetel account several days prior to completing the port request. Typically our customers modify phone number features and establish routing before the port completes. By not modifying that number, and not logging in again after submitting your port request, the default services were left enabled.

@JaredBusch said in Skyetel is a scam:

@Skyetel said in Skyetel is a scam:

@JaredBusch said in Skyetel is a scam:

But this is just theft. Also why is is -$10.11? Terminating those calls most certianly does not cost that much.

@JaredBusch please note that the Port In Fee was $10, the actual usage for this number was only $0.11. So you only spent $0.11 in usage for this number for the month of April thus far.

Now that I have been informed that the port in fee was not directly billed as I expected, that explains that.

$0.11 or $500 does not matter when it is for services never asked for.

Please note that we do disclose that there is a Port In fee on the Port In Page:

@JaredBusch said in Skyetel is a scam:

But this is just theft. Also why is is -$10.11? Terminating those calls most certianly does not cost that much.

@JaredBusch please note that the Port In Fee was $10, the actual usage for this number was only $0.11. So you only spent $0.11 in usage for this number for the month of April thus far.

@JaredBusch

I understand that this is frustrating and I apologize for the confusion here. When you port in a number onto our network, we activate the number with the PSTN, bring it into service, and enable our default services (Caller ID and Spam Block). It is our goal to make that phone number route immediately so that you can use it immediately. We assume that by porting in a number, you want it active.

When we activate a phone number and establish PSTN routing, we have to send the call somewhere - sorta like an IP Address. We can't activate the number and not route it - so we end up sending it to a Skyetel server that plays our version of "Phone Number not in service." This serves as a sorta of middle-ground; the number is "Active" with the PSTN but the experience callers have is that it is not in service.

By keeping a phone number "Active" with the PSTN we do have to have reserved capacity, and it does cost us money - Idle numbers aren't actually Idle. Again, like IPs, if they've been issued, they have to route somewhere. Therefore, because idle numbers do have a cost, we do charge for the call time to play that not in service message.

Lastly, it's important to note that keeping a number in our inventory without ever routing it is not how our network was designed to work - its designed to have an Endpoint assigned and routed.

@JaredBusch your are being billed for service because you ported in a phone number (1618654****) and it is receiving inbound calls. Additionally, you are being billed for the Caller ID and Spam Prevention lookups that you have enabled on your phone number.
Lastly - you were billed when you ported in the number

@JaredBusch @FATeknollogee

FWIW - this issue in particular was probably being caused by the ISP or the Modem, not the edgerouter. We recommended using TCP because it handles ISP NATing better and modems tend to get less confused by it.

While it could have something to do with the edgerouter, we like those routers and they tend to perform well. TCP just tends to be a catch all that fixes a lot of SIP deliverability issues.

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.

Hey All,

We have some really exciting news to share - today we have released an Open Source SMS & MMS GUI for the Skyetel SMS platform.

Its free, open source and you can check it out here:
https://skyetel.com/introducing-postcards/

and read our documentation here:
https://skyetel.atlassian.net/wiki/spaces/SUG/pages/649134085/Postcards

@BRRABill All your base are belong to us...

@Dashrender It used to be that legacy carriers had the best uptime (back when they exclusively used TDM), but they didn't switch from TDM to SIP gracefully and still haven't gotten their act together. Every big carrier has their own quirks but they are caused by the same fundamental problem: no big CLEC is a single network, they are only single billing mechanism for multiple underlying networks. A really good example of this is CenturyLink - Depending on where you are, you could be on TW Telecom's Network, or Qwest's, or Level 3, or the OG CTL network... its practically endless. That sort of architecture worked better when everything was TDM; voltage is voltage. With SIP... man - you have protocols, packet buffers, MTUs, ISPs, etc. It's infinitely more complicated to stitch together aging disparate networks transparently. Alternatively, If you are a small legacy carrier (like Cox) you don't have the money to trash millions of dollars of TDM to replace it with millions of dollars of VoIP equipment, pay to train your employees, and get your customers on board in a time period where you don't die from the transition (this is why the little guys tend to just get bought by the big ones)

Carriers like Twilio, VoIP.MS, Skyetel (us - shameless plug!) are better at SIP because thats all we ever were - Skyetel doesn't own a single piece of TDM equipment at all, and I bet neither do Twilio or VoIP.MS. We don't have to worry about training ready-to-retire employees who are more comfortable dealing with Muxers than Jitter. This fact is actually recognized by the FCC and is part of the reason why they let carriers like us skip the whole CLEC registration process and go straight to numbering authority.

All that to say - I'd bet on our network over any Legacy Carrier every day of the week. Truthfully - I'd bet on most SIP-Only networks over legacy carriers too. But i may be biased

Hi everyone!

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

@Dashrender @scottalanmiller Almost all carriers are using SIP for Local Calling. Toll Free calling is the last refuge of TDM (which is one of the reasons its so expensive). If your carrier is giving your a PRI, I'd bet almost anything its pure SIP

@wrx7m I'm obviously biased - but PRIs are a complete waste of money these days. Most SIP Trunk providers are delivering just as good of service as a PRI but at a fraction of the cost. I'd put our service up against any PRI any day of the week. So long as you have a good internet connection, using a PRI is a big waste of money.

Again though... I'm pretty biased lol

SIP Registration keeps the UDP ports open only for so long (I believe the ERL defaults to 90 seconds). So long as your registrations occurs on regular intervals that are lower than the UDP timeout, your port is effectively being forwarded automatically. Some routers do this much better than others - ERLs are pretty great and we recommend them. SonicWalls are the devices that we have the biggest headache with. If you can, enable NAT timeout on the PBX and keep that frequency low - that will keep the UDP port open forever and does take care of most problems with Port Forwarding. (Though I still prefer Fort Forwarding!)

When the PBX registers to the server/carrier, it gets the public IP information from the registration request and add its it to the call routing. You have to be careful though - just because you can receive calls doesn't mean you will have audio available - those can come on different ports and from different Public IPs. Smarter routers (like the ERL) understand the context of the transmission because they understand the dual-method involved in VoIP (RTP and SIP) and can fix mistakes other routers cant.