Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Add_workflow_for_techpubs
AUTH1
REV5
REV6
REV3
REV1
REV2

Session recordings are used for various purposes such as complying with regulations, monitoring quality of service of representatives, and storing call information for quality analysis.

The SIPREC protocol defines the interaction between a Session Recording Client (SRC) and a Session Recording Server (SRS), and controls the recording of media transmitted in the context of a communications session (CS) between multiple user agents.

The 

Spacevars
0series4
supports the following SIP recording interfaces:

  • SIPREC SIP-based session recording
  • Call monitoring MCT
  • NICE session recording
  • UDP/TCP towards the recording server
  • SIPREC over TLS

Include Page
NICE_vs_MediaPacketCapture
NICE_vs_MediaPacketCapture

Multiexcerpt include
MultiExcerptNameRecording Limit
PageWithExcerptSession Recording Support

Caption
0Table
1Supported ieft-draft Versions
 Category ieft-draft Version
Media Recording Architecturedraft-ietf-siprec-architecture-06
Protocoldraft-ietf-siprec-protocol-06
Recording Metadata

Fixed version of draft-ietf-siprec-metadata-07

The overall 

Spacevars
0series4
SIPREC strategy is depicted in the following diagram (this example uses SBC 5000 series platform):

Caption
0Figure
1SBC SIP Recording Strategy
3SBC SIP Recording Strategy

The 

Spacevars
0product
can act as a SRC and an RTP translator. As an SRC, the 
Spacevars
0product
initiates SIP recording session (RS) towards SRS with metadata. Unlike NICE, it is the responsibility of the
Spacevars
0product
 to determine if a call requires recording.

Info
titleNote
  • The SBC supports transmitting only the signaling data to the SRS over TCP.
  • LSWU is supported for SIPREC SIP-based session recording from 5.1.1 version on-wards.

In the SBC SIP Recording Strategy figure, the basic call is established between SIP phone 1 and SIP phone 2 through the

Spacevars
0product
and called as communication session (CS). The
Spacevars
0product
 establishes a RS based on CS towards SRS. The 
Spacevars
0product
and SRS may exist in the same or different administrative domains. Each 
Spacevars
0product
RS is mapped to a single call (communication session), and the communication session is based on called or calling party number.

The two methods to trigger a call recording are:

  • A call matches call recording criteria causing the PSX Policy Server to trigger the
    Spacevars
    0product
    to record the call.
  • Initiate recording via CLI using GCID.

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
  • GATEWAY

The PSX/ERE uses the following configurable objects when determining whether a call needs to be recorded:

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

Include Page
Recordertype_recordingtype
Recordertype_recordingtype

