RFC 6341

Use Cases and Requirements for SIP-Based Media Recording (SIPREC)

📅 published August 2011, from ietf

RFC 6341 🎀 The Title Block Tea

okay bestie, so this is RFC 6341 🦋, and the title is "Use Cases and Requirements for SIP-Based Media Recording (SIPREC)." It's from the IETF (Internet Engineering Task Force) and it's dated August 2011. The category is Informational, which means it's published for info and is not a standards track spec 💅. The ISSN is 2070-1721 ✨.

The authors are K. Rehor (Cisco Systems) and L. Portman (NICE Systems), who are both listed as editors, plus A. Hutton (Siemens Enterprise Communications) and R. Jain (IPC Systems) 🫶. The title block doesn't say it obsoletes or updates any other RFC, so no drama there 💜.

Abstract 💖

Session recording is a total necessity in lots of business comms environments, like call centers and financial trading floors 📞. In some of these places, every single call has to be recorded for regulatory and compliance reasons 😭. In others, calls might get recorded for quality control or business analytics 🧐.

Recording usually works by sending a copy of the session media to the recording devices 🎧. This document lays out requirements for extensions to SIP that will manage delivery of RTP media to a recording device, and the team is calling this SIP-based Media Recording ✨.

Status of This Memo 🌸

Okay, so this document is not an Internet Standards Track specification. It's published purely for info 🙈.

It is still a product of the IETF, which means it represents the consensus of the IETF community and got public review and approval from the Internet Engineering Steering Group (IESG) 🔥. Not every IESG-approved doc is a candidate for any level of Internet Standard though, so check Section 2 of RFC 5741 for the details 💅.

For the current status, any errata, or how to give feedback, go to http://www.rfc-editor.org/info/rfc6341 🦋.

Copyright (c) 2011 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 stand on the publication date. Read these carefully, because they spell out your rights and restrictions for this doc 📜. Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're also provided without warranty, as described in the Simplified BSD License ⚠️.

Table of Contents 🧚

   1. Introduction ....................................................2
   2. Requirements Notation ...........................................4
   3. Definitions .....................................................4
   4. Use Cases .......................................................5
   5. Requirements ...................................................10
   6. Privacy Considerations .........................................13
   7. Security Considerations ........................................14
   8. Acknowledgements ...............................................15
   9. Normative References ...........................................15

1. Introduction ✨

Okay, so session recording is a critical operational requirement for lots of businesses, especially where voice is the medium for commerce and customer support 🎙️. The financial industry is the big example of voice used for trade, and its call recording requirements are super strict 💀. Those recorded calls get used for dispute resolution and compliance 🧾. Other businesses, like customer support call centers, usually record calls for quality control or business analytics, but with different requirements 📊.

Depending on the country and its regulations, financial trading floors typically must record all calls 😤. Call centers, on the other hand, typically only record a subset of their calls, and calls must not fail no matter whether the recording device is available 🫠.

Respecting the privacy rights and wishes of people on a call is of paramount importance 🫶. In many jurisdictions, participants have a right to know the session is being recorded (or might be), and they have a right to opt out, either by ending the call or by asking that it not be recorded 🙅‍♀️. So this document has requirements for notifying users that a call is being recorded, and for letting users request that a call not be recorded 💖. Use cases where people on a call are not told that it is or might be recorded are outside the scope of this document 🚫. Lawful intercept in particular is outside the scope too 🙈.

Also, a one-size-fits-all model won't fit every market 💅. Scale and cost burdens vary a lot, and needs differ for capabilities like media injection, transcoding, and security 🧩. If a standardized solution supports every requirement from every recording market, but that would be too expensive for markets with lesser needs, then proprietary solutions for those markets will keep popping up 😩. So care must be taken to make a standards-based solution support optionality and flexibility 🌸.

