In FreePBX version 15.0.17.11 as far as I can tell Sip trunks (username & password) will no longer connect/register by either pjsip or chansip if they have the same bind port as the sip trunk. )
For example sipgate.co.uk trunks require port 5060, if I try to set up a trunk using pjsip (on bind port 5060) the provider does not respond to registration requests. If I change the bind port for pjsip to anything other than 5060 it all works fine.
The same happens if I use legacy chansip (the bind port cant be the same as the sip trunk port). The wireshark trace does nor see any response from the registration request. Again chansip trunks work fine if I change the bind port to anything other than 5060 (used by my trunks)
This was never a problem in the past (version 13.0.197.28) in fact many tutorials say its best to use 5060 at both ends.
Because sipgate.co.uk required port 5060 for sip trunks moving to the new version of FreePBX would be extremely problematic. Please can anyone help ?
It was never possible for chansip and pjsip to have the same bind port if they are both using the same protocol (udp e.g.) and bind to the same IP address.
Either one of the three has to be different.
If you use tcp for chansip and udp for pjsip, they can bind to the same port.
It’s recommended to move everything to pjsip and move away from the deprecated chansip.
Sorry I did not explain myself very well. I “always” keep chansip and pjsip on different bind ports.
The problem I am having is that I cant have my sip trunks (that are always on port 5060) connected via pjsip or chansip if either of these have a bind port of 5060 (never at the same time, I always swap them around and restart asterisk).
This was never a problem on my old FreePBX (v 13.0.197.28) systems, in fact I still have my old FreePBX running on the same network (through the same firewall) and that is happy to use the same port 5060 for the sip trunk and the bind port.
However as you say I am trying to migrate to newer versions and use pjsip exclusively
Any help would be appreciated.
The problem is a port conflict between PBXes. When the old PBX registers to sipgate, the firewall passes the source port number (5060) to the provider.
When the new PBX registers and is binding to its port 5060, the firewall sees the port in use and substitutes another value e.g. 1024, so sipgate sees the REGISTER coming from [your.public.ip]:1024. But the PBX doesn’t know this and asks (in the Contact header) that calls be sent to [your.public.ip]:5060. The result (depending on your firewall) is that incoming calls are either discarded or sent to the wrong PBX (which will likely reject them).
If you need to run more than one PBX on the same public IP address, you must assign unique bind ports among all SIP drivers on all systems.
Fantastic, that makes total sense. You are a life saver.
Just out of interest is this a problem you have seen before?
This has been driving me mad for over a week and your explanation fits the bill perfectly. I was just setting up a new server so I never though about the old FreePBX being the cause of the problem
It would be worth other people being aware “If you need to run more than one PBX on the same public IP address, you must assign unique bind ports among all SIP drivers on all systems.” I have not seen that mentioned anywhere.
It may be firewall related but in my opinion it is still worth knowing, especially if you are just setting up a temporary replacement server as part of a FreePBX upgrade.
The cause would have been more obviously firewall related if I had “intended” to have multiple permanent FreePBX systems on one private network.
As a sysadmin I have a reasonable network/firewall background however it still caught me out, so many thanks again to Stewart1
As an old mentor of mine said many years ago, things are always obvious looking back once you have worked out the cause of a problem
