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 recording session (RS) is established over SIP from the SRC to the SRS.

The SBC Core supports SIPREC towards multiple recorders based on the Internet Engineering Task Force (IETF) standard. The SBC acts as an SRC sending recording sessions to a third-party SRS when a configured recording-criteria is met, or when a specific recording is initiated through CLI/EMA using the appropriate global call identifier (GCID).

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.

SIPREC is not supported on an SBC configured to Signaling Only mode.

Note

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

Table 1: Supported RFCs

 CategoryRFCs
Use Cases and Requirements for SIP-Based Media Recording (SIPREC)RFC 6341
Media Recording ArchitectureRFC 7245
 Session Initiation Protocol (SIP) Recording MetadataRFC 7865
Session Recording Protocol

RFC 7866

Session Initiation Protocol (SIP) Recording Call FlowsRFC 8068

In the following figure, a basic call is established between SIP phone 1 and SIP phone 2 through the SBC, which is referred to as a communication session (CS). The SBC establishes an RS, based on the CS, towards the SRS. The SBC and SRS may exist in the same or different administrative domains. 

Figure 1: SBC SIP Recording Strategy


Configuring SIPREC Based Recording

The two methods to trigger a call recording are:

  • A call matches call recording criteria causing the Policy Server to trigger the SBC to record the call.
  • Initiate recording of a specific call using CLI/EMA and specifying the appropriate GCID.

PSX Configuration

The recording-criteria determine which sessions to record and target SRS information, along with other operational options.

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

  • Recording Criteria—contain the rules to match for invoking call recording (this is same for SIPREC and MCT).
  • Recorder Profile—contains information about the recorder to use for a particular Recording Entity (obsolete—used in older versions when SRS redundancy is not supported).
    • Transport
    • IP V4/V6 address and port
    • Contains
  • SRS Groups—contains multiple Recording profiles for SRS redundancy (up to 8).
    • Transport
    • IP V4/V6 address port
    • Encryption data (for SRTP)  
    • IP TG to be used by the SBC for RS session
    • Contains data of multiple SRS servers
  • Recording Cluster profile—contains multiple SRS Groups for simultaneous recording (up to 4).
Note

The PSX/ERE supports provisioning 1,024 Recording criteria , 256 SRS Group Profiles and 256 SRS Cluster Profiles.  

Recording Criteria

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

For detailed configuration information, refer to the section Deploying SBC For SIPREC.

CLI Triggers

You can initiated a recording session for a specific call by providing its GCID through a CLI "request" command. In the command you provide other details for the recording such as the IP address/port or FQDN/port for the corresponding session recorder. Refer to Request Global - CLI for more information. 

To enable/disable the SIPREC feature on a zone, use following syntax:

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

Refer to Zone - SIP Sig Port - CLI for more information.

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

% request global siprec startRecord gcid <GCID> callLeg ingress numOfStreams <Number of recorders  1 or 2> srsIpAddress <SRS IP ADDRESS> srsFqdn1 <FQDN> srsPort <SRS PORT> transport <tcp | udp> trunkGroup <TRUNK GROUP NAME> srsIpAddress2 <SRS IP ADDRESS> srsFqdn2 <secondary FQDN> srsPort2 <SRS Port> transport2 <tcp | udp> trunkGroup2 <SIP Trunk Group> 

% request global siprec stopRecord gcid <GCID> recorderAddress <IP Address> recorderFqdn <FQDN> recorderPort <Port Number> recorderId <recording session ID>
Note

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

Through CLI you can also list information on the calls currently being recorded such as the GCID, RTP addresses and the SRS IP address or FQDN.  To view SIPREC status, use  the following CLI syntax:

> show table global SipRecStatus                
       RECORDER          RECORDING  RX RTP           TX RTP           RECORDER  RECORDER
GCID   ADDRESS           LEG        ADDRESS          ADDRESS          FQDN      ID
555281 10.11.12.13:5060  ingress   10.11.12.13:8000  10.11.12.13:8002           1614567899


Recording Procedure

