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 supervisor 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 supervisors in the extensions generated on IVR observing the Routing Point. The strategy tries each supervisor until a call is routed to one supervisor 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.

How it works

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 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 ivr-observing-routing-point.
• Supervisor T-Controller creates a supervision session and forwards TMonitorNextCall to all local T-Controllers that contains the same geo-location configured as the supervisor T-Controller.
• Each Session Controller (SC) registers the request and creates an internal queue subscription.
• On receiving successful response from any SC, the supervisor T-Controller sends EventMonitoringNextCall to a supervisor 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 ivr-observing-routing-point with supervisor details in the context.
• Subscription is canceled by TCancelMonitoring which TC-owner distributes to all SCs. If MonitorScope is OneCall, TC-owner distributes TCancelMonitoring to all SCs as soon as a supervisor 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 TController which owns the supervisor 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 the Routing Point DN

To enable monitoring on the Routing Point DN:

1. Configure the following parameter on RP DN 5000.???
2. Create Routing Point DN 6000. This DN will be used to run a monitoring strategy.
3. Create a monitoring routing strategy. The routing strategy should check for each available observer from a list of observers provided by SIP Server and try routing to available observers until a call is successfully routed to one observer. If no observer can be selected, the routing strategy should respond with TRouteCall(otherDN = <BLANK_VALUE>, RouteType = Reject). See a sample strategy.
4. Upload the strategy to Routing Point DN 6000.

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

1. An observer logs in to the WWE desktop on Extension DN 2000 using AgentID='supervisor@onecloud.net'.
2. From the WWE desktop, the observer 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.
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 to one of the SIP Cluster nodes in the data center where the owner of the observer's 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 reject type.
6. A routing strategy on DN 6000 routes the call to the observer by generating a TRouteCall request with AttributeOtherDN = 2000.
7. SIP Server completes the conference and allows the observer to listen to how a caller is going through the IVR menu.
8. The observer desktop displays the monitoring information, such as the monitored DN number and its state.
9. The observer decides to continue monitoring the call even after the IVR stage is completed.
10. The call is routed to an agent.
11. The observer continues to monitor the call listening to how agents 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 observer when a new call arrives.

URS configuration and deployment procedure

For this feature, SIP Server will queue 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. As per current URS design, it 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.

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.