VoIP One-way Audio and Voice drops
-
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.
-
@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."
