OpenSIPS has the Call Center module for a while, a module that allows queuing and dispatching (to agents) of RTP based calls (audio or video).
OpenSIPS 3.3 focused on instant messaging, mainly session based messaging (or chat) in the context of IMS and Unified Communication (UC). And speaking of UC, the addition of chat (MSRP based) support into the Call Center support was a great improvement of the 3.3 release, transitioning the Call Center to a Contact Center.
What is the big difference between a Call Center and Contact Center? While the Call Center has only audio/video communication channels between customers and agents, in a Contact Center you may have a various set of such communication channels, such as chat/messaging, emails or tickets.
Therefore, different sources will push, using various communication channels, jobs into an aggregated, priority queue that will do dispatching to a single, unified, set of agents.
Contact Center with OpenSIPS 3.3
The existing Call Center module was extended in order to support MSRP based calls as well – to support sessions based instant messaging. From SIP perspective, the RTP-based calls – for audio/video – and the MSRP-based calls – for messaging – are the same kind of INVITE-BYE based sessions.
Still, the major difference in behavior comes from agents side and how the tasks (calls) from the queue are dispatched to them.
In the Contact Center version, an agent can handle either one call, either a set of parallel chats (messaging sessions). Yes, chatting is easier to be performed, so an agent may do multiple chat sessions in the same time. So an agent is now defined in a more complex manner, as:
- supported types of calls (RTP-based for audio/video or MSRP-based for chat). For each call type, the agent defines an SIP URI where to receive such calls. So, the agent may have one SIP device for audio and another one for chats.
- available channels/slots for each type of call. Note that for the RTP-based calls there is a hardcoded availability of 1 channel only.
***************** 1. row *******************
agentid: agentX
location: sip:agentX@10.0.0.10:5060
logstate: 1
msrp_location: sip:agentX@10.0.0.11:5060
msrp_max_sessions: 3
skills: info
***************** 2. row *******************
agentid: agentY
location: NULL
logstate: 1
msrp_location: sip:agentY@10.0.0.21:5060
msrp_max_sessions: 2
skills: info
***************** 3. row *******************
agentid: agentW
location: sip:agentW@10.0.0.30:5060
logstate: 1
msrp_location: NULL
msrp_max_sessions: 0
skills: info
Keep in mind that even if an agent can do multiple chats in the same time, once answering an audio call he will not be able to take any chats. Shortly, the chats and audio calls do exclude one another, and cannot be done in the same time.
Now, as mentioned before, the addition of chats changes the logic when comes to dispatching the queued calls to the agents. This logic becomes now rather complex as ideally:
- the calls should be evenly distributed across agents, to avoid overloading certain agents – yes, this is now possible, by pushing several chat based calls to the same agent, while no chats at all to other agents;
- the starvation of the audio calls in the queue should be avoided. The agents (due their ability to handle multiple chats sessions in the same time) may tend to get stuck in serving chats all the time (as chat sessions may overlap), not be available for audio calls at all.
As you can see, these two requirements for the dispatching logic somehow conflict, so kind of middle ground must be found here.
The module provides control over how the dispatching should be performed via the chat_dispatch_policy parameter.
The “balancing” dispatching mode
In this mode, the distribution will try to be even across the agents. The available agents are iterated one by one and they will receive one call – at a time – from the queue.
As you can see, you may mis-load the agents (by blocking them with small number of chats), leading to an audio calls starvation – agents are partially used by chat sessions, so they cannot take calls (of course, this only happens if you have mixed agents with audio/chat capabilities).
The “full-load” dispatching mode
In this mode, the distribution will try to make usage of an agent in the best possible way when comes to chat sessions – once the agent takes a chat, all the following chats will be assigned to him – the idea is to try to be efficient in using the resources/sessions of an agents, to leave as much space as possible for calls.
Of course, this may lead to a dis-balanced loading of chat agents – some will be full, others empty.
Bottom line, none of these dispatching modes are perfect and which one to use highly depends on the agents profile from case to case (i.e. if you have mixed agents or not).
The “external” dispatching via API
The perfect dispatching algorithm should implement an “look-ahead” into the queue (not looking only at the first element), combined with a global view over the available resources from all agents (not only from the currently evaluated agents). With such global view over queued calls and agent’s loading, an algorithm may be able to implement the fair call dispatching, by :
- respecting the priority of the calls in the queue
- avoiding starvation of the audio calls
- evenly loading the available agents
And as “perfect” is relative from scenario to scenario, the OpenSIPS 3.3 module allows you to externalize this dispatching logic.
You can disable the internal built-in dispatching logic (see the internal_call_dispatching) and allow an external application to take over and implement your own custom dispatching logic. Such an application will interact with OpenSIPS via the Management Interface for :
- fetching the status of the queued calls and logged agents
- dispatching a call to an agent
Conclusions
The Call Center to Contact Center evolution is just one step when comes to tackling the UC concept. And this step does not come by iteself – it is part of bigger plan of expending the OpenSIPS usage into the messaging / MSRP systems, dealing with end points, relaying, gateway’ing and high-level services.
But find out more during the OpenSIPS Summit 2022 in Athens.
Drops of wisdom, knowledge and news from OpenSIPS 