“Agents” are users which have specific characteristics, and are identified in our system by having the “c2cagent” capability. There is a service, called “Agent assigner”, which attends requests from any source and provides in response a valid agent following some assignation method. Two different assignation mechanisms are currently supported:

  • system agent assignation: will assign the first available agent, that is, the first agent connected to the system whose presence is ‘unknown’ or ‘available’.

  • external agent assignation: will delegate the agent assignation to a third-party REST API. A POST request will be made against a previously configured endpoint.

One, and only one, of these mechanisms, could be used at a given time. The resolution method is specified by the administration in the configuration as described below. When the system is configured for external agent assignation, the request will have the following body:

   channelId: string,
   channelType: string,
   context: any

with the following meaning:

  • channelId: unique identifier for the resource being assigned (roomId, conferenceId, etc);

  • channelType: one of the following chat,``voice``, c2c;

  • context: any arbitrary unknown object intended for usage by the third party assigner that manages the REST API.

The response must have the following body: {agentId: string}. agentId will be the identifier of the assigned agent.


It is required to inject the PresenceService since it isn’t loaded by default as the core services.

Service interaction description

When a message with getAgent method is received, when configured with system agent assignation it will gather all users with +c2cagent capability and will return the first with presence online: true and activity: available or activity: unknown. If configured with external agent assignation, the service will make an HTTP request to the configured endpoint and return the agentId contained in the response.

Service Configuration

To enable the service the service initialization needs to be added to``wac.ini`` file.


To indicate an user must behave as an assignable user, +c2cagent capability must be added to the user. If the block above is not present in the wac.ini file, neither external nor internal agent assigners will be enabled. Given the above block is present the operator could choose to use the external or internal agent assigner using the config/agentassigner.toml file:

externalAssignerUrl = "url of the external assigner endpoint"

If the config/agentassigner.toml does not exist, is empty or contains an empty agentassigner section the internal agent assigner will be used.

Configuration examples


If user1@domain and user2@domain includes the capability +c2cagent, they will be used to feed the service. When requesting an assignable user, the current service will offer user1 or user2 if they are available or any one of them if both are not available.

Logs: known log messages




Agents obtained: ${users}


An error ocurred while resolving agent


Message received: ${message}


Trying to obtain agent


Trying to obtain agents


Available agent found: ${agents[0]}


Checking if ${} is available


Getting presence for user ${userId}


Resolved agent ${agent}


Agent assigner configured with external assigner at: ${externalAssignerUrl}


Agent assigner will use system assigner

Troubleshooting & caveats

It is not possible to ensure that the response is deterministic. The assignable user offered as return depends on a bulk request, results are not ordered, so “the first user on the array” do not always correspond with the same user.