Once the SBC determines that the call must be recorded, it initiates the SIP INVITE towards the SRS specified in the recording criteria. The SBC:

  • Includes a “+sip.src” feature tag extension in the Contact URI
  • Includes an Options tag “siprec” in INVITE towards SRS.
  • Includes two m= lines, one for the Rx stream and one for the Tx stream.
    • The attribute “a=label” identifies the streams in the metadata.
  • Adds the RS-call specific data in the rs-metadata XML body. This metadata provides information on the attributes of the communication session (CS).
    • <gcid> the global call ID used in the SBC
    • Other SIP headers with their corresponding XML tags are added as per configuration
  • Sends the SDP offer with the same codec of the call leg that is being recorded towards the SRS.
  • When the SRS replies with its media IP/port information in a 200 OK, the SBC transparently duplicates the packets coming/going to the UE towards the SRS using the same codec as the original stream.
Note

The SBC does not support transcoding towards the SRS. If the SBC-SRS offer-answer negotiation fails, then the SBC sends a BYE message to the SRS and terminates the SIPREC call.

 

Note
  • The SBC does not support “Recording Aware UEs”
    • If an INVITE is received from UE with a options tag “require: siprec”, the SBC rejects the request with a 4xx message.
  • The SBC does not support SRS initiated recording
    • If an INVITE is received from an SRS with a options tag “require: siprec”, the SBC rejects the request with a 4xx message.
  • If any request except session keepalive re-INVITE/UPDATE or BYE is received in the context of an RS, the SBC rejects the request with a 405 "Method Not Allowed" message.


Note

The SBC stops recording a call in one of three ways:

  • Through a normal CS session disconnect
  • Receiving a BYE from the SRS
  • Manually through CLI, by providing the GCID for the call in the recording STOP command

Supported SIPREC Features

The SBC SIPREC support includes the following:

  • SIPREC is supported on UDP, TCP, and TLS protocols.
  • The SBC supports recording SIP and SIP-I calls.
  • If the OPTIONS ping mechanism is configured on the IP peer, it is used as a keep-alive mechanism for all the SRSs.
  • Troubleshooting a SIPREC recorded call using MCT is only possible when initiated through CLI.
  • SRS redundancy
  • Simultaneous recording
  • Dynamically programmable metadata content
  • The SBC records the SIPREC recording information in the CDR. 
Note

The SIPREC feature is controlled by a system-wide SBC license (SBC-SIPREC). If the license is not available, any SIPREC recording returned by a PSX is ignored.

SRS Redundancy

The SBC supports the concept of primary and secondary SRS servers for redundancy. It supports multiple (up to 8) srsGroupData objects within an SRS group profile to represent SRS servers in the group. All of the servers can be active at any point of time. The address of an SRS can be specified as an FQDN. Based on its DNS configuration, an FQDN can resolve to provide the IP addresses of multiple servers, thus enabling you to include more than eight servers in an SRS group.

  • The SBC can load balance among the recorders in the SRS group in sequential or round-robin fashion.
  • The SBC also supports crank-back mechanism where it tries the next SRS if an SRS does not respond to the RS INVITE or rejects the RS INVITE with a 4xx.
  • The SBC also maintains the health check of the SRS servers using OPTIONS pings. If an SRS is marked not reachable, the SBC automatically uses the next server in the SRS group for the next RS session.


Note

SRS redundancy is supported only when numOfStreams is set to "1" in an SRS group. When numOfStreams = "2'", the SBC is already sending media to the redundant recorder. 

Note
The SRS is not placed into a blacklist if it fails to respond to an RS INVITE because the blacklist is updated only by the path-check mechanism upon failure to respond to OPTIONS ping.

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

Note
  • The SBC supports support sending the recording streams to up to four SRS servers simultaneously.
  • Each recording criteria can be configured with a Recording Cluster. A Recording Cluster can have up to four SRS Groups.


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.

Example of Simultaneous Session Recording

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

Figure 2: An Example of Simultaneous Session Recording


 

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

CLI and EMA:

Alarms:

CDR:

SRTP Support for SIPREC Towards SRS

The SBC supports sending encrypted media streams (Secure Real-Time Transport Protocol (SRTP)) towards SIPREC recorders.