This document lays out requirements for using SIP [RFC3261] between a Session Recording Client and a Session Recording Server, so they can control the recording of media that was transmitted in the context of a Communication Session 📞. A Communication Session is the "call" between participants 💜. The Session Recording Client is the source of the recorded media 🎬. The Session Recording Server is the sink for the recorded media 🪣. It's worth noting that the protocol between a Session Recording Server and a Session Recording Client has very similar requirements to regular SIP media sessions, like codec and transport negotiation, encryption key interchange, and firewall traversal 🔐. Picking SIP for session recording means reusing an existing protocol, which is honestly iconic 👑.

The recorded sessions can be any RTP media sessions, including voice, dual-tone multifrequency (DTMF) (as defined by [RFC4733]), video, and text (as defined by [RFC4103]) 🎶.

An archived session recording usually has two parts: the Communication Session media content and the Communication Session Metadata 🗂️. The metadata is what lets recording archives be searched and filtered later, and lets a session be played back in a meaningful way, like with correct synchronization between the media ⏯️. The Communication Session Metadata needs to be conveyed from the Session Recording Client to the Session Recording Server 📨.

This document only considers active recording, where the Session Recording Client purposefully streams media to a Session Recording Server 🦋. Passive recording, where a recording device detects media directly from the network, is outside the scope of this document 🙅‍♀️.

2. Requirements Notation 💅

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]. They indicate the requirement levels for compliant mechanisms 🔥.

3. Definitions 🧚

Okay, here are the key terms, and they're honestly the foundation for everything else 🫶.

Session Recording Server (SRS): An SRS is a SIP User Agent (UA) that is a specialized media server or collector, and it acts as the sink of the recorded media 🪣. It's typically a multi-port device that can receive media from multiple sources at the same time 🔌. An SRS is also the sink of the recorded session metadata 🗃️.

Session Recording Client (SRC): An SRC is a SIP User Agent (UA) that acts as the source of the recorded media and sends it to the SRS 🎬. An SRC is a logical function, and its capabilities may be spread across one or more physical devices 🧩. In practice, an SRC could be a personal device (like a SIP phone), a SIP Media Gateway (MG), a Session Border Controller (SBC), or a SIP Media Server (MS) integrated with an Application Server (AS) 📱. This spec defines the term "SRC" so all of those SIP entities can be addressed generically under one definition 🌈. The SRC provides metadata to the SRS 📨.

Communication Session (CS): A session created between two or more SIP User Agents (UAs) that is the subject of recording 🎙️.

Recording Session (RS): The SIP session created between an SRC and an SRS for the purpose of recording a Communication Session 📼.

Figure 1 shows the relationship between a Recording Session and a Communication Session, visually 👀.

  +-------------+                                      +-----------+
  |             |        Communication Session         |           |
  |     A       |<------------------------------------>|     B     |
  |             |                                      |           |
  +-------------+                                      +-----------+
  ..................................................................
  .                             Session                            .
  .                            Recording                           .
  .                             Client                             .
  ..................................................................
                                   |
                                   | Recording
                                   | Session
                                   |
                                   v
                            +------------+
                            |   Session  |
                            |  Recording |
                            |   Server   |
                            +------------+

                              Figure 1

Metadata: Information that describes the recorded media and the CS they relate to 🗂️.

Pause and Resume during a Communication Session:

  • Pause: The action of temporarily discontinuing the transmission and collection of RS media ⏸️.
  • Resume: The action of recommencing the transmission and collection of RS media ▶️.

Most security-related terms in this document should be understood in the sense defined in [RFC4949] 🔐. That includes, but isn't limited to, "authentication", "confidentiality", "encryption", "identity", and "integrity" 💜.

4. Use Cases ✨

Use Case 1: Full-time Recording: One Recording Session for each Communication Session.

okay so bestie, let's look at how the call lifecycle lines up with the recording sessions 💅 Every Communication Session (CS) gets its own Recording Session (RS), so CS 1 gets RS 1, CS 2 gets RS 2, and so on. Iconic, right? 🎀

     CS  |--- CS 1 ---|      |--- CS 2 ---|     |--- CS 3 ---|

     RS  |--- RS 1 ---|      |--- RS 2 ---|     |--- RS 3 ---|
     t--->

                             Figure 2

