VoIP One-way Audio and Voice drops
-
@JaredBusch said:
@coliver said:
Oh, that is some really good information. I was looking to use it specifically in the fashion you describe and make it my "level 3" switch in addition to the router. Which is how I currently use the Meraki.
What I do in locations where I have more than one AP but already have PoE injectors is use the ERL and a $20 gigabit switch.
eth0 - WAN - To ISP device
eth1 - LAN - To main LAN switch
eth2 - WiFi - To $20 dumb switchI plug the access points into the dumb switch and I am done. Any dumb switch will blindly pass the VLAN tagging so everything just works.
This is specifically replacing the scenario you described. If the AP gear can be plugged in to the main switch and appropriate tagging and trunking setup on that, there is no need for something like this.
This would replace the Meraki firewall and manage all WAN traffic coming to/from our LAN.
-
In my other thread, this is a similar situation that I am a looking to.
I was/am considering the EdgeRouter-8, though the 5 port would probably do me just fine (assuming no one here has had any issues with VOIP through the 5 port).
-
@Dashrender said:
In my other thread, this is a similar situation that I am a looking to.
I was/am considering the EdgeRouter-8, though the 5 port would probably do me just fine (assuming no one here has had any issues with VOIP through the 5 port).
The only caution on the ER-8 is to be aware that none of the 8 ports are hardware switched.
Because of that, I have never bought one as I never want to give up some throughput by bridging a few interfaces.
The ER PoE is a great choice when you just need a couple switch ports on the router for convenience.
Otherwise, the router is really not the place to want switched ports in the first place.
-
Replaced the firewall. Still seeing the same issues we were before.
-
@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.
-
@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.
