UserStateList does not appear to update when users log out/close their browser

[ThomasLocke]

Log in a couple of users and make sure they are all accounted for in the UserStateList object.

Now close the browser for one of the users and call UserStateList again. Note that the now defunct user is still in the list.

Can/should we use the websocket close event to log out users serverside, or?

[rostgaard]

How about we add a logged-out state and change this upon user logout? Detecting agents "dead in the water" can be done by checking the last-active timestamp. Clients in idle may then resend "idle" state to bump the timestamp.

I'm a bit reluctant as to introduce a notification socket listener into CallFlowControl before it is strictly needed. Also, there is no user-log-out event currently.

[ThomasLocke]

I was thinking more along the lines of tying the users websocket connection to their login state, so when a connection breaks, the notification server call out to let the world know that user X is dead in the water.

That would handle both intentional and unintentional logouts.

[rostgaard]

I don't see the real benefit of being able to notify the agents real-time of other agents' status as a critical feature. The agent count is more of an informational widget that doesn't really add system functionality.

The resend-idle approach solves the issue with the trade-off of reduced accuracy, but the benefit of not introducing additional complexity to the server stack. Plus, agents who have a crashed client may not necessarily have closed their websocket, which leaves us with a false positive anyway.

[ThomasLocke]

I think you're missing one very vital point: Agents/supervisors use the active/paused count to decide when and if someone can go on a break.

If we have a count of 5 active, when in reality it is only say 3, then we have a very nasty problem in the real world.

So it's not the information itself that is "critical", it is the fact that it can be severely wrong under the current system.

[rostgaard]

But, given my solution, the information will only be wrong, iff a client has crashed, within the timeout duration (1 minute seems appropriate).
Under normal operation, everything will act as it should. So, I still think that the value of adding a lot of extra complexity and dependencies to the server stack to account for one boundary case is very little.

I can add this extra feature, but the problem will still be present. Just in another form. As previously stated; this solution still doesn't count agents that has locked up in a way that preserved their TCP (WebSocket) connections. To detect this, we need to have an activity timeout.
Also, the UserStatus is a pseudostate that has been added as a "best-effort" way of preventing phones to create multiple channels to the PBX.
There is still the whole question of connectivity to phone, which is just assumed to be there (if the PBX has an active registration for the peer) and, if we were to be certain of agent connectivity, we should probably also handle this failure scenario.

Turtles all the way down, my friend.

[ThomasLocke]

Lets turn this around then:

We need a solution to a very basic real-world problem: Employees need a reliable and trustworthy method of determining when they can take a break. Today this is wholly dependent on the active agent counter: Each employee keeps an eye on this counter, and don't leave their workstations if it's too low or bordering on disaster levels. :o)

This is not a corner-case issue. This is every single day at the office. It is probably one of the most important things to get right, as breaks are very important to people, and more so when the job involves a fair amount of being "locked" to your desk.

If we can't make the active/paused counter reliable, what can we then do to solve this?

Could we solve this with a simple heartbeat?

[ThomasLocke]

We ended up with a dead man's switch (/alive/{id} or somesuch REST) and an explicit logout interface.

If the dead man's switch isn't called at appropriate time, the agent is put in unknown state and an event is pumped out on the notification socket.

Did we talk about more @rostgaard?