Pop up vs not pop up behaviour

[Matt Ryan]

Hi there, I'm having an issue with the 3CX Live Chat & Talk with our website and not sure if it's by design or something I've done wrong.

At the moment I have it configured to connect to a single extension while we test it, but ultimately it will be pointed to a call queue.

If I configure it to pop out, it all works perfectly, I can chat and call the extension. If I configure it to not pop out (which is what I prefer for our site), the chat works but the phone button disappears.
I've tried changing the modes (it's set to Chat and Phone) but they all show the same behavior.

Is it possible to have the Phone button appear without having to use the pop up mode?

Thanks

 

[Constantinos Constantinou]

Hello @Matt Ryan ,

It is very strange about and not normal this behavior. Can you please share with me in a personal message your website, in order to review the configuration?

The mode option, Phone and Chat VS Phone and Chat - Ignore Queue Ownership applies only to queue setups.

If you have the mode on Phone and Chat the ideally you should see it on pop-out mode or non-pop-out.

 

[Matt Ryan]

Thanks for that, I've sent you a private message.

 

[Constantinos Constantinou]

Hello @Matt Ryan ,

The issue is that on your site you are not using a valid SSL certificate. This prevents the WebRTC (used for Audio/Video) to operate.

Thank you.

 

[Matt Ryan]

ok thanks for that. We are in the process of changing that now. Strange that it works in pop up mode though.

Thanks heaps for the prompt replies to this thread

 

[Constantinos Constantinou]

As I explained on the popout, you will see that the popout URL is on PBX side. That's why it is working because there the certificate is valid.

 

[Matt Ryan]

ah of course. Thanks again for that. I'll get the certificate installed.

 

[Matt Ryan]

Hi, we have the SSL installed and it all works fine when I direct the call to an individual extension but when I direct it to a queue, the call button disappears even though there are agents logged in and available.

 

[KaiK]

Hi! We also have a problem with 3CX Live Chat & Talk: It does not pop-up on our website.

We have a Debian local installation.
The website-URL is set correct in 3CX-settings/WordPress/Apps&Plugins (https://....).
The Firewall-Checker passes all tests on all ports.

The strange thing is, that the pop-up works under these conditions:
1) If I first open the 3CX admin dashboard using its IP (https://192.168.xxx.xxx:5001), I will be asked by the browser to confirm that I'll take the risk to proceed with that site. The error message says that the certificate is issued for [companyname]@my3cx.de but not for https://192.168.xxx.xxx:5001.

2) If I confirm this dialogue and then open our website with 3CX Live Chat & Talk installed in the same browser session, it will work.

Login to the 3CX admin dashboard using https://[companyname].my3cx.de:5001/ does not work from out internal network. I have to use https://192.168.xxx.xxx:5001. I already reissued the Let's Encrypt Certificate using /usr/lib/3cxpbx/PbxConfigTool -renew-certificates. But that didn't resolve the issue.

Does anyone have an idea on how to resolve this? Thanks!

 

[KaiK]

I resolved this problem... It was caused by 3CX presenting the Click2Talk-URL (in extension settings) depending on whether you logged in to the 3CX-console from an internal IP or using the FQDN.

As our 3CX is installed in our internal network, we have to login using its internal IP (https://192.168.xxx.xxx:5001). In that case, 3CX displays the following Click2Talk-URL in the extension settings: https://192.168.xxx.xxx:5001/callus#username

According to the manual of WordPress Live Chat & Talk, one has to enter the Click2Talk-URL into the WordPress plugin. And this is the root cause of our (and others) problems: As the website is hosted on an external webserver, you must always use https://[companyname].my3cx.de:5001/callus#username instead of https://192.168.xxx.xxx:5001/callus#username.

This problem had been mentioned in another forum thread, so feel free to find further details there:
https://www.3cx.com/community/threa...sitors-with-chat-talk-video.62867/post-270325

My concern is why 3CX always uses the FQDN for the Click2Meet-URL but either the IP or the FQDN for the Click2Talk-URL (depending on with which you are logged into the 3CX console). To me that's illogical.

My suggestions towards 3CX on how to make handling simpler:
1) Split the Click2Talk-URL in extensions into two separate fields
Field 1: Internal IP, with comment in brackets: Use this for communicating inside your company
Field 2: FQDN, with comment in brackets: Use this for the WordPress Live Chat & Talk plugin. Or as an alternative: Add a comment that if one is logged in using the internal IP, he has to adapt the Click2Talk-URL for us with the WordPress plugin, so that it uses the FQDN instead.

2) Update the manual for the WordPress plugin in a way that it clearly states that for webservers, you always have to enter an FQDN into the plugin and not the internal IP of your 3CX, also if the Click2Talk-URL starts with https://192.168.xxx.xxx

Thanks!