FOOD FOR THOUGHT BulkVS.com -- Great Origination/Termination/TF rates!

[kenn10]

Several important excerpts from the FCC ruling:

Mandating the STIR/SHAKEN Framework
We require all originating and terminating voice service providers to implement the STIR/SHAKEN framework in the IP portions of their networks by June 30, 2021 for several compelling reasons. First, ubiquitous STIR/SHAKEN implementation will yield substantial benefits for American consumers. We estimate that the benefits of eliminating the wasted time and nuisances caused by illegal scam robocalls will exceed $3 billion annually.[1] And more importantly, we expect STIR/SHAKEN paired with call analytics to serve as a tool to effectively protect American consumers from fraudulent robocall schemes that cost Americans approximately $10 billion annually.[2] Further, we anticipate that implementation will increase consumer trust in caller ID information and encourage consumers to answer the phone, thereby benefitting businesses, healthcare providers, and non-profit charities.[3] Widespread implementation also benefits public safety by decreasing disruptions to healthcare and emergency communications systems, and as a result, saving lives.[4] Additional benefits include significantly reducing costs for voice service providers by eliminating unwanted network congestion and decreasing the number of consumer complaints about robocalls.[5] Ultimately, we expect widespread STIR/SHAKEN implementation to reduce the scourge of illegal robocalls that plague Americans every day.[6]

Second, the record overwhelmingly reflects support from a broad array of stakeholders for rapid STIR/SHAKEN deployment, and many commenters support a STIR/SHAKEN mandate.[7] Commenters, including the attorneys general of all fifty states and the District of Columbia, consumer groups, and major voice service providers expressed support for Commission action if widespread voluntary implementation did not occur.[8] The unified state attorneys general argue that a mandate is necessary “in the absence of prompt voluntary implementation” by the end of 2019 because without such action, “bad actors exploit inexpensive and ubiquitous technology to scam consumers and to intrude ...

Implementation Deadline. We set the implementation deadline of June 30, 2021 for two reasons. First, it is consistent with the TRACED Act, which requires us to set a deadline for implementation of STIR/SHAKEN that is not later than 18 months after enactment of that Act, i.e., no later than June 30, 2021.[1] Second, this deadline will provide sufficient time for us to implement, and for voice service providers to gain, a meaningful benefit from the implementation exemption and extension mechanisms established by the TRACED Act.[2] Because we find that this implementation deadline is necessary to accommodate the various exemption and extension mechanisms established by the TRACED Act, we decline to adopt the suggestion of some commenters that we mandate implementation by June 1, 2020.[3]

 

[Halea]

Full FCC information on SHAKEN/STIR mandates: https://www.fcc.gov/document/fcc-mandates-stirshaken-combat-spoofed-robocalls

All user provided caller ids are not spoofed robocalls. Probably a good chunk of all business phone calls rely on "spoofed" caller ids for legitimate reasons. So FCC mandates fighting spoofed robocalls, it doesn't say user provided caller id won't be transmitted over IP or POTS networks.
This is why all the major (and minor probably) players are implementing techniques to single out misleading or malicious robocalls by way of building consumer feedback based databases or call pattern and target identification.
Note that such systems are not even blocking those calls, but just tagging them to bring them to your attention. It's the end user who decides to take or to decline the call. The carriers are not given and have no authority to block the calls regardless the reason. I am not saying it's good or bad, it's just how it is, and the most recent regulation changes still adhere to that principle.
So, don't lose your sleep. You are still going to be able to spoof caller ids for legitimate use.

 

[ChipG]

Hey guys, it seems BulkVS.com is down, I can not log in or get any pages to load, is anyone else having an issue with them?

Thank you!

 

[ChipG]

It's back up now but there was an outage for about 10 minutes.

 

[Prits]

Hello DoctorJ,

Thank you this information!

yeah I too had followed Wards article to the T, but following your suggestion, it seems to have fixed my issue!!!

i appreciate your knowledge and help. When I asked BulkVS, the said that they did not know and that I had to troubleshoot on my own. I was surprised at this because I had read on this forum that their support is very good. Oh well, hopefully that was just an isolated experience!

Hello Gurus

I have a question...

I decided to connect to BulkVS using IP authentication (at a sandbox at CrownCloud) instead of sip registration as I already have another PBX using SIP based registration with BulkVS successfully.

I purposefully skipped adding the 4 BulkVS IP addresses to the iptables-custom as shown in @wardmundy tutorial https://nerdvittles.com/?p=32094 to first test that those IP's were in fact being blocked and hence calls would be rejected and then I would add the IP entries once I confirmed that.

