Groups and Queues

From a point of view of the core API, queues and groups are added and deleted using the same SDMP messages.

The GroupAdd [AG] and GroupDelete [DG] messages can now be used to create and delete groups, as well as queues.

A queue differs from a group in the following ways:

1. a queue has some additional properties, such as:
   • Offer Timeout
   • Expiry Timeout
   • Overflow Address
2. a queue belongs to a specific campaign and tenant; a group belongs only to a specific tenant
3. a queue contains resources relating to a collection of media sessions ; a group represents a logical grouping of endpoints

A group may contain another group as a member. This aggregate behaviour allows hierarchies to be built and simplifies operation.

This logic holds true for queues as well. A queue may have groups as members, as well as endpoints. However a queue may not have other queues as members, only groups.

When configuring abstract groups, the supervisor selects from the list of endpoints and groups configured (Fig. 2):

Fig. 2 - Adding a New Group

The list of group members can contain both groups and endpoints.

It is not possible to have an endpoint address - Agent Extension (AE) - and a Group Address (GA) with the same value.

As stated above, a group and a queue can have both endpoints and groups of endpoints as members. In the Repository Editor, queue configuration now appears as shown in Fig. 3:

Fig. 3 - Editing a Queue

This shows both endpoints and groups as possible members.

The UI prevents basic recursion errors such as selecting a group as a member of itself. However, it is still possible to have say Group A containing Group B as a member and Group B can contain Group A as a member. Inside Softdial CallGem™, member lists are built using non-recursive algorithms to prevent circular relationships from causing unwanted loops.

In order to allow freedom of addressing and also resolve some issues of address conflict, addresses are now unique per tenant rather than globally. This means that the Agent Extension (AE) and Group Address (GA) parameters used in the API are now unique per tenant; in other words, 2 different tenants may have an endpoint with the same extension number, or may have 2 groups with the same address.

Internally, the collections that were global are now per tenant. This will also improve scalability.

Inbound routes are now determined at both tenant and landlord level.

See:
Tenant Level - Inbound Routes
Landlord Level - Inbound Routes

Operationally, Softdial CallGem™ ‘flattens’ all groups and queues into lists of endpoints. This enables a simple and deterministic view of the available resources to be maintained.

Whenever a queue or group is edited and members changed, all dependent queues and groups have their memberships recalculated.

The syslog records operational changes in membership with log entries with the prefix QUEUE: or GROUP:.

As groups are a mechanism by which many agents are allocated in configuration, Softdial CallGem™’s real-time agent management APIs follow suit.

The management APIs MoveAgent [MA] and KillAgent [KA] now take an optional Group Address (GA) parameter which is mutually exclusive with the Agent Name (AN) parameter. This allows supervisors to issue a request to move or kill a whole group of endpoints.

The behaviour of group-based move or kill differs slightly from requests for individual agents. A move or kill request will only be processed if there is not an existing request to make the endpoint unavailable of a higher precedence than the move or kill request. Unavailable precedence is the same as for V10.6.

An endpoint group may be spread across several campaigns. A kill request will forcibly log the endpoints out of the different campaigns that they are on. A move request will move all endpoints to a specific campaign, regardless of which campaign they are in.