today we tried to figure out a Problem with inbound connectivity of our FreePBX.
While this, we’ve seen, that asterisk re-registers every 75 seconds. FreePBX defaultexpiry is set to 120, and expires: 120 is submitted in the REQUEST: REGISTER.
The Provider sends back expires=90 after the Contact-Field in the Status 200 OK
The provider told me, the registration every 75 seconds is not correct.
Can you explain, why asterisk re-registers every 75 seconds?
Min-Expiry is set to 60, Max-Expiry is set to 3600, registertimeout is set to 20.
To ensure overlap so that the registration doesn’t expire, a call come in, and then the registration occur again Asterisk will register ahead of time and refresh the registration. This is a perfectly normal SIP thing to do.
What exactly is your inbound connectivity problem?
the problem is, that the Invites from the Provider are requested to the old port of the last registration, while the port changed in the registration already…
for example:
Asterisk registers at the provider with request to send answers to port 10.000
Invite to Port 10.000 (everything is working fine)
Asterisk registers at the provider with request to send answers to port 11.000
Invite to Port 10.000 (but should be 11.000 already) will never reach the system
Invite to Port 10.000 (but should be 11.000 already) will never reach the system
Invite to Port 10.000 (but should be 11.000 already) will never reach the system
New Call some seconds later: Invite to Port 11.000 (everything is working fine again)
i told the provider, that this behavier is not correct and they should fix it!
but he told me, the regirstrations every 75 seconds would be a problem.
so, but why is it 75 seconds? Does asterisk accept the 90 send from the provider and substract 15 seconds always?
yes, the system is behind a pfSense and is using NAT. So with every registration asterisk tells the provider the new port for the back-way-communication.
will asterisk accept the invites with the old port after a registration was done successfully with a new port?
AndrewZ, the ports i am talking about are not part of the pfsense guidline, as this is the backport for the opened connection! you are talking about keep-alive, you mean RTP-keep-alive? this has nothing todo with our problem, as this would just help in missing audio-transfer, but we have a sip-problem here…
Asterisk will only ever accept INVITEs directed to the fixed port number in the general section, default 5060. If that port number is changing at the remote end, you need to fix the router.
Using insecure=port, will stop Asterisk from checking the source port number on on any incoming request.
david551, you didn’t understand what i am talking about!
i do not talk about port 5060, on which asterisk is listening for registrations!
i am talking about the BACKWAY-Communication-Port, that asterisk sends when it registers itself to the provider! this is a random port number!
AndrewZ,
the only thing that could help is to set the option “Firewall Optimization Options” to Conservative - everything else is configured correctly - i’ll give that a try, thanks for the hint!
Asterisk does not use a random port number. It uses the port on which it is configured (5060 by default). pfSense is changing it to a random port on the egress, and closing the port mapping early so packets are not mapped back to Asterisk. The problem is in pfSense.
Thank you both for the explanation, jcolp and AndrewZ, it is very helpful to understand, that not asterisk, but pfsense changes the UDP-Ports (now this all makes sense to me…)
so, now the provider answered me, that he found invites, that has been send to the correct port (before the new registration), but never get answered aswell - so to configure the static port in pfsense as told in the guidlines is not the correct solution.
i know, for now, this is not the really right place for this question, as this is a pfSense-Question, but maybe it help other users in the future aswell to find a solution here…
AndrewZ, do you know what can be the cause, that packages to the correct port would not be transmitted from pfSense?
do you know if the “Conservative” option could help to solve this issue already?
Until we see something wrong in a SIP trace it’s too early to speak about ‘issue’, it’s just a high level general discussion so far.
If you want to identify the root cause - configure your router as recommended then make a dump on the WAN interface (protocol - UDP, host address - provider proxy ip). Open it in Wireshark, filter on SIP and analyze. Focus on either REGISTER or INVITE transaction, not both at once.
