SIP-based Media Recording

The device can record SIP-based media (RTP/SRTP) call sessions traversing it. The device can record not only audio streams, but also video streams for audio-video calls. The media recording support is in accordance with the Session Recording Protocol (SIPRec), which describes architectures for deploying session recording solutions and specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device. The device's SIPRec feature is in compliance with the following:

■ RFC 6341 (Use Cases and Requirements for SIP-Based Media Recording)
■ Session Recording Protocol (draft-ietf-siprec-protocol-02)
■ Architecture (draft-ietf-siprec-architecture-03)
■ RFC 7865 (Session Initiation Protocol (SIP) Recording Metadata)

Warning for Deployments in France: The device supports SIP-based Media Recording (SIPRec) according to RFC 6341. As such, you must adhere to the Commission Nationale Informatique et Liberté’s (CNIL) directive (https://www.cnil.fr/en/rights-and-obligations) and be aware that article R226-15 applies penalties to the malicious interception, diversion, use or disclosure of correspondence sent, transmitted or received by means of telecommunication, or the setting up of a device designed to produce such interceptions.

● The SIP-based Media Recording feature is available only if the device is installed with a License Key (see License Key) that includes this feature. The License Key specifies the maximum number of supported SIP recording sessions. For audio-video calls, video recording needs additional SBC media channel resources.
● For maximum concurrent SIPRec sessions, refer to the device's Release Notes, which can be downloaded from AudioCodes website.
● You can view active and historical SIPRec call information, using the CLI command show voip calls.
● You can customize SBC CDRs generated by the device to include the field "Is Recorded" which indicates if the SBC leg was recorded or not. For more information, see Customizing CDRs for SBC Calls and Test Calls.

Session recording is a critical requirement in many business communications environments such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics. Recording is typically performed by sending a copy of the session media to the recording devices.

The SIPRec protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) from the Session Recording Client (SRC), which is on the path of the Communication Session (CS), to a Session Recording Server (SRS) at the recording equipment. The device functions as the SRC, sending recording sessions to a third-party SRS, as shown in the figure below.

The device can record calls between two IP Groups, or between an IP Group and a Trunk Group for Gateway calls. The type of calls to record can be specified by source and/or destination prefix number or SIP Request-URI, as well as by call initiator. The side ("leg") on which the recording is done must be specified. Specifying the leg is important as it determines the various call media attributes of the recorded RTP (or SRTP) such as coder type.

The device can also record SRTP calls and send it to the SRS in RTP, or vice versa. For this functionality, simply configure the 'SBC Media Security Mode' parameter of the IP Profile that is associated with the SRS's IP Group to Secured or Not Secured, respectively. If you need to record the call in a coder that is different to the coder used in the call, the device can also be located between an SRS and an SRC to perform coder transcoding. In this setup, the device receives SIP recording sessions from the SRC and transcodes the media between the SRC and SRS, and then forwards the recording to the SRS in the transcoded media format.

The device can send recorded SBC calls to multiple SRSs. To achieve this, you can configure up to three groups of SRSs, where each group can contain one SRS (standalone), or two SRSs operating in an active-standby (1+1) mode for SRS redundancy. The device sends both SIP signaling and RTP to all standalone SRSs. For Gateway calls, only one SRS is supported.

For SRS redundancy, the device sends SIP signaling to all SRSs (active and standby), but sends RTP only to the active SRSs. If during a recorded call session, the standby SRS detects that the active SRS has gone offline, the standby SRS sends a re-INVITE to the device and the device then sends the recorded RTP to the standby SRS instead (which now becomes the active SRS). For new calls, if the device receives no response or a reject response from the active SRS to its' sent INVITE message, the device sends the recorded call to the standby SRS.

