I have an old FreePBX v2.11.0.43 (asterisk version 11.25.2) at one end (sys1) and a FreePBX v14.0.13.6 (asterisk version 13.20.0) in the other (sys2), using PJSIP on port 5060. Both are connected behind firewalls and have static public IP addresses (external IP and local network are properly configured on both ends).
I’ve been struggling for many hours with trying to make calls between them.
I was trying initially to create trunks without authentication, but sys1 kept rejecting the calls coming from sys2:
SIP Peer ACL: Rejecting ‘xx.xx.xx.xx’ due to a failure to pass ACL ‘(BASELINE)’
Then, I tried to add a username and secret to the trunk (on both ends), but that didn’t solve the problem either. I also disabled in sys2’s trunk pjsip advanced settings the field “Permanent Auth Rejection”, but that also didn’t solve the problem.
Can anyone suggest trunk settings for both ends to enable site to site communications?
Thank you very much in advance for your kind assistance.
So, I switched between the complicated pjsip and chan_sip and now chan_sip controls port 5060 and I recreated all the extensions and peers accordingly.
This is what sys1 (old) sees when I call from sys2:
And that’s what the verbose logs say:
This is the config of the peer on sys2 (call originator):
Not to dampen your enthusiasm for this, but an IAX2 (Inter-Asterisk) trunk might meet your needs better. It’s just a suggestion, though, so if you’ve already rejected it, never mind.
It gets you away from the differences of the two SIP drivers.
It gets you away from Chan-SIP (which can present its own unique challenges).
It sets you up for fewer comm problems since you don’t have to worry about RTP sessions and one-way audio issues later.
It allows you to set up the trunks using “the same” configuration (minus the IP address bit).
It gets you away from having to declare and undeclare NAT configuration.
The options should be considerably simpler.
Use the external IP address for both (to establish the routing) and NAT the IAX2 port so that it points from the firewall to the PBX at both ends. IAX2 traverses NAT easily and since you’re connecting to Asterisk servers, it should work out of the box.
nat=yes should be on neither, as it is deprecated.
The best solution in the case of disjoint NATted networks is to use a VPN
With proper configuration, I don’t think you should need nat=force_rport between two Asterisks. I can’t remember if media addresses are handled correctly in SDP, but if they are, you shouldn’t need nat=comedia, either.
This is a well documented error when it comes to Chan_SIP. That means the Deny/Permit settings are stopping it. Since this is Chan_SIP these can be global. You don’t have any global Deny/Permit rules set on sys1?
I actually played with these values (yes/no) on either end (all 4 combinations). They don’t seem to be related to that error I’m getting.
What’s even stranger is that I can route an inbound DID that comes from my ITSP to sys2 back to sys1, but when calling from within sys2, it rejects my extensions.
Do you have the same extension numbers on both systems?
If so, you are being caught by chan_sip’s authentication order. It sees the extension number first.
You could do this with chan_pjsip and set up the matching/authentication order to make it work. But it’s probably better to rework your numbering if you’re going to have two partner PBXes calling each other by extension numbers.
In almost all cases, the solution for this, on chan_sip, is to use type=peer and no other type. There are a lot of cookbook examples that, misleadingly, suggest you need type=friend. The result is also more secure.
I was saying there should not be any type=friend entries for the extensions, or is it a limitation of FreePBX that you are forced to use them?
About the only time you actually need type=friend is when two devices share the same IP address. Even then, I’m fairly sure that you don’t need it if they can be given fixed port numbers.
There is a common misunderstanding that you need a type=user element in order to initiate calls.
With type=peer, Asterisk will still accept registrations on the basis of the extension name, but will then authenticate and identify outgoing calls base on IP address and port number. That has the advantage that any attacker either has to break the registration, which is likely to get noticed, or has to do IP address spoofing even to get to the first stage of faking a call from an extension.
Welcome to the FreePBX forum yes, the extensions are type=friend for chan_sip. Limitation or design decision, I doubt it will change as chan_sip fades into history.
You nailed it . That was indeed the issue. Problem solved, but now I have another issue to handle:
I have calls coming into sys2 from my ITSP, where some of the DIDs should come into local extensions while others should be directed to sys1.
I configured the inbound route of the numbers that need to be redirected to be routed to the relevant trunk of sys1, but I don’t want the RTP to relay through sys2 (which is currently the case).
So, how do I route RTP through sys2 when it comes to calls from external trunks to local extensions, while trunk to trunk calls’ RTP wouldn’t be relayed through it?
yes, the extensions are 