Hello All,
I am registering (chan_sip) some Gigaset and some Grandstream phones.
I am having a very hard time with the Grandstream, they just don’t want to.
If I ping the PBX from the phone, it says no answer, any other host on the LAN will answer.
I managed to register just one, and I notice that the port keeps changing, and is not 5060:
[2020-04-30 09:47:06] VERBOSE[2940] chan_sip.c: Registered SIP ‘12’ at 192.168.1.85:31307
[2020-04-30 12:04:02] VERBOSE[2692] chan_sip.c: Registered SIP ‘12’ at 192.168.1.85:16906
[2020-04-30 14:09:08] VERBOSE[2692] chan_sip.c: Registered SIP ‘12’ at 192.168.1.85:15636
[2020-04-30 14:21:20] VERBOSE[2692] chan_sip.c: Registered SIP ‘12’ at 192.168.1.85:23768
[2020-04-30 14:27:08] VERBOSE[2692] chan_sip.c: Registered SIP ‘12’ at 192.168.1.85:36039
[2020-04-30 14:36:29] VERBOSE[2828] chan_sip.c: Registered SIP ‘12’ at 192.168.1.85:24108
[2020-04-30 15:38:45] VERBOSE[2828] chan_sip.c: Registered SIP ‘12’ at 192.168.1.85:13188
[2020-04-30 15:39:52] VERBOSE[2828] chan_sip.c: Registered SIP ‘12’ at 192.168.1.85:13188
[2020-04-30 16:09:56] VERBOSE[2828] chan_sip.c: Registered SIP ‘12’ at 192.168.1.85:17331
[2020-04-30 16:39:05] VERBOSE[2828] chan_sip.c: Registered SIP ‘31’ at 192.168.1.77:46722
[2020-04-30 16:42:36] VERBOSE[2828] chan_sip.c: Registered SIP ‘15’ at 192.168.1.23:5060
[2020-04-30 17:10:14] VERBOSE[2828] chan_sip.c: Registered SIP ‘35’ at 192.168.1.48:5060
[2020-04-30 17:32:16] VERBOSE[2828] chan_sip.c: Registered SIP ‘18’ at 192.168.1.26:5060
The last three are Gigasets, they show port 5060, and they register in a click.
In the Grandstream account setup, SIP/Basic/Settings, Local Sip Port is 5060.
Many Grandstream devices have a ‘User Random Port’ option or similar, which you should turn off. Search all the config pages related to SIP for ‘random’.
Otherwise, a NAT or VPN between the device and PBX, if any, could be modifying the source port number.
Probably being blocked by FreePBX firewall. If not, some other element in your network? If PBX is on a VM and not bridged networking, that’s another way it could be blocked. Or, maybe an IP address conflict?
The firewall is not (yet) enabled, the FreePBX is sitting inside a fenced LAN.
Why would the Gigaset work, if it were for a PBX setup?
The FreePBX is on a VM, bridged, so all IP are on same level.
I’ve noticed something similar with a Grandstream BT100 (on the same network as the PBX).
Put Wireshark to work and noticed that the BT100 (on 192.168.7.91) is responding to some requests from the PBX (on 192.168.7.68) with a Status 200 (OK) to the wrong IP address (188.195.237.73). Hope the snippet attached works. As a result, the PBX marks the BT100 as non-reachable.
I aim to upgrade the BT100 firmware to the latest in the hope it might fix the problem but, as it was end of life some time ago, I’m not very hopeful this will solve the problem.
Bizarre. That seems to be a cable modem in Germany. Do you recognize the address as somehow related to your system? Also, can you see that address anywhere in the Grandstream’s config? What’s the history of this device, e.g. was it once used with or perhaps even locked to another provider?
I assume that you were capturing traffic at the Grandstream (if on the PBX, the problematic packet shouldn’t have been seen by tcpdump, unless you had set up port mirror/monitor on the switch).
@stewart1 - I think I have the answer, as when poking around to fix a different problem (NTP traffic not getting through - sorry, haven’t mastered referencing other tickets), I found 188.195.237.73 in the NAT address on the FreePBX config. Replaced this with my own IP address and the BT100 is behaving.
So this looks to be a default on the FreePBX version issued for the Raspberry Pi. But still odd, as you say.
BTW - I had wireshark running on the RPi, not port mirroring. Not sure if that helps explain things better
ok, I found why some phones wouldn’t talk to to FreePBX… The evil PBX had put them in jail…
They were configured for an older FreePBX, same IP, so as soon as it was up they started to try to connect, with wrong credentials.
The steps to fix were:
