Tutorial for newcomers:
One-way audio, or in some cases zero-way audio, might be the result of a networking issue either caused by bad config(s) in your linux server, or firewall soft/hardware.
Of course, it could be something else altogether
I'll share my troubleshooting process with the group - it most likely will be of benefit to newish users
What to do when Audio/Network Fails:
Step 1: Immediately begin writing down everything that you have interacted (tinkered) with on the server and network gear in the past hour (or longer, depending on when you notice the failure). This includes, ranging from easiest to detect (and fix) to the hardest:
*] Check with your service provider (ISP, VoIP) to make sure your account is current
**] Make sure all necessary hardware components are powered on
A] FreePBX web gui interaction
B] Webmin
C] Linux CLI
D] Firewall hardware/Managed Switches
E] Gateway/Modem
Don't do anything until you write your list - blindly troubleshooting can take you where you are so far over your head (beyond your ability) that you won't even be able to remember changes you may have made from two minutes prior! And yes, this entire post is based off of personal experience
For paperless operations, use your favorite text program like notepad on windows.
Step 2: Using your list from Step 1, go over any changes that you made and look for mistakes. In certain instances of Linux CLI (and elsewhere, I'm sure) if you make a change in on place, it may create changes in numerous other places, and you will need to track down the after-effects of the mistake. Google & Wikipedia is your friend
Example: You want to add/remove/update/downgrade a hardware network interface card (nic) on your server. After reboot your Ethernet device no longer shows as eth0, it shows eth1. Let's say you want to fix it, so you make changes using the Linux CLI or Webmin - perhaps to try to simply rename the device. Sounds reasonable/logical, right? Wrong. (Google it)
As a general rule of thumb, if you have a complex pbx system setup, and you still can't determine what caused the audio/network issue, "decomplexify" your system to a basic setup and then get that to work again. Once you have the basic service operational again, then selectively reactivate your customizations. Examples (IMO) of nonbasic elements:
On FreePBX:
day/night
time conditions
follow me
queues
numerous ring groups
camp on
parking lot
blacklist
I can't count how many times I've tinkered incorrectly within Freepbx resulting in an offline service/server. The easiest thing to do in FreePBX when this happens:
1) set up a simple extension that you can access
2) set up a simple ivr that routes calls to your extension, making sure to use the '0' 'i' 't' options - so three separate option rules
3) set up a simple catch all in the Inbound Routes
(should already have it by default incrediblepbx install) and then route all calls to your simple ivr
Other nonbasic elements:
On Linux:
bonding network interfaces
utilizing more than one nic / ip address
virtual anything unless you are "testing"
tinkering with iptables / fail2ban
changing hardware frequency/clock/timing/resource allocation {which has nothing related to system time}
selinux
protocol binding
On Webmin:
Non-default Network Routing
Bandwidth monitoring
lvm
virtual anything
clusters
firewall
The list can literally go on and on but this should be a good start.
One-way audio, or in some cases zero-way audio, might be the result of a networking issue either caused by bad config(s) in your linux server, or firewall soft/hardware.
Of course, it could be something else altogether
I'll share my troubleshooting process with the group - it most likely will be of benefit to newish users
What to do when Audio/Network Fails:
Step 1: Immediately begin writing down everything that you have interacted (tinkered) with on the server and network gear in the past hour (or longer, depending on when you notice the failure). This includes, ranging from easiest to detect (and fix) to the hardest:
*] Check with your service provider (ISP, VoIP) to make sure your account is current
**] Make sure all necessary hardware components are powered on
A] FreePBX web gui interaction
B] Webmin
C] Linux CLI
D] Firewall hardware/Managed Switches
E] Gateway/Modem
Don't do anything until you write your list - blindly troubleshooting can take you where you are so far over your head (beyond your ability) that you won't even be able to remember changes you may have made from two minutes prior! And yes, this entire post is based off of personal experience

For paperless operations, use your favorite text program like notepad on windows.
Step 2: Using your list from Step 1, go over any changes that you made and look for mistakes. In certain instances of Linux CLI (and elsewhere, I'm sure) if you make a change in on place, it may create changes in numerous other places, and you will need to track down the after-effects of the mistake. Google & Wikipedia is your friend
Example: You want to add/remove/update/downgrade a hardware network interface card (nic) on your server. After reboot your Ethernet device no longer shows as eth0, it shows eth1. Let's say you want to fix it, so you make changes using the Linux CLI or Webmin - perhaps to try to simply rename the device. Sounds reasonable/logical, right? Wrong. (Google it)
As a general rule of thumb, if you have a complex pbx system setup, and you still can't determine what caused the audio/network issue, "decomplexify" your system to a basic setup and then get that to work again. Once you have the basic service operational again, then selectively reactivate your customizations. Examples (IMO) of nonbasic elements:
On FreePBX:
day/night
time conditions
follow me
queues
numerous ring groups
camp on
parking lot
blacklist
I can't count how many times I've tinkered incorrectly within Freepbx resulting in an offline service/server. The easiest thing to do in FreePBX when this happens:
1) set up a simple extension that you can access
2) set up a simple ivr that routes calls to your extension, making sure to use the '0' 'i' 't' options - so three separate option rules
3) set up a simple catch all in the Inbound Routes
(should already have it by default incrediblepbx install) and then route all calls to your simple ivr
Other nonbasic elements:
On Linux:
bonding network interfaces
utilizing more than one nic / ip address
virtual anything unless you are "testing"
tinkering with iptables / fail2ban
changing hardware frequency/clock/timing/resource allocation {which has nothing related to system time}
selinux
protocol binding
On Webmin:
Non-default Network Routing
Bandwidth monitoring
lvm
virtual anything
clusters
firewall
The list can literally go on and on but this should be a good start.