|
Third party call control from Aculab is implemented according to IETF RFC 3725.
If, for example, an incoming call finds a contact centre agent busy on an existing call, the call is answered by a voice prompt (to determine the service required) played over a media processing resource path. The call is then placed on hold, queuing for an agent, and the media channel is released, however, the application retains control of the call and the signalling is always present. When an agent becomes free, the caller is connected to talk to the agent. Optionally, if the application or the agent requires it, the call can be recorded by means of further media paths being connected.
The key point to note is that the caller and the agent ‘calls’ are controlled by the application from beginning to end. Even when the media path has been ‘transferred’ (e.g., connected to an agent) the call control hasn’t. From an API standpoint, the ‘calls’ are the SIP sessions. The media is variable and might not be connected at any point at all during the ‘call’. Media channels are only used as and when they are required and many more channels of SIP signalling might be used than media channels. The programming model is consistent, and quite simple, regardless of the media type (voice or video), and handling third party call control is very much like, and no more difficult than, but certainly more powerful than, simple first party call control.
|
