I have 2 extensions out of 18 in FreePBX that will not register with the server. When the extensions were created (over a year ago) they worked fine. We use Grandstream VoIP phones and are a small office. Both phones are GPX1625. All phones and FreePBX server are on the same switch.
Work done so far.
- Reset SIP password
- Moved GPX1625 to new network drop
- Updated Firmware on GPX1625
- Updated FreePBX modules
- Factory reset GPX1625 and re-configured
- Swapped GXP1625 with a working GPX1405 (same results - no registration)
- Completed a WireShark PCAP capture from the GPX1625. Verified that syn requests are sent to the FreePBX server but there are no responses.
This last step has me questioning why this extension will not register while I have other Grandstream phone that register just fine.
Any thoughts on where to go from here?
What SIP driver are you using? What port is the sip driver bound to? To which port are your phones connecting?
Configured via web interface, commercial EPM, or open source EPM?
Possibly, the SYN requests are for fetching a config file and failing because of firewall rules, wrong port, etc. In this case, the idle screen would not show the account name (would either show Grandstream or be blank).
If provisioning was successful (account name appears on screen), then SYN packets are surprising, because on a small system SIP generally uses UDP transport. Did you intentionally configure the phone to do SIP over TCP or TLS?
Some phones will try TCP if UDP fails, but in that case you should be seeing INVITE packets also.
Apologies but I’m unsure of what you are asking. Where do I find the SIP driver? The SIP port is 5060. The phone’s SIP setting are all default, I’ve never changed them in previous setups.
Thanks for the reply
You need to go to Advanced Settings -> SIP settings. There you can check which driver is enabled and to which port it is bound
Configuration is via the web interface.
There is no FW between the phones and the FreePBX server.
Provisioning is done by uploading the .xml via TFPT when the phone is initially configured. They don’t get a config file after every reboot. Yes, the xml files does load (on the reconfigured phone) and the user’s name and extension appears in the LED window.
The phone SIP settings is configured to use UDP as default. I don’t change these defaults.
Thanks for the reply.
Ok I went in the FreePBX UI to Settings -> Advance Settings and found several sip entries under Device Settings, however none said Driver or Port.
However under Settings -> Asterisk SIP Settings, under the Chan SIP Settings tab, I was able to find the Bind port. This is set to default 5060. The Bind Address is 0.0.0.0
Are you sure that the SYN packets are being sent to the PBX IP address? (There could be requests to e.g. check Grandstream for updated firmware; if your firewall was blocking those you’d see them repeat, but they wouldn’t cause any trouble.)
Which destination port for SYN packets sent to the PBX?
Do you also see any UDP packets sent to port 5060 on the PBX? Does your config file specify a domain name or an IP address for the PBX? If a domain name, do you see the DNS lookups in your Wireshark trace, and are they successful? If an IP address, is it correct? Can you ping the phone from a shell prompt on the PBX?
I wanted to verify that the OS firewall was not the issue. It wasn’t. So I checked the FreePBX firewall. The Responsive Firewall was disabled. This rejects incoming connections. Enabling this and allowing SIP Protocol caused both phones that previously wouldn’t register to complete the process and both are back in production.
Thanks for all replies… It helps to process these with like minded folks!
If that’s actually the case, you probably needed to add the networks your phones were on to the “internal” network list in the Integrated Firewall.
The OS firewall and the FreePBX firewall are the same thing,
iptables. When you enabled responsive, it allowed a limited number of registration attempts from hosts that were otherwise denied access, which probably means the FreePBX firewall is misconfigured.
Spend some time reading the firewall wiki:
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.