Web Chat - Client unable to hold connection

Hi all!

My actual problem is that when I try to get a chat-connection the client connects, I receive a notification and a new chat-window opens. But after some seconds the client gets the messages “We are unable to connect you to an agent. Please try back later” and after pressing OK: “Your chat session has been ended by Agent”.

System is a new installed Openfire 3.5.1


-Setting up a new Workgroup and Queue with 1-2 users

-Tried several settings

Any suggestions? Did I make someting wrong in the setup for webchat?

Does Web Chat need Openfire Enterprise?

Thank You!


I am having the same problem as you are. I just upgraded from 3.5.0 to 3.5.1 saturday and installed the fastpath and webchat plugins and have been experiencing the same problem. Weird thing is that the webchat worked a few times then doesn’t seem to work any longer. The agent gets the notification of a request, accepts it and on the webchat side, it looks like its trying to connect the fails with the errror We are unable to connect

you to an agent. Please try back later" and after pressing OK: "Your

chat session has been ended by Agent".

I am using the embedded database on the opensource 3.5.1 version, I’ve installed the fastpath 3.5.1 version along with the commercial webchat plugin. I am running on a centos 4.5 server. btw, using spark 2.5.8 for the clients.

Could it be related to the webchat plugin still being commercial? is it looking for some sort of license key?

Also, there doesn’t seem to be any errors being logged in the webchat-error.log file.

Note to All: The cool thing is that the sales department in our company was thinking about doing a web support agent type thing just recently and the open sourcing of the enterprise stuff at this time is perfect timing for us. This openfire server is great, easy to setup and manage. Perfect for overworked IT guys like myself. Many thanks and appreciation to the Jive and igniterealtime guys for this great software.

Thanks to all for any help or suggestions!


I know in previous versions if the agent was a GroupChat Admin you would see this behavior.

I’m experiencing this with 3.4.5 and have been working with support for a few weeks now. Our problem looks to be a agent side issue, the customer initiates the request agent accepts. Customer joins chat room but is booted before the agent is able to connect. I think its a timing issue.

Very interesting, I removed myself from Group Chat/Group Chat Settings/Administrators and all seems well. The webchat seems to be working much better now. I just tried several webchat sessions and had no connection problems.

Thanks So Much!


I’m having exactly the same problem as this. Can’t figure out what it is doing.

I did see a message somewhere else in this forum regarding the installation of a webchat…Server name, domain name and certificates should all match (http://www.igniterealtime.org/community/thread/33754) but on sorting this lot, that didn’t work. May do for you guys though, so I thought it would be helpful.

Another thing to check would be that you are allowing anonymous users to connect (I am). Oh, and if you haven’t restared the openfire server since making changes to plugins, try that as well.

These are all just guesses at things that might help. None have worked for me, but maybe you’ll have better luck with them.

If anyone else has any ideas, please let me know, because I can’t figure this out at all.


Ok, sorry, my browser (or perhaps I) was being stupid, and I couldn’t see these messages. When the agent isn’t a GroupChat admin it works perectly.

Is there any way round this issue? - I would quite like to be a GroupChat Admin and Fastpath support operator…

Many thanks

I actually worked with support for several days on this problem (I’m using 3.5.0). What we ended up doing was the support rep recompiled the fastpath plugin with a higher connect time, I don’t know the exact timeout but it was hardcoded. What we figured out was the Customer was connecting to the chat room but the agent was taking too long to join (after clicking accept). So now with this higher timeout the customer may end up waiting a few seconds longer but we have yet to have a connection problem.