I am working on deployment of a new system but both I and the managed IT partner have been struggling for two weeks to make things work with their Cisco Meraki MX67 appliance / router.
FreePBX server is cloud hosted on Vultr, phones are Grandstream GRP series. Outgoing calls work just fine, but incoming calls do not work unless the SIP and RTP port(s) are forwarded to each device. This is an issue as from what I can tell, Free PBX / Asterisk does not allow you to define different ports for each extension.
I’m hoping someone with Meraki experience with a similar setup has a suggestion…thanks in advance!
I know nothing about Meraki, but I believe it does not have any SIP ALG or similar logic that would cause trouble.
While I agree that configuring each device with unique ports is a management nightmare and should be avoided unless no other solution exists, there is nothing conflicting in Asterisk (SIP and RTP ports on the remote side can be anything and don’t have to be ‘defined’).
I suggest that you start by removing all port forwarding and any other special settings in the Meraki. In the GRPs, set Register Expiration to 1 (default is 60). On FreePBX, assuming pjsip extensions, confirm that RTP Symmetric, Rewrite Contact and Force rport are all set to Yes (the defaults) and Qualify Frequency is set to 60 (also the default). Set Max Contacts to 3 (default is 1).
Test. If you still have trouble, report what the Asterisk log shows (extensions becoming unreachable, authentication errors, etc.)
I have verified all of those / made changes, but I believe the issue is as follows:
However, if an external PBX attempts to initiate a connection to an internal phone, it will be blocked unless there is a port forwarding or NAT rule allowing that communication.
How are inbound connections handled?
The MX is a stateful firewall, so most inbound communication will only be allowed as a response to an established outbound conversation. Inbound communication can be explicitly allowed by means of port forwarding or 1:1 NAT/1:Many NAT rules, whereby a specific internal device is associated with a public port/IP.
When considering how to implement a VoIP solution, it is important to note who will be initiating what communication; if an internal phone initiates a connection to an external PBX, the stateful firewall will allow the PBX’s response back into the network. However, if an external PBX attempts to initiate a connection to an internal phone, it will be blocked unless there is a port forwarding or NAT rule allowing that communication.
For more information on port forwarding and NAT rules on the MX, please refer to the following articles:
So, I have an extension working right now forwarding the ports to that individual phone 1:1, but that doesn’t solve the problem of what to do with the other phones…
Please remove the forwarding and test with only two phones online. If that fails, report what goes wrong. If it doesn’t fail, add a few phones at a time until you see trouble.
So, we had forwarding setup for one phone. It worked. Changes forwarding rules to another phone / removed prior forwarding rule and both work / phone without forwarding rules has worked for 4 days.
Can certainly do this with the remainder but what is keeping this alive / open and how long will it last? I’m decently versed with networking but don’t have an in-depth understanding in this area.
The working call was to ext. 103. Was that also true for the failed call? If so, that’s very strange, because there is no INVITE present. However, there is a NOTIFY to 103, so the PBX must have thought it was registered, not in DND, etc.
For logs that are plain text files, please paste them at pastebin.freepbx.org and post the link here. Using a .RTF or similar just makes them harder to read and search.
At the Asterisk command prompt, type pjsip set logger on
which will show all SIP traffic in the Asterisk log, along with the regular entries. This log of a failed call will be much more useful than the abbreviated capture on the Meraki, though posting links for both would be even better.
Since the Meraki seems to randomize the source port number on each new NAT connection, check whether successive registrations from the same extension have the same source port. If not, the connection is somehow being lost.
Also, using the SIP trace from the Asterisk log, confirm that everything is going at the expected rate. You should see a pair of REGISTER requests from each phone every minute, as well as two OPTIONS requests, and one OPTION request from the PBX back to the phone.
In the failed call, there was no INVITE to 100, but 100 was sent a NOTIFY telling it that 110 was now in use, and 100 sent a 200 OK reply. So, it seems likely that Asterisk didn’t send the call to 100 because some other (perhaps corrupted) state info was present (DND, CF, busy and CW disabled, etc.) We really need the Asterisk log for the call to see why it was rejected. Also, please check the log for unexpected state changes for 100 such as loss of registration, or any errors associated with 100 such as becoming unreachable.
We need the Asterisk log for the failing call. There is no evidence (so far) of anything wrong with the network. I did see one thing unusual – ext. 101 registered twice within a few seconds. This is perfectly normal if you intentionally have two phones on this extension (an incoming call rings both and first to answer gets it). If you have two phones with the same credentials by mistake, that’s obviously something you’ll want to fix, but is likely unrelated to the trouble you are having with ext. 100.
The Asterisk database (or possibly the FreePBX database) for extension 100 seems somehow corrupted.
At a root shell prompt, type asterisk -rx 'database show DEVICE/100' asterisk -rx 'database show DEVICE/103'
I suspect that the value of dial for 100 is bad (should be PJSIP/100).
Look at the settings for extension 100 in the GUI and check the value of Dial there. If it’s wrong, try fixing it. If it’s ok, try deleting the extension and creating it again.
I went back and looked in each extension and it is indeed missing the second and third digits and this whole issue is something that I caused in using the Free PBX Bulk importer…in downloading the template, there is a field entitled “dial” which has a default it seems of “PJSIP/1” and I skipped right over it, but now recognize that this is the issue all along.
As a subsequent thought, it doesn’t make a lot of sense why the test phone I have sitting in my office works automatically / fixed this issue on it’s own, or the two others in which we opened ports for.
The managed IT provider mentioned in passing he did tweak one extension and change the driver from pjsip to chansip, which could have reset it?