"reset all states" box does not seem to work as advertised.
-
What do your incoming WAN rules at the sites look like? For the VOIP in particular??
-
@chpalmer said in VoIP SIP Trunks randomly disconnecting:
What do your incoming WAN rules at the sites look like? For the VOIP in particular??
What I attached in the OP is the inbound NAT rule and has an associated WAN rule
-
Hard to tell without actually seeing your aliases. But all my VOIP locations work without a hitch. I do not use local PBX but only from a cloud provider.
It appears then that your behind double NAT at the Uverse locations..??
SIP was not originally designed to be behind any NAT. It was only added (hacked in) later as the idea of residential users caught on. Double NAT can be really troublesome in a lot of cases. Im not sure Id even try it behind anything with the Uverse router in the way personally. Id be wanting to bypass it. But thats me.
So question would be "Has it ever worked without issues"? Have you contacted voip.ms to see if they are having issues? They seem to be a smaller one man type operation from what I see over at DSLR. Im understanding that the connection between the PBX and VOIP.ms servers is the issue..correct?
-
Hard to tell without actually seeing your aliases. But all my VOIP locations work without a hitch. I do not use local PBX but only from a cloud provider.
It appears then that your behind double NAT at the Uverse locations..??
No there is a setting in the Uverse modem to pass the exteral IP addresst to the pfSense router disabling any routing and firewalls on the Uverse modem.SIP was not originally designed to be behind any NAT. It was only added (hacked in) later as the idea of residential users caught on. Double NAT can be really troublesome in a lot of cases. Im not sure Id even try it behind anything with the Uverse router in the way personally. Id be wanting to bypass it. But thats me.
So question would be "Has it ever worked without issues"?
Yes at some locationsHave you contacted voip.ms to see if they are having issues?
Started there had them do some live loggin but there we not getting any register attempts when led me back to pfSense
They seem to be a smaller one man type operation from what I see over at DSLR. Im understanding that the connection between the PBX and VOIP.ms servers is the issue..correct?
I wouldn't say they are a small one man provider. They have servers all over the US. This isnt a issue with their service.The main issue is the bad route states being set by what i assume is a service disruption with the ISP which then sets the route to a private IP address:
VOIPVLAN udp 10.2.12.2:5060 -> 208.xxx.xx.xx:5060 NO_TRAFFIC:SINGLE 220.064 K / 0 132.12 MiB / 0 B WAN udp 192.168.100.11:5060 (10.2.12.2:5060) -> 208.xxx.xx.xx:5060 SINGLE:NO_TRAFFIC 220.064 K / 0 132.12 MiB / 0 BDeleting these states the PBX will reconnect immediately
VOIPVLAN udp 10.2.12.2:5060 -> 208.xxx.xx.xx:5060 MULTIPLE:MULTIPLE 90 / 85 55 KiB / 48 KiB WAN udp 98.xxx.xx.xxx:5060 (10.2.12.2:5060) -> 208.xxx.xx.xx:5060 MULTIPLE:MULTIPLE 87 / 85 54 KiB / 48 KiBSo the state is remaining despite the public address being set in pfsense. IF pf sense temporally get a private ip address due to a brief service outage then goes back to the public ip this setting should clear all states but is not.
-
Yep- I get that the cable connection might assume an address from the modem in the cable modem range. But not the Uverse modems. I would assume that your pfsense in those instances always has a WAN address in the 192.168.x.x range. Thus being behind double NAT. If that is true then the states would always show that address. Please clarify that.
The cable modem problem is probably a different horse. If the state tries to connect and does not clear then that is an issue that should be duplicatable anywhere else by someone with a similar setup.
If I pull the cable off my modem and let it sit it would actually take a bit for it to start handing out addresses on 192.168.100.x. In fact the only time it seems that it ever does is if I re-boot it and not the router. I would assume that any cable modem would be similar but could be wrong as Ive not tested them all. The issue as to why your modem decides its a good time to do that should be looked into.
You should change the title of the thread here to detail that the "reset all states" box does not seem to work as advertised. Many will be turned off by VOIP in the title if they do not understand it. Actually by what that box says in the description it should not be necessary in your case.
Looking at System/Routing.. how are your gateway functions set up? Specifically "Gateway Action" ??
-
Uverse modem would actually be the "gateway" that probably does not drop when service suffers. Setting a different monitoring address (such as the next hop off site) would help to trigger "gateway" events such as dropping states. For the gateway event to happen the pings have to change.
-
This post is deleted! -
Yep- I get that the cable connection might assume an address from the modem in the cable modem range. But not the Uverse modems. I would assume that your pfsense in those instances always has a WAN address in the 192.168.x.x range. Thus being behind double NAT. If that is true then the states would always show that address. Please clarify that.
Ok to clarify and show examples, the all The AT&T uverse locations have a public IP address inside pfsense not a private.
In the AT&T IP Passthough is enabled for the MAC address of the pfSense router.
https://forums.att.com/conversations/att-internet-equipment/strict-nat-bridge-mode-what-is-ip-passthrough-can-i-enable-on-my-arris-bgw210-or-like-router/5defbfffbad5f2f606ad5ed2The IP address of the AT&T modem is 192.168.1.254, so I believe when a brief loss in service occurs an invalid state is set for a private IP address in that subnet on the pfSense WAN. The 208.xxx.xx.xx:5060 is my SIP trunk provider. Here is an example of a bad state:
WAN udp 192.168.1.198:5060 (10.2.14.2:5060) -> 208.xxx.xx.xx:5060 SINGLE:NO_TRAFFIC 223.387 K / 0 131.94 MiB / 0 KiBAfter I delete that state the PBX connects immediately. Here is an example of what the state should be:
WAN udp 108.xx.xxx.xx:5060 (10.2.14.2:5060) -> 208.xx.xx.xx:5060 MULTIPLE:MULTIPLE 16.047 K / 15.578 K 9.48 MiB / 8.59 MiBWould enabling this option help clear that state automatically?
I have this option enabled already:
The cable modem problem is probably a different horse. If the state tries to connect and does not clear then that is an issue that should be duplicatable anywhere else by someone with a similar setup.
If I pull the cable off my modem and let it sit it would actually take a bit for it to start handing out addresses on 192.168.100.x. In fact the only time it seems that it ever does is if I re-boot it and not the router. I would assume that any cable modem would be similar but could be wrong as Ive not tested them all. The issue as to why your modem decides its a good time to do that should be looked into.
Lets focus on the AT&T DSL uverse service. The cable service rarely has issues but I have had the same issue.You should change the title of the thread here to detail that the "reset all states" box does not seem to work as advertised. Many will be turned off by VOIP in the title if they do not understand it. Actually by what that box says in the description it should not be necessary in your case.
Looking at System/Routing.. how are your gateway functions set up? Specifically "Gateway Action" ??
-
Under Gateway Actions-
Ive asked for a bit of information from a friend back east from me with Uverse how his setup works.. He has several statics however so Im not sure if things work the same.
-
I need to bump this issue because I am still experiencing issues with all the suggestions given.
-
@compsmith said in "reset all states" box does not seem to work as advertised.:
I need to bump this issue because I am still experiencing issues with all the suggestions given.
Does anyone else have any suggestions how i prevent this from happening as this is still a issue
