RFC 7865
Session Initiation Protocol (SIP) Recording Metadata
Internet Engineering Task Force (IETF) 🎀 Session Initiation Protocol (SIP) Recording Metadata ✨
Okay bestie, so this one is RFC 7865 💖 It's a Standards Track document from May 2016, and it's giving official spec energy. The authors are R. Ravindranath (Cisco Systems), P. Ravindran (Nokia Networks), and P. Kyzivat (Huawei) 🫶 It's published by the IETF with ISSN 2070-1721. Note that it doesn't say it obsoletes or updates any other RFCs, so it's a fresh standalone spec 🌸
Abstract ✨
Okay, so session recording is literally critical in places like call centers and financial trading orgs 📞💅 In a lot of these environments, every single call has to be recorded for regulatory, compliance, and consumer protection reasons 😭 Usually the recording happens by sending a copy of a media stream to a recording device 🎙️ This doc describes the metadata model as the Session Recording Server (SRS) sees it, plus the recording metadata format 🧚
Status of This Memo 🦋
This is an Internet Standards Track document 💜
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑 If you want more on Internet Standards, check out Section 2 of RFC 7841 🍓
Info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7865 🌈
Copyright Notice 💅
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date 📜 Read these carefully, bestie, because they spell out your rights and restrictions 🙈 Any Code Components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Simplified BSD License ✨
Table of Contents 🧚
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Definitions .....................................................4
4. Metadata Model ..................................................5
5. Recording Metadata Format from SRC to SRS .......................6
5.1. XML Data Format ............................................7
5.1.1. Namespace ...........................................7
5.1.2. 'recording' Element .................................7
6. Recording Metadata Classes ......................................7
6.1. Recording Session ..........................................8
6.1.1. Attributes ..........................................8
6.1.2. Linkages ............................................9
6.2. Communication Session Group ................................9
6.2.1. Attributes .........................................10
6.2.2. Linkages ...........................................10
6.3. Communication Session .....................................11
6.3.1. Attributes .........................................11
6.3.2. Linkages ...........................................12
6.4. CS-RS Association .........................................13
6.4.1. Attributes .........................................14
6.4.2. Linkages ...........................................14
6.5. Participant ...............................................14
6.5.1. Attributes .........................................15
6.5.2. Linkages ...........................................15
6.6. Participant-CS Association ................................16
6.6.1. Attributes .........................................17
6.6.2. Linkages ...........................................17
6.7. Media Stream ..............................................18
6.7.1. Attributes .........................................18
6.7.2. Linkages ...........................................19
6.8. Participant-Stream Association ............................19
6.8.1. Attributes .........................................20
6.8.2. Linkages ...........................................20
6.9. Syntax of XML Elements for Date and Time ..................21
6.10. Format of Unique ID ......................................21
6.11. Metadata Version Indicator ...............................21
7. Recording Metadata Snapshot Request Format .....................22
8. SIP Recording Metadata Examples ................................23
8.1. Complete SIP Recording Metadata Example ...................23
8.2. Partial Update of Recording Metadata XML Body .............25
9. XML Schema Definition for Recording Metadata ...................26
10. Security Considerations .......................................30
11. IANA Considerations ...........................................31
11.1. SIP Recording Metadata Schema Registration ...............31
12. References ....................................................31
12.1. Normative References .....................................31
12.2. Informative References ...................................32
Acknowledgements ..................................................34
Authors' Addresses ................................................341. Introduction 🌸
Session recording is a must-have in lots of comms environments, like call centers and financial trading orgs 📞 In some of these, every call has to be recorded for regulatory, compliance, and consumer protection reasons 😭 Recording usually works by sending a copy of a media stream to a recording device 🎙️
This doc is all about the recording metadata, which describes the Communication Session (CS) 💖 It describes a metadata model as the Session Recording Server (SRS) sees it, plus the recording metadata format ✨ The requirements for all this live in [RFC6341], and the architecture is described in [RFC7245] 🧚
2. Terminology 🦋
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🫶 This doc only uses these key words when it's referencing normative statements in existing RFCs 💅
3. Definitions 💜
Metadata model: A metadata model is an abstract representation of metadata using a Unified Modeling Language (UML) [UML] class diagram 🎀
Metadata classes: Each block in the model is a class 🌈 A class is a blueprint you use to create instances (called "objects") of itself ✨ The description of each class also has a representation of its attributes in a second compartment below the class name 🦋
Attributes: Attributes represent the elements listed in each of the classes 💅 They're listed in the second compartment below the class name. Each instance of a class carries values for that class's attributes, and those values get added to the recording's metadata 🧚
Linkages: Linkages show the relationship between classes in the model 🫶 Each one is a logical connection between classes (or objects) in class diagrams (or object diagrams) 💖 The linkages in this document's metadata model are associations 🌸
This doc also refers to the terminology defined in [RFC6341] 🍓
4. Metadata Model ✨
Metadata is the info that describes the recorded media and the CS they relate to 📼 Here's the model for metadata as an SRS sees it 👑
+-------------------------------+ 1..*
| Recording Session (RS) |----+
+-------------------------------+ |
| 1..* | 1..* |
| | |
| | 0..* |
| +-----------------+ |
+------------+ | | Communication | |
| CS-RS | | | Session Group | |
| Association|--+ | (CS-Group) | |
| | | +-----------------+ |
+------------+ | | 0..1 |
| | |
| 0..* | 1..* |
+-------------------------------+ |
| Communication Session (CS) | |
| | |
+-------------------------------+ |
| 1..* | 0..1 |
+-----+ | |
| | 0..* | 0..* | 0..*
| +-------------+ receives +----------------+ |
| | Participant |----------| Media Stream |--+
| | |0..* 0..*| |
| | | | |
| | | | |
| | | sends | |
| | |----------| |
| | |1.* 0..*| |
| +-------------+ +----------------+
| | |
| | |
| +------------------------+------------+
| |
| |
| +------------------+ +----------------------+
| |Participant-CS | | Participant-Stream |
+-----------| Association | | Association |
| | | |
+------------------+ +----------------------+The metadata model is a UML class diagram 🧠 It shows the structure of metadata in general by listing the classes, their attributes, and how the classes relate to each other 💅 Each block in the model above is a class 🎀 The linkages between classes are the relationships, which can be associations or compositions 🦋 The metadata goes from the Session Recording Client (SRC) to the SRS 🫶
The model lets metadata about CSs get communicated to the SRS as a series of snapshots 📸 Each snapshot is the state as seen by one SRC at one particular instant 🕰️ When metadata changes from one snapshot to the next, that reflects a change in what's being recorded ✨ For example, if a participant joins a conference, the SRC sends the SRS a snapshot with that participant's info (attributes like the (Name, AoR) tuple and associate-time) 🧚 (Note: "AoR" means "Address-of-Record".) 💖
Some metadata doesn't have to be sent explicitly from the SRC to the SRS, if the SRS can get it from context (e.g., from SIP or Session Description Protocol (SDP) signaling) 🌈 For example, the label attribute within the stream XML element points to an SDP a=label attribute, which identifies an m-line within the Recording Session (RS) SDP 🍓 The SRS learns the media properties from that media line 🔥
Part 1 of 6 is done, bestie! 🎀 Five more parts are coming, so stay tuned 💜
5. Recording Metadata Format from SRC to SRS ✨
okay so this section is the overview of the recording metadata format, and it's giving "how do we pass the vibes between SRC and SRS" 💅 Some of the metadata model is assumed to already be available to the SRS through SDP [RFC4566], so it doesn't get repeated in the XML document format defined here 🫶 SDP attributes describe media formats like audio and video. Everything else, like participant details, lives in a brand new recording-specific XML document of type application/rs-metadata+xml 🎀 The SDP "label" attribute [RFC4574] is the ID that lets a metadata XML document point at a specific media description in the SDP the SRC sent to the SRS. Iconic linking 🦋
The XML document can carry either the complete metadata or a partial update. A partial update only includes the elements that changed since the last metadata that was reported 🌸
5.1. XML Data Format
Every recording metadata XML document the SRC sends to the SRS has a 'recording' element 👑 That element is the container for all the other elements in the doc. A 'recording' object is an XML document, so it starts with an XML declaration and includes an encoding declaration in there, for example <?xml version="1.0" encoding="UTF-8"?> ✨ If the charset parameter on the MIME content type is present and it's different from the encoding declaration, the charset parameter wins 💜
Every application conforming to this specification MUST accept the UTF-8 character encoding to ensure minimal interoperability. Non-negotiable, bestie 🔥
Syntax and semantic errors in an XML document should be reported to the originator, using application-specific mechanisms 🙈
5.1.1. Namespace
With the following URN, this document defines a new namespace URI for the elements defined here 🌈
urn:ietf:params:xml:ns:recording:15.1.2. 'recording' Element
The 'recording' element MUST contain an xmlns namespace attribute with a value of urn:ietf:params:xml:ns:recording:1. Exactly one 'recording' element MUST be present in every recording metadata XML document. Main character energy, one per doc 👑
A 'recording' element MAY contain a 'dataMode' element that says whether the XML document is a complete document or a partial update. If there's no 'dataMode' element, the default value is "complete" 🍓
6. Recording Metadata Classes 🦋
This section breaks down each class in the metadata model, plus the attributes for each one. It also explains how the classes link together and which XML element represents each of them 🧚
6.1. Recording Session
+-------------------------------+
| Recording Session (RS) |
+-------------------------------+
| | 1..* 0..*
| start-time |-------------- Media Stream
| end-time |
| |
| |
+-------------------------------+
| 1..* | 1..*
| |
| 0..* | 0..*
Communication Communication
Session (CS) Session Group (CS-Group)Each instance of an RS class, the RS object, represents a SIP session created between an SRC and SRS for the purpose of recording a CS 🎀 The RS object is represented in the XML schema by the 'recording' element, which relies on the SIP/SDP session the XML document is associated with to supply the attributes of the RS element 💖
6.1.1. Attributes
An RS class has the following attributes:
- start-time - Represents the start time of an RS object.
- end-time - Represents the end time of an RS object.
The 'start-time' and 'end-time' values can be derived from the Date header (if it's present in the SIP message) in the RS. If the Date header isn't there, 'start-time' is derivable from the time the SRS receives the notification of the SIP message that sets up the RS, and 'end-time' is derivable from the time the SRS receives a disconnect on the RS SIP dialog 🫶
6.1.2. Linkages
Each instance of an RS has:
- Zero or more instances of CS-Groups.
- Zero or more instances of CS objects.
- Zero or more instances of MediaStream objects.
Zero instances of CSs and CS-Groups in a 'recording' element are allowed, so persistent recording scenarios work 🌸 A persistent RS is a SIP dialog set up between the SRC and the SRS even before any CS is set up. The metadata the SRC sends when that persistent RS SIP dialog gets set up may not have any CS (or related CS-Group) elements in the XML, because there may not be a session linked to the RS yet 🙈 For example, a phone acting as an SRC can set up an RS with the SRS, possibly even before the phone is part of a CS. Once the phone joins a CS, that same RS gets used to convey the CS metadata. Efficiency is my love language 😭
6.2. Communication Session Group
Recording Session (RS)
| 1..*
|
| 0..*
+-------------------------------+
| Communication Session |
| Group (CS-Group) |
+-------------------------------+
| group_id |
| associate-time |
| disassociate-time |
| |
+-------------------------------+
| 0..1
|
| 1..*
Communication Session (CS)One instance of a CS-Group class, the CS-Group object, provides the association or grouping of all related CSs 🧚 Like, in a contact center flow, a call can get transferred to multiple agents, and each of those can trigger the setup of a new CS. If the SRC knows which CSs are related, it can group them using the CS-Group element. The CS-Group object is represented in the XML schema by the 'group' element 🌈
6.2.1. Attributes
A CS-Group has the following attributes:
- group_id - This attribute groups different CSs that are related. The SRC (or the SRS) is responsible for ensuring the uniqueness of
'group_id'in cases where multiple SRCs interact with the same SRS. The mechanism by which the SRC groups the CS is outside the scope of this document 💅 - associate-time - This is the time when a grouping is formed. The rules that determine how the SRC does a grouping of different CS objects are outside the scope of this document ✨
- disassociate-time - The
'disassociate-time'for the CS-Group is calculated by the SRC as the time when the grouping ends 🦋
6.2.2. Linkages
The linkages between a CS-Group class and other classes are associations. A CS-Group is associated with the RS and CS in the following ways:
- There are one or more RS objects per CS-Group.
- Each CS-Group object has to be associated with one or more RSs. Each RS can be set up by potentially different SRCs 👑
- There are one or more CSs per CS-Group (for example, in cases where the call is transferred). A CS cannot be associated with more than one CS-Group 🔥
6.3. Communication Session
Recording Communication
Session (RS) Session Group (CS-Group)
| 1..* | 0..1
| |
| 0..* | 1..*
+-------------------------------+
| Communication Session (CS) |
+-------------------------------+
| session_id |
| sipSessionID |
| reason |
| group-ref |
| start-time |
| stop-time |
+-------------------------------+
| |
| 0..* | 0..1
| |
| 0..* | 0..*
Participant Media StreamA CS class and its object in the metadata model represent the CS and its properties as the SRC sees them. The CS object is represented in the XML schema by the 'session' element 🎀
6.3.1. Attributes
A CS class has the following attributes:
- session_id - This attribute is used to uniquely identify an instance of a CS object, namely the
'session'XML element within the metadata XML document.'session_id'is generated using the rules mentioned in Section 6.10 🫶 - reason - This represents the reason a CS was terminated. The value is derived from the SIP Reason header [RFC3326] of the CS. There MAY be multiple instances of the
'reason'XML element inside a'session'element. The'reason'XML element has'protocol'as an attribute, which indicates the protocol the reason string is derived from. The default value for the'protocol'attribute is "SIP". The'reason'element can be derived from a SIP Reason header in the CS 💖 - sipSessionID - This attribute carries a SIP Session-ID as defined in [SessionID]. Each CS object can have zero or more
'sipSessionID'elements, and more than one'sipSessionID'attribute may be present in a CS. For example, if three participants (A, B, and C) are in a conference that has a focus acting as an SRC, the metadata the SRC sends to the SRS will likely have three'sipSessionID'elements, one for each of the SIP dialogs the focus has with each of the three participants 🌸 - group-ref - A
'group-ref'attribute MAY be present to indicate the group (identified by'group_id') that the enclosing session belongs to 🍓 - start-time - This optional attribute represents the start time of the CS as seen by the SRC 🧚
- stop-time - This optional attribute represents the stop time of the CS as seen by the SRC 🌈
This document doesn't specify attributes for what should happen to a recording of a CS after it has been delivered to the SRS (for example, how long to keep the recording or what access controls to apply). The SRS is assumed to behave according to its local policy. The ability of the SRC to influence that policy is outside the scope of this document. However, if there are implementations where the SRC wants to specify its own policy preferences, that information could be sent as extension data attached to the CS 💅✨
6.3.2. Linkages ✨
okay so a CS gets linked to the CS-Group, participant, MediaStream (MS), and RS classes using the association relationship 💖. the CS and participant association gives you:
- A CS will have zero or more participants.
- A participant is associated with zero or more CSs. This includes participants who aren't directly part of any CS 👀. An example is participants in a pre-mixed media stream. The SRC may know about these participants but have no signaling relationship with them. This might happen if one participant in a CS is a conference focus. To sum it up, even if the SRC doesn't have direct signaling relationships with every participant in a CS, it should nevertheless create a participant object for each participant it knows about 🫶.
- The model also allows participants in a CS who aren't participants in the media 🧚. An example is the identity of a Third Party Call Control (3pcc) that started a CS with two or more participants in the CS. Another example is the identity of a conference focus. Of course, a focus is probably in the media, but since it may only be there as a mixer, it may not report itself as a participant in any of the media streams.
the association between the CS and the media stream gives you:
- A CS will have zero or more streams.
- A stream can be associated with at most one CS. A stream in a persistent RS doesn't have to be associated with any CS before the CS is created, so zero association is allowed 🌸.
and the association between the CS and the RS gives you:
- Each instance of an RS has zero or more instances of CS objects.
- Each CS has to be associated with one or more RSs. Each RS can potentially be set up by different SRCs 🌈.
6.4. CS-RS Association 🦋
1..* 0..*
Recording Communication
Session ----------+---------- Session
|
|
|
+-----------------------+
| CS-RS Association |
| |
+-----------------------+
| associate-time |
| disassociate-time |
| session_id |
+-----------------------+the CS-RS Association class describes a CS being associated with an RS for a period of time. A single CS can be associated with different RSs (maybe by different SRCs), and it can be associated and dissociated several times 🔥. It's represented in XML using the 'sessionrecordingassoc' XML element.
6.4.1. Attributes 💅
The CS-RS Association class has these attributes:
associate-timeis calculated by the SRC as the time it sees a CS associated to an RS.disassociate-timeis calculated by the SRC as the time it sees a CS disassociate from an RS.session_id: each instance of this class MUST have a'session_id'attribute that identifies the CS this association belongs to 🎀.
6.4.2. Linkages
The CS-RS Association class is linked to the CS and RS classes ✨.
6.5. Participant 🌸
Communication Session (CS)
| 0..*
|
| 0..*
+-------------------------------+
| Participant |
+-------------------------------+
| nameID |
| participant_id |
| |
+-------------------------------+
| 0..* 1..* |
receives| |sends
| 0..* 0..* |
Media Streama participant class and its objects hold info about a device that's part of a CS and/or that contributes to or consumes media stream(s) belonging to a CS 💜. It's represented in the XML schema using the 'participant' element.
6.5.1. Attributes 🦋
A participant class has two attributes:
nameIDis a list of (Name, AoR) tuples. An AoR (Section 6 of [RFC3261]) can be a SIP/SIPS/tel URI ("SIPS" means "SIP Secure"; the tel URI is discussed in [RFC3966]), a Fully Qualified Domain Name (FQDN), or an IP address 🌈. For example, the AoR may be pulled from theFromheader field or theP-Asserted-Identityheader [RFC3325] field. The SRC's local policy decides where the AoR gets drawn from. The Name parameter is the participant name (SIP display name) or the dialed number (when known). Multiple tuples are allowed for cases where a participant has more than one AoR. For example, aP-Asserted-Identityheader can have both SIP and tel URIs 🙈.participant_ididentifies the'participant'XML element within the XML document. It's generated using the rules in Section 6.10. This attribute MUST be used for all references to a participant within a CS-Group, and it MAY be used to reference the same participant more globally 👑.
This document doesn't specify other attributes about participants (e.g., participant role, participant type). An SRC that has info on these can pass it along as extension data in the 'participant' XML element from the SRC to the SRS 💀.
6.5.2. Linkages
The participant class is linked to the MS and CS classes using an association relationship. The association between the participant and the MS allows the following:
- A participant will receive zero or more media streams.
- A participant will send zero or more media streams. (The same participant can provide multiple streams, e.g., audio and video 🎧.)
- A media stream will be received by zero or more participants. It's possible, though maybe unlikely, for a stream to be generated but sent only to the SRC and SRS, not to any participant. For example, in a conference where everyone's on hold and the SRC is collocated with the focus 😭. Also, a media stream may be received by multiple participants (e.g., "whisper" calls, side conversations) 🤫.
- A media stream will be sent by one or more participants (pre-mixed streams).
An example of a participant receiving zero or more streams is a supervisor having a side conversation with an agent while the agent chats with a customer 🎀.
6.6. Participant-CS Association 💖
1..* 0..*
Communication
Session -----------+----------- Participant
|
|
|
+---------------------------+
| Participant-CS Association|
| |
| |
+---------------------------+
| associate-time |
| disassociate-time |
| param |
| participant_id |
| session_id |
+---------------------------+the Participant-CS Association class describes a participant being associated with a CS for a period of time. A participant can be associated to and dissociated from a CS several times (like joining a conference, leaving, then joining again) 🦋.
The Participant-CS Association object is represented in the XML schema using the 'participantsessionassoc' element.
6.6.1. Attributes ✨
The Participant-CS Association class has these attributes:
associate-timeis calculated by the SRC as the time it sees a participant associated to a CS.disassociate-timeis calculated by the SRC as the time it sees a participant disassociate from a CS. A given participant can have multiple associate times and disassociate times within the same communication session 🔁.param: the capabilities here are the ones indicated in the Contact header as defined in Section 9 of [RFC3840]. For example, in a CS (which can be a conference), you can have participants playing the role of "focus" 👑. These participants don't contribute media to the CS; however, they switch the media received from one participant to every other participant in the CS. Indicating the capabilities of participants (here, "focus") would be useful for the recorder to learn about these kinds of participants 🧠. The capabilities are represented using the'param'XML element in the metadata. The'param'XML element encoding defined in [RFC4235] is used to represent the capability attributes in metadata. Each participant may have zero or more capabilities. A participant may use different capabilities depending on the role it plays at a particular instance, for example if a participant moves across different CSs (e.g., due to transfer) or is present in different CSs at the same time with different roles 🌀.participant_ididentifies the participant this association belongs to.session_ididentifies the session this association belongs to.
6.6.2. Linkages
The Participant-CS Association class is linked to the participant and CS classes 🫶.
6.7. Media Stream 🌈
Participant
| 0..* 1..* |
receives| |sends
| 0..* 0..* |
+-------------------------+
| Media Stream |
0..1 0..* +-------------------------+
Communication ------------| |
Session | label |
| content-type |
| stream_id |
| session_id |
+-------------------------+
0..* |
|
|
1..* |
Recording Sessiona MS class (and its objects) has the properties of media as the SRC sees it and sends it to the SRS 🎬. Different snapshots of MS objects may be sent whenever the media changes (e.g., a direction change like pause/resume, a codec change, and/or a participant change) 💫. The MS object is represented in the XML schema using the 'stream' element 💜.
6.7.1. Attributes
okay so a MS class has the following attributes 💖
label- thelabelattribute inside thestreamXML element points at an SDPa=labelattribute 🏷️ that identifies an m-line in the RS SDP. That m-line carries the media stream from the SRC to the SRS 🦋content-type- the content of a MS element gets described using thea=contentattribute from Section 5 of [RFC4796] 🎀 If the SRC wants the SRS to know the content-type, it adds ana=contentattribute to the m-line in the RS SDP 💅stream_id- everystreamelement has its own uniquestream_idattribute, which helps identify the stream ✨ It gets generated using the rules in Section 6.10 🌸session_id- this one ties the stream to a specificsessionelement 🧚
the metadata model can include media streams that are not being delivered to the SRS, and this is so real 😭 for example, an SRC offers audio and video to an SRS that only accepts audio in response. The metadata snapshots the SRC sends to the SRS can keep showing the changes to the video stream too 🎬
6.7.2. Linkages
a MS class is linked to the participant and CS classes through the association relationship 🔗 The participant details are in Section 6.5, and the CS details are in Section 6.3. main character energy 👑
6.8. Participant-Stream Association
+-------------------------+
| Participant-Stream |
| Association |
+-------------------------+ +-----------Participant
| associate-time | | 0..* | 1..* |
| disassociate-time |---+ receives| |sends
| send | | 0..* | 0..* |
| recv | | | |
| participant_id | | | |
+-------------------------+ | | |
+-----------Media Streama Participant-Stream Association class describes how a participant is associated with a MS for a period of time 🦋 The participant can be a sender, a receiver, or both 💜
This class is represented in XML using the participantstreamassoc element 🎀
6.8.1. Attributes
a Participant-Stream Association class has the following attributes 💅
associate-time- this tells you the time a participant started contributing to a MS 🌸disassociate-time- this tells you the time a participant stopped contributing to a MS 🥀send- this tells you whether a participant is contributing to a stream or not 🎤 This attribute has a value that points to a stream, represented by its unique_id. Having the attribute present means the participant is contributing to that stream. If a participant stops contributing to a stream because of changes in a CS, a snapshot MUST be sent from the SRC to the SRS with nosendelement for that stream 🙈recv- this tells you whether a participant is receiving a media stream or not 👂 This attribute has a value that points to a stream, represented by its unique_id. Having the attribute present means the participant is receiving that stream. If the participant stops receiving a stream because of changes in a CS (like hold), a snapshot MUST be sent from the SRC to the SRS with norecvelement for that stream 🫶participant_id- this points to the participant that astreamelement is associated with 🧚
the participantstreamassoc XML element is how we represent a participant's association with a stream 💖 The send and recv XML elements MUST be used to indicate whether a participant is contributing to a stream or receiving a stream 📣 There MAY be multiple instances of the send and recv XML elements inside a participantstreamassoc element 🍓 If a metadata snapshot is sent with a participantstreamassoc element that has no send and no recv elements, it means the participant is neither contributing to any streams nor receiving any streams 💀
6.8.2. Linkages
the Participant-Stream Association class is linked to the participant and MS classes 🔗
6.9. Syntax of XML Elements for Date and Time
the XML elements associate-time, disassociate-time, start-time, and stop-time contain strings that represent the date and time ⏰ The value of these elements MUST follow the Instant Messaging and Presence Protocol (IMPP) date-time format [RFC3339]. Timestamps that contain "T" or "Z" MUST use the capitalized forms 🌈
As a security measure, the timestamp element MUST be included in all tuples, unless the exact time of the status change cannot be determined. 🔐
6.10. Format of Unique ID
a unique_id gets generated in two steps 🦋
- First, the Universally Unique Identifier (UUID) is created using any of the procedures in Sections 4.3, 4.4, and 4.5 of [RFC4122]. The algorithm MUST ensure that it does not use any potentially personally identifying information to generate the UUIDs 🙈 If implementations are using a Name-Based UUID as defined in Section 4.3 of [RFC4122], a namespace ID generated using the guidance in Section 4.2 or 4.5 of [RFC4122] might be a good choice 🌸
- Second, the UUID is encoded using base64 as defined in [RFC4648] 🎀
the unique_id mechanism described above SHOULD be used for each metadata element ✨ Multiple SRCs can refer to the same element/UUID (how each SRC learns the UUID here is beyond the scope of this document) 🤷♀️ 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 🚨 For example, the SRS may choose to reject or ignore the portions of metadata where it detects that the same UUID is mapped to an element that is different than the expected element. (The SRS learns the mapped UUID when it sees an element for the first time in a metadata instance.) this is the part where the details matter, bestie 💅
6.11. Metadata Version Indicator
the Metadata version exists so the SRC and SRS can know which version of the metadata XML schema is being used 📚 SRCs and SRSs that support this specification MUST use version 1 in the namespace urn:ietf:params:xml:ns:recording:1 in all the XML documents 💜 Implementations may not interoperate if the receiver does not know the version the sender implemented 😬 No negotiation of versions is provided. The version number has no significance, although documents that update or obsolete this document (possibly including drafts of such documents) should include a higher version number if the metadata XML schema changes 🌟
7. Recording Metadata Snapshot Request Format
the SRS can explicitly request a metadata snapshot from the SRC 🙋♀️ To request one, the SRS MUST send a SIP request message with an XML document that has the namespace urn:ietf:params:xml:ns:recording:1. The XML document has the following elements:
- A
requestsnapshotXML element MUST be present as the top-level element in the XML document 👑 - A
requestreasonXML element, which gives the reason (as a string) for requesting the snapshot, MAY be present as a child XML element ofrequestsnapshot🎀
the example below shows a metadata snapshot request from the SRS 💖
<?xml version="1.0" encoding="UTF-8"?>
<requestsnapshot xmlns='urn:ietf:params:xml:ns:recording:1'>
<requestreason xml:lang="it">SRS internal error</requestreason>
</requestsnapshot>Example Metadata Snapshot Request from SRS to SRC 📨
8. SIP Recording Metadata Examples
8.1. Complete SIP Recording Metadata Example
okay, this one is the full vibe ✨ The following example provides all the tuples involved in the recording metadata XML body 🧁
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>complete</datamode>
<group group_id="7+OTCyoxTmqmqyA/1weDAg==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
<!-- Standardized extension -->
<call-center xmlns='urn:ietf:params:xml:ns:callcenter'>
<supervisor>sip:alice@atlanta.com</supervisor>
</call-center>
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</group>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>ab30317f1a784dc48ff824d0d3715d86;
remote=47755a9de7794ba387653f2099600ef2</sipSessionID>
<group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</session>
<participant participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor="sip:bob@biloxi.com">
<name xml:lang="it">Bob</name>
</nameID>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</participant>
<participant participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor="sip:Paul@biloxi.com">
<name xml:lang="it">Paul</name>
</nameID>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</participant>
<stream stream_id="UAAMm5GRQKSCMVvLyl4rFw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>97</label>
</stream>
<stream stream_id="8zc6e0lYTlWIINA6GR+3ag=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>98</label>
</stream>
<stream stream_id="EiXGlc+4TruqqoDaNE76ag=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>99</label>
</stream>
<sessionrecordingassoc session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</sessionrecordingassoc>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
</recording>Example Metadata Snapshot from SRC to SRS 🎞️
8.2. Partial Update of Recording Metadata XML Body 🦋
okay so this example shows a partial update to the recording metadata XML body, building on the example we just looked at. the snapshot only carries the disassociate-time for one participant leaving a session, so it's the bare minimum needed to say "this person left" 🌸
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<participant
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor="sip:bob@biloxi.com">
<name xml:lang="it">Bob</name>
</nameID>
</participant>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
</recording>Partial Update of SIP Recording Example XML Body 💅
9. XML Schema Definition for Recording Metadata ✨
this section is the schema itself 🧚 it defines the XML schema for the recording metadata document, so if you want the exact rules for what's valid, it's all right here.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:recording:1"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:recording:1"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang -->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="https://www.w3.org/2001/xml.xsd"/>
<xs:element name="recording" type="tns:recording"/>
<xs:complexType name="recording">
<xs:sequence>
<xs:element name="datamode" type="tns:dataMode"
minOccurs="0"/>
<xs:element name="group" type="tns:group"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="session" type="tns:session"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="participant" type="tns:participant"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="stream" type="tns:stream"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="sessionrecordingassoc"
type="tns:sessionrecordingassoc"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="participantsessionassoc"
type="tns:participantsessionassoc"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="participantstreamassoc"
type="tns:participantstreamassoc"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="group">
<xs:sequence>
<xs:element name="associate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="disassociate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="group_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="session">
<xs:sequence>
<xs:element name="sipSessionID" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="reason" type="tns:reason"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="group-ref" type="xs:base64Binary"
minOccurs="0" maxOccurs="1"/>
<xs:element name="start-time" type="xs:dateTime"
minOccurs="0" maxOccurs="1"/>
<xs:element name="stop-time" type="xs:dateTime"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="session_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="sessionrecordingassoc">
<xs:sequence>
<xs:element name="associate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="disassociate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="session_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="participant">
<xs:sequence>
<xs:element name="nameID" type="tns:nameID"
maxOccurs='unbounded'/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="participant_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="participantsessionassoc">
<xs:sequence>
<xs:element name="associate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="disassociate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="param" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="pname" type="xs:string"
use="required"/>
<xs:attribute name="pval" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="participant_id" type="xs:base64Binary"
use="required"/>
<xs:attribute name="session_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="participantstreamassoc">
<xs:sequence>
<xs:element name="send" type="xs:base64Binary"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="recv" type="xs:base64Binary"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="associate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="disassociate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="participant_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="stream">
<xs:sequence>
<xs:element name="label" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="stream_id" type="xs:base64Binary"
use="required"/>
<xs:attribute name="session_id" type="xs:base64Binary"/>
</xs:complexType>
<xs:simpleType name="dataMode">
<xs:restriction base="xs:string">
<xs:enumeration value="complete"/>
<xs:enumeration value="partial"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="nameID">
<xs:sequence>
<xs:element name="name" type ="tns:name" minOccurs="0"
maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="aor" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="name">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="reason">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute type="xs:short" name="cause" use="required"/>
<xs:attribute type="xs:string" name="protocol" default="SIP"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="requestsnapshot" type="tns:requestsnapshot"/>
<xs:complexType name="requestsnapshot">
<xs:sequence>
<xs:element name="requestreason" type="tns:name"
minOccurs="0"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
</xs:complexType>
</xs:schema>10. Security Considerations 🔐
okay, security time, and this one is seriously important bestie 😭 this document describes a super extensive set of metadata that may be recorded by the SRS, and honestly most of it could be considered private data. so the procedures in the Security Considerations section of [RFC7866] MUST be followed by the SRC and the SRS, both for mutual authentication and to protect the content of the metadata in the RS. no skipping, no cap 🫶
an SRC MAY, by policy, choose to limit the parts of the metadata it sends to the SRS for recording 🌈 and the SRS policy might not require recording all the metadata it gets. for the sake of data minimization, the SRS MUST NOT record additional metadata that is not explicitly required by local policy. this is the data-hoarding rule, and it's a big deal 💜
metadata sitting in storage needs to be protected at a level that is comparable to the recording session itself. treat it like the call, because it basically is. 🔥
11. IANA Considerations 🍓
this specification registers a new XML namespace and a new XML schema, so IANA gets some new entries to keep track of 🎀
11.1. SIP Recording Metadata Schema Registration 🌸
URI: urn:ietf:params:xml:ns:recording:1- Registrant Contact: IETF SIPREC working group, Ram Mohan R (rmohanr@cisco.com)
- XML: the registered XML schema is contained in Section 9. its first line is
<?xml version="1.0" encoding="UTF-8"?>, and its last line is</xs:schema>. ✨
12. References 📚
12.1. Normative References 📚✨
okay bestie, these are the must-reads 💅 the docs this whole spec leans on. if you skip one, the rest of the spec gets confusing fr 💀
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<http://www.rfc-editor.org/info/rfc3339>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840,
DOI 10.17487/RFC3840, August 2004,
<http://www.rfc-editor.org/info/rfc3840>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
DOI 10.17487/RFC4122, July 2005,
<http://www.rfc-editor.org/info/rfc4122>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description
Protocol (SDP) Label Attribute", RFC 4574,
DOI 10.17487/RFC4574, August 2006,
<http://www.rfc-editor.org/info/rfc4574>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>.
[RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description
Protocol (SDP) Content Attribute", RFC 4796,
DOI 10.17487/RFC4796, February 2007,
<http://www.rfc-editor.org/info/rfc4796>.
[RFC7866] Portman, L., Lum, H., Ed., Eckel, C., Johnston, A., and A.
Hutton, "Session Recording Protocol", RFC 7866,
DOI 10.17487/RFC7866, May 2016,
<http://www.rfc-editor.org/info/rfc7866>.12.2. Informative References 🌸
these ones are the extra-credit reading 🤓 super helpful for the bigger picture, but the spec still works without them. no cap 🧚
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
DOI 10.17487/RFC3325, November 2002,
<http://www.rfc-editor.org/info/rfc3325>.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, DOI 10.17487/RFC3326, December 2002,
<http://www.rfc-editor.org/info/rfc3326>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, DOI 10.17487/RFC3966, December 2004,
<http://www.rfc-editor.org/info/rfc3966>.
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An
INVITE-Initiated Dialog Event Package for the Session
Initiation Protocol (SIP)", RFC 4235,
DOI 10.17487/RFC4235, November 2005,
<http://www.rfc-editor.org/info/rfc4235>.
[RFC6341] Rehor, K., Ed., Portman, L., Ed., Hutton, A., and R. Jain,
"Use Cases and Requirements for SIP-Based Media Recording
(SIPREC)", RFC 6341, DOI 10.17487/RFC6341, August 2011,
<http://www.rfc-editor.org/info/rfc6341>.
[RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor,
"An Architecture for Media Recording Using the Session
Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245,
May 2014, <http://www.rfc-editor.org/info/rfc7245>.
[SessionID]
Jones, P., Salgueiro, G., Pearce, C., and P. Giralt,
"End-to-End Session Identification in IP-Based Multimedia
Communication Networks", Work in Progress,
draft-ietf-insipid-session-id-22, April 2016.
[UML] Object Management Group, "OMG Unified Modeling Language
(UML)", 2011, <http://www.omg.org/spec/UML/2.4/>.Acknowledgements 🫶💖
big group hug to everyone who gave their time, brainpower and honest feedback 🥹 the list is long and every name is so appreciated: John Elwell, Henry Lum, Leon Portman, De Villiers de Wet, Andrew Hutton, Deepanshu Gautam, Charles Eckel, Muthu Arul Mozhi Perumal, Michael Benenson, Hadriel Kaplan, Brian Rosen, Scott Orton, Ofir Roth, Mary Barnes, Ken Rehor, Gonzalo Salgueiro, Yaron Pdut, Alissa Cooper, Stephen Farrell, and Ben Campbell 🌈
and a special shoutout to Joe Hildebrand, Peter Saint-Andre, and Matt Miller for helping write the XML schema 🎀, plus Martin Thomson for validating that schema and dropping comments on it too 👑 literally the dream team 😭
Authors' Addresses 🦋
the people who actually wrote this, with their contact details 💌
Ram Mohan Ravindranath
Cisco Systems
Cessna Business Park
Bangalore, Karnataka
India
Email: rmohanr@cisco.com
Parthasarathi Ravindran
Nokia Networks
Bangalore, Karnataka
India
Email: partha@parthasarathi.co.in
Paul Kyzivat
Huawei
Hudson, MA
United States
Email: pkyzivat@alum.mit.eduthat's the whole doc, babe 🎉 the protocol is officially yours to slay 💜
📦 where this page comes from
- ietf: rfc7865 2016-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms