In this section:
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 SBC Core supports the following proprietary SIP recording interfaces: Access to the Media Capture Tool is restricted to privileged, password-protected user accounts. Tracking of its use is tracked by AUD logging. The SBC can record all the calls in the system. The number of recording sessions depends on the available interface bandwidth.
From 6.2.0 release onward, the SBC determines the SRS reachability only through the SIP ARS status. The pathCheckProfile
must be configured to determine the reachability of the SRS peers and treat failure response such as 501 as OPTIONS failure.
When considering which combinations of NICE recording, MCT, Lawful Intercept (LI), Call Trace and SIPREC are supported. The order of priority is the following:
- Lawful Intercept
- Other recording (NICE, Veriant or SIPREC)
- MCT
- 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 SBC.
- 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) and rejected by SBC 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, the 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 stops when any of the other features are being used.
- When Call Trace with the filter Media Capture is enabled, it captures the media packets into .
PKT
files for both Ingress and Egress legs. - Features like LI, SIPREC, and NICE can be triggered after the call is established and Call Trace starts capturing packets for both Ingress and Egress legs. In this case, the requested leg for higher priority Call Recording feature is intercepted/recorded, and other legs are captured in .
PKT
file. Once the higher priority Call Recording ends for the call, the SBC does not go back to Call Recording of lower priority for the same call.
When the Call Trace feature is enabled and any of the recording features are triggered, the behavior of the SBC is as shown in the table below:
NoteMCT uses MCAST when Splitter is used by another recorder.
SBC Configuration
SIPREC configuration is based on the current MCT configuration available in the PSX using the same Recording Criteria and Recorder profiles to control which calls are to be recorded.
The SBC identifies when a call needs to be recorded using following methods:
- Perform a PSX query to determine whether the call needs to be recorded based on preconfigured criteria. If so, the query result includes the type of recording along with the Recorder (SRS) information.
- 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, The SBC initiates a Recording Session towards the SRS with an INVITE request to the SRS IP address/port pair as configured in the PSX for the corresponding recordable object (this information is received in the Policy Response).
If configured to record transcoded calls only, the SBC sends INVITE request after it is determined that the call needs to be transcoded.
SIPREC is a licensed feature.
PSX Configuration
The PSX determines the necessity of recording a call 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, the PSX hosts the objects to determine the necessity of recording a call based on information provided by following objects:
- "Recording Entity" object containing recording criterion information
- "Recorder" object describing the recorder to use for a particular Recording Entity
The need to record a call is 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 the need to record a call (see figure Recording Entity and Recorder Objects below):
- Recording Entity—contains information about recording criterion
- Recorder—contains information about the recorder to use for a particular Recording Entity.
- If there is more than one SRS associated with the SRS Cluster, the SBC records on both the legs (Ingress and Egress). The first two recordings are on Ingress leg and the rest on Egress.
- For Quad SIPREC, there are four recordings triggered. Two recordings are triggered on the Ingress leg and two on the Egress leg.
- If there is more than one SRS Group configured, it is recommended to set
recordingType
to "both legs" or "all legs". - When SIPREC is selected as the Recorder Type, and Recording Type is selected as “both legs” and “all legs”, the SBC by default records the ingress leg.
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 Ribbon 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 are recorded. If all legs are to be recorded and "dtg" parameter is used, all four legs are used if next-hop is a Ribbon 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.
Older versions of the SBC may not support SIPREC feature. Before you begin configuring for SIPREC, check the CRC screen to ensure it includes SBC name and Recorder type (this check is not possible at the configuration time).
Basic Configuration Steps
The following are needed to configure SBC for SIPREC support.
Enable
siprec
flag on Signaling Port towards the SRS server to support SIPREC SIP extensions. (For CLI command details, refer to Zone - SIP Sig Port - CLI.When the
siprec
flag is enabled, ensure therecorder
flag is disabled.Start/stop a SIPREC recording for a particular call that is active using
request global sipRec startRecord
/stopRecord
commands (refer to Request Global - CLI for details).View SIPRREC status using
show table global sipRecStatus
command.