Session Initiation Protocol (SIP) Recording Metadata
Extracted elements (30)
Metadata is conveyed from SRC to SRS as a series of snapshots, each representing the state at a particular instant as seen by a single SRC. This snapshot model accommodates incremental updates: the SRC sends only changed elements in a partial-mode document rather than retransmitting the full metadata on every change.
Some metadata (media format, codec properties) is derivable from SDP and is not repeated in the XML document; only metadata not available from SIP/SDP signaling (participant details, grouping, association times) is included in the 'application/rs-metadata+xml' body. The SDP 'a=label' attribute bridges the XML stream elements to SDP m-lines.
The SRC should create a Participant object for every participant it knows about, even those without a direct SIP signaling relationship (e.g., participants in a pre-mixed stream, or a 3pcc initiator). This allows the SRS to have a complete picture of who was involved in a CS regardless of the SRC's direct signaling scope.
Zero CS and CS-Group instances are allowed in a 'recording' element to support persistent recording scenarios where the RS SIP dialog is established before any CS exists (e.g., a phone sets up an RS with the SRS before joining a call). Once a CS is established, the same RS carries the CS metadata.
No version negotiation mechanism is defined for the recording metadata schema. The version is embedded in the XML namespace URI (urn:ietf:params:xml:ns:recording:1). Implementations may not interoperate if the metadata XML schema version implemented by the sender is not known by the receiver; future documents updating this schema should use a higher version number in the namespace.
Every application conforming to this specification MUST accept the UTF-8 character encoding to ensure minimal interoperability. If the MIME charset parameter differs from the XML encoding declaration, the charset parameter takes precedence.
For snapshot requests, the SRS MUST send a SIP request message with an XML document having the recording namespace, and a 'requestsnapshot' XML element MUST be present as the top-level element.
If two SRCs use the same UUID, they MUST retain the UUID/element mapping. If the SRS detects that a UUID is mapped to more than one element at any point in time, it MUST treat this as an error and may reject or ignore the offending metadata portions.
SRCs and SRSs supporting this specification MUST use version 1 in the namespace (urn:ietf:params:xml:ns:recording:1) in all XML documents. Implementations may not interoperate if the sender's version is unknown to the receiver; no version negotiation is provided.
The 'recording' element MUST contain an xmlns namespace attribute with value 'urn:ietf:params:xml:ns:recording:1', and exactly one 'recording' element MUST be present in every recording metadata XML document.
The 'send' and 'recv' XML elements MUST be used to indicate whether a participant is contributing to or receiving a stream. If a participant stops contributing or receiving due to CS changes, a snapshot MUST be sent from the SRC to the SRS with no 'send' (or 'recv') element for that stream.
The SRC and SRS MUST follow the security procedures in RFC 7866 for mutual authentication and to protect recording metadata content. For data minimization, the SRS MUST NOT record additional metadata that is not explicitly required by local policy.
The UUID generation algorithm used for unique_id MUST ensure that it does not use any potentially personally identifying information. Each instance of a CS-RS Association MUST have a session_id attribute identifying the CS to which it belongs.
An SRC MAY by policy limit the parts of metadata sent to the SRS. The SRS MUST NOT record additional metadata beyond what local policy requires (data minimization principle). UUID generation MUST NOT use personally identifying information, and implementations using Name-Based UUIDs should use a non-PII namespace ID.
Every recording metadata XML document uses the MIME type 'application/rs-metadata+xml' and is rooted in a 'recording' element acting as a container. The document represents either a complete metadata snapshot or a partial update, indicated by the optional 'dataMode' child element ('complete' is the default).
The Communication Session (CS) class, represented by the 'session' XML element, captures the CS as seen by the SRC. Key attributes include session_id (base64 UUID), sipSessionID (per RFC Session-ID), reason (from SIP Reason header with protocol attribute), group-ref, start-time, and stop-time.
The Communication Session Group (CS-Group) class, represented by the 'group' XML element, groups related Communication Sessions (e.g., a transferred call across multiple agents). Its attributes are group_id (base64-encoded UUID, unique across SRCs interacting with the same SRS), associate-time, and disassociate-time.
The CS-RS Association class ('sessionrecordingassoc' element) records the association of a CS to an RS over time. A single CS may be associated with different RSs by different SRCs and may be associated/dissociated multiple times. Its required attribute session_id references the CS; associate-time and disassociate-time mark the period.
The Media Stream class ('stream' element) has attributes: label (referencing SDP 'a=label' identifying the m-line in the RS SDP), content-type (from SDP 'a=content' attribute per RFC 4796), stream_id (base64 UUID), and session_id associating the stream to a CS. The metadata can include streams not delivered to the SRS.
The Participant class ('participant' element) describes a device involved in a CS and/or contributing or consuming media streams. Its attributes are nameID (list of (Name, AoR) tuples where AoR is a SIP/SIPS/tel URI, FQDN, or IP address) and participant_id (base64 UUID). The SRC should create participant objects for all known participants even without direct signaling relationships.
The Participant-CS Association class ('participantsessionassoc' element) records the period and capabilities of a participant's association to a CS. Attributes include associate-time, disassociate-time, param (Contact header capabilities per RFC 3840), participant_id, and session_id. A participant may associate/disassociate multiple times within a session.
The Participant-Stream Association class ('participantstreamassoc' element) describes a participant's association to a media stream as sender, receiver, or both. Attributes include associate-time, disassociate-time, send (points to stream unique_id), recv (points to stream unique_id), and participant_id. Absence of send/recv elements means the participant is neither sending nor receiving.
The Recording Session (RS) class represents a SIP dialog between an SRC and SRS established for recording purposes. It has 'start-time' and 'end-time' attributes derivable from the SIP Date header or dialog setup/teardown times, and is represented by the 'recording' XML element whose SIP/SDP session provides its attributes.
The SIPREC metadata model defines eight classes: Recording Session (RS), Communication Session Group (CS-Group), Communication Session (CS), CS-RS Association, Participant, Participant-CS Association, Media Stream, and Participant-Stream Association. These classes and their associations describe all recorded session metadata as viewed by the SRS.
The SRS may explicitly request a metadata snapshot from the SRC by sending a SIP request containing an XML document with a 'requestsnapshot' top-level element (namespace urn:ietf:params:xml:ns:recording:1) and optional 'requestreason' child element providing a human-readable reason string.
This document registers a new XML namespace URI 'urn:ietf:params:xml:ns:recording:1' and a new XML schema (contained in Section 9) in the IANA XML namespace registry under the SIPREC working group.
Most recording metadata (participant identities, session timing, communication relationships) is private data. Mutual authentication between SRC and SRS and protection of metadata content must follow RFC 7866 procedures. Metadata in storage must be provided a level of security comparable to that of the recording session itself.
Date and time values in 'associate-time', 'disassociate-time', 'start-time', and 'stop-time' XML elements MUST follow the RFC 3339 (IMPP) date-time format. Timestamps containing 'T' or 'Z' MUST use the capitalized forms.
Unique identifiers (session_id, participant_id, stream_id, group_id) are generated by creating a UUID per RFC 4122 (Sections 4.3, 4.4, or 4.5) and then encoding it using base64 per RFC 4648. The result is carried as xs:base64Binary in the XML schema.
XML namespace for all recording metadata elements is 'urn:ietf:params:xml:ns:recording:1'. The version number (1) is embedded in the namespace URI; SRCs and SRSs conforming to this specification MUST use this exact namespace. No version negotiation is provided.