- Joined
- Apr 19, 2018
- Messages
- 1
- Reaction score
- 0
Hello,
We've been using 3CX for years and we're very happy with the product.
For years, we've run our 3CX on a Windows server we're using for other purposes and it worked fine.
Some time ago, we replaced our analog lines and FXO device with a VoIP Provider. Things seemed to work well with the provider for a while.
More recently, we replaced our old server with a new Windows server and moved our 3CX installation onto the new server. Again, things seemed to work fine for a while.
For the last few months, we've been having very rare and infrequent problems with egress audio on PSTN calls via the SIP provider. The circumstances are strange in that we never have audio problems with our remote STUN extensions outside of the office.
- Extension to Extension calls over the LAN --> Never a problem.
- Extension on LAN calls to remote STUN Extensions ---> Never a problem.
- Remote STUN extensions to LAN extensions ---> Never a problem.
- Inbound PSTN calls --> Started as the only problem and occurred rarely.
- Outbound PSTN calls --> Just started today, lasted about 5 minutes and hasn't happened since.
This problem only pertains to PSTN calls and is only affecting egress audio leaving our office, going only to the PSTN via the SIP provider.
Our Internet connection is a Comcast cable modem with 20Mbps down/5Mbps up and a static IP.
Our router is a Cisco RV42G. It's the same router we've had since before we switched to the VoIP provider. We've verified that port forwarding is configured properly.
Several weeks ago, in order to try to eliminate the Windows OS and other installed software on the server as a contributor to the problem, we created a new Hyper-V VM, gave it plenty of resources and moved 3CX to that VM running Debian which was installed using the 3CX ISO.
We are unable to recreate this problem at will. It only happens every few weeks and does not happen in any regular pattern that we can identify. There is also no pattern relating to the callers and callees, which we can identify.
If anyone has any suggestions, they would be greatly appreciated. Thank you in advance!
We've been using 3CX for years and we're very happy with the product.
For years, we've run our 3CX on a Windows server we're using for other purposes and it worked fine.
Some time ago, we replaced our analog lines and FXO device with a VoIP Provider. Things seemed to work well with the provider for a while.
More recently, we replaced our old server with a new Windows server and moved our 3CX installation onto the new server. Again, things seemed to work fine for a while.
For the last few months, we've been having very rare and infrequent problems with egress audio on PSTN calls via the SIP provider. The circumstances are strange in that we never have audio problems with our remote STUN extensions outside of the office.
- Extension to Extension calls over the LAN --> Never a problem.
- Extension on LAN calls to remote STUN Extensions ---> Never a problem.
- Remote STUN extensions to LAN extensions ---> Never a problem.
- Inbound PSTN calls --> Started as the only problem and occurred rarely.
- Outbound PSTN calls --> Just started today, lasted about 5 minutes and hasn't happened since.
This problem only pertains to PSTN calls and is only affecting egress audio leaving our office, going only to the PSTN via the SIP provider.
Our Internet connection is a Comcast cable modem with 20Mbps down/5Mbps up and a static IP.
Our router is a Cisco RV42G. It's the same router we've had since before we switched to the VoIP provider. We've verified that port forwarding is configured properly.
Several weeks ago, in order to try to eliminate the Windows OS and other installed software on the server as a contributor to the problem, we created a new Hyper-V VM, gave it plenty of resources and moved 3CX to that VM running Debian which was installed using the 3CX ISO.
We are unable to recreate this problem at will. It only happens every few weeks and does not happen in any regular pattern that we can identify. There is also no pattern relating to the callers and callees, which we can identify.
If anyone has any suggestions, they would be greatly appreciated. Thank you in advance!
