I have a FPBX installation on a dual NIC server. I need to bind one NIC with chan_sip, and the other one with PJSIP stack, both on the 5060 port.
After first configuration, it works well (or it seems so), but when I enter SIP Settings from web interface, “something” changes my configuration and moves chan_sip to 5062 port. Obviously, this does not affect the running asterisk, which binds the right ports on the right NICs at startup, but is dangerous in case of a configuration change and restart.
You think is something wanted, or just a bug of configuration interface which does not pay attention at the dual NIC setup?
I’m running latest version 14 (220.127.116.11) of FPBX, and i think is something easily reproduceable in every enviroment with the same release.
Thanks in advance to anyone that will spend a bit of time reading this!
thanks for the response. I tried also with a FPBX 15 on my Hyper-V, and does the same. When you save and apply configuration there is no override, but if you move in dashboard and then click again under settings -> Advanced SIP Settings, you will notice that the Apply config button appears without any human change on the configuration, and you will find chan_sip port moved to 5062.
does anyone tried the same? I think this is a dangerous way to do “data validation” (that should be made on submit button if necessary), because the user is not warned about the configuration change, and will have problems on next system restart due to the signaling port shift…
I have not tested this, but the effect is not new.
I have seen this when restoring a legacy backup that used chan_sip to a new install that was set to use chan_pjsip on 5060.
The extensions are restored as chan_sip showing as 5060 until you hit the asterisk settings page. Then it move chan_sip to 5062. I mentioned it in the ticket I had at the time about other issues with legacy backup restore, but it wasn’t anything I cared about.
It is obviously the same bit of code hitting you. In your case, the port validation code obviously is not checking the entire bind info.
Asterisk doesn’t care how many NICs are on the system. Asterisk doesn’t care how your default routes are setup on the system. Asterisk doesn’t care that IP A and IP B should be on different NICs. I think my point here is, Asterisk doesn’t care at this level.
Chan_SIP and Chan_PJSIP are two different things. Yes, they are both SIP drivers but that’s like saying you want Apache and Nginx to run on different IPs but both use 80. It’s not going to happen even though they are both web servers.
It is no where near recommended and suggested that these two SIP drivers listen on the same port. Can cause issues.
Not allowing Chan_SIP and Chan_PJSIP to share a port is not a bug. It should be catching this and complaining and/or not allowing the change to be saved. If it is, then that is the bug and it should be fixed.
Did I say it couldn’t be? I am referring to the network interfaces on the system, not a config setting in Asterisk. Do you recall any Chan_SIP/PJSIP setting that actually cared about the network interface the IP was on? I don’t.
Telling the service what IP to bind to is not the same as what Ethernet interface or the default routes of the system are.
Let me be a little more clear: Having Chan_SIP and Chan_PJSIP listening on the same port, regardless of different IPs (or NICs), is a bad way to do this. It is not a recommended way or a suggested way. It is a bad practice that should not be encouraged.
Whilst I agree that trying to run two drivers on the same port number is a recipe for confusion and disaster, local IP addresses are bound to a single interface, so binding to an IP address does bind to an interface.