Service supervision during IVR phase

[FDS: https://intranet.genesys.com/display/RDSIPS/%5BFDS%5D+IVR+Supervision+in+SIP+Cluster]

New functionality in SIP Cluster deployment allows to start service observing while calls are in the IVR phase where different kind of treatments can be played to callers.

Supported features

An IVR supervision session can be initiated by a T-Library client such as WWE connected to SIP Cluster T-Controller by issuing a TMonitorNextCall request. The request must contain:

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

Monitoring session will be started only for the calls arrived on the monitored RP in SIP cluster nodes which are present in same data center (geo-location) as supervisor owner node.

Cross Data center supervision is not supported - Monitoring session will not be started if call arrives to the other data center where supervisor owner node is present.

Intrusion not supported - Monitoring session will not be started for the calls which are already staying in queue when monitoring subscription is created.

A monitoring session can be canceled by a T-Library client such as WWE connected to SIP Cluster T-Controller by issuing a TCancelMonitoring request. One supervisor can monitor only one routing point or an agent.

Monitoring sessions for multiple observers on the same RP DN

Multiple observers can monitor the same RP. Only one supervisor is allowed per call. If two observers monitor the same RP, for the first call on the monitored RP SIP Server adds both the supervisor information in the extensions generated on IVR observing routing point. Strategy tries each supervisor until call is routed to one supervisor successfully. For second call on the monitored RP, supervisor which is not selected for the first call is added. Each SIP Cluster node in the DC where supervision is activated maintains a queue of supervisors who are waiting to monitor call on a RP DN. Each call arriving to this RP is given with the list of available supervisors and strategy routes the call to the first available call. If one supervisor fails to join the call, then that supervisor is moved to the end of the line.

IVR Supervision Design

The monitoring session will be controlled by the TController which owns the supervisor DN. The TController when receives TMonitorNextCall or TCancelMonitoring requests from the supervisor client will forward the request to T-Controller that owns supervisor DN.

ivr-observing-routing-point is to be configured on the VoIP DN of service type 'sip-cluster-nodes'.
All URS instances in SIP Cluster have the same strategy loaded for the ivr-observing-routing-point which is described in next section.
Supervisor TController creates supervision session and forwards TMonitorNextCall to all local TControllers which has the same geo-location configured as the supervisor TController.
Each SC is registering the request and creates an internal queue subscription.
On receiving successful response from any one session controller, supervisor TController will send EventMonitoringNextCall to supervisor desktop which submitted the request
As soon as call arrives to the monitored RP on one of the SC this SC triggers supervision for the call by creating an internal SingleStepConference request to ivr-observing-routing-point with supervisor details in the context.
Subscription gets canceled by TCancelMonitoring which TC-owner distributes to all SC's. If MonitorScope is OneCall, then TC-owner distributes TCancelMonitoring to all SC's as soon as supervisor is invited to monitor the first call.
Switching between supervision mode from silent to connect and vice versa will be allowed only after call is routed from monitored routing point to an agent. TSetMuteOff and TSetMuteOn will be first forwarded to the TController which owns the supervisor DN. Supervisor TController forwards it to TController of SIP Cluster Node that owns the supervision call. TController forward the request to local Session Controller where supervision call is progress. Session Controller processes the request and sends the response back to TController.

The following section explains about the steps for feature provisioning and how monitoring session will be established.

Feature Provisioning

Customers need to enable monitoring of the RP DN 5000.

Configure the following parameter on RP DN 5000.
Create RP DN 6000. This DN is used to run the monitoring strategy.
Create a monitoring routing strategy. Sample strategy is explained in next section.
- Routing strategy should check for each available observer from the list of observers provided by SIP Server and try routing to the available observers until call is successfully routed to either one observer.

If no observer can be selected, then routing strategy should respond with TRouteCall(otherDN = <BLANK_VALUE>, RouteType = Reject).

Upload strategy to the RP DN 6000.

Monitoring session for one observer with scope = call and type = OneCall

Observer logs in to the WWE desktop on Extension DN 2000 using AgentID = 'supervisor@onecloud.net'
Observer uses WWE desktop to send a TMonitorNextCall request with AttributeOtherDN set to 5000 which means that RP DN 5000 is the monitoring target. Monitoring is started with scope call and type OneCall.
SIP Server creates a monitoring subscription and sends a confirmation to the desktop using EventMonitoringNextCall.
SIP Server starts monitoring session when a new call arrives to one of the SIP Cluster nodes in the Data Center where owner of the observer's desktop resides to.
SIP Server transforms inbound call to a conference by adding IVR observing RP to the call. SIP Server generates EventQueued on a RP DN 6000. This event contains the following key in the AttrExtensions: 'Agents'='supervisor@onecloud.net'
- If supervisor is not in a Ready state, then URS will issue TRouteCall with reject type.
Routing strategy on the RP DN 6000 routes the call to the observer by generating TRouteCall request with AttrOtherDN = 2000.
SIP Server completes the conference and allows the observer to listen how caller is going through the IVR menu.
Observer desktop displays the monitoring information such as monitored DN number and its state
Observer decides to continue monitoring the call even after the IVR stage is completed.
Call is routed to an agent.
Observer continues to monitor the call listening how agents talks to the caller.
SIP Server terminates the supervision subscription as the type was set to OneCall. Monitoring session won't be triggered for this observer when new call arrives.

URS configuration and deployment procedure

By this feature, SIP Server will queue calls on two different RP (monitored RP, ivr-observing-routing-point) with same ConnID at the same time. As per current URS design, it cannot run for the same call (the same connid) 2 strategies simultaneously. In such situation then URS, based on its configuration options will drop one strategy and will execute only one. So to have this feature work with URS, we need to have one dedicated URS HA pair in each DC to be installed. This additional URS will monitor only the RP which is configured as ivr-observing-routing-point and not other RP's configured in the cluster switch. The other URS in the environment should not monitor the RP which is configured as ivr-observing-routing-point. This new pair of URS must be connected to the routing Stat Server and to the default ports of all SIP Cluster nodes in this DC.

Following configuration should be done on RP DN's. For easy understanding, configuration is explained with sample names.

In the annex section of RP DN (which is configured as ivr-observing-routing-point), create a section for each of the new URS applications (both primary and backup instances) added in all data center. In each section, add a new option 'event_arrive' = 'routerequest'. Also another section with name __ROUTER__ to added with option 'event_arrive' = 'none'. This is to make sure that observing routing point is monitored by only the dedicated URS present in each data center.
In the application level option of new URS instances, under default section set option 'event_arrive' = 'none'.

Sample configuration attached below with new URS application names added as URS_IVR_Monitoring_Prim, URS_IVR_Monitoring_Bkup:

Routing strategy design sample

This section provides a routing strategy design sample, which should be loaded on the IVR observing Routing Point.

The sample strategy first has a Multi Assign object. The list of supervisor's agentID separated by comma are retrieved from the EventRouteRequest extensions by the ExtensionData function. From the list of supervisors, first supervisor is taken.

If the value retrieved is not null, then using target selection block, strategy tries to route the call. If the call is routed to the supervisor successfully then strategy is completed. If the target selection block fails, then next supervisor agentID is selected from the list and the routing is tried until a call is successfully routed.

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

Configuration

Configuration Options

The following configuration is required to enable new functionality:

ivr-observing-routing-point = <RP_WITH_MONITORING_STRATEGY>

Option Name ivr-observing-routing-point Default Value no default value Valid Values Name of the RP DN where monitoring strategy is loaded Changes take effect Immediately Description Name of the Routing Point DN where monitoring strategy is loaded This option is to be configured on the VoIP DN of service-type 'sip-cluster-nodes'

External components configuration and dependencies

For this feature, option agent-reservation should be enabled by setting it either to true or implicit on URS application level option. WWE/GWS should be enhanced to allow supervisor issue TMonitorNextCall for RP DN.

HA Considerations

If switchover occurs after supervisor created a subscription for RP, then new Primary maintains this subscription active.

Limits and Constraints

Only call scope is supported.
Only silent supervision is supported. Supervisor can switch monitoring mode from mute to connect and connect to mute only after call is established with an agent. Switching to coach mode is not supported.
Intrusion is not supported i.e. Monitoring session will not be started for the calls which are already staying in queue when monitoring subscription is created.
Though IVR supervision can work for all type of calls, as customer requirement is only for inbound calls we will be testing only inbound calls in the scope of this feature.
In case of split brain scenario, when supervisor DN is owned by two nodes which are disconnected, then if two calls are landed on monitored RP on two disconnected nodes it might result in SIP Server sending two calls to the same supervisor. It is expected that WWE/GWS would handle such scenario in a better way by rejecting the second call.

Contents