Best posts made by Skyetel

@Dashrender said in Skyetel defenses tripped:

I have to hand to it to @Skyetel - it's outside of Support hours but they got the notice of my post and came in and responded.

Very awesome!

I hope that at some point Skyetel can hire some people to be in the support desk 24/7 (even if from home) so there is less stress on @Skyetel.

But for now I'll take the win in being part of MangoLassi!

Thanks @Dashrender for the nice words :).

FWIW - we do have on call 24/7, but only for emergency tickets from current customers. But I'm happy that I was able to get you setup!

@JaredBusch said in SIP, PBX, E911 routing and teminology.:

@JasGot said in SIP, PBX, E911 routing and teminology.:

The provider is Skyetel, and they will not/can not re-write the outbound caller ID based on a calling plan/route. My first choice would be to have Skyetel re-write all outbound caller IDs to be the main number UNLESS the dialed number was "911".

That is not the job of the provider. That is the job of the PBX.

FWIW - there are providers that do this (not us though). Its extremely expensive as you have to own all the phone numbers you are using, and the rates to do this are very high.

@travisdh1 said in Postcards for SMS by Skyetel.:

@manxam said in Postcards for SMS by Skyetel.:

@scottalanmiller : Just for clarification, what do you mean that Docker isn't cross platform?

Exactly that, Docker IS NOT CROSS PLATFORM. Build a Docker widget with Ubuntu and you can not run it on CentOS.

I think what's more important than how it works is that it is not intuitive to most people (even me). We write all of our applications for docker because it makes them more resilient and easier to scale, but they are conceptually more difficult for the vast majority of our users who are used to being able to just go to /var/www/html and make the changes they want. We went with docker to maintain that standard, but it has created some headaches for our users who aren't comfortable with it. This is why we're releasing Postcards 1.1 in a OVF and prepackaged.

@JaredBusch said in Skyetel's 4th Region:

@Skyetel how new is 4.skyetel.com my PBX doesn't see the A record now.

So my initial test was valid, but seems DNS is not solid yet or something.

This was our mistake - we reset our DNS settings for 4.skyetel.com in preparation for tomorrow mornings announcement. Should be solid now that it’s been deployed to our production settings on Cloudflare. (It needed TCP support)

@JaredBusch said in Skyetel's 4th Region:

Also, since 4.skyetel.com has both A records and SRV records, it works perfectly in FreePBX without any extra firewall settings or the need for the match/permit setting in advanced.

[jbusch@pbx ~]$ dig 4.skyetel.com @1.1.1.1

; <<>> DiG 9.9.4-RedHat-9.9.4-74.el7_6.1 <<>> 4.skyetel.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17708
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;4.skyetel.com.			IN	A

;; ANSWER SECTION:
4.skyetel.com.		229	IN	A	52.8.201.128
4.skyetel.com.		229	IN	A	52.60.138.31
4.skyetel.com.		229	IN	A	52.41.52.34
4.skyetel.com.		229	IN	A	50.17.48.216

;; Query time: 3 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Apr 23 21:38:56 CDT 2020
;; MSG SIZE  rcvd: 119

[jbusch@pbx ~]$ dig SRV _sip._udp.4.skyetel.com @1.1.1.1

; <<>> DiG 9.9.4-RedHat-9.9.4-74.el7_6.1 <<>> SRV _sip._udp.4.skyetel.com @1.1.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28558
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1452
;; QUESTION SECTION:
;_sip._udp.4.skyetel.com.	IN	SRV

;; ANSWER SECTION:
_sip._udp.4.skyetel.com. 269	IN	SRV	10 10 5060 ca1.skyetel.com.
_sip._udp.4.skyetel.com. 269	IN	SRV	10 10 5060 va1.skyetel.com.
_sip._udp.4.skyetel.com. 269	IN	SRV	10 10 5060 or1.skyetel.com.
_sip._udp.4.skyetel.com. 269	IN	SRV	10 10 5060 eh.skyetel.com.

;; Query time: 3 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Apr 23 21:39:03 CDT 2020
;; MSG SIZE  rcvd: 214

It also has TCP support

@JasGot said in Wrong Caller ID:

@Skyetel said in Wrong Caller ID:

@JasGot said in Wrong Caller ID:

@krzykat said in Wrong Caller ID:

@JasGot What are you referencing? The DIP at Skyetel or ?

For the Caller ID Editor.

Without the "1" They accept it, tell you it has processed, then do nothing with it......

With the "1", they accept it, tell you it has processed, then they actually submit it to the Caller ID database in the sky (or wherever it is)

This might be a bug. I’ll have it checked out.

Or, and better, do validation on the submission and require 11 digits! (Always better to validate user input....)

We cant validate a submission like we can elsewhere because the CID updated is not a real time process. That’s why (as Jared noted) it can take a couple of days for it to update. These updates sit in a queue and get updated when the CID gods are in a good mood.

We tweaked our UI to allow 10 digit entries based on feedback here and I suspect that when we did that, the thing that converts the entry into E.164 got mixed up. The CID stuff is crazy arcane...

CID entries can also get rejected If the LIDB thinks their data is more accurate than ours. We don’t get any feedback about that (the log will just show it as rejected, often without a reason, and we have to open a ticket to dispute the rejection.)

And of course, as Jared mentioned, if the party you are calling caches their records for a long time (or never updates them - something that’s super common) then there’s nothing we can do.

So yea, that tool hides a lot and generates a lot of support tickets for us. We try to make what is an absurdly complicated process easy, but by doing so we’re opening the door to bugs like this. Welcome to telecom! lol

@scottalanmiller said in Install Skyetel Postcards on CentOS 7:

@JasGot said in Install Skyetel Postcards on CentOS 7:

@scottalanmiller Works ok with 2GB? I remember someone saying it really needs 4gb.

Perfectly fine in 2GB. Going to test 1GB soon. Only using 480MB according to free.

It takes 2GB to build, but then its very lightweight. 4GB is recommended if you are have other things running on the server that is hosting Postcards.

@ing-joserivera26 said in VitalPBX 3:

@JaredBusch In that case you must put the host in the match field. I guess you must put: srv.skyetel.com

Skytel said in your blog:

SkyEtel

@JasGot said in Recording calls on a SIP Trunk to a local Recorder/Logger:

Forgot to add this above, it may require two recording methods: since it is an in house pbx. Ext to Ext recording is required.

Oh - in that case It would depend on what PBX you are using. @JaredBusch would probably know about that than I would. However - most PBXs support call recording internally. That would be the best option if you can do it

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.

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

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.

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

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.

@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