Jump to: navigation, search

SIP Server and Asterisk Integration Overview

Asterisk integrated with SIP Server can function in three different roles:

  • As a PBX with a business call routing capability.
    Asterisk is configured to send business calls to SIP Server to engage a Genesys routing solution. SIP Server uses the routing results to forward the call to the selected agent.
  • As a voicemail server.
    SIP Server uses Asterisk as a voicemail server. Unanswered calls are forwarded to Asterisk to record the voice messages. Contact center agents receive indication on their T-Library agent desktops about new voice messages waiting in their voicemail box. Agents can access and manage their voicemail boxes hosted on Asterisk.
  • As a media server.
    SIP Server uses Asterisk as a Media Server. Asterisk is engaged in the call to perform one of the following functions:
    • Call recording
    • Announcement or music playing
    • DTMF digits collection
    • Conferences

When SIP Server is integrated with Outbound Contact Server (OCS), the following configuration changes on Asterisk might be recommended. The notifyringing parameter should be set to no in order to avoid notifications sent by Asterisk when an agent’s extension goes to ringing state. This parameter can only be set globally in the [general] section of the sip.conf file.

Asterisk with a Business Call Routing Capability

The SIP Server - Asterisk Deployment Architecture figure depicts a sample deployment architecture of SIP Server with Asterisk, in which:

  • Asterisk is connected to the network via a SIP gateway.
  • The agent endpoint is registered on Asterisk.
  • The agent endpoint is associated with a T-Library desktop application.
SIP Server - Asterisk Deployment Architecture

Integration with the Asterisk switch relies on the SIP presence subscription from SIP Server. For any call handled by the agent endpoint, Asterisk is requested to provide a notification about the status change for that endpoint. SIP Server uses those notifications to synchronize an agent state visible to all Genesys T-Library clients with the actual state of this agent. The business call routing solution that is built on these integration principles involves SIP Server to handle the business calls only. Private calls are processed locally on Asterisk. Agent statuses are reported to SIP Server for all call types, because they are used to identify the agents' availability for the Genesys Routing Solution.

All figures in this topic depicting Stream Manager refer to the Genesys Stream Manager. This component, when working together with SIP Server, provides different kinds of media services, such as ring-back, music-on-hold, DTMF digit collection, and others. You can also configure Asterisk to work as a media server for SIP Server. For information about architectural and configuration details of this solution, see Asterisk as a Media Server.

Private Calls

An Asterisk dialing plan can be set up in such a way that private calls (direct calls to an agent, for example) are not forwarded to SIP Server. Instead, only the notification about the busy status of the endpoint is passed to SIP Server. SIP Server uses this status change notification to set the endpoint DN to a busy state (EventAgentNotReady), so that the rest of the Genesys suite will not consider that DN available for the routing of contact center calls.

The following figure illustrates the processing of private calls.

Private Call Processing

Contact Center Calls

In the same way that you can set up an Asterisk dialing plan to bypass SIP Server for private calls, you can write rules so that Asterisk connects contact center calls (typically, calls to the service number of the company) to SIP Server. After that, SIP Server triggers a strategy for Universal Routing Server (URS) to process this type of call. Eventually, an agent DN is selected to handle the customer call and SIP Server initiates a new dialog to Asterisk for the selected endpoint. Finally, Asterisk delivers the call to the agent endpoint.

This mechanism creates a signaling loop inside SIP Server, which is then in charge of maintaining the inbound leg from Asterisk (customer leg) with the outbound leg to Asterisk (agent leg).

Note: From the Asterisk perspective, the two legs are two completely separate calls. Correlation is performed at the SIP Server level.

By staying in the signaling path, SIP Server detects any change in call status, and can therefore produce call-related events (EventRinging, EventEstablished, EventReleased, and so on).

Any call control operation from the agent must be performed using a third-party call control (3pcc) procedure. In other words, the agent desktop must be used for any call control operation (besides the answer call operation). This includes, but is not limited to, hold, transfer, and conference requests.

The following figure illustrates the processing of contact center calls.

Contact Center Call Processing

Call Flows

Subscription

At startup, SIP Server sends SUBSCRIBE messages to the Asterisk switch, which notifies about changes in the endpoints' status. The Asterisk switch sends NOTIFY messages to SIP Server to report the endpoints' status. See the following figure.

Presence Subscription from SIP Server

If an endpoint is not yet registered, the Asterisk switch reports its status as closed. As soon as the endpoint registers, Asterisk sends a NOTIFY message to SIP Server, reporting the status open. See the following figure.

Private Calls