With this feature, the SBC:

  • Supports SRTP (encrypted streams) towards SIPREC server.
  • Provides SIPREC functionality with SRTP calls.
  • Provides flexibility by supporting both SRTP or RTP towards the SRS, based on the configuration in the srsGroupData.
  • Supports sending SRTP packets (encrypted media streams) as received from the endpoints (relay/pass-through).
  • Supports sending SRTP packets with a different encryption technique using the crypto suite profile configured in the srsGroupData.
  • Provides support to terminate an original SRTP call at the SBC for the SIPREC, such that:
    • The encrypted media packets are decrypted at the SBC and are re-encrypted again towards the user endpoint using the crypto suite profile negotiated between the SBC and the UE.
    • The decrypted media packets towards the SRS can be:
      • Encrypted using the same negotiated crypto suite profile.
      • Encrypted using different crypto suite profile as provided by the srsGroupData.
      • Send only decrypted media packets (RTP) towards the SRS based on the configuration (CS crypto is ignored).

The following two options in srsGroupData control SRTP support:

  • srtp: Specifies whether SRTP is enabled for the SRS or not.
  • cryptoSuiteProfile: If SRTP is enabled, the SBC uses the encryption technique called for in the specified profile for the recording session towards the SRS.
Note
  • If SRTP is disabled towards SRS, the SBC terminates an original SRTP call as it is supposed to decrypt the media towards SRS.
  • If SRTP is enabled and the srsGroupData provides its own crypto suite profile, the SBC terminates the original SRTP call to encrypt using the srsGroupData crypto suite profile.

When SRTP is disabled for the SRS, the SBC sends unencrypted streams towards the SRS irrespective of whether the CS is using RTP or SRTP.

When SRTP is enabled for the SRS and if the CS leg that is recorded is not using SRTP:

  • If a cryptoSuiteProfile is configured for the SRS, the SBC sends SRTP packets using the cryptoSuiteProfile on the recorded leg towards the SRS. 
     
  • If a cryptoSuiteProfile is not configured for the SRS, the SBC sends RTP packets. 

When the CS is using SRTP pass-through:

  • If the call is recorded and SRTP is enabled for the SRS, the SBC relays the SRTP packets as received from the user endpoint.
  • If SRTP is enabled for the SRS and a cryptoSuiteProfile is configured, the SBC re-encrypts the media using the configured cryptoSuiteProfile.

When the CS is an SRTP terminated call:

  • If a cryptoSuiteProfile is configured for the SRS, the SBC sends the SRTP packets using the cryptoSuiteProfile on the recorded leg towards the SRS. 
  • If a cryptoSuiteProfile is not configured for the SRS, the SBC uses the cryptoSuiteProfile from the CS and sends SRTP packets.
Note

If the SIPREC functionality fails, the alarm sonusSbxSipRecSrsSelectionFailedNotification is generated in the following scenarios:

  • When the original CS call is SRTP and SIPREC is triggered through CL.
  • When DTLS-SRTP call is supported.
  • When the SBC offers SRTP towards the SRS and the SRS answers with either an invalid crypto or with RTP. In this scenario, the SBC tries to find an "offer-answer" match with the next available SRS (SRS redundancy) before failing the SIPREC request.

Dynamically Programmable Metadata Content

The SBC supports a set of SIPREC specifications (RFC 7245, RFC 7865, RFC 7866, and RFC 8068) that include support for "dynamically programmable" selection of metadata content.

  • The profile sipRecMetaDataProfile provides the capability to configure the headers that are mapped from the target call leg to XML and the corresponding metadata XML element name.
  • In case of a basic call, all information is copied from the initial-INVITE message on the leg where the tap is, to the metadata XML. The "To" header and "to-tag" are also copied from local information (as the to-tag is not present in the INVITE).
  • In case of a SIPREC trigger during a REFER-based transfer, irrespective of where the SIPREC tap is, all information is copied from the initial-INVITE of the new call leg towards the transfer target (C party).
  • In case of a CLI-triggered recording, the existing implementation of sending predefined information in metadata XML remains the same (gcid, call-id, from, to). The new configuration of header-metadata mapping is not considered in this scenario.


Note

The maximum size of the callData section in the metadata portion of the SIPREC INVITE sent towards SRS is 2,048 bytes.

The following call flow diagram displays the XML tag names.

Figure 3: Call Flow



