I’m trying to make my Freepbx work with my provider. We are in the test phase.
The trunk is working, i can dial in and out without issue so far.
My problem is that my Freepbx register to the trunk every 20 seconds.
My provider is adamant that the problem is with freepbx and not with them.
My provider told me to register every 1800 seconds / 30min to remove chance of getting blacklisted.
My expiration is set at 3600, so from what i read that should do it.
so i ran sngreb and here is the register and OK response.
i do send 3600 while my provider send back 30.
Is the expiration value the one that set the actual timeout for the registration of the trunk or just the timeout before i get a 200 OK from the provider ?
If expiration is not the setting I need, where can I force a different value before freepbx try to register again with that trunk.
I get by in Freepbx, not an expert. Let me know if i need to provide any more informations.
The provider is ultimately in control. You can request 3600 seconds, but that doesn’t mean the remote side will accept it - and in this case they decided on 30 seconds instead.
It is the actual lifetime of the registration, in both places, in the response. The expectation is that you actually refresh before the expiry, to allow for re-transmissions, so 20 seconds is a reasonable value given what the provider’s system is saying.
So my provider is refusing to change his expiration value, saying that his other customer does not have that issue. Note : I’m his first Freepbx customer.
I’ll try to get him to change his value again, otherwise it seems like i’m at a dead end.
I’ve reread this several times and I can’t find an actual problem statement from you other then “My problem is that my Freepbx register to the trunk every 20 seconds.”
That’s not a problem, that’s by design. So what’s the actual problem?
Maybe not. The 200 OK response to register shows rport=65476 (your router/firewall rewrote the source port number from 5060 to 65476), so Equi-tel sees that the PBX is behind a NAT and may have chosen a short expiry to keep the connection alive.
However, the Contact header shows port 12143, so I suspect that a SIP ALG may also be active, and it might have rewritten the Expiration header to 30 before sending it to Equi-tel.
In your firewall, try turning off any SIP ALG or passthrough. Also, if it has a ‘disable source port rewriting’, ‘consistent NAT’ or similar setting, turn that on.
If you still have trouble, please post router/firewall make/model and any VoIP-related settings. If it doesn’t have your public IP on its WAN interface, please explain (ISP modem is configured as router, ISP does NAT, etc.)
Since your IP address from DERYtelecom is static, if Equi-tel offers IP authentication, you could use that and avoid registration altogether.
My setup.
Fortigate 60E 7.2.2
Fortigate has the public IP.
Everything is pretty much vanilla. The rules that allow freepbx access to the internet has nat enabled.
No security profile or anything in the rule.
I found how I can disable the SIP ALG for my Fortigate but it seems I need to reboot the device to finalise the configuration. I Will let you know tomorrow if that was a success.
Here is the guide i found : Disabling SIP ALG on a Fortigate Firewall
I know there is a way to turn off sip alg without rebooting. Basically you can tear down existing sessions for the changes to be applied. Don’t have the guide handy, although rebooting may be easiest way.
Watch out for Sip Helper as well as those boxes has both.
The OP is set to expire every 3600 seconds, except the provider wants 1800 seconds. Registrar services have a minimum and maximum expire times they expect. Anything outside of that can be readjusted. So OP sends REGISTER with an expire value double that the provider wants which appears to be making it exceed the maximum expire time they allow. It is then being readjusted to 30 seconds (generally the minimum default in these systems) and because of that a new REGISTER happens every 20 seconds per standards. Now the provider is saying this can cause a blacklisting.
Solution: Change the Expire time on the trunk to what the provider has said is their requested expire time. It will then not exceed maximum limits and be readjusted to the minimum expire time.
And yes, the provider shouldn’t have the minimum expire time set to 30 seconds if that is too short for them. I’m going to guess the other customer just followed the recommended settings given to them by the provider.
You are right, i did put 3600 instead of 1800. It has now been corrected to 1800.
i made the changes in my firewall (Disabling SIP ALG & activated Preserve Source Port into the Fortigate Policy of Freepbx.)
So far it still register every 20 seconds, but it no longer Register > Unauthorized > Register > OK.
Now it does Register > OK.
Those configuration did change the outgoing port and made it stay 5060 without rewrite.
The “VIA” line is no longer present in “200 OK” message like before.
So I guess the next step would be to find a way to confirm if Fortigate rewrite the header or not. I’ll try to look into that tomorrow.
As long as the provider keeps sending back a 30 second Expire this problem is going to keep happening. You need to find out why they keep ignoring the Expire time being sent to them.
If you look at an hour’s worth of registrations, you will almost certainly see at least one 401 UnAuthorized.
Verifying credentials is a relatively expensive operation for the provider, as it requires a database lookup, which is why they don’t want you to register too often. However, frequent registration is a good way to keep customers’ NAT association open. So, it’s common for them to set up their SBCs or other load-balancing devices, so that when you register successfully, they send a very short Expires, even though the real server recognizes the registration as valid for e.g. 1800 seconds. Then, each time the customer re-registers, the SBC sends a 200 OK without communicating with the server at all. The SBC keeps track of the time and when the real registration is about to expire, it passes it to the server which responds with a 401 again.
Now I see two likely possibilities: One is that the provider only does this when they believe it’s necessary. For example, their may be a NAT setting for you on their portal, or set by your representative. Since Asterisk can correctly simulate being on a public IP, it should be possible to turn this off and avoid frequent registrations. The other is that they do this for everyone but the tech you are working with is unaware. In that case, leaving things alone is probably best, because you will regain registration quickly after e.g. a brief network outage.
Of course, if they support IP authentication, avoiding registration altogether is best; if the network is working when a call comes in you’re sure to get it.
No, not really. There is an expense but not that much.
The issue is simple, the provider keeps sending back Expire times of 30 seconds. The provider is complaining to the user they are registering every 20 seconds and they want them to stop doing that. Since the user has done different expire times and no matter what it is set to the provider sets it to 30 seconds.
None of that has to do with NAT or any of these other theories because the provider is the one that is causing this issue. They can say it’s a FreePBX issue but they would be wrong, they are using Broadsoft and it works just fine with Asterisk. I’ve used that platform before and Asterisk based systems worked just fine on it. Either this provider spent a lot of money on Broadsoft and has no idea how to use it (be a waste of money) or they are reselling someone elses services and using their infrastructure and still doesn’t understand Broadsoft.
It’s possible that the are not complaining about the number of registrations, but rather the number of different registrations. However, if they are, their inability to describe the real problem still suggests they are black box operators.
Why would the port number matter when doing registrations? That makes no sense what so ever. All this talk about NAT and other network stuff doesn’t change the fact that each final 200 OK to the REGISTER request, being sent by the provider, has the Expire value set to 30 seconds. That is something being done on the provider side. That is what is causing the system to re-register every 20 seconds.
Again, the provider needs to be asked why they keep sending back 200 OK’s with an Expire: 30
