Session Recording Protocol
updated by
- rfc-9806 — Updates to SIP-Based Media Recording (SIPREC) to Correct Metadata Media Type
Extracted elements (31)
The SRS base-mode requirement to support separate m-lines (one per CS media direction) was chosen to enable minimum interoperability without mandating full mixing support. It also allows SRS implementations targeting specific use cases (e.g., security cameras, one-way audio) without having to support all modalities.
The UPDATE method was chosen for the SRS to request a metadata snapshot (rather than re-INVITE) because UPDATE can be sent regardless of the state of the SIP dialog. This avoids requiring support for both UPDATE and re-INVITE for this single operation.
The SRS MUST support both FIR (Full Intra Request) and SIP INFO (RFC 5168 XML video fast update) for requesting video decoder refresh points, using FIR when successfully negotiated and SIP INFO for backward compatibility with implementations that predate FIR adoption.
A recording-aware UA MUST indicate recording awareness by including the 'record-aware' option tag in the Supported header of the initial INVITE or response. It MUST also provide a recording indication to the end user showing whether recording is on, off, or paused for each medium.
For base interoperability, an SRC MUST support separate SDP m-lines (one per CS media direction). An SRS supporting audio recording MUST support receiving at least two audio m-lines; one supporting audio and video MUST support at least four total m-lines.
For the Communication Session, the SRC MUST provide recording indications to all participants. When a participant UA includes the 'record-aware' option tag, the SRC MUST provide the indication via the SDP 'a=record' attribute; otherwise the SRC MUST use other means such as an in-band tone.
Symmetric RTP and symmetric RTCP are REQUIRED: entities MUST use the same source port for sending RTP as they signal for receiving RTP, and likewise for RTCP.
The SRC and SRS MUST support SIP with TLS version 1.2, SHOULD follow RFC 7525 best practices, and the RS MUST be at least as secure as the CS — meaning at least equivalent cipher suite strength. A CS using SIPS/SRTP may not be recorded over plain SIP/RTP without equivalent compensating controls.
The SRC MUST include a SDP 'a=label' attribute (per RFC 4574) on each media stream in the Recording Session SDP offer to identify each recorded stream. The label name maps to the Media Stream Reference in the SIPREC metadata.
The SRC MUST include the '+sip.src' feature tag in the Contact URI for all Recording Sessions, so that an SRS can confirm the dialog is for the purpose of a Recording Session. When an SRC sends a REGISTER request, it MAY include this tag to advertise itself.
The SRC MUST include the 'siprec' option tag in the Require header when initiating a Recording Session, causing UAs that do not support the Session Recording Protocol to reject the INVITE with 420 (Bad Extension). The SRS MUST do likewise when it initiates an RS.
The SRC MUST only treat an incoming SIP session as a Recording Session when both the '+sip.srs' feature tag and the 'siprec' option tag are present in the INVITE request. The SRS applies the symmetric rule requiring both '+sip.src' and 'siprec'.
The SRC MUST send metadata to the SRS in a Recording Session. The SRC SHOULD include a full metadata snapshot in the initial INVITE; if not yet available, it SHOULD send one as soon as metadata becomes available. If the SRS requests a snapshot, the SRC MUST immediately provide a full metadata snapshot.
The SRS MUST include the '+sip.srs' feature tag in the Contact URI for all Recording Sessions. When an SRS sends a REGISTER request, it SHOULD include this tag to indicate it is an SRS.
The SRS MUST NOT add recorded streams in an RS when the SRS sends a new SDP offer. When the SRS initiates an RS, it MUST send the INVITE without an SDP offer, allowing the SRC to generate the offer containing the streams to be recorded.
The SRS MUST NOT request a full metadata snapshot in an UPDATE response or in any SIP transaction other than an UPDATE request. The snapshot request MUST contain a body with Content-Disposition 'recording-session' and MUST NOT contain an SDP body.
When each UA in a CS traversal (e.g., B2BUA or conference focus) is aware that the CS is being recorded, it MUST propagate the recording indication via the 'a=record' attribute to all other parties in the CS.
Whenever the recording state changes (e.g., recording terminates), the SRC MUST initiate a re-INVITE or UPDATE to update the SDP 'a=record' attribute in the Communication Session.
Metadata is carried in the content type 'application/rs-metadata' with Content-Disposition 'recording-session'. When a SIP message contains both an SDP offer and metadata, the body MUST be 'multipart/mixed' with separate subordinate parts for SDP and metadata. Metadata may be a full snapshot or an incremental partial update.
Persistent recording allows an RS to be established in the absence of a CS, with the SRC continuously sending media and updating metadata as new CSs are created. When no CS is active, the SRC and SRS SHOULD follow RFC 6263 keepalive procedures to maintain NAT bindings on the allocated RTP/RTCP ports.
The 'a=record' SDP attribute is a session-level or media-level attribute used by the SRC to indicate recording state to recording-aware UAs in the CS. Values are 'on' (recording in progress), 'off' (no recording), and 'paused' (recording in progress but media is paused). Media-level overrides session-level.
The 'a=recordpref' SDP attribute allows a CS participant to express a recording preference at the session or media level. Values are 'on', 'off', 'pause', and 'nopreference'. The SRC is not required to honor the preference but MUST report any resulting state change via 'a=record'.
The Recording Session (RS) is a SIP session established between the Session Recording Client (SRC) and the Session Recording Server (SRS) to deliver replicated real-time media and metadata from a Communication Session (CS). The RS is independent of the CS and may span multiple CSs.
The SRC may act as an RTP translator (forwarding or transcoding), RTP mixer, or RTP endpoint with respect to the RS. As a forwarding translator it preserves SSRCs; as a mixer it uses its own SSRC and conveys source SSRCs as CSRCs; as an endpoint the RS RTP session is completely independent of the CS.
This document registers the Content-Disposition parameter value 'recording-session', indicating that the body contains either metadata about the RS or the reason for a metadata snapshot request, as determined by the Content-Type MIME value.
This document registers two new SDP attributes: 'record' (session- or media-level; allowed values 'on', 'off', 'paused'; provides recording indication) and 'recordpref' (session- or media-level; allowed values 'on', 'off', 'pause', 'nopreference'; provides recording preference).
This document registers two SIP media feature tags per RFC 3840: 'sip.src' (boolean; UA is a Session Recording Client) and 'sip.srs' (boolean; UA is a Session Recording Server). ASN.1 identifiers 1.3.6.1.8.4.27 and 1.3.6.1.8.4.28 respectively.
This document registers two SIP option tags: 'siprec' (identifies the SIP session as a Recording Session; used in Require header) and 'record-aware' (indicates UA ability to receive recording indicators in SDP). Both are registered per RFC 3261.
Metadata in the RS may contain sensitive call details such as participant identities, call timing, and media attributes. The SRC may be configured to suppress certain metadata for privacy reasons; the SRS MUST protect stored metadata with appropriate access controls.
The RS MUST be at least as secure as the CS. The SRC and SRS MUST support TLS 1.2 for SIP signaling, and SRTP SHOULD be used for recorded media. Downgrading from SIPS/SRTP to plain SIP/RTP in the RS is not permitted unless equivalent compensating controls are in place.
The SRC and SRS MUST support mutual TLS authentication and SHOULD support SIP Digest authentication. An SRS MUST verify that it is authorized to receive recordings from the SRC; the SRC MUST verify the SRS identity before sending recorded media and metadata to prevent unauthorized capture.