In this section:

Related articles:


Use session recording 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:

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

Access to the Media Capture Tool is restricted to privileged, password-protected user accounts. Tracking of its use is tracked by AUD logging.

Note

The SBC can record all the calls in the system. The number of recording sessions depends on the available interface bandwidth.


Note

The SBC determines the SRS reachability through the SIP ARS status. You must configure the Path Check Profile to determine the reachability of the SRS peers and treat a failure response, such as 501, as an 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:

  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 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:

Behavior of the SBC when Call Trace is enabled and Call Recording is triggered.

Feature  Behavior of the SBC when Call Trace is enabled and Call Recording is triggered








LI  







IMS LI



TCP/UDP


Calling number target: Ingress leg is intercepted to LI server. Egress leg packet is captured in a .PKT file as Call Trace is enabled.
Called number target: Egress leg is intercepted to LI server. Ingress leg media streams are captured in a .PKT file as Call Trace is enabled.
Calling & Called number target: Both Ingress and Egress legs are intercepted to LI server. In this case, capturing of media packets to .PKT files does not take place even if Call Trace is enabled.



PCSI LI



TCP

LI request in INVITE: Ingress leg is intercepted to LI server. Egress leg packet is captured in a .PKT file as Call Trace is enabled.

LI request in 18x/200: Egress leg is intercepted to LI server. Ingress leg media streams are captured in a .PKT file as Call Trace is enabled.

LI request in re-INVITE:  For initial Invite, both legs are captured to a .PKT file as Call Trace is enabled. After re-INVITE, the media streams of the Ingress leg is intercepted to LI server. The Call Trace feature continues to capture the media stream of the Egress leg.
LI request in 200 OK for re-INVITE: Ingress leg is intercepted to LI server. The Call Trace feature continues to capture the media stream of the ingress leg.
P-DCS-LAES LI
UDPP-DCS-LAES header received in 18x: Media streams of the Egress leg are sent to the recorder. Media streams of the Ingress leg are captured in .PKT files as the state of Call Trace is enabled.








NICE/SIPREC









NICE

Request to record Ingress leg: Media streams of Ingress leg are sent to NICE server. Media streams of Egress leg are captured in .PKT files as Call Trace is enabled.

Request to record Egress leg: Media streams of Egress leg are sent to NICE server. Media streams of Ingress leg are captured in .PKT files as Call Trace is enabled.

Request to record both legs: Media streams of both Ingress and Egress leg are sent to NICE server.  In this case, capturing of media packets in a .PKT file does not occur if Call Trace is enabled.




SIPREC



PSX TRIGGER to record Ingress leg: Media streams of Ingress leg are sent to SIPREC server. Media streams of Egress leg are captured in .PKT files as Call Trace is enabled.

PSX TRIGGER to record Egress leg: Media streams of Egress leg are sent to SIPREC server. Media streams of Ingress leg are captured in .PKT files as Call Trace is enabled.

CLI trigger to record Ingress leg: Unless a CLI trigger is received, media of both Ingress and Egress legs are captured in .PKT file. Once a SIPREC CLI trigger is received for the Ingress leg, media streams of the Ingress leg are sent to SIPREC server. Egress leg continues to be captured in .PKT files.

CLI trigger to record Egress leg: Unless a CLI trigger is received, media of both Ingress and Egress legs are captured in .PKT files. Once a SIPREC CLI trigger is received for Egress leg, media streams of Egress leg are sent to SIPREC server. Ingress leg continues to be captured in .PKT files.



MCT

PSX TRIGGER to record Ingress leg: MCT captures media on the Ingress leg using MCAST. Packet Capture will capture media on both the legs using Splitter.

PSX TRIGGER to record Egress leg: MCT captures media on the Egress leg using MCAST. Packet Capture will capture media on both the legs using Splitter.

PSX TRIGGER to record both legs: MCT captures media on both the legs using MCAST. Packet Capture will capture media on both the legs using Splitter.
Note

MCT 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:

  1. 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.
  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, 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.

Note

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:

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


Note
  • 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 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 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.
Note

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.

  1. 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 the recorder flag is disabled.

  2. 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).

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



  • No labels