- Joined
- Aug 29, 2019
- Messages
- 12
- Reaction score
- 9
Huge fan of 3CX! Since switching to 3CX we really have saved 80% (over!) vs previous solutions we had used. I am in no-way tech savvy but I was able to use the PBX express over 2 years ago to set-up our first instance and I haven't had to touch it since. Such a solid product.
Potentially Helpful Information:
So I need to figure out why the devices didn't connect to the fresh VM before I attempted this again. After reading through the forums I believe my problem was related to the 'Network interface for registration and provisioning' in the 'Phone Provisioning' section of the extensions settings. In all of our extensions our internal IP address was selected not the FQDN. After reading the forums I believe changing this field, so that our FQDN is used, will resolve the problem I was experiencing (regarding the devices not connecting to the new VM). I am not 100% certain this will be the answer to my problem -I have to test first, but any input would be helpful. The larger problem is that IF this is the solution to my problem I am confused as to why and don't understand some implications of networks settings in 3CX, which I would like to understand better. Let me explain:
In other forum posts I have read that our external extensions (iPhone apps running out in different cities) do not use the 'Local PBX IP' server settings inside of the account settings of the app (from the configuration file). Since they are 'external' devices the Local PBX IP information won't be used. But when I changed the 'Network interface for registration and provisioning' field to use the FQDN (in the extension settings inside of the admin panel) and re-provisioned the iPhone app it only changed the 'Local PBX IP' field in the account settings of the iPhone app. The 'External PBX IP' field always used the FQDN. My questions are:
1. Since the iPhone app is an 'External' device why does changing the 'Network interface for registration and provisioning' field (in the extensions settings) to use the FQDN matter when it only seems to update the 'Local PBX IP' field in the iPhone account settings? Since the 'External PBX IP' field in the iPhone account settings was always the FQDN and the device is never on an internal network shouldn't the app automatically just use the 'External PBX IP' settings?
2. When the internal IP address is used for the 'Network interface for registration and provisioning' extension field and then, on the iPhone app, I go into the 'Accounts' section underneath the account name it has extension@internal_ip (example: [email protected]). The iPhone app works but I am confused as to how/why it works because the internal IP shouldn't be accessible by the remote iPhone.
3. I am confused of the implications of the field 'Choose which IP is the Default Internet facing IP Address. (Default gateway)' in the 'Network Settings' of 3CX. For us it is the Internal IP address of the VM and there are no other choices from the drop-down menu. Since our VM is cloud hosted and we do not have any 'internal' devices I don't get how this field is utilized. Does it not matter in our scenario?
4. Is there a way for newly created extensions to default to using the external FQDN in the 'Network interface for registration and provisioning' field instead of the internal IP address?
5. I seen another post in this forum that suggested, when setting up a new 3CX instance, selecting the 'Enter your local FQDN (if you have a managed DNS)' field (vs staying with 'Local IP' selection) and then pasting in the same external FQDN that 3CX provided in the previous steps. This way, the default value for the 'Network interface for registration and provisioning' in the extension settings would be the FQDN and there would be no need to worry about devices trying to connect via internal IP address. I was wary about going this route because it seems like I am providing incorrect information to 3CX during the setup because we wouldn't actually have a 'local' FQDN, just the same external one 3CX provided. Is this something I should consider in my scenario?
Essentially I am confused about the implications of 'external' and 'internal' networks. 3CX seems to be able to tell the difference when which one should be used and since we have no internal devices I thought 3CX would just ignore any internal network instructions and instruct all devices to use the external FQDN. But that doesn't seem to be the case with the iPhone apps that have 'Network interface for registration and provisioning' field set to internal IP...that field seems to matter for some reason in our situation and I can't understand why.
Thanks for taking the time to read my post! I read several other related forum posts and I couldn't find an answer to my misunderstanding.
Potentially Helpful Information:
- Enterprise License
- Version: 16.0.676
- Linux Installation
- Cloud Hosted (Google Cloud)
- Using 3CX provided FQDN
- We do NOT use split DNS nor do we use an internal FQDN (I don't really know the implications of this but we haven't set it up)
- Firewall Check passed
- All devices are external devices (mostly 3CX iPhone apps across several cities) using the latest version of the iOS app.
So I need to figure out why the devices didn't connect to the fresh VM before I attempted this again. After reading through the forums I believe my problem was related to the 'Network interface for registration and provisioning' in the 'Phone Provisioning' section of the extensions settings. In all of our extensions our internal IP address was selected not the FQDN. After reading the forums I believe changing this field, so that our FQDN is used, will resolve the problem I was experiencing (regarding the devices not connecting to the new VM). I am not 100% certain this will be the answer to my problem -I have to test first, but any input would be helpful. The larger problem is that IF this is the solution to my problem I am confused as to why and don't understand some implications of networks settings in 3CX, which I would like to understand better. Let me explain:
In other forum posts I have read that our external extensions (iPhone apps running out in different cities) do not use the 'Local PBX IP' server settings inside of the account settings of the app (from the configuration file). Since they are 'external' devices the Local PBX IP information won't be used. But when I changed the 'Network interface for registration and provisioning' field to use the FQDN (in the extension settings inside of the admin panel) and re-provisioned the iPhone app it only changed the 'Local PBX IP' field in the account settings of the iPhone app. The 'External PBX IP' field always used the FQDN. My questions are:
1. Since the iPhone app is an 'External' device why does changing the 'Network interface for registration and provisioning' field (in the extensions settings) to use the FQDN matter when it only seems to update the 'Local PBX IP' field in the iPhone account settings? Since the 'External PBX IP' field in the iPhone account settings was always the FQDN and the device is never on an internal network shouldn't the app automatically just use the 'External PBX IP' settings?
2. When the internal IP address is used for the 'Network interface for registration and provisioning' extension field and then, on the iPhone app, I go into the 'Accounts' section underneath the account name it has extension@internal_ip (example: [email protected]). The iPhone app works but I am confused as to how/why it works because the internal IP shouldn't be accessible by the remote iPhone.
3. I am confused of the implications of the field 'Choose which IP is the Default Internet facing IP Address. (Default gateway)' in the 'Network Settings' of 3CX. For us it is the Internal IP address of the VM and there are no other choices from the drop-down menu. Since our VM is cloud hosted and we do not have any 'internal' devices I don't get how this field is utilized. Does it not matter in our scenario?
4. Is there a way for newly created extensions to default to using the external FQDN in the 'Network interface for registration and provisioning' field instead of the internal IP address?
5. I seen another post in this forum that suggested, when setting up a new 3CX instance, selecting the 'Enter your local FQDN (if you have a managed DNS)' field (vs staying with 'Local IP' selection) and then pasting in the same external FQDN that 3CX provided in the previous steps. This way, the default value for the 'Network interface for registration and provisioning' in the extension settings would be the FQDN and there would be no need to worry about devices trying to connect via internal IP address. I was wary about going this route because it seems like I am providing incorrect information to 3CX during the setup because we wouldn't actually have a 'local' FQDN, just the same external one 3CX provided. Is this something I should consider in my scenario?
Essentially I am confused about the implications of 'external' and 'internal' networks. 3CX seems to be able to tell the difference when which one should be used and since we have no internal devices I thought 3CX would just ignore any internal network instructions and instruct all devices to use the external FQDN. But that doesn't seem to be the case with the iPhone apps that have 'Network interface for registration and provisioning' field set to internal IP...that field seems to matter for some reason in our situation and I can't understand why.
Thanks for taking the time to read my post! I read several other related forum posts and I couldn't find an answer to my misunderstanding.
Last edited:
