Call supervision during IVR phase

Introduced in SIP Server version 8.1.102.95, calls in a SIP Cluster deployment can be observed while in the IVR phase where different treatments can be applied.

An IVR supervision session can be initiated by a T-Library client, such as Workspace Web Edition (WWE), connected to the SIP Server T-Controller by issuing a TMonitorNextCall request. The request must contain:

• AttributeMonitorNextCallType, which defines the type of call supervision. Possible values are MonitorOneCall and MonitorAllCalls.
• AttributeExtensions/MonitorScope, which defines the scope of call supervision. Only call scope is supported and supervision is continued once started until the call is cleared.
• AttributeExtensions/MonitorMode, which defines the mode of call supervision. Only silent monitoring mode is supported. A supervisor can switch to connect mode after a call is established with an agent.

Supported supervision features

• A monitoring session can be started only for a call that arrives at the monitored Routing Point in a SIP Cluster node that is in the same data center (geo-location) as a supervisor owner node.
• Cross data center supervision is not supported. A monitoring session is not started if a call arrives at the other data center where a supervisor owner node is present.
• Intrusion is not supported. A monitoring session is not started for the calls that are already in queue when monitoring subscription is created.
• A monitoring session can be canceled by a T-Library client, such as WWE, by issuing a TCancelMonitoring request.
• One supervisor can monitor only one Routing Point or an agent.

Monitoring sessions for multiple supervisors on the same Routing Point

Multiple supervisors can monitor the same Routing Point. However, only one supervisor is allowed per call. If two supervisors monitor the same Routing Point, for the first call on the monitored Routing Point, SIP Server adds information on both supervisors in AttributeExtensions generated on the IVR observing Routing Point. The strategy tries each supervisor until a call is routed to one of them successfully. For the second call on the monitored Routing Point, SIP Server adds the supervisor that is not selected for the first call.

Each SIP Cluster node in the data center, where supervision is activated, maintains a queue of supervisors who are waiting to monitor a call on a Routing Point DN. Each call arriving at this Routing Point is given a list of available supervisors, and a strategy routes the call to the first available supervisor. If one supervisor fails to join the call, that supervisor is moved to the end of the line.

Enabling monitoring on a Routing Point DN

1. Create an observing Routing Point DN where a monitoring strategy will be loaded—for example, 6000.
2. On the VoIP DN containing service-type=sip-cluster-nodes, set the ivr-observing-routing-point option to the Routing Point DN where a monitoring strategy is loaded. For example, ivr-observing-routing-point=6000.
3. Create a monitoring routing strategy. The routing strategy should check for each available supervisor from a list of supervisors provided by SIP Server and try routing to available supervisors until a call is successfully routed to one supervisor. If no supervisor is selected, the routing strategy should respond with TRouteCall (otherDN = <BLANK_VALUE>, RouteType = Reject). See a sample strategy.
4. Upload the strategy to the Routing Point DN 6000.
5. Configure URS instances in SIP Cluster by following guidelines in URS configuration.
6. Create an application that will apply a treatment of playing the IVR menu to a call.

Sample call flow: Monitoring session for one supervisor with scope=call and type=OneCall

1. A supervisor logs in to the WWE desktop on Extension DN 2000 using AgentID='supervisor@onecloud.net'.
2. From the WWE desktop, the supervisor sends a TMonitorNextCall request containing AttributeOtherDN = 5000, which means that Routing Point DN 5000 is the monitoring target. Monitoring is started with the scope call and type OneCall.
3. SIP Server creates a monitoring subscription and sends a confirmation to the desktop using EventMonitoringNextCall.
4. SIP Server starts a monitoring session when a new call arrives at one of the SIP Cluster nodes in the data center where the owner of the supervisor desktop resides.
5. SIP Server transforms the inbound call to a conference by adding the IVR observing Routing Point to the call. SIP Server generates EventQueued on DN 6000. This event contains the following key in the AttributeExtensions: 'Agents'='supervisor@onecloud.net'.
   • If a supervisor is not in a Ready state, URS distributes TRouteCall with the RouteReject type.
