Page History

Overview

The SIPREC protocol defines the interaction between

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

TheThe  

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

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.

The overall 

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

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

Figure 1 SBC SIP Recording Strategy 3 SBC SIP Recording Strategy

Image Added

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 

  Spacevars
  0 product

  to record the call.
• Initiate recording via CLI using GCID.

PSX Configuration

The recording-criteria determine, which sessions to record, 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).
• Contains
• Transport
• IP V4/V6 address and port
• SRS Groups—contains multiple Recoding profiles for SRS redundancy (up to 8).
• Contains data of multiple SRS servers
• Transport
• IP V4/V6 address port
• Encryption data (for SRTP)  
• IP TG to be used by the SBC for RS session
• Recording Cluster profile—contains multiple SRS Groups for simultaneous recording (up to 4).

Recording Criteria

The need to record a call is decided from the PSX based on the following criteria

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

The two methods to trigger a call recording are:

• A call matches call recording criteria causing the PSX to trigger the

  Spacevars
  0 product

  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

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.

• GATEWAY

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

CLI Triggers

• Recording RTP session can be initiated

Supported SIPREC features include:

• Recording RTP session for a call by providing its GCID via through CLI. The user provides the IP Address/port for the corresponding session recorder via through the same CLI command.
• Listing the calls currently being recorded using a CLI command. The The 

  Spacevars
  0 product

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

• 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
  0 product

   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
  0 product

   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
  0 product

   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.

To enable/disable SIPREC feature, use following syntax:

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

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

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

To view SIPREC status, use CLI syntax:

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

To enable/disable SIPREC feature, use following syntax:

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

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

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

To view SIPREC status, use CLI syntax:

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

Recording Procedure

Once the 

• Includes a “+sip.src” feature tag extension in the Contact URI
• Options Tag “siprec” in INVITE towards SRS.
• 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 participants of the communication session
• <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.

For configuring SIPREC feature, refer to the section Deploying SBC For SIPREC.

Supported Features

The 

• The SIPREC is supported on UDP, TCP, and TLS protocols.
• The 

  Spacevars
  0 product

  supports recording SIP and SIP-I calls.
• If 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
• SRS Server Overload Protection
• Simultaneous recording
• Dynamically programmable metadata content
• The SBC records the SIPREC recording information in the CDR.
  

SRS Redundancy

The 

• The 

  Spacevars
  0 product

  can load balance among the recorders in the SRS Group in sequential or round-robin fashion.
• The 

  Spacevars
  0 product

  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 

  Spacevars
  0 product

  also maintains the health check of the SRS servers using Options PING. If an SRS is marked not reachable, the SBC automatically uses the next server in the SRS group for the next RS session.

SRS Server Overload Protection 

Address Reachability Service 

The ARS capability enables the SBC to determine whether a server is reachable and provides the ability to temporarily "blacklist" a server IP address if necessary. Within an ARS profile you define when to blacklist a peer, in this case an SRS server, and a recovery algorithm that defines when to remove blacklisting, restoring the server into service. You can assign an ARS profile to the SIP trunk group that handles traffic toward the SRS servers.

An ARS profile offers three types of blacklisting criteria. In the context of monitoring SRS servers, they apply as follows:

• • Timeout-based blacklisting – an SRS server can be blacklisted based on exceeding a threshold of timeouts from INVITE requests toward the server. The blacklisting continues until the server meets the recovery criteria specified in the profile.
  • 503 response-based blacklisting when a Retry-After header value is present – an SRS server can be blacklisted after the server responds with a SIP 503 "Service Unavailable" message that contains a Retry-After header. The blacklisting continues for the duration specified in the Retry-After header.
  • 503 response-based blacklisting when a Retry-After header value is not present – an SRS server can be blacklisted after the server responds with SIP 503 "Service Unavailable" messages, without Retry-After headers, that exceeds the rate specified in the profile. The blacklisting continues until the server meets the recovery criteria specified in the profile.
    

Once the SBC blacklists an SRS server using any of the previous criteria, the SBC does not attempt to send the SRS server any recording requests until it recovers, as specified in the profile.

Refer to the following pages for more information:  

• Address Reachability Service for an overview of ARS concepts
• SIP ARS Profile - CLI and Service Profiles - SIP ARS Profile (EMA) for information on configuring ARS profiles.

Call Admission Control

