DO NOT SHARE THESE DOCS WITH CUSTOMERS!
This is an LA release that will only be provided to a select number of PLM-sanctioned customers (PDFs only). Contact PLM for details.
In this section:
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).
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.
Table 1: Supported RFCs
Category | RFCs |
---|---|
Use Cases and Requirements for SIP-Based Media Recording (SIPREC) | RFC 6341 |
Media Recording Architecture | RFC 7245 |
Session Initiation Protocol (SIP) Recording Metadata | RFC 7865 |
Session Recording Protocol | RFC 7866 |
Session Initiation Protocol (SIP) Recording Call Flows | RFC 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
The two methods to trigger a call recording are:
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:
The PSX/ERE supports provisioning 1,024 Recording criteria , 256 SRS Group Profiles and 256 SRS Cluster Profiles.
The need to record a call is decided from the PSX based on the following criteria in the given order of priority:
For detailed configuration information, refer to the section Deploying SBC For SIPREC.
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>
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
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:
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.
The SBC stops recording a call in one of three ways:
The SBC SIPREC support includes the following:
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.
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.
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.
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.)
recordingType
to "both legs" or "all legs".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:
The SBC supports sending encrypted media streams (Secure Real-Time Transport Protocol (SRTP)) towards SIPREC recorders.
With this feature, the SBC:
srsGroupData
.srsGroupData.
srsGroupData
.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.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:
cryptoSuiteProfile
is configured for the SRS, the SBC sends SRTP packets using the cryptoSuiteProfile
on the recorded leg towards the SRS. cryptoSuiteProfile
is not configured for the SRS, the SBC sends RTP packets. When the CS is using SRTP pass-through:
cryptoSuiteProfile
is configured, the SBC re-encrypts the media using the configured cryptoSuiteProfile
.When the CS is an SRTP terminated call:
cryptoSuiteProfile
is configured for the SRS, the SBC sends the SRTP packets using the cryptoSuiteProfile
on the recorded leg towards the SRS. cryptoSuiteProfile
is not configured for the SRS, the SBC uses the cryptoSuiteProfile
from the CS and sends SRTP packets.If the SIPREC functionality fails, the alarm sonusSbxSipRecSrsSelectionFailedNotification is generated in the following scenarios:
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.
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.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
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><sip:+1999@10.54.80.8:51801;user=phone>;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>