VoIP One-way Audio and Voice drops
-
@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.
-
@scottalanmiller said:
Are the ports being forwarded in this case? For both SIP and for RTP? @coliver
Not usually although I was for testing purposes. Still encountered this issue.
-
@coliver said:
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?
Yes, that would be fine. So all SIP and RTP are going only to the one server? And how is that against best practices? It's the only best practice that I know of in this case.
And yes, STUN is for SIP + RTP connections.
-
@scottalanmiller said:
@coliver said:
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?
Yes, that would be fine. So all SIP and RTP are going only to the one server? And how is that against best practices? It's the only best practice that I know of in this case.
And yes, STUN is for SIP + RTP connections.
I've read you shouldn't forward those ports unless absolutely necessary. It was working fine without them initially, since December.
-
@coliver said:
I've read you shouldn't forward those ports unless absolutely necessary. It was working fine without them initially.
What's the logic on not forwarding them? If you restrict them to the IP(s) of the SIP Trunk provider there is no additional security risk but it always adds stability.
Doing it "only when needed" means you've knowingly left a fragility and are just waiting for things to fail before fixing it. That's not a best practice style guideline
Like saying "don't steer the car, until you start hitting small objects on the side of the road, THEN it is a good idea to steer."
-
@scottalanmiller said:
@coliver said:
I've read you shouldn't forward those ports unless absolutely necessary. It was working fine without them initially.
What's the logic on not forwarding them? If you restrict them to the IP(s) of the SIP Trunk provider there is no additional security risk but it always adds stability.
Doing it "only when needed" means you've knowingly left a fragility and are just waiting for things to fail before fixing it. That's not a best practice style guideline
Like saying "don't steer the car, until you start hitting small objects on the side of the road, THEN it is a good idea to steer."
That's fine. Either way I was still having that issue with the ports forwarded.
-
@coliver said:
That's fine. Either way I was still having that issue with the ports forwarded.
That's extremely odd. Have you tried connecting a PBX to the provider from another location? This really does sound like it is down to either the provider themselves or the ISP having an issue.
-
@coliver said:
@scottalanmiller said:
@coliver said:
I've read you shouldn't forward those ports unless absolutely necessary. It was working fine without them initially.
What's the logic on not forwarding them? If you restrict them to the IP(s) of the SIP Trunk provider there is no additional security risk but it always adds stability.
Doing it "only when needed" means you've knowingly left a fragility and are just waiting for things to fail before fixing it. That's not a best practice style guideline
Like saying "don't steer the car, until you start hitting small objects on the side of the road, THEN it is a good idea to steer."
That's fine. Either way I was still having that issue with the ports forwarded.
Now the question is, are all the needed ports fordwarded, and working as desired? I have found when setting up FTP I often forget to forward the data ports needed to work with FTP.
-
@coliver it is relatively easy to set STUN up on a phone at least and test that part.
On a side note, what is your PBX running in? I once tried running in Hyper-V and ran into a slew of problems with load and the NIC drivers.
-
His ISP is the SIP trunk provider for the main SIP service.
He setup a SIP trunk to another provider and experienced the same issues.
With all of the testing done to date, the problem is the ISP based on what we know so far.
-
@FiyaFly said:
On a side note, what is your PBX running in? I once tried running in Hyper-V and ran into a slew of problems with load and the NIC drivers.
Related: Hyper-V has NIC issues if you do not disabled VMQ on the VM unless the hardware supports it correctly. I have a client with Hyper-V 2012 R2 and a ton of NIC issues were going on until I disabled VMQ.
-
@FiyaFly said:
@coliver it is relatively easy to set STUN up on a phone at least and test that part.
On a side note, what is your PBX running in? I once tried running in Hyper-V and ran into a slew of problems with load and the NIC drivers.
It is running on Hyper-V. Up until this point it hasn't been an issue.
-
@coliver said:
It is running on Hyper-V. Up until this point it hasn't been an issue.
Unlikely having VM related issues, but they are worth mentioning. The Hyper-V server was not updated lately was it?
-
@JaredBusch said:
@coliver said:
It is running on Hyper-V. Up until this point it hasn't been an issue.
Unlikely having VM related issues, but they are worth mentioning. The Hyper-V server was not updated lately was it?
I don't think so but I'm going to look into it now, I've looked before but didn't notice anything. I've noticed something odd, the PBX server has some serious packet loss to the SIP trunk whereas my desktop does not... they are both on the same switch. This still doesn't explain the issues I was having with the other SIP trunk but it may have something to do with the current issues.
-
@coliver have you checked to see if the NICs in your Hyper-V server actually have VMQ enabled or not?
In Powershell (assuming Server 2012 / R2) try
get-netadapter-vmq
-
@JaredBusch said:
His ISP is the SIP trunk provider for the main SIP service.
He setup a SIP trunk to another provider and experienced the same issues.
With all of the testing done to date, the problem is the ISP based on what we know so far.
Gotcha. Yes, that makes sense. I missed that the ISP and SIP trunk was the same provider.
-
I've seen a lot of issues from those "ISP as SIP trunk providers." Those seem to always be the ones that are willing to have things fail because they have good lock-in.
If you can test the third party SIP provider from home, for example, with the same setup (a bit of work) that would prove a lot.
-
@dafyre said:
@coliver have you checked to see if the NICs in your Hyper-V server actually have VMQ enabled or not?
In Powershell (assuming Server 2012 / R2) try
get-netadapter-vmq
The Hyper-V team was the original network adapter that this was on. Since starting with these issues I have moved that over to a dedicated port Ethernet 2.
-
Have you considered disabling VMQ ?
