Skyetel's 4th Region
-
HAHAHAHAHAHAHAHA you named it 'eh'
_sip._udp.4.skyetel.com. 300 IN SRV 10 10 5060 eh.skyetel.com.
[jbusch@dt-jared ~]$ dig SRV _sip._udp.4.skyetel.com ; <<>> DiG 9.11.14-RedHat-9.11.14-2.fc31 <<>> SRV _sip._udp.4.skyetel.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19180 ;; 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. 300 IN SRV 10 10 5060 va1.skyetel.com. _sip._udp.4.skyetel.com. 300 IN SRV 10 10 5060 eh.skyetel.com. _sip._udp.4.skyetel.com. 300 IN SRV 10 10 5060 or1.skyetel.com. _sip._udp.4.skyetel.com. 300 IN SRV 10 10 5060 ca1.skyetel.com. ;; Query time: 27 msec ;; SERVER: 10.254.103.4#53(10.254.103.4) ;; WHEN: Thu Apr 23 21:07:18 CDT 2020 ;; MSG SIZE rcvd: 214
-
@JaredBusch lol, yes. yes we did lol.
-
@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.
-
If I remove the 127.0.0.1 it resolves. But I've never noticed issues in the past. with this typical setup.
-
Also, since 4.skyetel.com has both
A
records andSRV
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
-
@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 andSRV
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
-
@Skyetel said in Skyetel's 4th Region:
It also has TCP support
TLS/SRTP support coming? Or just setting up TCP for those unlucky people that have to use it?
-
@JaredBusch said in Skyetel's 4th Region:
@Skyetel said in Skyetel's 4th Region:
It also has TCP support
TLS/SRTP support coming? Or just setting up TCP for those unlucky people that have to use it?
Just for those who have to use TCP.
TLS/SRTP forces us to get into the audio path and we’re not super excited to do that. Upstream PSTN networks don’t support it either.
-
@Skyetel said in Skyetel's 4th Region:
@JaredBusch said in Skyetel's 4th Region:
@Skyetel said in Skyetel's 4th Region:
It also has TCP support
TLS/SRTP support coming? Or just setting up TCP for those unlucky people that have to use it?
Just for those who have to use TCP.
TLS/SRTP forces us to get into the audio path and we’re not super excited to do that. Upstream PSTN networks don’t support it either.
Not something I'm worried about but there are always those clients that think it is a must have.
-
@Skyetel said in Skyetel's 4th Region:
It also has TCP support
Asterisk itself supports SRV and has ever since PJSIP was released.
I've never bothered to dig into WTF FreePBX is doing with DNS yet, but I cannot use
srv.skyetel.com
in a PJSIP trunk. I assume because there is noA
record. Asterisk recognizes things mostly, but the trunk never comes up for outbound calls. Your portal shows green and I assume I will get calls (never tested that and I should).[jbusch@pbx ~]$ dig srv.skyetel.com @1.1.1.1 ; <<>> DiG 9.9.4-RedHat-9.9.4-74.el7_6.1 <<>> srv.skyetel.com @1.1.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10202 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1452 ;; QUESTION SECTION: ;srv.skyetel.com. IN A ;; AUTHORITY SECTION: skyetel.com. 3600 IN SOA lou.ns.cloudflare.com. dns.cloudflare.com. 2033936176 10000 2400 604800 3600 ;; Query time: 7 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Thu Apr 23 21:46:57 CDT 2020 ;; MSG SIZE rcvd: 113
On the other hand,
term.skyetel.com
has noSRV
records.[jbusch@pbx ~]$ dig SRV _sip._udp.term.skyetel.com @1.1.1.1 ; <<>> DiG 9.9.4-RedHat-9.9.4-74.el7_6.1 <<>> SRV _sip._udp.term.skyetel.com @1.1.1.1 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29549 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1452 ;; QUESTION SECTION: ;_sip._udp.term.skyetel.com. IN SRV ;; AUTHORITY SECTION: skyetel.com. 3274 IN SOA lou.ns.cloudflare.com. dns.cloudflare.com. 2033936176 10000 2400 604800 3600 ;; Query time: 3 msec ;; SERVER: 1.1.1.1#53(1.1.1.1) ;; WHEN: Thu Apr 23 21:44:33 CDT 2020 ;; MSG SIZE rcvd: 124
-
Well - it looks like we have to issue an update about this.
Unfortunately, 4.skyetel.com clashes with some systems that do not support numerical values in DNS entries (yes, thats a real thing) and so please use na.skyetel.com instead. We will be sending out an email tomorrow asking everyone to please use na.skyetel.com instead of 4.skyetel.com. Sorry for the headache guys.