Supported SIPREC features include:

  • Recording RTP session for a call by providing its GCID via CLI. The user provides the IP Address/port for the corresponding session recorder via the same CLI command.

  • Listing the calls currently being recorded using a CLI command. The

    Spacevars
    0product
     displays their GCID, and the RTP destinations and the SRS IP address.

  • Record any type of call leg (SIP, SIP-I ) by specifying the call to be recorded via CLI.

  • The called and calling party numbers in the recording criteria may be configured as a prefix.

  • PSX support provisioning 128 Recording criteria and 128 Recorder profiles.

    • You can provision up to 256 SRS Group Profiles.
    • You can provision up to 256 SRS Cluster Profiles.
    • You can set up 128 Call Recording Criteria.
  • Sending and receiving “+sip.src” feature tag extension in the Contact URI

  • Options Tag “siprec” in INVITE towards SRS.

  • Sending and receiving the rs-call specific data in the rs-metadata XML body

  • If a INVITE is received from a SRS or UE with a options tag “require: siprec”, the

    Spacevars
    0product
     rejects the request with a 4xx message.

  • Transparently passing the SIPREC specific feature tags from the UE to the registrar.

  • If the original call uses any codecs other than the above, it is assumed that the SRS will terminate the RS. So SRC continues operating the CS and RS until this happens.

  • The

    Spacevars
    0product
     transparently duplicates the packets coming/going to the UE towards the SRS using the same Codec as the Original stream.

  • If any request except session keepalive Re-INVITE/UPDATE or BYE is received in the context of a RS, the

    Spacevars
    0product
     rejects the request with a 405 "Method Not Allowed" message.

  • If Options PING mechanism is configured on the IP peer, it is used as a keep-alive mechanism for all the RSs.

  • Stop recording a call in one of three ways:
    • Providing GCID via CLI
    • Via normal CS Sessions disconnect
    • Receiving Bye from SRS
  • Troubleshooting a SIPREC recorded call using MCT is only possible when initiated via CLI. 

  • The SBC supports SIPREC on the multiple recorders based on the Internet Engineering Task Force (IETF) standard.The SBC acts as an SRC and a Real-time Transport Protocol (RTP) to initiate SIP RS on the SRS(s).

    • Once the recording criteria are met, the SBC receives SRS IP group along with the number of streams (one or two) from the ERE.
    • The SRS IP group contains a maximum of eight SRS IP addresses along with the Trunk Group and the transport information, which the ERE sends (either round-robin or sequential).
    • The SBC decides the type of INVITE message to be sent to SRS based on:
      • If the value of the parameter for numOfStreams received is 1, the SBC sends the INVITE to the first reachable SRS IP address and uses the rest of the IP addresses for SRS redundancy.
      • If the value received is 2, the SBC sends the Fork INVITE to the first two reachable SRS IP addresses.
    • Once the SRS IP sends the response, the SBC starts streaming media towards the SRS.

Refer to NICE Session Recording for the list of supported codecs.

Info
titleNote

The SIPREC feature is controlled by a system-wide

Spacevars
0product
license (
Spacevars
0product
-SIPREC). If the license is not available, any SIPREC recording returned by a PSX is ignored.

To enable/disable SIPREC feature, use following syntax:

Code Block
languagenone
% set addressContext <ADDRESS-CONTEXT> zone <ZONE> sipSigPort <SIP SIGNALLING PORT> siprec <disabled|enabled>

To start/stop a recording, the following CLI syntax applies:

Code Block
languagenone
% request global sipRec startRecord gcid <GCID> callLeg ingress numOfStreams <Number of recorders  1 or 2> srsIpAddress <SRS IP ADDRESS> srsPort <SRS PORT> transport <tcp | udp> trunkGroup <TRUNK GROUP NAME> srsIpAddress2 <SRS IP ADDRESS> srsPort2 <SRS Port> transport2 <tcp | udp> trunkGroup2 <SIP Trunk Group> 
% request global sipRec stopRecord gcid <GCID> recorderAddress <IP Address> recorderPort <Port Number>
Info
titleNote

If only the GCID value is mentioned in the stopRecord, all the multiple recordings for that GCID are stopped at once.

To view SIPREC status, use CLI syntax:

Code Block
languagenone
> show table global SipRecStatus
       RECORDER           RX RTP            TX RTP            RECORDING  
GCID   ADDRESS            ADDRESS           ADDRESS           LEG
1      10.11.12.13:5060   10.11.12.13:8000  10.11.12.13:8002  ingress

Refer to Zone - SIP Sig Port - CLI and Request Global - CLI pages for CLI command details.

Simultaneous Session Recording - SIP Ingress and Egress Legs

The SBC is enhanced to support simultaneously recording SIP egress and ingress legs during a session, for a total of four recordings (four simultaneous streams: two in the ingress leg, and two in the egress leg). The following are unique recording servers identified by different IP ports:

  • Primary SRS
  • Secondary SRS
  • Biometric
  • Analytics

The SBC provisions the SIPR recordings towards all 4 recorders, two from Ingress tap point and another two from egress tap point. (Due to NP limitations, four simultaneous recordings cannot be triggered on the same call leg.)

Basic Quad SIPREC

Below is a diagram illustrating the use case of Quad SIPREC, with first two recordings on Ingres call-leg, and the next 2 recordings on egress call-leg.

Caption
0Figure
1Basic Quad SIPREC

 

For more information on parameter configurations and CDR field descriptions refer to:

CLI and EMA:

Alarms:

CDR: