2 freepbx 15 machines, connected to the same router.
1st: 10.64.133.18
2nd: 192.168.86.250
Created Sip trunks on both in order to be able to dial beetween them.
Machines can communicate its other just fine (no firewalls etc)
Sip trunk register on both just fine. Having Allow Anonymous Inbound SIP Calls = No, I get “The number you have dialed is not in service…” and in the logs I have on the 2nd
WARNING[2243][C-000007b3]: Ext. s:7 @ from-sip-external: “Rejecting unknown SIP connection from 10.64.133.18:5060”
Please explain your setup in more detail, including screenshots or descriptions of your trunk settings.
This seems strange. Did you create two pairs of trunks, one for A->B and one for B->A? If so, why? If not (and you’re using registration), only one side registers and the other side receives registration. However, I would recommend a static configuration to avoid the possibility of ‘lost’ registration. Each side can still use qualify to confirm that the other side is responding and take appropriate action (failover or notification) if not.
Are these ‘old’ systems? On recent versions, pjsip listens on port 5060 and chan_sip on 5160. So without specifying a port number in your chan_sip trunk, it would go to the pjsip driver on the other PBX, which of course wouldn’t recognize it. Also, if this is a relatively new system, why are you using chan_sip at all?
First machine (192.168.86.250) has pjsip on 5060 and sip on 5160.
Second machine (10.64.133.18) has sip on 5060
The second machine has been upgraded from freepbx 13, so this is why it has sip on 5060 and not pjsip
So I need to add
port=5160 on the second machine peer details?
Edit:
added the port=5160 to the second machine peer, added insecure=port,invite and changed “from-internal” on both machines and now it works just fine…
Actually I don’t think is the “from-internal” change which makes the difference rather the insecure part.
Also about the port…The 1st machine could have problem with that but the second should have the same problem. I mean if it eas port missing Ishould at least make calls from the second to the first…
The insecure parameter has no effect on the originating trunk. It tells the receiving trunk to accept the incoming INVITE without challenging it. However, if username and secret are identical at both ends, a challenge should be successful and insecure should make no difference.
In any case, since the connection is local and firewalled off from the internet, setting insecure is not a problem, either.