● For the device's SRS active-standby feature to function, it must be supported by the third-party SRS. For supported third-party SRS vendors, contact your AudioCodes sales representative.
● The device can send recordings (media) to up to three active SRSs. In other words, any one of the following configurations are supported:
✔ Up to three standalone (active) SRSs.
✔ Up to three active-standby SRS pairs (i.e., six SRSs, but recordings are sent only to the three active SRSs).
✔ One standalone (active) SRS and two active-standby SRS pairs.
✔ Two standalone (active) SRSs and one active-standby SRS pair.
● SRS active-standby redundancy is a license-dependent feature and is available only if it is included in the License Key installed on the device (see Viewing the License Key). Therefore, the SIPRec feature can require two licenses – the regular license ("SIPRec Sessions") for standalone (active) SRSs and a license for SRS active-standby redundancy ("SIPRec Redundancy"). If you are implementing only standalone SRSs, you only need the “SIPRec Sessions” license. If you are implementing SRS active-standby redundancy, you need both licenses.
● The “SIPRec Sessions” license defines the maximum number of sessions for active SRSs (standalone SRS and the active SRS in the active-standby redundancy pair). The "SIPRec Redundancy" license defines the maximum number of SIPRec sessions for the standby SRS in the active-standby redundancy pair. For example, if you want to support 10 SIPRec sessions per SRS, the required licenses for various scenarios are as follows:
✔ One standalone SRS: "SIPRec Sessions" = 10
✔ Two standalone SRSs: "SIPRec Sessions" = 20
✔ One active-standby redundancy pair: "SIPRec Sessions" = 10; "SIPRec Redundancy" = 10
✔ Two active-standby redundancy pairs: "SIPRec Sessions" = 20; "SIPRec Redundancy" = 20
✔ One standalone SRS and two active-standby redundancy pairs: "SIPRec Sessions" = 30; "SIPRec Redundancy" = 20

The device initiates a recording session by sending an INVITE message to the SRS when the call to be recorded is connected. The SIP From header contains the identity of the SRC and the To header contains the identity of the SRS. The SIP message body of the INVITE contains the following:

■ SDP body:
● Two 'm=' lines that represent the two RTP/SRTP streams (Rx and Tx).
● Two 'a=label:' lines that identify the streams.

If the recorded leg includes a video stream, the SDP not only includes the two audio streams ('m=audio'), but also two video streams ('m=video') in send-only RTP mode ('a=sendonly') - one for Tx and one for Rx.