For private calls, the Asterisk dialing plan is set up in such a way that the call is sent directly to the endpoint. Asterisk notifies SIP Server about the call activity on that particular endpoint. In this case, SIP Server generates EventAgentNotReady, which reports the overall agent status as unavailable for contact center calls. (See the Private Call Processing figure.)

SIP Server generates only agent-related TEvents for the private Asterisk calls—for example, EventAgentReady and EventAgentNotReady. Call-related events"such as EventRinging, EventEstablished, and so on--are not generated for private calls, because SIP Server is not involved in the processing of private calls.

As soon as the call is released at the endpoint, Asterisk notifies SIP Server, which then generates an EventAgentReady message. The agent is then considered available for contact center calls.

Note: The mechanism for private outbound call processing is exactly the same. SIP Server receives the NOTIFY messages sent by Asterisk.

Contact Center Calls

Inbound Calls to SIP Server: Inbound contact center calls are programmed within the Asterisk dialing plan to be directed to SIP Server. In this case, the call arrives at a Routing Point, and URS is triggered. You can request a call treatment (using the TApplyTreatment request) to play announcement or music. If Stream Manager is configured to provide a treatment functionality, SIP Server connects a caller to Stream Manager to listen to the treatment while waiting for an agent to become available. See the following figure.

Handling Contact Center Calls

Whenever the agent becomes ready, SIP Server receives a TRouteCall request to the targeted agent endpoint. Because this endpoint is configured to point to Asterisk, SIP Server then initiates a new dialog with Asterisk to engage the agent. Asterisk forwards the call to the specified endpoint and reports to SIP Server the call activity on that endpoint with a NOTIFY message (EventAgentNotReady). When the call is answered, Stream Manager is disconnected, and the original SIP dialog is renegotiated between SIP Sever and Asterisk.

Because SIP Server is in the signaling path for contact center calls, it generates all call-related events (EventRinging, EventEstablished, and so on) for the agent's DN. See the following figure.

Delivering the Call to the Agent

Furthermore, when the call is released, SIP Server also generates EventReleased, and Asterisk notifies SIP Server with a NOTIFY message (EventAgentReady). See the following figure.

Contact Center Call Disconnection

Inbound Calls to Extensions: Inbound contact center calls, and manual internal first-party call control (1pcc) calls that are directed to extensions, are not visible to SIP Server; as a result, you cannot make third-party call control (3pcc) calls for them. Only inbound calls that are directed to Routing Points on SIP Server, and manual internal calls, which go via Routing Points can be seen by SIP Server; as a result, 3pcc calls can be made for them.

Outbound Calls: An outbound call that is contact-center-related (for example, a call back to a customer) must be performed using 3pcc operations. This ensures that SIP Server creates and controls the SIP dialogs on behalf of the agent endpoint. SIP Server uses the call flow 1 described in RFC 3725 to create a call initiated from the agent's T-Library client using the TMakeCall request.

An agent initiates the outbound call by sending the TMakeCall request from the T-Library client to SIP Server. SIP Server attempts to engage the agent by sending the INVITE message to this agent endpoint (via Asterisk).

Note: If the phone is not configured with auto-answer, the agent must manually answer the call. This is the only manual action that is required for contact center calls.

If Stream Manager is configured to provide treatments, then SIP Server connects the agent to Stream Manager to listen to a ringback tone while establishing a connection to the outbound call destination. See the following figure.

Engaging the Agent Endpoint for an Outbound Call

SIP Server contacts the requested destination number. After the destination answers the call, SIP Server discontinues the ringback tone (by sending the BYE message to Stream Manager) and renegotiates with the agent endpoint (via Asterisk), so that the media stream is connected between the agent and the customer. See the following figure.

Connecting to the Customer

Although disconnection would work if it were initiated directly from the agent endpoint, it is good practice to always use a desktop application to perform any actions related to contact center calls. Therefore, the disconnection is requested by sending the TReleaseCall request to SIP Server.

SIP Server manages two dialogs: one for the agent and another for the customer. It sends the BYE message to both of them, and the call is eventually disconnected. See the following figure.

Outbound Call Disconnection

Asterisk as a Voicemail Server

Asterisk can provide the voicemail server functionality. A stand-alone Asterisk solution allows all agents registered on Asterisk to use multiple voicemail boxes. SIP Server integration with Asterisk adds several new voice-mail-related features to the standard Asterisk set:

  1. Agents registered on SIP Server (an agent VOIP phone sends the SIP REGISTER message to SIP Server) can use voicemail boxes hosted on Asterisk.
  2. All agents (registered on Asterisk or on SIP Server) can receive voicemail notifications on their T-Library client desktops.
  3. Voicemail boxes can be associated with extensions, agent logins, and agent groups.

Voicemail Boxes For Agents Registered on SIP Server