So the rule is: record every CS for each specific extension/person 💖

Why do people go this hard? Usually for business process stuff (like confirming a transaction or settling a dispute) or to stay on the right side of government regulations 📋 You'll see this in enterprise setups, contact centers, and financial trading floors. ngl it's giving serious responsibility 😭

This one is also commonly known as Total Recording 🧚

Use Case 2: Selective Recording: Start a Recording Session when a Communication Session to be recorded is established.

Now this one is more of a "pick and choose" moment 🦋 Here, Communication Sessions 1 and 3 get recorded, but CS 2 is left alone. Main character energy for CS 2, not being filmed 🙈

     CS  |--- CS 1 ---|      |--- CS 2 ---|     |--- CS 3 ---|

     RS  |--- RS 1----|                         |--- RS 2 ---|
     t--->

                             Figure 3

Use Case 3: Start/Stop a Recording Session during a Communication Session.

This is the flexible one, bestie ✨ A Recording Session can kick off in the middle of a call, either because a user hits a button on their phone or because an application (like a contact center customer service app) or a business event triggers it 🌸 It can then wrap up during the call or when the call ends. And honestly, one call can have one or more Recording Sessions doing their thing 💜

     CS  |------------- Communication Session -----------|

     RS           |---- RS 1 ----|  |---- RS 2 -----|
     t--->

                             Figure 4

Use Case 4: Persistent Recording: A single Recording Session captures one or more Communication Sessions.

Okay this is giving "one tape to rule them all" 👑 One Recording Session runs nonstop and catches several Communication Sessions in a row.

            |--- CS 1 ---|      |--- CS 2 ---|     |--- CS 3 ---|

     RS  |------------------- Recording Session ------------------|
     t--->

                             Figure 5

The recording never stops, not even for a second ⏰ Quiet stretches where no CS is happening still have to come out right on playback. You could record silence during those gaps, or skip them and just mark them with metadata so playback knows what to do 🎀 This shows up in financial trading desks and emergency (first-responder) service bureaus 🚨

Also, the length of a Persistent Recording Session has zero connection to how long the actual calls last, which is so freeing 🦋 It also helps dodge media clipping, that awful thing where the first bit of a call gets chopped off because the recording was still starting up 😭

Here's the catch: the connection and the media attributes for the Recording Session aren't signaled again for each CS before it can be recorded. You can still renegotiate the codec though, so it's not totally frozen 🧊

Sometimes more than one concurrent CS (say, on one trading-floor turret) gets mixed into a single Recording Session 🎧

                     |-------- CS 1 -------|
                        |-------- CS 2 -------|
                   |-------- CS 3 -------|

     RS  |----------- Recording Session --------------|
     t--->

                             Figure 6

Use Case 5: Real-time Recording Controls.

Sometimes, while a Recording Session is active, privacy or security says "nope, not this part" 🙅‍♀️ For example, with PCI (payment card industry) compliance, credit card info has to be protected. One fix is simply not recording the caller while they read out their card number 💳

A Pause/Resume control is one example of a real-time control 🫶

Use Case 6: IVR / Voice Portal Recording.

Self-service Interactive Voice Response (IVR) apps might need recording for two reasons: tuning how well the app performs or meeting compliance rules 📞

The metadata for an IVR session recording must include session information, and it may also include application context info, like VoiceXML session variables or dialog names 🧚

Use Case 7: Enterprise Mobility Recording.

Plenty of agents and enterprise workers who need their calls recorded aren't sitting in the office 🏠 Two examples:

  • Home-based agents or enterprise workers.
  • Mobile phones of knowledge workers (e.g., insurance agents, brokers, or physicians) when they make work-related calls that legally need recording 📱

Use Case 8: Geographically distributed or centralized recording.

Banks, insurance agencies, and retail stores can have tons of locations, possibly up to thousands of small sites 🏬 Usually the branches only have phones and network gear, with no recording services on site. So if calls inside or between branches need recording, a centralized recording system in the data centers can work together with the telephony gear (like a Private Branch Exchange (PBX)) 🌈