The CAC capability provides a method to avoid overload by applying limits on bandwidth usage and call sessions toward the SRS server. To apply CAC rules to a specific SRS server, you configure an IP Peer object to represent the SRS server, and then attach to it a SIP CAC profile that specifies the limits and rules you want to impose. You can define CAC limits within a SIP CAC profile in terms of both bandwidth usage limits and call limits. 

SIP CAC profiles specify CAC limits for a specific endpoint (peer), in this case an SRS server. Although the SIP CAC profile object includes a wide range of parameters, only the top-level and egress-endpoint-level parameters apply in the context of SRS servers. Specifically, you can use the following CAC parameters when creating a SIP CAC profile to apply to an IP peer that represents an SRS server:

• aggregateMessage
• bandwidthLimit
• bandwidthLimitThreshold
• callEgressAggregatePreference
• callEgressBurstSize
• callEgressRate
• callEgressRatePeriod
• callLimit
• callLimitEgress
• callLimitThreshold

The SBC imposes the limits configured in the SIP CAC profile when determining whether to send SIPREC traffic towards the server to which it is assigned. If a SIPREC request fails due to CAC limits and a redundant SRS server is configured, the SBC attempts to send the request to the next available redundant SRS server.

 Refer to the following pages for more information:

• Call Admission Controls for an overview of CAC concepts and a description of the SIP CAC profile.
• Zone - IP Peer - CLI and Zone - IP Peer (EMA) for information on configuring an IP peer object.
• SIP CAC Profile - CLI and Profiles - SIP CAC Profile (EMA) for information on configuring SIP CAC profiles.

Simultaneous Session Recording - SIP Ingress and Egress Legs

The 

The 

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.

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

CLI and EMA:

• Request Global - CLI
• Servers - SRS Group Profile - CLI
• Servers - Call Recording Criteria - CLI
• Servers - SRS Group Profile - CLI
• Zone - SIP Sig Port - CLI
• Global - SIPrec
• Global - Servers - Srs Group Profile

Alarms:

• sonusSbxSipRecSrsSelectionFailedNotification - MINOR
• sonusSbxSIPRecLicenseNotAvailable - MINOR

CDR:

• CDR Field Descriptions

SRTP Support for SIPREC Towards SRS

The 

• The 

  Spacevars
  0 product

  sends the SRTP streams as received from the endpoints.
• The 

  Spacevars
  0 product

  is configured to perform a different encryption (using dedicated crypto suite profile) towards the Session Recording Server (SRS).
• The 

  Spacevars
  0 product

  is configured to send plain RTP packets even when the original Communication Session (CS) is an SRTP call.

With this feature, the

• 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 input control in the srsGroupData.
• Supports sending SRTP packets (encrypted media streams) as received from the endpoints (relay/pass-through).
• Supports sending SRTP packets with different encryption techniques using new crypto suite profile configured in the srsGroupData.
• Provides support to terminate 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 negotiated crypto suite profile (CS) between the SBC and the UE.
  • The decrypted media packets towards SRS can be:
    • Encrypted using the same CS negotiated crypto suite profile.
    • Encrypted using different crypto suite profile as provided by the srsGroupData.
    • Send decrypted media packets (RTP) only towards SRS based on the configuration (CS crypto is ignored).

The following two options are added to the srsGroupData:

• srtp: Specifies whether SRTP is enabled for the SRS or not.
• cryptoSuiteProfile: If SRTP is enabled, encrypt recording session using this crypto details.

When SRTP is disabled for the SRS, the 

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

• If cryptoSuiteProfile is configured for the SRS, the

  Spacevars
  0 product

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

  Spacevars
  0 product

   sends the RTP packets. 

When the CS is using SRTP pass-through:

• If the call is recorded and SRTP is enabled for the SRS, the 

  Spacevars
  0 product

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

When the CS is an SRTP terminated call:

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

Dynamically Programmable Metadata Content

The 

• The profile sipRecMetaDataProfile is introduced to the services to provide the capability to configure the headers that are mapped from the target call leg to the 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. However, "To" header and "to-tag" is copied additionally from the local information (as to-tag does not present in the INVITE).
• In case of SIPREC trigger during 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 CLI triggered recording, the existing implementation of sending predefined information in metadata XML remains same (gcid, call-id, from, to). The new configuration of header-metadata mapping is not considered in this scenario.

The following call flow diagram displays the XML tag name.

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>