One or multiple voicemail boxes can be created on Asterisk for the agents registered on SIP Server. All voicemail features configured on Asterisk become available for SIP Server agents. Unanswered calls can be forwarded to the corresponding voicemail box allowing callers to leave a voice message. SIP Server agents can call their voicemail boxes from their VOIP phones to listen to the voice messages and to manage the voicemail box.

Voicemail Notifications Sent to SIP Server T-Library Clients

Genesys contact center agents use T-Library client desktops. If Asterisk is configured as a voicemail server for SIP Server, agents can receive notifications about the new voice messages left in their voicemail boxes on their T-Library client desktops. These notifications also provide information about the number of old and new messages stored in the voicemail box.

Voicemail Boxes Associated with Extensions, Agent Logins, or Agent Groups

SIP Server associates each voicemail box it controls on Asterisk with one of the following configuration objects in the Configuration Layer: Extension, Agent Login, or Agent Group. The voicemail box associated with a corresponding object defines a group of SIP Server T-Library clients to receive voicemail status notifications for a particular voicemail box. Voicemail notifications described in this section are transmitted using the T-Library interface. SIP Server sends messages to its T-Library clients.

If the voicemail box is associated with an extension, then notifications are sent to an agent whose T-Library client is registered to this extension. If the voicemail box is associated with the agent login, then SIP Server sends voicemail notifications to this agent T-Library client. In this case, it does not matter what DN this agent used to log in.

It is also possible to associate a voicemail box with the agent group. If a new voice message is left in such a voicemail box, then all logged in agents associated with this agent group will receive a notification about this message.

Call flows

The following figure illustrates a general integration schema representing Asterisk configured as a voicemail server for SIP Server.

Asterisk Configuration as a Voicemail Server

The figure also shows how voicemail services can be provided for two agents: Agent DN 1000 and Agent DN 2000. Both agents use T-Library desktops connected to SIP Server via the T-Library protocol. Agent DN 1000 has the VOIP phone that is registered on Asterisk. Agent DN 2000 has the VOIP phone that is registered on SIP Server.

Asterisk is configured to fully support all calls made from and to DN 1000. For this purpose, it has a SIP entity [1000] configured in the sip.conf file to represent the agent's phone. It also has a voicemail box configured in some private context [MY_COMPANY] in the Asterisk voicemail.conf configuration file.

SIP Server integration with Asterisk requires adding a new object to the Asterisk configuration to provide the voicemail functionality for the SIP Server agent at DN 2000. A new voicemail box for this agent is created in the [GVM_DN] context of the Asterisk voicemail.conf configuration file.

The Asterisk Message Waiting Indicator (MWI) interface is used to integrate Asterisk as a voicemail server with SIP Server. The MWI interface utilizes the SIP subscription schema. SIP Server subscribes to the message-summary event at Asterisk using the SIP SUBSCRIBE request method:

SUBSCRIBE sip:gvm-1000@192.168.0.300 SIP/2.0

From: sip:gvm-1000@192.168.0.300;tag=7C217D88

To: sip:gvm-1000@192.168.0.300;tag=as050e992c

Call-ID: 1CD815F7-1@192.168.0.300

CSeq: 1103 SUBSCRIBE

Content-Length: 0

Via: SIP/2.0/UDP 192.168.0.200:5060;branch=z9hG4bK3B

Event: message-summary

Accept: application/simple-message-summary

Contact: <sip:gsipmwi@192.168.0.200:5060;mb=1000;dn=1000;tp=1>

Expires: 600

Asterisk sends notifications to SIP Server about the voicemail box status using the SIP NOTIFY message:

NOTIFY sip:gsipmwi@192.168.0.200:5060;mb=1000;dn=1000;tp=2 SIP/2.0

Via: SIP/2.0/UDP 192.168.0.200:5070;branch=z9hG4bK219f391e

From: "asterisk" <sip:asterisk@192.168.0.200:5070>;tag=as13d3077a

To: <sip:gsipmwi@192.168.0.200:5060;mb=1000;dn=1000;tp=2>

Contact: <sip:asterisk@192.168.0.200:5070>

Call-ID: 1CD815F7-1@192.168.0.300

CSeq: 102 NOTIFY

User-Agent: Asterisk PBX

Event: message-summary

Content-Type: application/simple-message-summary

Content-Length: 43

Messages-Waiting: yes

Voice-Message: 1/0

SIP Server generates the EventUserEvent message based on this notification and sends it to the T-Library client registered on a DN associated with a particular voicemail box. This is an example of such a T-Library event:

EventUserEvent

AttributeUserData [120] 00 01 03 00..

'gsipmwi'(list) 'Mailbox 1000'