■ XML body (also referred to as metadata), which provides information on the participants of the call session:
● <group id>: Logging Session ID (displayed as [SID:nnnnn] in Syslog), converted to hex (or Base64 format). This number remains the same even if the call is forwarded or transferred. This is important for recorded calls.
● <session id>: SIP Call-ID header value of the recorded leg, which the device represents as a unique hashed number.
● <group-ref>: Same as <group id>.
● <participant id>: SIP From / To user.
● <nameID aor>: From/To user@host.
● <send> and <recv>: IDs for the RTP/SRTP streams in hex (or Base64 format) - bits 0-31 are the same as group, bits 32-47 are the RTP port.
● <stream id>: Same as <send> for each participant.
● <label>: 1 and 2 (same as in the SDP's 'a=label:' line).
● RFC 7865 only:
◆ <sessionrecordingassoc>: Session association data.
◆ <participantsessionassoc>: Data for association between participant and session.
◆ <participantstreamassoc>: Data for association between participant and stream.

If the recorded leg includes a video stream, the metadata body contains two additional <stream> sections, which denote the Tx and Rx recording streams of the video payload. When RFC 7865 is chosen as the metadata format, the <participantstreamassoc> sections also contain this additional pair of streams.

You can configure the format of the recording metadata (i.e., based on RFC 7865 or "legacy") generated by the device. For more information, see Configuring Format of SIPRec Metadata.

The SRS can respond with 'a=recvonly' for immediate recording or 'a=inactive' if recording is not yet needed, and send a re-INVITE at any later stage with the desired RTP/SRTP mode change. If a re-INVITE is received in the original call (e.g., when a call is on hold), the device sends another re-INVITE with two 'm=' lines to the SRS with the updated RTP/SRTP data. If the recorded leg uses SRTP, the device can send the media streams to the SRS as SRTP; otherwise, the media streams are sent as RTP to the SRS.

Below is an example of an INVITE sent by the device to the SRS, showing the legacy and RFC 7865 metadata formats (only one of these is generated in real-life scenarios):

INVITE sip:VSRP@1.9.64.253 SIP/2.0
Via: SIP/2.0/UDP 192.168.241.44:5060;branch=z9hG4bKac505782914
Max-Forwards: 10
From: <sip:192.168.241.44>;tag=1c505764207
To: <sip:VSRP@1.9.64.253>
Call-ID: 505763097241201011157@192.168.241.44
CSeq: 1 INVITE
Contact: <sip:192.168.241.44:5060>;src
Supported: replaces,resource-priority
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
Require: siprec
User-Agent: Device /7.24A.356.888
Content-Type: multipart/mixed;boundary=boundary_ac1fffff85b
Content-Length: 1832
--boundary_ac1fffff85b
Content-Type: application/sdp 

v=0 
o=AudioCodesGW 921244928 921244893 IN IP4 10.33.8.70 
s=SBC-Call 
c=IN IP4 10.33.8.70 
t=0 0 
m=audio 6020 RTP/AVP 8 96 
c=IN IP4 10.33.8.70 
a=ptime:20 
a=sendonly 
a=label:1 
a=rtpmap:8 PCMA/8000 
a=rtpmap:96 telephone-event/8000 
a=fmtp:96 0-15 
m=audio 6030 RTP/AVP 8 96 
c=IN IP4 10.33.8.70 
a=ptime:20 
a=sendonly 
a=label:2 
a=rtpmap:8 PCMA/8000 
a=rtpmap:96 telephone-event/8000 
a=fmtp:96 0-15
--boundary_ac1fffff85b

Content-Type: application/rs-metadata
Content-Disposition: recording-session
■ Legacy XML metadata: 
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording'>
  <datamode>complete</datamode>
  <group id="00000000-0000-0000-0000-00003a36c4e3">
    <associate-time>2010-01-24T01:11:57Z</associate-time>
  </group>
  <session id="0000-0000-0000-0000-00000000d0d71a52">
    <group-ref>00000000-0000-0000-0000-00003a36c4e3</group-ref>
    <start-time>2010-01-24T01:11:57Z</start-time>
	<ac:AvayaUCID xmlns="urn:ietf:params:xml:ns:Avaya">FA080030C4E34B5B9E59</ac:AvayaUCID>
  </session>
  <participant id="1056" session="0000-0000-0000-0000-00000000d0d71a52">
    <nameID aor="1056@192.168.241.20"></nameID>
    <associate-time>2010-01-24T01:11:57Z</associate-time>
    <send>00000000-0000-0000-0000-1CF23A36C4E3</send>
    <recv>00000000-0000-0000-0000-BF583A36C4E3</recv>
  </participant>
	<participant id="182052092" session="0000-0000-0000-0000-00000000d0d71a52">
    <nameID aor="182052092@voicelab.local"></nameID>
    <associate-time>2010-01-24T01:11:57Z</associate-time>
    <recv>00000000-0000-0000-0000-1CF23A36C4E3</recv>
    <send>00000000-0000-0000-0000-BF583A36C4E3</send>
  </participant>
  <stream id="00000000-0000-0000-0000-1CF23A36C4E3" session="0000-0000-0000-0000-00000000d0d71a52">
    <label>1</label>
  </stream>
  <stream id="00000000-0000-0000-0000-BF583A36C4E3" session="0000-0000-0000-0000-00000000d0d71a52">
    <label>2</label>
  </stream>
</recording>
--boundary_ac1fffff85b—
● RFC 7865 XML metadata: 
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns="urn:ietf:params:xml:ns:recording" xmlns:ac="http://abc">
  <datamode>complete</datamode>
  <group group_id="4gAAAAC9YRUBDQDw">
    <associate-time>2018-04-17T09:35:41</associate-time>
  </group>
  <session session_id="OWc4Md2PHao=">
    <group-ref>4gAAAAC9YRUBDQDw</group-ref>
  </session>
  <participant participant_id="MjAw">
    <nameID aor="200@10.33.8.52">
        <name xml:lang="en">Bob</name>
    </nameID>
  </participant>
  <participant participant_id="MTAw">
    <nameID aor="100@10.33.8.52"></nameID>
  </participant>
  <stream stream_id="mBfiAAAAAL1hFQENAPA=" session_id="OWc4Md2PHao=">
    <label>1</label>
  </stream>
  <stream stream_id="hBfiAAAAAL1hFQENAPA=" session_id="OWc4Md2PHao=">
    <label>2</label>
  </stream>
  <sessionrecordingassoc session_id="OWc4Md2PHao=">
    <associate-time>2018-04-17T09:35:41</associate-time>
  </sessionrecordingassoc>
  <participantsessionassoc participant_id="MjAw" session_id="OWc4Md2PHao=">
    <associate-time>2018-04-17T09:35:41</associate-time>
  </participantsessionassoc>
  <participantsessionassoc participant_id="MTAw" session_id="OWc4Md2PHao=">
    <associate-time>2018-04-17T09:35:41</associate-time>
  </participantsessionassoc>
  <participantstreamassoc participant_id="MjAw">
    <send>mBfiAAAAAL1hFQENAPA=</send>
    <recv>hBfiAAAAAL1hFQENAPA=</recv>
  </participantstreamassoc>
  <participantstreamassoc participant_id="MTAw">
    <send>hBfiAAAAAL1hFQENAPA=</send>
    <recv>mBfiAAAAAL1hFQENAPA=</recv>
  </participantstreamassoc>
</recording>