May 14, 2019 at 5:23 pm #5246
Scenario: All users have MiCollab on their desktop and Mobile Phones.
When a device initiates a chat (User A – mobile) to (User B), only that device gets the replies (User A – mobile). That is fine during the current chat, but if the remote user (User B) decides to pick up the chat again a day later, the chats only reach the original device (User A – mobile). The user might now be sitting at his desktop (User A – desktop) and be oblivious to multiple chat requests from (User B). The only way the (User A – desktop) App gets chats again from (User B) is if (User B) deletes the chat history completely and initiates a new chat request. Upon initiating a new chat request, all (User A) devices see the inbound chat.
What we Expect:
We expect that all chat enabled devices for (User A) be able to receive incoming chats from (User B) regardless of whatever chat history has ocurred between the two.
Is this a bug or some setting we need to tweak?
Thanks,May 14, 2019 at 6:39 pm #5247
Thanks for using the forums. I understand exactly the experience you and your users are describing, and off the bat let me tell you this: it’s per current design.
In my experience (I have the same version you do), if someone initiaes a chat with me, and I’m logged into my desktop and mobile client, I will get the chat notification on both sides but as soon as I answer in any device, the other side will stop getting messages and the session will persist on the medium used. MiCollab hasn’t been fitted with persistent session communication, this is why.
Now because of this it makes sense that if you pick up the same conversation from days before on the last device you chatted, the messages will only be delivered to the device it was interacting with, this is because of the signatures left behind regarding this interaction, in essence it’s picking off where it left off.
Honestly speaking, this experience can be improved and I’m hoping they do. I’ll try to figure out what I can find out and report back. Allow me a couple of days.
In the meantime, if you have any further questions or comments feel free to drop me a line.
May 15, 2019 at 8:04 am #5249
- This reply was modified 1 week, 2 days ago by Eric Laracuente.
If this is indeed by design, it is very unfortunate. We embraced MiCollab as a Unified Communications tool, but given this chat issue, it is now looking more like a divided communications tool if we can only use one device once a chat is begun. During normal business days, our employees can begin a chat on their smartphone before they arrive at the office, and they expect to continue the chat from their desktop once they arrive. It is clearly not working and people are getting frustrated fast. What leads you to believe this is by design and not a bug?
RicardoMay 15, 2019 at 8:18 am #5250
I truly understand. MiCollab currently is a single presence system, the same way that Skype for Business (online or on-prem) is. if you compare them side by side, they actually suffer from the same issues.
For true multi-communication, presence and collaboration Mitel does have MiTeam, which is a comparable solution to Teams, Slack… offering the same amount of persistent chats, notifications, team breakout and more. Maybe this is something you might want to look at?
MiCollab basically grew from being a graphical interface of the PBX to a collaboration tool. Not excusing its flaws but I understand where they at from a technology standpoint. The good thing is that they are actively working on it and improving it, I will bring up your suggestions to that team and see how I can get you timelines of features.
Thank you!May 15, 2019 at 11:09 am #5251
Just wanted to provide a short update. I did some extra testing internally and I found that I might have been wrong.
I’ve found that for messages initiated between the Mobile or PC Client all messages appear in the locations you are signed into. All replies also show regardless of where. This looks to be an improvement over the 7.x version.
Now, why is this not the experience you are living, let’s ask some questions:
Where is your server in the network?
How do you route traffic to and from the DMZ to your MiCollab server?
I would recommend you would look at the Mobile requirements for the MiCollab server, there are some specific TCP Ports that require to be open:
Let me know if you need any further assistance or have questions, I would be glad to get you up and running. And Apologies for the miss information.May 15, 2019 at 3:48 pm #5252
I did lots of testing to remove any routing/firewall issues from the equation. Testing has been done both with all devices on the same LAN (including the MiCollab server) as well as with devices across disparate networks with the same result.
When a device initiates a chat, all devices belonging to the destination user get the chat. The destination user can move back and forth between devices seamlessly and can continue the chat just fine. The originating device on the other hand cannot move to any of his other devices because none of the chat messages have been received at those devices. The only way he can, for example, move from the Smart Phone to the PC is to delete the chat from the Smart Phone and begin a new chat on the PC.
I will go ahead and see about opening a ticket with our vendor to see if we can get some traction with Mitel.
Thanks.May 15, 2019 at 3:55 pm #5253
Oh, and to answer your DMZ question, our MiCollab server is configured in “server gateway mode”. One interface has a public IP facing our ISP, and the other interface has a LAN IP facing our IP Phones and PCs. That is why I mentioned that even a local test where all devices are on the LAN (no routing or firewall) has the same issue.
- This reply was modified 1 week, 1 day ago by Ricardo Villa.
You must be logged in to reply to this topic.