When scanning a QR code displayed by the management console, it would seem that the domain name for the provisioning URL, that is encoded within the QR code, is not as might be expected.
Within the QR code, I would have expected the provisioning URL to contain the domain name that is specified in the extension's Phone Provisioning tab, under the heading "Network interface for registration and provisioning". Instead, I have noticed that the url encoded into the QR code uses whatever domain name is specified in the url that is being used to access the management console.
At my office, I was accessing the management console from my web browser using the url: https://localintranetdomain:5001. My internal DNS routes this domain to a 10.x.x.x IP address that accesses the 3CX PBX (on a cloud machine) via our internal network. Consequently, cell phones for our users would provision without a problem if connected to our internal network using wifi. But, provisioning would fail with 'PBX Could Not Be Reached', if a cell phone was not connected to our internal network, even though the "Network interface for registration and provisioning" setting has always been set to the PBX server's public domain name.
When I switched to accessing the management interface from my web browser using the url: https://publicdomain:5001 instead of https://localintranetdomain:5001, this issue was resolved.
I'm therefore posting this message just to share the fact that the choice of url used to access the management console is unexpectedly significant in regard to QR code provisioning, and an extension's configured "Network interface for registration and provisioning" setting is unexpectedly disregarded, when it comes to the url encoded within the provisioning QR code.
Within the QR code, I would have expected the provisioning URL to contain the domain name that is specified in the extension's Phone Provisioning tab, under the heading "Network interface for registration and provisioning". Instead, I have noticed that the url encoded into the QR code uses whatever domain name is specified in the url that is being used to access the management console.
At my office, I was accessing the management console from my web browser using the url: https://localintranetdomain:5001. My internal DNS routes this domain to a 10.x.x.x IP address that accesses the 3CX PBX (on a cloud machine) via our internal network. Consequently, cell phones for our users would provision without a problem if connected to our internal network using wifi. But, provisioning would fail with 'PBX Could Not Be Reached', if a cell phone was not connected to our internal network, even though the "Network interface for registration and provisioning" setting has always been set to the PBX server's public domain name.
When I switched to accessing the management interface from my web browser using the url: https://publicdomain:5001 instead of https://localintranetdomain:5001, this issue was resolved.
I'm therefore posting this message just to share the fact that the choice of url used to access the management console is unexpectedly significant in regard to QR code provisioning, and an extension's configured "Network interface for registration and provisioning" setting is unexpectedly disregarded, when it comes to the url encoded within the provisioning QR code.
