Solved 3CX desktop client intermittantly switching between IP and DNS name for webmeetings

[FridayIT]

Good afternoon,

I have a really... interesting issue I have noticed. The new desktop client is intermittantly showing an IP address rather than DNS name when creating a meeting. you can see on the below screenshot the desktop client is using a 10.x IP while the "webapp" shows the correct web address. The interesting thing is this is intermittant, and I have seen the new desktop app change back and forth (I didn't know it was intermittant which is why I believed it to be "resolved" yesterday).

The desktop client seems to switch between IP and DNS at random when relaunched. I have confirmed I have spit DNS setup on our internal DNS server. Since the certificate is not internal I am unable to have it go to an IP address without a certficate warning.

I can confirm, when opening a "quick" meeting, the add meeting it will reference my correct dns name and "click2talk" link.

 

[StefanW]

Hi @FridayIT,

the URL shown inside the app is in relation to how the client is currently connected to 3CX.
Whereby the browser is in a static link, the Desktop APP, like the Mobile Apps, are multi location-aware.
This means if the connection to the server using the FQDN fails it will retry by the second link, if 3CX was installed in hybrid mode (not split-brain DNS), this would explain the switching of the URLs

 

[FridayIT]

Hi @FridayIT,

the URL shown inside the app is in relation to how the client is currently connected to 3CX.
Whereby the browser is in a static link, the Desktop APP, like the Mobile Apps, are multi location-aware.
This means if the connection to the server using the FQDN fails it will retry by the second link, if 3CX was installed in hybrid mode (not split-brain DNS), this would explain the switching of the URLs

Ah, I think that makes sense.

Is there a way I can see how the PBX was originally installed? (one of my colleages did the original installation)

I think I might have an idea of how to fix this, I have a feeling your hunch is correct, as the pbx shows the provisioning link as an IP rather than dns name under the extension settings. I see now there is an option in V18 to do this via dns.

As a test, I changed my extension to dns and opened my mobile app on android (which I think uses the same logic) and I can see there is no longer a seperate url for "external link" in the provisioning section.

This would also explain why the issue was "intermittant" the app's logic was likely to always try to go to the internal IP first as that was what was set in the provisioning settings. windows sleep being the sneaky beast it is, probably took a few seconds for the network adapter to "wake" and while doing this "fixed" the issue until it realized it could use the internal IP again which then caused it to "switch back"

This actually might fix some of our wifi roaming issues as well (not a 3cx issue as roaming between cellular and wifi at my home office is almost instant). I'll run some tests when I am in office tomorrow and if all is well then change this for everyone.

 

[NickD_3CX]

Is there a way I can see how the PBX was originally installed? (one of my colleages did the original installation)

There is not a straight forward way, but if in the MC you go to Settings --> Parameters and you search for "LINK_LOCAL", if the URLs contain the Local IP address of the 3CX system, then the "I don't have a local DNS" option was chosen during the installation.
If the URLs have an FQDN, then that would be what you input during the installation.

Important!!!
As tempting as it may be to just change those values, DON'T! This is just an indicator for what was selected during the installation. Changing the values will most likely break you system.
You will need to perform a re-install if you want to re-configure this in a different way.

 

[FridayIT]

There is not a straight forward way, but if in the MC you go to Settings --> Parameters and you search for "LINK_LOCAL", if the URLs contain the Local IP address of the 3CX system, then the "I don't have a local DNS" option was chosen during the installation.
If the URLs have an FQDN, then that would be what you input during the installation.

Important!!!
As tempting as it may be to just change those values, DON'T! This is just an indicator for what was selected during the installation. Changing the values will most likely break you system.
You will need to perform a re-install if you want to re-configure this in a different way.

Yup, looks like that is the case, but I think we can work around this by simply using the dns name in the phone provisioning settings. I am testing this fix and if it works I'll leave everything as is.... otherwise I may have to visit reinstallation city.

(I'm hesitant to reinstall as we are on an unsupported provider atm due to factors beyond our control, which requires specific routing rules to be made)

I've done some brief testing and simply changing the dns settings seems to be enough to fix the desktop client. assuming there aren't any other issues with not selecting that option initially, then I think we can mark this as solved .

 

[FridayIT]

Good morning everyone,

Testing seems positive, I don't see any side effects of the change and will push the provisioning to now use dns instead of IP to everyone

Lets mark this as solved .