Session Recording Support

Session recording is used for various purposes such as complying with regulation, monitoring quality of service of representatives as well as storing call information for quality analysis.

The

• SIPREC SIP-based session recording
• Call monitoring MCT
• NICE session recording

When considering which combinations of NICE recording, MCT, Lawful Intercept (LI), Call Trace and SIPREC are supported. the Priority order is the following:

1. Lawful Intercept
2. Other recording (NICE, Veriant or SIPREC)
3. MCT
4. Call-media-trace

The following conditions apply to the above features:

• LI and SIPREC can be used simultaneously on a call if LI is using MCAST. However, if LI uses Splitter, SIPREC config is ignored by the
  Unable to show "metadata-from": No such page "_space_variables"
  .
• Old NICE and SIPREC recordings cannot co-exist because both use Splitter. If SIPREC recording is in progress, NICE INVITE generally comes late (after the call is answered), thus will get rejected by
  Unable to show "metadata-from": No such page "_space_variables"
  if other is present.
• MCT and SIPREC use the same trigger logic from PSX. PSX returns the recorder profile of the best matched criteria. When matching criteria, SIPREC is given the highest score. So if both SIPREC and MCT are configured, PSX returns the recorder profile of SIPREC. So, if a SIPREC call has to be debugged, MCT has to be triggered by CLI using GCID and in this case MCT uses MCAST.
• Call trace with Packet capture feature will stop when any of the other features are being used.

SBC Configuration

SIPREC configuration is based on the current MCT configuration available in PSX/ePSX using the same Recording Criteria and Recorder profiles to control which calls are to be recorded.

The

1. Perform a PSX/ePSX query to determine whether the call needs to be recorded based on preconfigured criteria. If so, the query result will include the type of recording along with the Recorder (SRS) information.
2. From CLI. In this scenario, a stable call exists and operator provides the GCID of the call to be recorded.

The distinction between MCT and SIPREC is made based on the Recorder-Type field returned in the DS query response.

If a call is classified to be recorded by the PSX/ePSX, SBC initiates a Recording Session towards the SRS with an INVITE request to the SRS IP address/port pair as configured in the PSX/ePSX for the corresponding recordable object (this information is received in the Policy Response).

If configured to record transcoded calls only, the

ePSX/PSX Configuration

The ePSX/PSX determines whether a call needs to be recorded based on the following criteria (in the given order of priority):

• Recorder type
  • SIPREC – more priority
  • MCT
• Next hop signaling IP address
• Previous hop signaling IP address
• Calling Party Number
• Called Party number
• Ingress TG ID
• Egress TG ID
• GSX name

As supported for MCT, ePSX/PSX hosts the objects to determine whether a call needs to be recorded based on information provided by following objects:

1. "Recording Entity" object containing recording criterion information
2. "Recorder" object describing the recorder to use for a particular Recording Entity

The need to record a call can be decided from the PSX based on the following criteria in the given order of priority:

• Recorder type
  • SIPREC
  • MCT
• Next hop signaling IP address
• Previous hop signaling IP address
• Calling Party Number
• Called Party number
• Ingress TG ID
• Egress TG ID
• GSX name

The PSX uses the following configurable objects to determine whether a call needs to be recorded (see Figure 1):

• Recording Entity—contains information about recording criterion
• Recorder—contains information about the recorder to use for a particular Recording Entity.

Recording Entity and Recorder Objects

Recording Entity Objects:

• "Recorder Name" is the name of the recorder entry to be used for recording sessions associated with this recording entity.
• "Recording Start Criterion" determines what condition would trigger a call to be recorded.
• Recorder Type : MCT or SIPREC. Indicates whether the recorder supports Sonus Proprietary MCT interface or SIPREC specification. Default MCT
• "Recording Type" specifies which legs of a call need to be recorded. Ingress leg is recorded before transcoding. Egress leg is recorded after transcoding. All legs may be recorded unconditionally or only if transcoding is performed. If all legs are to be recorded and if GW-GW protocol is used between two SBCs, all four legs will be recorded. If all legs are to be recorded and "dtg" parameter is used, all four legs will be used if next-hop is a Sonus SBC.
  • For the SIPREC case, Recording-type is not significant as both participants’ info and streams from both are sent to the SRS. It shall be documented for the SIPREC application, the Recording-type to Ingress/Egress for all other values, it is assumed to be ingress.
• "Recording Stop Criterion" specifies when recording entity should not cause any new recordings anymore. With "manual" option, all calls meeting the criterion are recorded. If "number of calls" is specified, a call meeting the criterion won't be recorded if the number of already recorded calls reached that number.
  • When SIPREC is used, this shall be set as “manual” to allow all the calls to be recorded.
• "Status" allows to enable/disable a recording entity.

Basic Configuration Steps

The following are needed to configure

1. Enable "sipRec" flag on Signaling Port towards the SRS server to support SIPREC SIP extensions. (For CLI command details, see zone sipSigPort - CLI.

   When sipRec flag is enabled, the recorder flag must be disabled.

2. Start/stop a SIPREC recording for a particular call that is active using request global sipRec startRecord / stopRecord commands (see request global for details).

3. View SIPRec status using show table global sipRecStatus command.