RFC 7245
An Architecture for Media Recording Using the Session Initiation Protocol
An Architecture for Media Recording Using the Session Initiation Protocol 🎀
RFC 7245 ✨
Title block, the tea: This is an IETF document (Internet Engineering Task Force) published as an Informational RFC in May 2014 with ISSN 2070-1721 📄. The editors are A. Hutton, Ed. (Unify) and L. Portman, Ed. (NICE Systems), plus R. Jain (IPC Systems) and K. Rehor (Cisco Systems, Inc.) 👑. It doesn't list anything it obsoletes or updates, so it's standing on its own 💅.
Abstract
Okay so session recording is a HUGE deal in places like call centers and financial trading 📞. Sometimes every single call has to be recorded for regulatory, compliance, and consumer protection reasons, and it's giving serious responsibility 😭. Recording a session usually works by sending a copy of a media stream over to a recording device. This doc describes architectures for deploying session recording solutions in an environment built on the Session Initiation Protocol (SIP) 🦋.
Status of This Memo
Real talk, this doc is not an Internet Standards Track spec. It's published for informational purposes 🌸.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for the details 🧚.
Info about the current status of this document, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc7245 💜.
Copyright Notice
Copyright (c) 2014 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 in effect on the date of publication of this document. Please review these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🫶.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Session Recording Architecture . . . . . . . . . . . . . . . 5
3.1. Location of the SRC . . . . . . . . . . . . . . . . . . . 5
3.1.1. B2BUA Acts as a SRC . . . . . . . . . . . . . . . . . 5
3.1.2. Endpoint Acts as SRC . . . . . . . . . . . . . . . . 6
3.1.3. A SIP Proxy Cannot Be a SRC . . . . . . . . . . . . . 7
3.1.4. Interaction with MEDIACTRL . . . . . . . . . . . . . 7
3.1.5. Interaction with Conference Focus . . . . . . . . . . 9
3.2. Establishing the Recording Session . . . . . . . . . . . 10
3.2.1. SRC-Initiated Recording . . . . . . . . . . . . . . . 11
3.2.2. SRS-Initiated Recording . . . . . . . . . . . . . . . 11
3.2.3. Pause/Resume Recording Session . . . . . . . . . . . 12
3.2.4. Media Stream Mixing . . . . . . . . . . . . . . . . . 12
3.2.5. Media Transcoding . . . . . . . . . . . . . . . . . . 12
3.2.6. Lossless Recording . . . . . . . . . . . . . . . . . 12
3.3. Recording Metadata . . . . . . . . . . . . . . . . . . . 13
3.3.1. Contents of Recording Metadata . . . . . . . . . . . 13
3.3.2. Mechanisms for Delivery of Metadata to SRS . . . . . 13
3.4. Notifications to the Recorded User Agents . . . . . . . . 13
3.5. Preventing the Recording of a SIP Session . . . . . . . . 13
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
7. Informative References . . . . . . . . . . . . . . . . . . . 151. Introduction ✨
Okay, so session recording is a critical requirement in tons of communications environments, like call centers and financial trading 💅. In some of these places, all calls must be recorded for regulatory, compliance, and consumer protection reasons, which is honestly iconic and also a lot 🙈. Recording a session usually means sending a copy of a media stream to a recording device. This document describes architectures for deploying session recording solutions as defined in "Use Cases and Requirements for SIP-Based Media Recording (SIPREC)" [RFC6341] 🌸.
This doc focuses on how sessions get set up between a Session Recording Client (SRC) and the Session Recording Server (SRS). The point is to carry the Replicated Media and Recording Metadata (for example, the identity of the parties involved) that relate to the Communication Session 🧚.
Once the SRS has received the Replicated Media and Recording Metadata, they'll usually get archived so they can be retrieved later. The procedures for archiving and retrieving that info are outside the scope of this document 💜.
This document only considers active recording, where the SRC purposefully streams media to an SRS. Passive recording, where a recording device picks up media straight from the network (for example, with port-mirroring techniques), is outside the scope of this document. Lawful intercept is also outside the scope here, and that takes into account the IETF policy on wiretapping [RFC2804] 🔥.
The Recording Session between the SRC and the SRS uses the normal procedures for establishing INVITE-initiated dialogs, as specified in [RFC3261]. It also uses the Session Description Protocol (SDP) to describe the media used during the session, as specified in [RFC4566] 🦋. That said, it's intended that some extensions to SIP (for example, Headers, Option Tags, etc.) will be defined to support the requirements for media recording 👑. The Replicated Media is required to be sent in real-time to the SRS, and the SRC doesn't buffer it. That's what lets the SRS analyze the media in real-time ⭐.
2. Definitions 🎀
The first four definitions are quoted from RFC 6341. Lemme walk you through all of them 💖.
- Session Recording Server (SRS): A Session Recording Server (SRS) is a SIP User Agent (UA) that acts as a specialized media server or collector and is the sink of the recorded media. An SRS is typically built as 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): A Session Recording Client (SRC) is a SIP User Agent (UA) that's the source of the recorded media, sending 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 specification defines the term "SRC" so that all of these 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 CS 🧚.
The following terms are defined by this document 🌸.
- Recording-aware User Agent (UA): A SIP User Agent that's aware of SIP extensions associated with the CS. Those extensions might be used to tell the recording-aware UA that a session is being recorded, or the recording-aware UA might use them to express preferences about whether a recording should be started, paused, resumed, or stopped 👑.
- Recording-unaware User Agent (UA): A SIP User Agent that's unaware of SIP extensions associated with the CS. A recording-unaware UA will be notified that a session is being recorded, or it will express preferences about whether a recording should be started, paused, resumed, or stopped, through some other means that's out of scope for the SIP media recording architecture 🙈.
- Recording Metadata: The metadata describing the CS that the SRS requires. This includes, for example, the identities of users who take part in the CS and the dialog state. This metadata is typically archived with the Replicated Media at the SRS, and it's delivered to the SRS in real-time ✨.
- Replicated Media: A copy of the media associated with the CS. It was created by the SRC and sent to the SRS. It may contain all the media associated with the CS (for example, audio and video) or just a subset (for example, audio). Replicated Media is part of the Recording Session 💖.
3. Session Recording Architecture 🧚
3.1. Location of the SRC 🦋
This section has some example session recording architectures showing how the SRC is a logical function. It can be located in one physical component or split across several of them 💜.
3.1.1. B2BUA Acts as a SRC ✨
okay so a SIP Back-to-Back User Agent (B2BUA) that can get to the media being recorded can be the SRC 🎀 it might already know the session needs recording before the CS is even set up, or it might decide to record once the session is already going 🦋
if the SRC is the one deciding to start the RS, it sends a SIP INVITE request to the SRS 💌 and if the SRS is the one deciding, it starts the SIP RS by sending an INVITE to the SRC 🧚
the RS INVITE carries info that marks the session as being set up for recording 💅 and that stops it from getting accidentally routed to a UA that isn't an SRS (when the RS was started by the SRC), or the other way around 🙈
the B2BUA/SRC is also the one in charge of letting the UAs in the CS know the session is being recorded 📣 and it has to go along with requests from recording-aware UAs, or with configured policies saying the CS should not be recorded 🔒
+-----------+
(Recording Session) | Session |
+------SIP------>| Recording |
| | Server |
| +--RTP/RTCP-->| (SRS) |
| | +-----------+
V V ^
+-------------+ |
| | |
| |-- Metadata -+
| |
| B2BUA |
| |
| Session |
+--------+ | Recording | +---------+
| |<- SIP ->| Client |<- SIP ->| |
| UA-A | | (SRC) | | UA-B |
| |<- RTP/->| |<- RTP/->| |
+--------+ RTCP | | RTCP +---------+
+-------------+
|____________________________________________________|
(Communication Session)
Figure 1: B2BUA Acts as the Session Recording Client3.1.2. Endpoint Acts as SRC 🌸
a SIP endpoint / UA can be a SRC too 💖 in that case the endpoint sends the Replicated Media over to the SRS 📤
if the endpoint is the one deciding to start the Recording Session, it kicks things off by sending an INVITE to the SRS 🚀 and if the SRS decides, it starts the SIP Session by sending an INVITE to the endpoint 💜 how that decision actually gets made is totally out of scope for the SIP media recording architecture, so not our problem here 🙅♀️
(Recording Session) +-----------+
+----------SIP------>| |
| +----RTP/RTCP---->| Session |
| | | Recording |
| | | Server |
| | +-- Metadata -->| (SRS) |
| | | | |
| | | +-----------+
| | |
| | |
| | |
| | |
V V | (Communication Session)
+--+------+ +---------+
| |<-------SIP--------->| |
| UA-A | | UA-B |
| (SRC) |<-----RTP/RTCP------>| |
+---------+ +---------+
Figure 2: SIP Endpoint Acts as the Session Recording Client3.1.3. A SIP Proxy Cannot Be a SRC 🚫
a SIP Proxy can't be an SRC, and the reason is super simple 🥺 it doesn't have access to the media, so it has no way to get the Replicated Media delivered to the SRS 😭
3.1.4. Interaction with MEDIACTRL 🎬
the MEDIACTRL architecture [RFC5567] is all about an Application Server (AS) controlling a Media Server (MS) 🎛️ which can be used for stuff like conferencing and recording media streams ✨ in that setup, the AS usually uses SIP Third Party Call Control (3PCC) to tell the SIP UAs to send their media to the Media Server 📡
the SRC or the SRS from this document can be built the [RFC5567] way too 🧩 so when you break them down further, they might be an AS that talks to an MS through a MEDIACTRL interface 💅
when the SRS is built that way (Figure 3), the MS is the sink for the recording media, and the AS is the sink for the metadata and also where the RS SIP signaling ends 🎯 when the SRC is built that way (Figure 4), the MS is the source of the recording media, and the AS is the source of the metadata and where the RS SIP signaling terminates 🌈
Session Recording Server (SRS)
+----------------------------------------+
| |
(Recording Session) | +-----------+ +------------+ |
+------------SIP----|->| | | | |
| | | MEDIACTRL |MEDIACTRL | Media | |
| | |Application|<-------->| Server | |
| +-----Metadata--->| Server | | (Recorder)| |
| | | | | | | |
| | | +-----------+ +------------+ |
| | | ^ |
| | +------------------------------|---------+
| | +--------------- RTP/RTCP -----------------+
| | |
V | V
+---+------+ +---------+
| |<-------SIP-------------->| |
| UA-A | (Communication Session) | UA-B |
| (SRC) |<-------RTP/RTCP--------->| |
+----------+ +---------+
Figure 3: Example of Session Recording Server using MEDIACTRL +----------+
(Recording Session) | Session |
+-----------SIP------------------------->|Recording |
| +----------Metadata------------------->| Server |
| | | (SRS) |
V | UA-A Session Recording Client (SRC) +----------+
+----------------------------------------+ ^
| | |
| +-----------+ +------------+ | |
| | | Control | |<-RTP/RTCP-+ +---------+
| | UA | Protocol | Media | | | |
| |Application|<-------->| Server | |<----SIP----->| UA-B |
| | Server | | |<-----RTP------>| |
| | | | | | +---------+
| +-----------+ +------------+ |
| |
+----------------------------------------+
Figure 4: Example of Session Recording Client Decomposition3.1.5. Interaction with Conference Focus 🎤
in a centralized conference, a conference focus plus mixer [RFC4353] together can act as a SRC 🎀 so they give the SRS the Replicated Media and the recording metadata that goes with it 💕 in this setup the SRC can provide media and metadata for each participant, including side conversations where the media goes through the mixer 👀
the conference focus can give either mixed Replicated Media or separate streams for each conference participant (see Figure 5) 🎚️
the conference focus can also act as a recording-aware UA when one of the participants is acting as a SRC 🫶
in another setup, a SIP endpoint that's a conference participant can be the SRC 🙌 then the SRC has access to the media and metadata for that one participant, and it might be able to grab more metadata from the conference focus 🔍 for example, it could use the conference event package from [RFC4575] to learn about the other participants and pass that along to the SRS inside the recording metadata 📦
the SRC might be in the conference from the very beginning, or it might join later on ⏰
User 1
+-----------+
| |
| |
|Participant|
| 1 |
| |
+-----------+
^ ^SIP
RTP | |Dialog
| |1
User 2 V V Recording
+-----------+ +-----------+ Session *************
| | | |<------------>* *
| |<-- RTP -->| |<-RTP/RTCP 1->* *
|Participant|<--------->| Focus/SRC |<-RTP/RTCP 2->* SRS *
| 2 | SIP | |<-RTP/RTCP 3->* *
| | Dialog | | * *
+-----------+ 2 +-----------+ *************
^ ^
| |SIP
RTP | |Dialog
| |3
V V
+-----------+
| |
| |
|Participant|
| 3 |
| |
+-----------+
User 3
Figure 5: Conference Focus Acting as an SRC3.2. Establishing the Recording Session 🎬
the SRC or the SRS can be the one to start the Recording Session 🚦
heads up, the Recording Session is independent from the CS being recorded, both at the SIP dialog level and at the session level 🧠 so they're separate things, bestie 💅
for media negotiation, regular SIP/SDP capabilities should be used, and existing transcoding capabilities and media encryption should not be precluded 🔐
3.2.1. SRC-Initiated Recording 🌟
when the SRC starts the Recording Session to send media over to the SRS, it does the following stuff 📋
- it's provisioned with a Unified Resource Identifier (URI) for the SRS, and that URI gets resolved through the normal [RFC3263] procedures 🗺️
- it starts the dialog by sending an
INVITErequest to the SRS, and the dialog gets set up following the normal procedures for INVITE-initiated dialogs in [RFC3261] 🤝 - it puts an indication in the
INVITEthat the session is established for recording the associated media 🎙️ - it includes an SDP attribute of
a=sendonlyon each media line if the Replicated Media is supposed to start right away, or it includesa=inactiveif it isn't ready to send the media yet 🎚️ - it replicates the media streams that are going to be recorded and sends that media to the SRS 📡
the Recording Session can replicate all of the media associated with the CS, or just a subset of it 💜
3.2.2. SRS-Initiated Recording 📞
okay bestie, this is the flip side, where the SRS starts the Recording Session with the SRC 💅 When the SRS does this, it:
- Is provisioned with a Unified Resource Identifier (URI) for the SRC; the URI is resolved through normal [RFC3263] procedures.
- Sends an INVITE request to the SRC.
- Includes in the INVITE an indication that the session is established for the purpose of recording the associated media.
- Identifies the sessions that are to be recorded. The actual mechanism of the identification depends on SRC policy.
- Includes an SDP attribute of
a=recvonlyfor each media line if the Recording Session is to be started immediately, or includesa=inactiveif it is not ready to receive the media.
If the SRS doesn't know which media streams are available to record, it can use an offerless INVITE 🧚 That way the SRC gets to make the initial SDP offer. Main character energy for the SRC 👑
3.2.3. Pause/Resume Recording Session ⏯️
The SRS or the SRC may pause the recording by changing the SDP direction attribute to inactive, and resume it by changing the direction back to recvonly or sendonly 🌸 Pause, play, vibe.
3.2.4. Media Stream Mixing 🎛️
okay so in a basic audio-only session, there are usually two audio/RTP streams between the two UAs, one for each direction 🎧 When you record that media, the two streams may or may not be mixed at the SRC before they get sent to the SRS. If they're not mixed, two separate streams go to the SRS, and the SDP offer to the SRS has to describe two separate media streams. If they are mixed, a single mixed media stream goes to the SRS. Two tracks or one blend, your call 🍓
3.2.5. Media Transcoding 🔄
The CS and the RS get negotiated separately using the standard SDP offer/answer exchange, and that can mean the SRC has to do media transcoding between the two sessions 🫠 If the SRC can't transcode, it may limit the media formats in the offer to the SRS, depending on what was negotiated on the CS. Or it may limit what it puts in the offer on the CS, if it already knows which media formats the SRS supports. Honestly though, the SRS is usually the more capable device, so it can offer the SRC a wide range of media format options. It may even use a media transcoder, as described in [RFC5369] ✨
3.2.6. Lossless Recording 🛡️
Session recording can be a regulatory requirement in some communication environments, and those environments may impose a requirement generally known as "lossless recording" 😭 A full lossless recording solution can involve multiple layers. The pieces can range from setting up networks for appropriate QoS, to reliable transmission of recorded media, and maybe certain SIPREC protocol-level capabilities in the SRC and SRS. It's a whole team effort, bestie 🫶
3.3. Recording Metadata 🗂️
3.3.1. Contents of Recording Metadata
The metadata model is defined in [REC-METADATA] 📋
3.3.2. Mechanisms for Delivery of Metadata to SRS 📬
The SRS gets session recording metadata from the SRC. The metadata is carried over SIP-based mechanisms, as specified in [REC-PROTOCOL]
It's also possible for metadata to be transported over non-SIP-based mechanisms, but those are considered out of scope 🙈
And it's possible to have an RS session without the metadata. In that case, the SRS will be getting the metadata some other way, or not at all 💀
3.4. Notifications to the Recorded User Agents 🔔
Usually, a user in a session that's about to be recorded gets told with an announcement at the start of the call, or they might hear warning tones in the media. SIPREC goes a step further, though: it lets an indication that the call is being recorded be included in the SIP requests and responses associated with that CS 🥰
The SRC provides the notification to all SIP UAs whose received media it's replicating for recording purposes. If the SRC is acting as a SIP endpoint, as described in Section 3.1.2, then it also provides a notification to the local user 🎀
3.5. Preventing the Recording of a SIP Session 🚫
During the initial session establishment, or during an established session, a recording-aware UA may give an indication of its preference about recording the media in the CS. The mechanisms for doing that are specified in [REC-PROTOCOL] 🙅♀️
4. IANA Considerations 📚
This document has no actions for IANA 🎉 It does mention SIP/SDP extensions, though. The associated IANA considerations are addressed in [REC-PROTOCOL], which is where they're defined.
5. Security Considerations 🔐
Okay, this part is seriously important, so no skipping! 😤 The Recording Session is basically a standard SIP dialog and media session, so it uses the existing SIP security mechanisms to secure both the Recording Session and the Recording Metadata.
This architecture is only meant for cases where the users know they're being recorded, and the architecture gives the SRC a way to notify users that they're being recorded. This architectural solution is not intended to support lawful intercept, which, in contrast, requires that users are not informed 🙅♀️
It's the SRS's job to protect the Replicated Media and Recording Metadata once they've been received and archived. The stored content must be protected using a cipher at least as strong as (or stronger than) the original content. However, the mechanism for protecting the storage and retrieval from the SRS is out of scope of this work. The keys used to store the data must also be securely maintained by the SRS, and should only be released, securely, to authorized parties. How to secure those keys, properly authorize a receiving party, or securely distribute the keying material is also out of scope of this work 🔑
Protection of the RS should not be weaker than protection of the CS, and it may need to be stronger, because the media is retransmitted, which gives more chances for interception. This applies to both the signaling and media paths 👀
It is essential that the SRC will authenticate the SRS, because the client must be certain that it's recording on the right recording system 🚨 It's less important for the SRS to authenticate the SRC, but implementations must have the ability to perform mutual authentication.
In some environments, it's desirable not to decrypt and re-encrypt the media. In that case, the same media encryption key is negotiated and used within the CS and RS. If for any reason the media are decrypted on the CS and then re-encrypted on the RS, a new key must be used 🗝️
The retrieval mechanism for media recorded by this protocol is out of scope. Anyone building retrieval mechanisms should think carefully about the security implications, because the retriever usually isn't a party to the call that was recorded. Retrievers should be authenticated carefully. The cryptosuites used on retrieval should be no less strong than those used on the RS, and may need to be stronger 💜
6. Acknowledgements 🫶
Huge thanks to John Elwell, Brian Rosen, Alan Johnson, Cullen Jennings, Hadriel Kaplan, Henry Lum, Paul Kyzivat, Parthasarathi R., Ram Mohan R., Charles Eckel, Friso Feenstra, and Dave Higton for their significant contributions and help with this document and the working group ✨ Also, thanks to everyone on the SIPREC WG mailing list for giving such valuable input to this work 🌈
7. Informative References 📖
- [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.
- [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
- [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
- [RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use Cases and Requirements for SIP-Based Media Recording (SIPREC)", RFC 6341, August 2011.
- [REC-METADATA] Ravindranath, R., Ravindran, P., and P. Kyzivat, "Session Initiation Protocol (SIP) Recording Metadata", Work in Progress, February 2014.
- [REC-PROTOCOL] Portman, L., Lum, H., Eckel, C., Johnston, A., and A. Hutton, "Session Recording Protocol", Work in Progress, February 2014.
- [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
- [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
- [RFC5567] Melanchuk, T., "An Architectural Framework for Media Server Control", RFC 5567, June 2009.
- [RFC5369] Camarillo, G., "Framework for Transcoding with the Session Initiation Protocol (SIP)", RFC 5369, October 2008.
- [RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
Authors' Addresses 🦋
Andrew Hutton (editor)
Unify
Hofmannstrasse 51
81359 Munich
Germany
EMail: andrew.hutton@unify.com
Leon Portman (editor)
NICE Systems
8 Hapnina
Ra'anana 43017
Israel
EMail: leon.portman@gmail.com
Rajnish Jain
IPC Systems
777 Commerce Drive
Fairfield, CT 06825
USA
EMail: rajnish.jain@outlook.com
Ken Rehor
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
EMail: krehor@cisco.com📦 where this page comes from
- ietf: rfc7245 2014-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms