VoIP One-way Audio and Voice drops
-
@JaredBusch said:
@coliver said:
Replaced the firewall. Still seeing the same issues we were before.
This needs qualified.
Replaced how? Swapped a Meraki unit? that woudl imply same programming thus potentially the same issue. Completely different hardware? Then it comes to verifying the new configuration.
Completely new firewall - ERPoE-5. I'm running into the same issues I was before with latency and packet loss, symptoms are exactly the same.
-
At this point you are really pointing to the ISP.
Let's think here.
You swapped router.
You swapped SIP trunk provider.
You swapped from PBX to direct on a phone.Potential solutions to try:
Have your ruled out the local switching hardware.
Have you ruled out needing QoS on the LAN? Obviously this is extremely rare, but you have already tested every normal source of an issue.
Can you connect from a secondary ISP at all on site? -
@JaredBusch said:
At this point you are really pointing to the ISP.
Let's think here.
You swapped router.
You swapped SIP trunk provider.
You swapped from PBX to direct on a phone.Potential solutions to try:
Have your ruled out the local switching hardware.Wired the PBX (which is a VM) directly to the router, via a different port on the server and a new Hyper-V virtual switch dedicated to just the PBX virtual machine. Still encountered the same issues. This was prior to the recent router switch. I'm considering bringing up a second host to test it out on.
Have you ruled out needing QoS on the LAN? Obviously this is extremely rare, but you have already tested every normal source of an issue.
It seems to only affect calls to and from the outside world. Would local QoS provide
Can you connect from a secondary ISP at all on site?
No, unfortunately we are very rural which makes a different ISP impossible, we only have one option for a SIP trunk provider for our numbers... which is the ISP.
-
QoS is not very likely as the issue is not quality, but dropping.
-
Are you sure that STUN is configured?
-
@scottalanmiller said:
Are you sure that STUN is configured?
I am fairly certain STUN isn't configured, nor do I know how to go about doing that. With STUN don't both end points (our SIP trunk and PBX) have to be configured with the same STUN server?
-
@scottalanmiller said:
Are you sure that STUN is configured?
Why do you bring up STUN again? this has nothing to do with STUN. The phones are internal to the PBX.
-
@coliver said:
@scottalanmiller said:
Are you sure that STUN is configured?
I am fairly certain STUN isn't configured, nor do I know how to go about doing that. With STUN don't both end points (our SIP trunk and PBX) have to be configured with the same STUN server?
Wait, when STUN is a necessity, why are we going through all this troubleshooting if the basics aren't done yet. I said earlier that if STUN wasn't set up this would happen.
-
@JaredBusch said:
@scottalanmiller said:
Are you sure that STUN is configured?
Why do you bring up STUN again? this has nothing to do with STUN. The phones are internal to the PBX.
The PBX can still have issues if behind NAT.
-
Because the PBX itself is just a phone, really.
-
Am I losing my mind? I've not been to sleep in two days, but STUN should be needed if the PBX is behind NAT and/or all ports are not explicitly forwarded to it.
-
All ports means all of those used by the SIP and RTP services with the SIP Trunk vendor.
-
@scottalanmiller said:
The PBX can still have issues if behind NAT.
All PBX systems (self hosted) should be behind NAT (and a firewall IMO).
You forward the ports at the point of the NAT and restrict based on the source IP to the SIP trunk provider. -
@JaredBusch said:
@scottalanmiller said:
The PBX can still have issues if behind NAT.
All PBX systems (self hosted) should be behind NAT (and a firewall IMO).
You forward the ports at the point of the NAT and restrict based on the source IP to the SIP trunk provider.Sure, I agree. But if the ports are not forwarded, you would need STUN to help the NAT not get confused or you would expect one way audio from time to time.
-
@scottalanmiller said:
Am I losing my mind? I've not been to sleep in two days, but STUN should be needed if the PBX is behind NAT and/or all ports are not explicitly forwarded to it.
Show me the scenario where you have STUN setup on the SIP trunk
In 10 years I have seen that exactly zero times.
-
@JaredBusch said:
@scottalanmiller said:
Am I losing my mind? I've not been to sleep in two days, but STUN should be needed if the PBX is behind NAT and/or all ports are not explicitly forwarded to it.
Show me the scenario where you have STUN setup on the PBX trunk
In 10 years I have seen that exactly zero times.
I always have ports forwarded so it is not necessary.
-
Are the ports being forwarded in this case? For both SIP and for RTP? @coliver
-
@scottalanmiller said:
I always have ports forwarded so it is not necessary.
Thus, my point. So stop bringing up a technology that is not used in this scenario.
-
@scottalanmiller said:
Am I losing my mind? I've not been to sleep in two days, but STUN should be needed if the PBX is behind NAT and/or all ports are not explicitly forwarded to it.
Every where I've looked STUN is only necessary if you have more then one SIP device communication out to the internet at a time... Since we have only one SIP device (the PBX) going out to the internet, and everything else is talking to that server, then would STUN be unnecessary in that case?
Unless I misunderstood STUN, which is entirely possible, and it really is supposed to be for SIP connections. Regardless if I was to go against best practices and forward both the SIP port and the RTP ports to the SIP server from the router, which I've tried, wouldn't that render STUN unnecessary?
-
@coliver said:
Every where I've looked STUN is only necessary if you have more then one SIP device communication out to the internet at a time... Since we have only one SIP device (the PBX) going out to the internet, and everything else is talking to that server, then would STUN be unnecessary in that case?
That's only because if you only have one you can port forward to get around the issue. STUN is often unneeded when you have only one, but that isn't guaranteed.