Known Issues

This section lists all known issues related to SIPREC on the SBC.

SRS Group roundRobin loadDistribution Issue

Problem Statement: In the SRS Group, the "roundRobin" loadDistribution scheme does not function properly when the following two criteria are both met:

  • A call that matches the SIPREC recording criteria has multiple routes;
  • The number of SRS IPs is exactly divisible by the number of routes.

Under standard operations when "roundrobin" is selected as the loadDistribution scheme for the SRS Group, the SRS IPs are shifted in the srsGroupProfile each time the SIPREC criteria is matched.

However, when the number of SRS IPs is exactly divisible by the number of routes, the SRS IPs jump by the number of routes. This results in SIPREC skipping certain SRS IPs.

Example: If the srsGroupProfile is configured with six SRS Servers (SRS_IP1, SRS_IP2, SRS_IP3, SRS_IP4, SRS_IP5, SRS_IP6) and two routes (Route#0, Route#1), then SIPREC will behave as follows when the recording criteria is matched at ingress TG:

  1. For Call#1, Route#0, 0th entry will be SRS_IP1
  2. For Call#1, Route#1, 0th entry will be SRS_IP2
  3. For Call#2, Route#0, 0th entry will be SRS_IP3
  4. For Call#2, Route#1, 0th entry will be SRS_IP4
  5. For Call#3, Route#0, 0th entry will be SRS_IP5
  6. For Call#3, Route#1, 0th entry will be SRS_IP6
  7. For Call#4, Route#0, 0th entry will be SRS_IP1
  8. For Call#4, Route#1, 0th entry will be SRS_IP2

Assuming that Route#0 is always successful, then only SRS_IP1, SRS_IP3, and SRS_IP5 will record. Therefore, SRS_IP2, SRS_IP4, and SRS_IP6 will always get skipped because the number of SRS IPs (six) is exactly divisible by the number of routes (two).

Solution: Configure the number of SRS IPs so that they are not exactly divisible by the number of routes returned for the call. Users can accomplish this by adding a mock IP or a repeated SRS IP to the srsGroupProfile. Additionally, users are recommended to update the number of SRS IPs to a prime number (ex: 5, 7, 11, 13, etc.) to minimize the chance that the number of SRS IPs is divisible by the number of routes.

Returning to the example above, the issue is resolved if a seventh SRS IP is added (SRS_IP7). Since the number of SRS IPs is no longer exactly divisible by the number of routes, the recordings flow properly, as follows: SRS_IP1, SRS_IP3, SRS_IP5, SRS_IP7, SRS_IP2, SRS_IP4, SRS_IP6, SRS_IP1, and so on.

Example SIP INVITE

An example SIP INVITE is shown below:

INVITE sip:SIPREC-SRS@10.54.80.8:51802 SIP/2.0
Via: SIP/2.0/UDP 10.34.171.39:5060;branch=z9hG4bK00B00021f4cdc2590c2
From: "SIPREC-SRC" <sip:SIPREC-SRC@10.34.171.39>;tag=gK00000237
To: "SIPREC-SRS" <sip:SIPREC-SRS@10.54.80.8>
Call-ID: 35651585_16777218_133945398@10.34.171.39
CSeq: 787532 INVITE
Max-Forwards: 70
Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE,NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH
Accept: application/sdp, application/rs-metadata-request,application/rs-metadata
Contact: "SIPREC-SRC" <sip:SIPREC-SRC@10.34.171.39:5060>;+sip.src
Require: siprec
Supported: timer,100rel
Session-Expires: 1800
Min-SE: 90
Content-Length:  4560
Content-Type: multipart/mixed;boundary=sonus-content-delim
MIME-Version: 1.0

--sonus-content-delim
Content-Disposition: session; handling=required
Content-Length:   296
Content-Type: application/sdp

v=0
o=Sonus_UAC 748003 60371 IN IP4 10.34.171.39
s=SIP Media Capabilities
t=0 0
m=audio 1052 RTP/SAVP 0
c=IN IP4 10.54.4.51
a=label:1
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:k3NkQB3Tkr23twOMMjd8YjvLI/XPdgE+a1D8FDho
a=rtpmap:0 PCMU/8000
a=sendonly
a=maxptime:10
m=audio 1050 RTP/SAVP 0
c=IN IP4 10.54.4.51
a=label:2
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:k3NkQB3Tkr23twOMMjd8YjvLI/XPdgE+a1D8FDho
a=rtpmap:0 PCMU/8000
a=sendonly
a=maxptime:10

--sonus-content-delim
Content-Disposition: recording-session
Content-Length:  3976
Content-Type: application/rs-metadata+xml

<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
    <datamode>complete</datamode>
    <group group_id="OTIxYzk4MDAtN2RkYy0xMA==">
        <associate-time>2018-08-09T08:31:44Z</associate-time>
        <callData xmlns='http://ribboncommunications.com/siprec/calldata'>
            <xTo>&lt;sip:+1999@10.54.80.8:51801;user=phone&gt;;tag=1</xTo>
            <xVia>SIP/2.0/UDP 10.34.171.34:5060;branch=z9hG4bK00B0000a25afeb7eee5</xVia>
            <xCSeq>844797 INVITE</xCSeq>
            <xFrom>"sipp" <sip:sanrayana@10.34.171.34>;tag=gK0000011e</xFrom>
            <xContentType>application/sdp</xContentType>
            <xMaxForwards>70</xMaxForwards>
            <srsgrpId>GR1</srsgrpId>
            <xAcceptContact>*;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"</xAcceptContact>
            <xPPreferredIdentity>"sipp" <sip:sanrayana@10.54.80.8:5061></xPPreferredIdentity>
            <mprofileVers>v1.0</mprofileVers>
            <gcid>35651585</gcid>
        </callData>
    </group>
    <session session_id="OTIxYzlhM2UtN2RkYy0xMA==">
        <group-ref>OTIxYzk4MDAtN2RkYy0xMA==</group-ref>
        <start-time>2018-08-09T08:31:44Z</start-time>
    </session>
    <participant participant_id="OTIxYzk4MDEtN2RkYy0xMA==">
        <nameID aor="sanrayana@10.34.171.34:5060">
            <name xml:lang="en">sipp</name>
        </nameID>
    </participant>
    <participant participant_id="OTIxYzk4MDItN2RkYy0xMA==">
        <nameID aor="+1999@10.54.80.8">
            <name xml:lang="en"> </name>
        </nameID>
    </participant>
    <stream stream_id="OTIxYzk4MDQtN2RkYy0xMA==" session_id="OTIxYzlhM2UtN2RkYy0xMA==">
        <label>1</label>
        <associate-time>2018-08-09T08:31:44Z</associate-time>
    </stream>
    <stream stream_id="OTIxYzk4MDUtN2RkYy0xMA==" session_id="OTIxYzlhM2UtN2RkYy0xMA==">
        <label>2</label>
        <associate-time>2018-08-09T08:31:44Z</associate-time>
    </stream>
    <sessionrecordingassoc session_id="OTIxYzlhM2UtN2RkYy0xMA==">
        <associate-time>2018-08-09T08:31:44Z</associate-time>
    </sessionrecordingassoc>
    <participantsessionassoc participant_id="OTIxYzk4MDEtN2RkYy0xMA==" session_id="OTIxYzlhM2UtN2RkYy0xMA==">
        <associate-time>2018-08-09T08:31:44Z</associate-time>
    </participantsessionassoc>
    <participantsessionassoc participant_id="OTIxYzk4MDItN2RkYy0xMA==" session_id="OTIxYzlhM2UtN2RkYy0xMA==">
        <associate-time>2018-08-09T08:31:44Z</associate-time>
    </participantsessionassoc>
    <participantstreamassoc participant_id="OTIxYzk4MDEtN2RkYy0xMA==">
        <send>OTIxYzk4MDQtN2RkYy0xMA==</send>
        <recv>OTIxYzk4MDUtN2RkYy0xMA==</recv>
    </participantstreamassoc>
    <participantstreamassoc participant_id="OTIxYzk4MDItN2RkYy0xMA==">
        <send>OTIxYzk4MDUtN2RkYy0xMA==</send>
        <recv>OTIxYzk4MDQtN2RkYy0xMA==</recv>
    </participantstreamassoc>
</recording>