Service supervision during IVR phase

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

In a SIP Cluster deployment, calls can be observed while in the IVR phase where different kind of treatments can be played.

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 once started will be continued until 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 the calls arrived on the monitored Routing Point in SIP Cluster nodes which are present in 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 to 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 connected to the 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 Routing Point

Multiple observers can monitor the same Routing Point. However, only one observer is allowed per call. If two observers monitor the same Routing Point, for the first call on the monitored Routing Point SIP Server adds information of both observers in AttributeExtensions generated on IVR observing the Routing Point. The strategy tries each observer until a call is routed to one of them successfully. For a 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 to 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.

IVR Supervision Design (do we need this section?)

The monitoring session is controlled by the T-Controller which owns the supervisor DN. When the T-Controller receives TMonitorNextCall or TCancelMonitoring requests from a supervisor, it forwards the request to the T-Controller that owns the supervisor DN.

ivr-observing-routing-point is configured on the VoIP DN containing service-type=sip-cluster-nodes.
All URS instances in SIP Cluster have the same strategy loaded at a Routing Point specified in ivr-observing-routing-point.
Supervisor T-Controller (?) creates a supervision session and forwards TMonitorNextCall to all local T-Controllers that have the same geo-location configured as the supervisor T-Controller.
Each Session Controller (SC) registers the request and creates an internal queue subscription.
On a receiving successful response from any SC, the supervisor T-Controller sends EventMonitoringNextCall to a observer desktop which submitted the request.
As soon as a call arrives to the monitored Routing Point on one of the SC, this SC triggers supervision for the call by creating an internal SingleStepConference request to a Routing Point specified in ivr-observing-routing-point containing the observer details.
Subscription is canceled by TCancelMonitoring which a TC owner distributes to all SCs. If MonitorScope is OneCall, the TC owner distributes TCancelMonitoring to all SCs as soon as an observer is invited to monitor the first call.
Switching between supervision modes from silent to connect and vice versa is allowed only after a call is routed from the monitored Routing Point to an agent. TSetMuteOff and TSetMuteOn will be first forwarded to the T-Controller which owns the observer DN. Supervisor T-Controller forwards it to T-Controller of the SIP Cluster Node that owns the supervision call. T-Controller forwards the request to a local SC where a supervision call is progress. The SC processes the request and sends the response back to T-Controller.

Enabling monitoring on a Routing Point DN

On the VoIP DN containing service-type=sip-cluster-nodes, configure the ivr-observing-routing-point option to point to a Routing Point DN where a monitoring strategy is loaded. For example, ivr-observing-routing-point=6000.
Create a Routing Point DN where a monitoring strategy is loaded; for example, 6000.
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.
Upload the strategy to Routing Point DN 6000.
Configure URS instances in SIP Cluster by following guidelines in URS configuration points.
[How do we configure 5000?]

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

A supervisor logs in to the WWE desktop on Extension DN 2000 using AgentID='supervisor@onecloud.net'.
From the WWE desktop, the supervisor sends a TMonitorNextCall request containing AttributeOtherDN set to 5000, which means that Routing Point DN 5000 is the monitoring target. Monitoring is started with the scope call and type OneCall.
SIP Server creates a monitoring subscription and sends a confirmation to the desktop using EventMonitoringNextCall.
SIP Server starts a monitoring session when a new call arrives to one of the SIP Cluster nodes in the data center where the owner of the supervisor's desktop resides.
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 Reject type.
A routing strategy on DN 6000 routes the call to the supervisor by generating a TRouteCall request containing AttributeOtherDN = 2000.
SIP Server completes the conference and allows the supervisor to listen to how a caller is going through the IVR menu.
The supervisor desktop displays the monitoring information, such as the monitored DN number and its state.
The supervisor decides to continue monitoring the call even after the IVR stage is completed.
The call is routed to an agent.
The supervisor continues to monitor the call listening to how agents talks to the caller.
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 points

For this feature, SIP Server queues calls on two different Routing Point (a monitored Routing Point and a Routing Point specified in ivr-observing-routing-point) 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 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.

In the Annex section of the 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 centers. In each section, add the event_arrive option set to routerequest. In addition, add another section with the name __ROUTER__. In that section, add the event_arrive options set 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 Application-level option of new URS instances, under the default section, set the event_arrive option to none.

Sample configuration for URS primary and and backup instances with application names: URS_IVR_Monitoring_Prim and URS_IVR_Monitoring_Bkup

Routing strategy sample

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

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.

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 then 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.

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

Configuration Option

The following configuration 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 on the URS application level option.
WWE should allow a supervisor to issue TMonitorNextCall for a Routing Point DN.

HA Considerations

If a switchover occurs after a supervisor is created a subscription for a Routing Point, a new Primary maintains this subscription 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.

Contents