summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7245.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7245.txt')
-rw-r--r--doc/rfc/rfc7245.txt899
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc7245.txt b/doc/rfc/rfc7245.txt
new file mode 100644
index 0000000..cc4412f
--- /dev/null
+++ b/doc/rfc/rfc7245.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) A. Hutton, Ed.
+Request for Comments: 7245 Unify
+Category: Informational L. Portman, Ed.
+ISSN: 2070-1721 NICE Systems
+ R. Jain
+ IPC Systems
+ K. Rehor
+ Cisco Systems, Inc.
+ May 2014
+
+
+ An Architecture for Media Recording
+ Using the Session Initiation Protocol
+
+Abstract
+
+ Session recording is a critical requirement in many communications
+ environments such as call centers and financial trading. In some of
+ these environments, all calls must be recorded for regulatory,
+ compliance, and consumer protection reasons. Recording of a session
+ is typically performed by sending a copy of a media stream to a
+ recording device. This document describes architectures for
+ deploying session recording solutions in an environment that is based
+ on the Session Initiation Protocol (SIP).
+
+Status of This Memo
+
+ This document is not an Internet Standards Track specification; it is
+ published for informational purposes.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Not all documents
+ approved by the IESG are a candidate for any level of Internet
+ Standard; see Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7245.
+
+
+
+
+
+
+
+
+
+
+
+Hutton, et al. Informational [Page 1]
+
+RFC 7245 Architecture for Media Recording May 2014
+
+
+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) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as 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 are 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 . . . . . . . . . . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+Hutton, et al. Informational [Page 2]
+
+RFC 7245 Architecture for Media Recording May 2014
+
+
+1. Introduction
+
+ Session recording is a critical requirement in many communications
+ environments such as call centers and financial trading. In some of
+ these environments, all calls must be recorded for regulatory,
+ compliance, and consumer protection reasons. Recording of a session
+ is typically performed by 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 document focuses on how sessions are established between a
+ Session Recording Client (SRC) and the Session Recording Server (SRS)
+ for the purpose of conveying the Replicated Media and Recording
+ Metadata (e.g., identity of the parties involved) relating to the
+ Communication Session.
+
+ Once the Replicated Media and Recording Metadata have been received
+ by the SRS, they will typically be archived for retrieval at a later
+ time. The procedures relating to the archiving and retrieval of this
+ information are outside the scope of this document.
+
+ This document only considers active recording, where the SRC
+ purposefully streams media to a SRS. Passive recording, where a
+ recording device detects media directly from the network (e.g., using
+ port-mirroring techniques), is outside the scope of this document.
+ In addition, lawful intercept is outside the scope of this document,
+ which takes account of the IETF policy on wiretapping [RFC2804].
+
+ The Recording Session that is established between the SRC and the SRS
+ uses the normal procedures for establishing INVITE-initiated dialogs
+ as specified in [RFC3261] and uses the Session Description Protocol
+ (SDP) for describing the media to be used during the session as
+ specified in [RFC4566]. However, it is intended that some extensions
+ to SIP (e.g., 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 is not buffered by
+ the SRC to allow for real-time analysis of the media by the SRS.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hutton, et al. Informational [Page 3]
+
+RFC 7245 Architecture for Media Recording May 2014
+
+
+2. Definitions
+
+ The first four definitions are quoted from RFC 6341.
+
+ Session Recording Server (SRS): A Session Recording Server (SRS) is
+ a SIP User Agent (UA) that is a specialized media server or
+ collector that acts as the sink of the recorded media. An SRS is
+ typically implemented as a multi-port device that is capable of
+ receiving media from multiple sources simultaneously. An SRS is
+ the sink of the recorded session metadata.
+
+ Session Recording Client (SRC): A Session Recording Client (SRC) is
+ a SIP User Agent (UA) that acts as the source of the recorded
+ media, sending it to the SRS. An SRC is a logical function. Its
+ capabilities may be implemented across one or more physical
+ devices. In practice, an SRC could be a personal device (such as
+ 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" such that all such SIP entities can be generically addressed
+ 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
+ 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 is aware of
+ SIP extensions associated with the CS. Such extensions may be
+ used to notify the recording-aware UA that a session is being
+ recorded, or by a recording-aware UA to express preferences as to
+ whether a recording should be started, paused, resumed, or
+ stopped.
+
+ Recording-unaware User Agent (UA): A SIP User Agent that is unaware
+ of SIP extensions associated with the CS. Such a recording-
+ unaware UA will be notified that a session is being recorded or
+ will express preferences as to whether a recording should be
+ started, paused, resumed, or stopped via some other means that is
+ out of scope for the SIP media recording architecture.
+
+
+
+
+
+
+
+
+Hutton, et al. Informational [Page 4]
+
+RFC 7245 Architecture for Media Recording May 2014
+
+
+ Recording Metadata: The metadata describing the CS that is required
+ by the SRS. This will include, for example, the identities of
+ users that participate in the CS and dialog state. Typically,
+ this metadata is archived with the Replicated Media at the SRS.
+ The recording metadata is delivered in real-time to the SRS.
+
+ Replicated Media: A copy of the media that is associated with the
+ CS, was created by the SRC, and was sent to the SRS. It may
+ contain all the media associated with the CS (e.g., audio and
+ video) or just a subset (e.g., audio). Replicated Media is part
+ of the Recording Session.
+
+3. Session Recording Architecture
+
+3.1. Location of the SRC
+
+ This section contains some example session recording architectures
+ showing how the SRC is a logical function that can be located in or
+ split between various physical components.
+
+3.1.1. B2BUA Acts as a SRC
+
+ A SIP Back-to-Back User Agent (B2BUA) that has access to the media to
+ be recorded may act as an SRC. The B2BUA may already be aware that a
+ session needs to be recorded before the initial establishment of the
+ CS, or the decision to record the session may occur after the session
+ has been established.
+
+ If the SRC makes the decision to initiate the RS, then it will do so
+ by sending a SIP INVITE request to the SRS.
+
+ If the SRS makes the decision to initiate the Recording Session, then
+ it will initiate the establishment of a SIP RS by sending an INVITE
+ to the SRC.
+
+ The RS INVITE contains information that identifies the session as
+ being established for the purposes of recording and prevents the
+ session from being accidentally rerouted to a UA that is not an SRS
+ if the RS was initiated by the SRC or vice versa.
+
+ The B2BUA/SRC is responsible for notifying the UAs involved in the CS
+ that the session is being recorded.
+
+ The B2BUA/SRC is responsible for complying with requests from
+ recording aware UAs or through some configured policies indicating
+ that the CS should not be recorded.
+
+
+
+
+
+Hutton, et al. Informational [Page 5]
+
+RFC 7245 Architecture for Media Recording May 2014
+
+
+ +-----------+
+ (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 Client
+
+3.1.2. Endpoint Acts as SRC
+
+ A SIP endpoint / UA may act as a SRC. In that case, the endpoint
+ sends the Replicated Media to the SRS.
+
+ If the endpoint makes the decision to initiate the Recording Session,
+ then it will initiate the establishment of a SIP Session by sending
+ an INVITE to the SRS.
+
+ If the SRS makes the decision to initiate the Recording Session, then
+ it will initiate the establishment of a SIP Session by sending an
+ INVITE to the endpoint. The actual decision mechanism is out of
+ scope for the SIP media recording architecture.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hutton, et al. Informational [Page 6]
+
+RFC 7245 Architecture for Media Recording May 2014
+
+
+ (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 Client
+
+3.1.3. A SIP Proxy Cannot Be a SRC
+
+ A SIP Proxy is unable to act as an SRC because it does not have
+ access to the media and therefore has no way of enabling the delivery
+ of the Replicated Media to the SRS.
+
+3.1.4. Interaction with MEDIACTRL
+
+ The MEDIACTRL architecture [RFC5567] describes an architecture in
+ which an Application Server (AS) controls a Media Server (MS), which
+ may be used for purposes such as conferencing and recording media
+ streams. In the architecture described in [RFC5567], the AS
+ typically uses SIP Third Party Call Control (3PCC) to instruct the
+ SIP UAs to direct their media to the Media Server.
+
+ The SRC or the SRS described in this document may be architected
+ according to [RFC5567]; therefore, when further decomposed, they may
+ be made up of an AS that uses a MEDIACTRL interface to control an MS.
+
+ As shown in Figure 3, when the SRS is architected according to
+ [RFC5567], the MS acts as a sink of the recording media, and the AS
+ acts as a sink of the metadata and the termination point for RS SIP
+ signaling. As shown in Figure 4, when the SRC is architected
+ according to [RFC5567], the MS acts as a source of recording media,
+ and the AS acts as a source of the metadata and the termination point
+ for RS SIP signaling.
+
+
+
+
+Hutton, et al. Informational [Page 7]
+
+RFC 7245 Architecture for Media Recording May 2014
+
+
+ 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 Decomposition
+
+
+
+
+
+
+
+
+
+Hutton, et al. Informational [Page 8]
+
+RFC 7245 Architecture for Media Recording May 2014
+
+
+3.1.5. Interaction with Conference Focus
+
+ In the case of a centralized conference, a combination of the
+ conference focus and mixer [RFC4353] may act as a SRC and therefore
+ provide the SRS with the Replicated Media and associated recording
+ metadata. In this arrangement, the SRC is able to provide media and
+ metadata relating to each of the participants, including, for
+ example, any side conversations where the media passes through the
+ mixer.
+
+ The conference focus can either provide mixed Replicated Media or
+ separate streams per conference participant (as depicted in
+ Figure 5).
+
+ The conference focus may also act as a recording-aware UA in the case
+ when one of the participants acts as a SRC.
+
+ In an alternative arrangement, a SIP endpoint that is a conference
+ participant can act as an SRC. The SRC will in this case have access
+ to the media and metadata relating to that particular participant and
+ may be able to obtain additional metadata from the conference focus.
+ The SRC may, for example, use the conference event package as
+ described in [RFC4575] to obtain information about other participants
+ that it provides to the SRS within the recording metadata.
+
+ The SRC may be involved in the conference from the very beginning or
+ may join at some later point of time.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hutton, et al. Informational [Page 9]
+
+RFC 7245 Architecture for Media Recording May 2014
+
+
+ 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 SRC
+
+3.2. Establishing the Recording Session
+
+ The SRC or the SRS may initiate the Recording Session.
+
+ It should be noted that the Recording Session is independent from the
+ CS that is being recorded at both the SIP dialog level and at the
+ session level.
+
+ Concerning media negotiation, regular SIP/SDP capabilities should be
+ used, and existing transcoding capabilities and media encryption
+ should not be precluded.
+
+
+
+
+
+Hutton, et al. Informational [Page 10]
+
+RFC 7245 Architecture for Media Recording May 2014
+
+
+3.2.1. SRC-Initiated Recording
+
+ When the SRC initiates the Recording Session for the purpose of
+ conveying media to the SRS, it performs the following actions:
+
+ o Is provisioned with a Unified Resource Identifier (URI) for the
+ SRS; the URI is resolved through normal [RFC3263] procedures.
+
+ o Initiates the dialog by sending an INVITE request to the SRS. The
+ dialog is established according to the normal procedures for
+ establishing an INVITE-initiated dialog as specified in [RFC3261].
+
+ o Includes in the INVITE an indication that the session is
+ established for the purpose of recording the associated media.
+
+ o Includes an SDP attribute of "a=sendonly" for each media line if
+ the Replicated Media is to be started immediately, or includes
+ "a=inactive" if it is not ready to transmit the media.
+
+ o Replicates the media streams that are to be recorded and transmits
+ the media to the SRS.
+
+ The Recording Session may replicate all media associated with the CS
+ or only a subset.
+
+3.2.2. SRS-Initiated Recording
+
+ When the SRS initiates the media Recording Session with the SRC, it
+ performs the following actions:
+
+ o Is provisioned with a Unified Resource Identifier (URI) for the
+ SRC; the URI is resolved through normal [RFC3263] procedures.
+
+ o Sends an INVITE request to the SRC.
+
+ o Includes in the INVITE an indication that the session is
+ established for the purpose of recording the associated media.
+
+ o Identifies the sessions that are to be recorded. The actual
+ mechanism of the identification depends on SRC policy.
+
+ o Includes an SDP attribute of "a=recvonly" for each media line if
+ the Recording Session is to be started immediately, or includes
+ "a=inactive" if it is not ready to receive the media.
+
+ If the SRS does not have prior knowledge of what media streams are
+ available to be recorded, it can make use of an offerless INVITE,
+ which allows the SRC to make the initial SDP offer.
+
+
+
+Hutton, et al. Informational [Page 11]
+
+RFC 7245 Architecture for Media Recording May 2014
+
+
+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 the recording by
+ changing the direction back to "recvonly" or "sendonly".
+
+3.2.4. Media Stream Mixing
+
+ In a basic session involving only audio, there are typically two
+ audio/RTP streams between the two UAs involved in transporting media
+ in each direction. When recording this media, the two streams may be
+ mixed or not mixed at the SRC before being transmitted to the SRS.
+ In the case when they are not mixed, two separate streams are sent to
+ the SRS, and the SDP offer sent to the SRS must describe two separate
+ media streams. In the mixed case, a single mixed media stream is
+ sent to the SRS.
+
+3.2.5. Media Transcoding
+
+ The CS and the RS are negotiated separately using the standard SDP
+ offer/answer exchange which may result in the SRC having to perform
+ media transcoding between the two sessions. If the SRC is not
+ capable of performing media transcoding it may limit the media
+ formats in the offer to the SRS depending on what media is negotiated
+ on the CS or may limit what it includes in the offer on the CS if it
+ has prior knowledge of the media formats supported by the SRS.
+ However typically the SRS will be a more capable device which can
+ provide a wide range of media format options to the SRC and may also
+ be able to make use of a media transcoder as detailed in [RFC5369].
+
+3.2.6. Lossless Recording
+
+ Session recording may be a regulatory requirement in certain
+ communication environments. Such environments may impose a
+ requirement generally known as "lossless recording". An overall
+ solution for lossless recording may involve multiple layers of
+ solutions. Individual aspects of the solutions may range from
+ administering networks for appropriate QoS, reliable transmission of
+ recorded media, and perhaps certain SIPREC protocol-level
+ capabilities in SRC and SRS.
+
+
+
+
+
+
+
+
+
+
+
+Hutton, et al. Informational [Page 12]
+
+RFC 7245 Architecture for Media Recording May 2014
+
+
+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 obtains session recording metadata from the SRC. The
+ metadata is transported via SIP-based mechanisms as specified in
+ [REC-PROTOCOL]
+
+ It is also possible that metadata is transported via non-SIP-based
+ mechanisms, but these are considered out of scope.
+
+ It is also possible to have an RS session without the metadata; in
+ that case, the SRS will be receiving the metadata by some other means
+ or not at all.
+
+3.4. Notifications to the Recorded User Agents
+
+ Typically, a user that is involved in a session that is to be
+ recorded is notified by an announcement at the beginning of the
+ session or may receive some warning tones within the media. However,
+ SIPREC enables an indication that the call is being recorded to be
+ included in the SIP requests and responses associated with that CS.
+
+ The SRC provides the notification to all SIP UAs for which it is
+ replicating received media for the purpose of recording. 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 provide an indication of its
+ preference with regard to recording the media in the CS. The
+ mechanisms for this are specified in [REC-PROTOCOL]
+
+4. IANA Considerations
+
+ This document has no actions for IANA. This document mentions
+ SIP/SDP extensions. The associated IANA considerations are addressed
+ in [REC-PROTOCOL], which defines them.
+
+
+
+
+
+
+
+Hutton, et al. Informational [Page 13]
+
+RFC 7245 Architecture for Media Recording May 2014
+
+
+5. Security Considerations
+
+ The Recording Session is fundamentally a standard SIP dialog and
+ media session and therefore makes use of existing SIP security
+ mechanisms for securing the Recording Session and Recording Metadata.
+
+ The intended use of this architecture is only for the case where the
+ users are aware that they are being recorded, and the architecture
+ provides the means for the SRC to notify users that they are being
+ recorded.
+
+ This architectural solution is not intended to support lawful
+ intercept, which in contrast requires that users are not informed.
+
+ It is the responsibility of the SRS to protect the Replicated Media
+ and Recording Metadata once it has been received and archived. The
+ stored content must be protected using a cipher at least as strong
+ (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 these 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 may need to be stronger because the media is retransmitted
+ (allowing more possibility 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 is recording on the right recording
+ system. It is less important that the SRS authenticate the SRC, but
+ implementations must have the ability to perform mutual
+ authentication.
+
+ In some environments, it is desirable to not decrypt and re-encrypt
+ the media. This means 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 are re-encrypted on the RS, a new key must be
+ used.
+
+ The retrieval mechanism for media recorded by this protocol is out of
+ scope. Implementations of retrieval mechanisms should consider the
+ security implications carefully, as the retriever is not usually a
+ party to the call that was recorded. Retrievers should be
+ authenticated carefully. The cryptosuites on the retrieval should be
+ no less strong than those used on the RS and may need to be stronger.
+
+
+
+Hutton, et al. Informational [Page 14]
+
+RFC 7245 Architecture for Media Recording May 2014
+
+
+6. Acknowledgements
+
+ 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 assistance with this document and
+ working group. Also, thanks to all the members of the SIPREC WG
+ mailing list for providing 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.
+
+
+
+
+Hutton, et al. Informational [Page 15]
+
+RFC 7245 Architecture for Media Recording May 2014
+
+
+ [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
+
+
+
+
+
+
+
+
+
+Hutton, et al. Informational [Page 16]
+