Connecting 2 FreePBX systems


Hi Aaron,

Thank you for your prompt response to my query.

chansip is what I have on sys1 (the call receiver)

I’m looking at the INVITE that I receive from sys2:

From: “David” sip:2222@;tag=be91e69f-446a-4727-916d-b2ca628fc5fb
To: sip:111111@yy.yy.yy.yy
Contact: sip:asterisk@

It doesn’t feel right. I believe that these fields should contain sys2’s public IP address and not the local IP

As for your other question, I had the peer defined as friend.




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):

And that’s the one of the peer on sys1:

The incoming sections of both peers are empty

(Dave Burgess) #5

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.


Hi Dave,

I haven’t rejected this idea, as I never considered it in the 1st place.

To be honest, in the almost 20 years that I use asterisk, I never tried it.

I’ll try to read about it and see if that can indeed serve my purpose.


(Aaron) #7

Why not nat = yes on both?

(David55) #8

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.

(Tom Ray) #9

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?


None that I saw


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.

(Aaron) #12

If you can route dids back try changing peer to friend.


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.

(David55) #14

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.


Yes, but in this case, it still won’t help. The type=friend entries for the extensions will be matched first by their from headers (usernames).

(David55) #16

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 :slight_smile: 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 :clap:t3::clap:t3:. 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?



(Avayax) #19

Type friend is the default setting in Freepbx for an endpoint, but it can be changed to peer.


Well, what do I know? It sure can! My mistake.


If canreinvite is set for both ITSP and tie trunks (and sys2 isn’t doing anything to preclude reinvite such as recording or listening for DTMF), audio should be automatically redirected when the call is answered. And with canreinvite off for sys2 extensions, those calls will have audio relayed normally.

However, most trunking providers allow you to configure inbound routing on a per DID basis. Check your provider portal for this option.

(system) closed #22

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.