'Messages-Waiting' 'true'

'Voice-Message' '1/0'

'NewMessages " 1

"OldMessages " 0

AttributeUserEvent [1001]

AttributeThisDN '1000'

Dedicated SIP objects are created in the sip.conf Asterisk configuration file to support the MWI subscription. These objects are gvm-1000 and gvm-2000 in the Asterisk Configuration as a Voicemail Server figure. The GVM acronym in the object name stands for Genesys Voicemail. These objects are created in Asterisk for MWI subscription purposes only, and no SIP clients are registered on these objects. Both objects have a parameter pointing to a specific Asterisk voicemail box:

[gvm-1000]

mailbox=1000@MY_COMPANY

[gvm-2000]

mailbox=2000@GVM_DN

SIP Server activates one SIP subscription per voicemail box it needs to monitor. The above configuration guarantees that SIP Server will receive notification on a correct voicemail box when it subscribes to a corresponding GVM object.

MWI Subscription Scope

SIP Server activates one or multiple MWI subscriptions for each voicemail box it needs to monitor. Individual voicemail boxes created for Extensions or Agent Logins are monitored by a single MWI subscription per box. The number of MWI subscriptions activated per Agent Group voicemail box is equal to the number of agents currently logged in to this Agent Group.

SIP Server is designed in the assumption that all extensions have voicemail boxes. So, if MWI monitoring is enabled for the extensions (mwi-extension-enable is set to true), SIP Server at start up attempts to activate MWI subscriptions for all extensions configured in the Configuration Layer. Subscriptions for the Extension-related voicemail boxes are deactivated when SIP Server shuts down.

MWI subscription for Agent Login is when an agent with the corresponding agent ID logs in to SIP Server. SIP Server keeps this subscription active while the agent is logged in and stops it when the agent logs out.

The same MWI subscription logic is applied to the monitoring of voicemail boxes created for the Agent Groups. SIP Server activates MWI subscription for the group when the first agent associated with this group logs in. SIP Server stops the subscription when the last agent of this group logs out.

If, for some reason, a subscription request for any voicemail box type is rejected or times out, SIP Server attempts to activate this subscription again in one minute.

Building a Voicemail Solution

The Voicemail functionality in SIP Server and Asterisk allows you to build multiple Voicemail solutions with different complexity to address different business needs. This section provides examples that show how to build Voicemail solutions. It outlines general architectural ideas that refer to some configuration options only for clarification purposes. For configuration procedures, see the Framework 8.1 SIP Server Deployment Guide.

The easiest approach to a Voicemail solution is to have calls, which are not answered on a DN during a specified timeout, forwarded to the voicemail box associated with this DN (extension). This solution requires that you associate an Asterisk-hosted voicemail box with the DN. A DN object in Configuration Manager should be configured with the following options:

  • no-answer-overflow
  • no-answer-timeout

The no-answer-timeout option specifies the time during which the call must be answered. When the no-answer-timeout timer expires and the call is not answered, SIP Server uses the value of option no-answer-overflow to decide how to process the call. If this option contains the name of the voicemail box associated with this DN, then SIP Server sends the call to this voicemail box.

A similar solution can be configured for agents. SIP Server can apply the same algorithm that is used for process unanswered calls for an agent who ignores the DN where the agent logs in. In this case, the Asterisk-hosted voicemail box should be associated with the Agent Login (and not the extension). Also, the no-answer-timeout and no-answer-overflow options should be specified in the Agent Login configuration object.

SIP Server also allows you to use voicemail boxes in business call routing. Usually in those scenarios, calls are controlled by the URS strategy, which attempts to find an appropriate agent to forward the call to. There are many ways to write a URS strategy to utilize a Voicemail solution. For example, if a call is routed to an agent group that does not have any currently available agents, URS can send a call to the voicemail box associated with the Agent Group. In this case, all logged in members of this group will receive a notification about the new message left in the group voicemail box.

SIP Server can also redirect unanswered calls to the voicemail box based on the options configured for the SIP Server Application configuration object. There are two groups of options, which define how SIP Server processes unanswered calls for extensions and for agents:

  • extn-no-answer-XXX
  • agent-no-answer-XXX

See the Framework 8.1 SIP Server Deployment Guide for more information about the options.

Asterisk as a Media Server

You can configure Asterisk as a media server for SIP Server. SIP Server can utilize the following services provided by Asterisk:

  • Play announcements.
  • Collect DTMF digits.
  • Organize conferences.
  • Recording calls.

Communication between two servers is mainly based on RFC 4240--an exception is the recording service, which is not described in this RFC.

This page was last modified on September 7, 2018, at 18:04.

Feedback

Comment on this article:

blog comments powered by Disqus