6. A routing strategy on DN 6000 routes the call to the supervisor by generating a TRouteCall request containing AttributeOtherDN = 2000.
7. SIP Server completes the conference and allows the supervisor to listen to how a caller is going through the IVR menu.
8. The supervisor desktop displays the monitoring information, such as the monitored DN number and its state.
9. The supervisor decides to continue monitoring the call even after the IVR stage is completed.
10. The call is routed to an agent.
11. The supervisor continues to monitor the call listening to how the agent talks to the caller.
12. SIP Server terminates the supervision subscription as the type was set to OneCall. The monitoring session won't be triggered for this supervisor when a new call arrives.

URS configuration

In this feature, SIP Server queues calls on two different Routing Points (a monitored Routing Point and an observing Routing Point specified in the ivr-observing-routing-point option) with the same ConnID at the same time. URS cannot run two strategies for the same call (the same ConnID) simultaneously. For this feature to work with URS, there must be one dedicated URS HA pair in each data center installed. This additional URS pair will monitor only the Routing Point that is configured in ivr-observing-routing-point. The other URS in the environment should not monitor the Routing Point specified in ivr-observing-routing-point. This new pair of URS instances must be connected to the routing Stat Server and to the default ports of all SIP Cluster nodes in this data center.

Complete the following configuration for URS applications to work with this feature:

• In the Annex tab of the Routing Point DN that is specified in the ivr-observing-routing-point option, create a section for each of the new URS applications (both primary and backup instances). In each section, add the event_arrive option and set it to routerequest. In addition, add another section with the name __ROUTER__. In that section, add the event_arrive option and set it to none. This is to make sure that an observing routing point is monitored by only the dedicated URS present in each data center.
• In the new URS applications, under the default section, set the event_arrive option to none.

Sample configuration for URS primary and backup instances

In this sample configuration, the following URS application names are used: URS_IVR_Monitoring_Prim and URS_IVR_Monitoring_Bkup.

(Click the picture to expand)

Routing strategy sample

Here is an example of a routing strategy to be loaded on the IVR observing Routing Point:

(Click the picture to expand)

The sample strategy contains a Multi Assign object. A comma-separated list of supervisor IDs is retrieved from the EventRouteRequest AttributeExtensions by the ExtensionData function. From the list of supervisors, the first supervisor is taken.

(Click the picture to expand)

If the value retrieved is not null, the strategy tries to route a call using a target selection block. If the call is routed to the supervisor successfully, the strategy is completed.

If the target selection block fails, the next supervisor ID is selected from the list and the routing is tried until a call is successfully routed.

(Click the picture to expand)

(Click the picture to expand)

(Click the picture to expand)

If no supervisor is available, the strategy rejects the call with the RouteReject type.

(Click the picture to expand)

Configuration option

The following configuration option is required to enable this functionality:

ivr-observing-routing-point
Default Value: No default value
Valid Values: The name of the Routing Point DN where a monitoring strategy is loaded
Changes Take Effect: Immediately

Specifies the name of the Routing Point DN where a monitoring strategy is loaded. This option is to be configured on the VoIP DN containing the service-type option set to sip-cluster-nodes.

External components configuration and dependencies

• For this feature, the agent-reservation option should be enabled by setting it either to true or implicit in the URS Application level in the default section.
• WWE should allow a supervisor to issue TMonitorNextCall for a Routing Point DN.

HA considerations

If a switchover occurs after a supervisor created a subscription for a Routing Point, a new Primary SIP Server maintains this subscription as active.

Feature limitations

• Only call scope is supported.
• Only silent supervision is supported. A supervisor can switch monitoring mode from mute to connect and vice versa only after a call is established with an agent. Switching to coach mode is not supported.
• Intrusion is not supported; that is, a monitoring session will not be started for the calls that are already staying in queue when a monitoring subscription is created.