BUT, the INBOUND and OUTBOUND calls from BulkVS still work!

Any words of wisdom why this still happens even though the 4 IPs are not whitelisted?

(I am not using SIP Registration to connect at all)

(Please note, that I have tested the firewall by trying to access the PBX GUI via a none-whitelisted IP address and the firewall seems to work because it will not load the GUI on that non-whitelisted computer)

Incredible PBX/FAX 2020.1 for CentOS 7

Asterisk: UP Apache: UP MySQL: UP
SendMail: UP IPtables: UP SSH: UP
LAN port: UP Fail2Ban: UP Webmin: UP
UCP Dmon: UP PortKnock: UP NR VPN: UP
FaxGetty: DN IAX Modem: DN HylaFax: DN

RAM:78MB CentOS Rel. 7.8.2003 Disk:11GB

Asterisk 16.12.0 Incredible GUI 15.0.12.28

Private IP: XXX.XXX.XXX.XXX

Public Info: XXX.XXX.XXX.XXX

System Time: Tue Sep 29 10:14:07 MST 2020

 

[wardmundy]

@Prits: How do you know the IP addresses aren't already whitelisted?? Check in BOTH /etc/sysconfig/iptables and /usr/local/sbin/iptables-custom.

 

[Prits]

@Prits: How do you know the IP addresses aren't already whitelisted?? Check in BOTH /etc/sysconfig/iptables and /usr/local/sbin/iptables-custom.

Hey @wardmundy

Good question Sir! I should have mentioned that I looked at both those files and searched within them and I cannot find the 4 BulkVS IPs.

(On a side note, I merely spooled up the Incrediblepbx-2020 template at CrownCloud, so it's completely 'bare' and as far as I understand it, that template does not include BulkVS already as one of the trusted SIP providers. Nonetheless, I did check those 2 files /etc/sysconfig/iptables and /usr/local/sbin/iptables-custom and can't find those IP addresses)

 

[wardmundy]

Is this the PUBLIC version of Incredible PBX?

 

[tbrummell]

iptables -vnL | grep ip.address.bulk.vs

That will tell you if it's there or not.

 

[Prits]

Is this the PUBLIC version of Incredible PBX?

I'm not sure since all I did was follow this article and used the template at CrownCloud, so I'm thinking that it is since it sits on a VPS at CrownCloud with a public IP address:

5 Minutes to Paradise: Incredible PBX in the Cloud for $25/Yr. – Nerd Vittles

nerdvittles.com

 

[Prits]

iptables -vnL | grep ip.address.bulk.vs

That will tell you if it's there or not.

I guess not, since here is the output:

root@vps:~ $ iptables -vnL | grep ip.address.bulk.vs
WARNING: Always run Incredible PBX behind a secure firewall.
root@vps:~ $

 

[tbrummell]

hmmmm, drop the | grep.... and see what you get. You should have a few hundred lines. I'm curious if any rules are loaded.

 

[Prits]

hmmmm, drop the | grep.... and see what you get. You should have a few hundred lines. I'm curious if any rules are loaded.

Yeah! lol... here is all I could copy and paste from the console (there's a lot more at the beginning, so iptables is being loaded for sure)

udp dpts:5060:5069
0 0 ACCEPT udp -- * * 67.212.84.21 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 176.9.39.206 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 72.9.149.25 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 50.22.102.242 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 98.254.157.185 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 178.63.143.236 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 98.254.157.185 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 64.2.142.26 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 198.199.84.66 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 104.236.102.59 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 159.203.110.178 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 45.55.163.124 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 162.243.107.101 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 162.243.210.200 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 216.66.23.179 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT all -- * * 35.156.192.164 0.0.0.0/0
0 0 ACCEPT all -- * * 50.17.48.216 0.0.0.0/0
0 0 ACCEPT all -- * * 52.60.138.31 0.0.0.0/0
0 0 ACCEPT all -- * * 52.8.201.128 0.0.0.0/0
0 0 ACCEPT all -- * * 52.41.52.34 0.0.0.0/0
0 0 ACCEPT udp -- * * 207.239.159.171 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 38.130.255.68 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 38.130.255.68 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 173.246.36.196 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT udp -- * * 207.239.159.171 0.0.0.0/0 udp dpts:5060:5069
204 10692 ACCEPT all -- * * 98.171.92.224 0.0.0.0/0
0 0 ACCEPT all -- * * 99.198.122.166 0.0.0.0/0
0 0 ACCEPT all -- * * 99.198.122.166 0.0.0.0/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 274K packets, 139M bytes)
pkts bytes target prot opt in out source destination
WARNING: Always run Incredible PBX behind a secure firewall.
root@vps:~ $

 