Use Case 9: Record complex call scenarios.

This is the drama episode 🍿 Here's a scenario where one recorded call has to be linked to another call that also needs recording:

  • A Customer is in a conversation with a Customer Service Agent.
  • The Agent puts the Customer on hold in order to consult with a Supervisor.
  • The Agent enters into a conversation with the Supervisor.
  • The Agent disconnects from the Supervisor, then reconnects with the Customer.
  • The Supervisor call must be associated with the original Customer call.

Hold on, the plot twist is that the Supervisor call still has to be tied back to the Customer call 🔗

Use Case 10: High availability and continuous recording.

Different deployments have different needs for uptime, error handling, and so on 💪 Here's what can come up:

  • An SRS must always be available at call setup time.
  • No loss of media recording can occur, including during failure of an SRS.
  • The Communication Session must be terminated (or suitable notification given to parties) in the event of a recording failure.
Real talk: if the recording breaks, the call either ends or the people on it get told. No silent failures allowed 🚨

Use Case 11: Record multi-channel, multimedia session.

Some apps need more than one media stream recorded, and those streams might be different types 🎬 The media get synchronized either when they're stored or when they're played back.

Speech analytics tech (think word spotting, emotion detection, or speaker identification) may need speaker-separated recordings to work its best 🎙️

Multi-modal contact centers can mix audio, video, IM, or other ways of interacting 💬

On trading floors, to save on storage and recording resources, it may be better to mix several concurrent calls (Communication Sessions) on different handsets or speakers on the same turret into one recording session 🎧

Use Case 12: Real-time media processing.

It must be possible for an SRS to support real-time media processing, like speech analytics on trading-floor conversations ⚡ Real-time analytics can even step in automatically (by stopping the interaction or sending an alert) if, say, a trader isn't following the rules 🚫

Speaker separation is required in order to reliably detect who is saying specific phrases 🫶

5. Requirements ✨

