Before this callcenter_config queue reload [queuename] only reloads the queue
parameters and now it'll include a CC-Queue header with the queuename when using
mod_xml_curl and request a new config for updating agents and tiers related to the
queue.
If you are using mod_xml_curl please make sure to return the raw xml config file
with all the settings, queues, agents and tiers tags when we request the config
without a CC-Queue specified. If this header is present you can build the xml with
items only related to the queue requested.
A new strategy is now available through mod_callcenter, which aim
is to provide a mix between top-down and ring-all strategies.
If set to ring-progressively, the strategy will call an agent, and
then a second agent, and then a third agent, without cancelling
previous calls.
The delay between each call is 10 sec by default, but it can be
changed using the queue variable ring-progressively-delay.
Added counters for answered and abandoned calls for a queue.
Create two vars for cc_queue struct
- calls_answered
- calls_abandoned
These increases when the call is hangup.
This change also :
- refactor long lines of header and body to print the queue information.
- Update year in copyright
Adding a JSON API interface to fetch data in the JSON format. It abides with the JSON command and its implementations by other modules like mod_verto.
It outputs the exactly same column names as the data in CLI.
Various listing of mod_callcenter data such as agents, queues, members, tiers are as follows below.
- Listing of agents
Command: `json {"command": "callcenter_config", "format": "pretty", "data": {"arguments":"agent list"}}`
- Listing of queues
Command: `json {"command": "callcenter_config", "format": "pretty", "data": {"arguments":"queue list"}}`
- Listing of agents for a queue
Command: `json {"command": "callcenter_config", "data": {"arguments":"queue list agents", "queue_name":"support@default"}}`
(`queue_name` is a required)
- Listing of members(callers) for a queue
Command: `json {"command": "callcenter_config", "data": {"arguments":"queue list members", "queue_name":"support@default"}}`
- Listing of tiers for a queue
Command: `json {"command": "callcenter_config","data": {"arguments":"queue list tiers", "queue_name":"support@default"}}`
- Listing of members(callers)
Command: `json {"command": "callcenter_config","data": {"arguments":"member list"}}`
- Listing of tiers
Command: `json {"command": "callcenter_config","data": {"arguments":"tier list"}}`
It handles various errors and also returns back response in JSON as follow
E.g. Send a command without a required field (`queue_name`)
Command: `json {"command": "callcenter_config", "data": {"arguments":"queue list agents"}}`
Output: `{"command":"callcenter_config","data":{"arguments":"queue list agents"},"status":"error","message":"The command returned an error","response":{"error":"Missing data attribute: queue_name"}}`
The new C compiler breaks a lot of things. snprintf and timespec now exist, and redefining causes an error.
Many more things are warnings, so warnings-as-errors will fail - remove it from some projects for now.
V8: don't pass VS version to build batch file.
mod_sofia: Config has too-long if/elseif chain. Break this up to avoid "parser stack overflow; program too complex".
Add mod_conference.h to project and dir to includes.
Sets the agent state to Reserved before calling him. In this case,
the Agent is first updated to state Reserved ONLY if his previous
state was Waiting and status was Available/Available (On Demand).
The purpose is to avoid possible race conditions when external
applications are manipulating `agents` table.
Disabled by default.
* commit 'f63f8686bc8da391b3c46b24e10571215c8b377f':
FS-7049 - Documentation for state optional paramenter in callcenter_config queue list and count
fix FS-7049 - Count and list agents based on their state
If the member do an attended transfer this loop stops and
the agent is set to Available state again, when in fact he still
busy with other channel.
This was happening, for example, when a member calls support queue, then
the support operator do an attended transfer to sales queue, while the sales
operator is talking the member that was transferred, the sales queue will
send calls to the operator, which is not expected.