[Prits]

Just need help trying to wrap my head around this issue lol... I'm been researching the net to see if using IP address authentication in asterisk versus SIP registration for trunks opens up a pinhole of any kind in the firewall but I can't seem to find anything and therefore still can't understand why calls in and out are working using BulkVS IP authentication without adding their 4 IPs to the firewall!

 

[jerrm]

Just need help trying to wrap my head around this issue lol...

Are the calls coming from the same server the outbound calls were sent to?

Assuming UDP, outbound would be expected to work without firewall changes(barring something unusual).

Inbound normally wouldn't, but a recent outbound call, keepalive packet, registration from another trunk, etc could possibly cause conntrack to think the incoming was part of the prior conversation.

 

[jerrm]

I guess not, since here is the output:

Reviewing the thread, it looks like you took @tbrummell's post a little too literally.

Simplifying his suggestion, post the output of the below(should be cut and paste ready):

iptables -vnL | grep 198

 

[Prits]

Are the calls coming from the same server the outbound calls were sent to?

Assuming UDP, outbound would be expected to work without firewall changes(barring something unusual).

Inbound normally wouldn't, but a recent outbound call, keepalive packet, registration from another trunk, etc could possibly cause conntrack to think the incoming was part of the prior conversation.

no, so I have tried placing zero outbound calls and waited 24hrs+ to call inbound and calls still come through...

calls are not always coming inbound on the same IP address either... it's one of their 4 IPs... and when I do place an outbound call and then immediately place an inbound call, its not the same IP address as the outbound call either.

 

[Prits]

Reviewing the thread, it looks like you took @tbrummell's post a little too literally.

Simplifying his suggestion, post the output of the below(should be cut and paste ready):

iptables -vnL | grep 198

Here is the output @jerrm :

WARNING: Always run Incredible PBX behind a secure firewall.
root@vps:~ $ iptables -vnL | grep 198
0 0 ACCEPT all -- * * 99.198.110.51 0.0.0.0/0
0 0 ACCEPT all -- * * 99.198.122.166 0.0.0.0/0
0 0 ACCEPT all -- * * 99.198.110.51 0.0.0.0/0
0 0 ACCEPT all -- * * 99.198.122.166 0.0.0.0/0
0 0 ACCEPT udp -- * * 198.199.84.66 0.0.0.0/0 udp dpts:5060:5069
0 0 ACCEPT all -- * * 99.198.122.166 0.0.0.0/0
0 0 ACCEPT all -- * * 99.198.122.166 0.0.0.0/0
WARNING: Always run Incredible PBX behind a secure firewall.
root@vps:~ $

and it does not contain any of the BulkVS's IP addresses

 

[wardmundy]

Everyone enjoys an academic exercise up to a point, but this is obviously difficult to diagnose without access to your server AND your BulkVS account. If the calls are flowing and IPtables is otherwise blocking access from other non-whitelisted IP addresses, then I think you're in good shape. In the Asterisk CLI, you might want to check the following to be sure you don't have a SIP registration to BulkVS that you've forgotten about:

sip show registry
pjsip show registrations

If you want to hire someone to look at your server and your BulkVS account, I'm sure we could figure this out, but BulkVS is a reputable provider AND you have connectivity so I'm going to bow out on this one.

 

[Prits]

Everyone enjoys an academic exercise up to a point, but this is obviously difficult to diagnose without access to your server AND your BulkVS account. If the calls are flowing and IPtables is otherwise blocking access from other non-whitelisted IP addresses, then I think you're in good shape. In the Asterisk CLI, you might want to check the following to be sure you don't have a SIP registration to BulkVS that you've forgotten about:

sip show registry
pjsip show registrations

If you want to hire someone to look at your server and your BulkVS account, I'm sure we could figure this out, but BulkVS is a reputable provider AND you have connectivity so I'm going to bow out on this one.

Thanks @wardmundy
Like you said, I think that I am in good shape too! So, I'll just put my curiosity to bed for 'now'... (BUT THAT DOES NOT MEAN ANYONE ELSE CAN'T HELP IF THEY WANTED TO!)

I did run the commands you gave me to make sure and here is the output confirming no sip registrations:

vps*CLI> sip show registry
Host dnsmgr Username Refresh State Reg.Time
0 SIP registrations.

vps*CLI> pjsip show registrations
No objects found.

vps*CLI>


Thank you all for your help.