okay bestie, this is the checklist 📝 Every item below is a requirement for SIP-based Media Recording. Read them like a spec, because implementers really do rely on every word 💅

  • REQ-001: The mechanism MUST provide a means for using the SIP protocol for establishing, maintaining, and terminating Recording Sessions between a Session Recording Client and a Session Recording Server.
  • REQ-002: The mechanism MUST support the ability to record all CSs in their entirety.
  • REQ-003: The mechanism MUST support the ability to record selected CSs in their entirety, according to policy.
  • REQ-004: The mechanism MUST support the ability to record selected parts of selected CSs.
  • REQ-005: The mechanism MUST support the ability to record a CS without loss of media of RS (for example, clipping media at the beginning of the CS) due to RS recording preparation and also without impacting the quality or timing of the CS (for example, delaying the start of the CS while preparing for a recording session). See Use Case 4 in Section 4 for more details. 🎀
  • REQ-006: The mechanism MUST support the recording of IVR sessions.
  • REQ-007: The mechanism MUST support the recording of the following RTP media types: voice, DTMF (as defined by [RFC4733]), video, and text (as defined by [RFC4103]). 🎶
  • REQ-008: The mechanism MUST support the ability for an SRC to deliver mixed audio streams from multiple Communication Sessions to an SRS.
    • Note: A mixed audio stream is where several related Communication Sessions are carried in a single Recording Session. A mixed-media stream is typically produced by a mixer function. The RS MAY be informed about the composition of the mixed streams through session metadata. 🧠
  • REQ-009: The mechanism MUST support the ability for an SRC to deliver mixed audio streams from different parties of a given Communication Session to an SRS.
  • REQ-010: The mechanism MUST support the ability to deliver to the SRS multiple media streams for a given CS.
  • REQ-011: The mechanism MUST support the ability to pause and resume the transmission and collection of RS media.
  • REQ-012: The mechanism MUST include a means for providing the SRS with metadata describing CSs that are being recorded, including the media being used and the identifiers of parties involved.
  • REQ-013: The mechanism MUST include a means for the SRS to be able to correlate RS media with CS participant media.
  • REQ-014: Metadata format must be agnostic of the transport protocol.
  • REQ-015: The mechanism MUST support a means to stop the recording.
  • REQ-016: The mechanism MUST support a means for a recording-aware UA involved in a CS to request at session establishment time that the CS should be recorded or should not be recorded, the honoring of such a request being dependent on policy.
  • REQ-017: The mechanism MUST support a means for a recording-aware UA involved in a CS to request during a session that the recording of the CS should be started, paused, resumed, or stopped, the honoring of such a request being dependent on policy. Such recording-aware UAs MUST be notified about the outcome of such requests. 📣
  • REQ-018: The mechanism MUST NOT prevent the application of tones or announcements during recording or at the start of a CS to support notification to participants that the call is being recorded or may be recorded. 🔔
  • REQ-019: The mechanism MUST provide a means of indicating to recording-aware UAs whether recording is taking place, for appropriate rendering at the user interface.
  • REQ-020: The mechanism MUST provide a way for metadata to be conveyed to the SRS incrementally during the CS.
  • REQ-021: The mechanism MUST NOT prevent high-availability deployments. 🛡️
  • REQ-022: The mechanism MUST provide means for facilitating synchronization of the recorded media streams and metadata.
  • REQ-023: The mechanism MUST provide means for facilitating synchronization among the recorded media streams.
  • REQ-024: The mechanism MUST provide means to relate recording and recording controls, such as start/stop/pause/resume, to the wall clock time. ⏰
  • REQ-025: The mechanism MUST provide means for an SRS to authenticate the SRC on RS initiation.
  • REQ-026: The mechanism MUST provide means for an SRC to authenticate the SRS on RS initiation.
  • REQ-027: The mechanism MUST include a means for ensuring that the integrity of the metadata sent from the SRC to the SRS is an accurate representation of the original CS metadata.
  • REQ-028: The mechanism MUST include a means for ensuring that the integrity of the media sent from the SRC to the SRS is an accurate representation of the original CS media.
  • REQ-029: The mechanism MUST include a means for ensuring the confidentiality of the metadata sent from the SRC to the SRS.
  • REQ-030: The mechanism MUST provide a means to support RS confidentiality. 🔒
  • REQ-031: The mechanism MUST support the ability to deliver to the SRS multiple media streams of the same media type (e.g., audio, video). One example is the case of delivering unmixed audio for each participant in the CS.

6. Privacy Considerations 🌸

Respecting the privacy rights and wishes of people on a call is of paramount importance 💖 In lots of jurisdictions, participants have a right to know that the session is being recorded (or might be), and they have a right to opt out, either by ending the call or by demanding that it not be recorded. So this document includes requirements for notifying users that a call is being recorded, and for letting users ask that a call not be recorded. Use cases where people on a call aren't told that it is or might be recorded are outside the scope of this document. Lawful intercept, in particular, is also outside the scope of this document 🙅‍♀️

Rules about telling participants about a recording vary a lot by jurisdiction. In any given deployment, not everyone will be allowed to stop the recording of a CS, although any user can always end their own participation in the CS. Usually, users inside the domain doing the recording follow that domain's policies about whether CSs get recorded. Picture a call center: agents follow the call center's policies and may or may not be allowed to stop a CS, or part of one, from being recorded. Callers ringing into the call center will usually have to ask the agent not to record. And if the agent can't stop the recording, or the caller doesn't trust the agent, the only option is generally to end the CS 📞

Privacy also covers what happens to a recording after it's made. The big questions are who can access it (for example, getting a copy, viewing the metadata, or playing back the media), what it can be used for (for example, training, quality control, and so on), and how long it can be kept before it's deleted. These are usually policies of the domain making the recording, not policies of the individual users in a recorded CS, whether those users are in the same domain or a different one. Back to the call center: agents might learn the call center's rules on keeping and using recordings as part of their job contract, and callers from outside might get some of that info when they're told the CS will be recorded (for example, through an announcement saying calls may be recorded for quality purposes) 🎧

This document doesn't set any requirements for a user in a CS to be able to decide what happens to a recording, and it doesn't cover sending that kind of information from an SRC to an SRS. It's assumed the SRS has access to the policies that apply in its environment and can make sure recordings are stored and used according to them ✨

7. Security Considerations 🔐

Session recording has serious security implications for the SIP UAs being recorded, for the SRC, and for the SRS 💀

For the SIP UAs involved in the Communication Session, the requirements in this document let the UA find out that a Communication Session is being recorded, and ask for that particular Communication Session not to be recorded 👀

Humans usually don't look at or know about protocol signaling like SIP. On top of that, the SIP session might have started from a Public Switched Telephone Network (PSTN) gateway, which can't pass along any in-signaling indication that recording is happening. So users can be told about recording in the media itself, through voice announcements, a visual indicator on the endpoint, or other means 📢

As for the security of the protocols themselves, there's clearly a need for authentication, authorization, and eavesdropping protection. The SRC needs to know that the SRS it's talking to is legit, and vice versa, even when they're in different domains. Both the signaling and the media for the Recording Session need to be able to be authenticated and protected from eavesdropping. The details are in Section 5 💅

Communication Sessions and Recording Sessions can need different security levels, for both signaling and media, depending on how the deployment is set up. In some environments, for example, the SRS and SRC are collocated in a secure network region, so the RS won't need the same level of protection as a CS that runs over a public network. In other environments, the SRS might sit in a public cloud, and then the RS needs a higher level of protection than the CS. Because of this, there isn't a direct relationship between the security level of Communication Sessions and the security level of Recording Sessions 🌈

A malicious or corrupt SRC can tamper with media and metadata about a CS before sending that data to an SRS. Also, CS media and signaling can be tampered with on the network before they reach an SRC, unless proper means are in place to protect integrity during transmission on the CS. Ensuring that the media and metadata an SRC emits are correct is outside the scope of this work. Other organizational and technical controls will need to be used to prevent tampering 🚨

8. Acknowledgements 💜

Huge thanks to Dan Wing, Alan Johnson, Vijay Gurbani, Cullen Jennings, Hadriel Kaplan, Henry Lum, Dave Smith, Martin Palmer, Alissa Cooper, Deepanshu Gautam, Paul Kyzivat, Parthasarathi R, Ram Mohan R, and Charles Eckel for their major contributions and help with this document and the SIPREC WG 🫶 Thanks also to everyone on the DISPATCH WG and SIPREC WG mailing lists for their valuable input to this work 🦋

9. Normative References ✨

okay so here's the reading list the spec leans on, bestie 📚 each one is a whole RFC that the main text needs in order to make sense. every entry keeps its exact details 💅

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
           A., Peterson, J., Sparks, R., Handley, M., and E.
           Schooler, "SIP: Session Initiation Protocol", RFC 3261,
           June 2002.

[RFC4103]  Hellstrom, G. and P. Jones, "RTP Payload for Text
           Conversation", RFC 4103, June 2005.

[RFC4733]  Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF
           Digits, Telephony Tones, and Telephony Signals", RFC 4733,
           December 2006.

[RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
           FYI 36, RFC 4949, August 2007.

Authors' Addresses ✨

ok and here's who made this bb 🫶 the editors and contributors, with their contact info exactly as listed 🎀

Ken Rehor (editor)
Cisco Systems
170 West Tasman Dr.
Mail Stop SJC30/2/
San Jose, CA  95134
USA

EMail: krehor@cisco.com


Leon Portman (editor)
NICE Systems
8 Hapnina
Ra'anana  43017
Israel

EMail: leon.portman@nice.com


Andrew Hutton
Siemens Enterprise Communications

EMail: andrew.hutton@siemens-enterprise.com
URI:   http://www.siemens-enterprise.com


Rajnish Jain
IPC Systems
777 Commerce Drive
Fairfield, CT  06825
USA

EMail: rajnish.jain@ipc.com

that's the whole spec, babe 💖 we made it through!! 🦋

📦 where this page comes from