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
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).
会话记录是许多通信环境（如呼叫中心和金融交易）的关键要求。在其中一些环境中，出于监管、法规遵从性和消费者保护的原因，必须记录所有呼叫。会话的记录通常通过向记录设备发送媒体流的副本来执行。本文档描述了在基于会话启动协议（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.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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
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].
会话记录是许多通信环境（如呼叫中心和金融交易）的关键要求。在其中一些环境中，出于监管、法规遵从性和消费者保护的原因，必须记录所有呼叫。会话的记录通常通过向记录设备发送媒体流的副本来执行。本文档描述了“基于SIP的媒体录制（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.
本文档重点介绍如何在会话记录客户端（SRC）和会话记录服务器（SRS）之间建立会话，以便传输与通信会话相关的复制媒体和记录元数据（例如，相关方的身份）。
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.
一旦SRS接收到复制的媒体和记录元数据，通常会将其存档以供以后检索。与此信息的存档和检索相关的程序不在本文件的范围内。
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].
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].translate error, please retry
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.
SRC和SRS之间建立的录制会话使用[RFC3261]中规定的建立邀请发起对话的正常过程，并使用会话描述协议（SDP）来描述[RFC4566]中规定的会话期间要使用的媒体。然而，打算对SIP的一些扩展（例如，标题、选项标签等）进行定义，以支持媒体记录的要求。复制的介质需要实时发送到SRS，SRC不会对其进行缓冲，以允许SRS对介质进行实时分析。
The first four definitions are quoted from RFC 6341.
前四个定义引用自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.
会话记录服务器（SRS）：会话记录服务器（SRS）是一个SIP用户代理（UA），它是一个专门的媒体服务器或收集器，充当记录媒体的接收器。SRS通常被实现为能够同时从多个源接收媒体的多端口设备。SRS是记录的会话元数据的接收器。
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.
会话记录客户端（SRC）：会话记录客户端（SRC）是一个SIP用户代理（UA），充当记录媒体的源，将其发送到SRS。SRC是一个逻辑函数。它的功能可以跨一个或多个物理设备实现。实际上，SRC可以是个人设备（例如SIP电话）、SIP媒体网关（MG）、会话边界控制器（SBC）或与应用服务器（as）集成的SIP媒体服务器（MS）。本规范定义了术语“SRC”，使得所有此类SIP实体都可以在一个定义下通用地寻址。SRC向SRS提供元数据。
Communication Session (CS): A session created between two or more SIP User Agents (UAs) that is the subject of recording.
通信会话（CS）：在两个或多个SIP用户代理（UAs）之间创建的会话，它是记录的主题。
Recording Session (RS): The SIP session created between an SRC and SRS for the purpose of recording a CS.
录制会话（RS）：在SRC和SRS之间创建的SIP会话，用于录制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.
记录感知用户代理（UA）：一个SIP用户代理，它感知与CS相关联的SIP扩展。此类扩展可用于通知记录感知UA正在记录会话，或由记录感知UA表示关于是否应开始、暂停、恢复或停止记录的偏好。
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.
录制不知道的用户代理（UA）：不知道与CS关联的SIP扩展的SIP用户代理。这样的记录将被通知正在记录会话，或者将通过SIP媒体记录体系结构范围之外的一些其他方式表示关于是否应该开始、暂停、恢复或停止记录的偏好。
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.
记录元数据：描述SRS所需的CS的元数据。例如，这将包括参与CS和对话状态的用户的身份。通常，此元数据与SRS上的复制介质一起存档。记录元数据实时传送到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.
复制介质：与CS关联的介质副本，由SRC创建并发送到SRS。它可以包含与CS相关联的所有媒体（例如，音频和视频）或仅包含一个子集（例如，音频）。复制的媒体是录制会话的一部分。
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.
本节包含一些示例会话记录体系结构，展示了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.
能够访问要记录的媒体的SIP背靠背用户代理（B2BUA）可以充当SRC。B2BUA可能已经意识到在初始建立CS之前需要记录会话，或者记录会话的决定可能发生在会话建立之后。
If the SRC makes the decision to initiate the RS, then it will do so by sending a SIP INVITE request to the SRS.
如果SRC决定启动RS，那么它将通过向SRS发送SIP INVITE请求来执行此操作。
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.
如果SRS决定发起记录会话，则它将通过向SRC发送INVITE来发起SIP RS的建立。
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.
RS INVITE包含将会话标识为为了记录而建立的信息，并且如果RS由SRC启动，则可防止会话意外地重新路由到非SRS的UA，反之亦然。
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 notifying the UAs involved in the CS that the session is being recorded.translate error, please retry
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.
B2BUA/SRC负责遵守来自记录感知UAs的请求，或通过一些指示不应记录CS的配置策略。
+-----------+
(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)
+-----------+
(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
图1:B2BUA充当会话记录客户端
A SIP endpoint / UA may act as a SRC. In that case, the endpoint sends the Replicated Media to the SRS.
SIP端点/UA可以充当SRC。在这种情况下，端点将复制的媒体发送到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.
如果端点决定启动录制会话，那么它将通过向SRS发送INVITE来启动SIP会话的建立。
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.
如果SRS决定启动录制会话，则它将通过向端点发送INVITE来启动SIP会话的建立。实际的决策机制超出了SIP媒体记录体系结构的范围。
(Recording Session) +-----------+
+----------SIP------>| |
| +----RTP/RTCP---->| Session |
| | | Recording |
| | | Server |
| | +-- Metadata -->| (SRS) |
| | | | |
| | | +-----------+
| | |
| | |
| | |
| | |
V V | (Communication Session)
+--+------+ +---------+
| |<-------SIP--------->| |
| UA-A | | UA-B |
| (SRC) |<-----RTP/RTCP------>| |
+---------+ +---------+
(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
图2:SIP端点充当会话记录客户端
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.
SIP代理无法充当SRC，因为它无法访问介质，因此无法将复制介质传送到SRS。
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.
MEDIACTRL体系结构[RFC5567]描述了应用服务器（AS）控制媒体服务器（MS）的体系结构，媒体服务器（MS）可用于会议和记录媒体流等目的。在[RFC5567]中描述的体系结构中，AS通常使用SIP第三方呼叫控制（3PCC）来指示SIP UAs将其媒体定向到媒体服务器。
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.
本文件中描述的SRC或SRS可根据[RFC5567]进行架构设计；因此，当进一步分解时，它们可能由使用MEDIACTRL接口控制MS的AS组成。
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.
如图3所示，当根据[RFC5567]构建SRS时，MS充当记录介质的接收器，As充当元数据的接收器和RS SIP信令的终止点。如图4所示，当根据[RFC5567]构建SRC时，MS充当记录媒体源，As充当元数据源和RS SIP信令的终止点。
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--------->| |
+----------+ +---------+
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
图3：使用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------>| |
| | | | | | +---------+
| +-----------+ +------------+ |
| |
+----------------------------------------+
+----------+
(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
图4：会话记录客户机分解示例
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.
在集中式会议的情况下，会议焦点和混合器[RFC4353]的组合可以充当SRC，并因此向SRS提供复制媒体和相关联的记录元数据。在该布置中，SRC能够提供与每个参与者相关的媒体和元数据，包括例如媒体通过混合器的任何侧对话。
The conference focus can either provide mixed Replicated Media or separate streams per conference participant (as depicted in Figure 5).
会议焦点可以为每个会议参与者提供混合复制媒体或单独的流（如图5所示）。
The conference focus may also act as a recording-aware UA in the case when one of the participants acts as a SRC.
当一名参与者充当SRC时，会议焦点还可以充当记录感知UA。
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.
在替代安排中，作为会议参与者的SIP端点可以充当SRC。在这种情况下，SRC将有权访问与该特定参与者相关的媒体和元数据，并且可能能够从会议焦点获得额外的元数据。例如，SRC可以使用[RFC4575]中所述的会议事件包来获取其在记录元数据中向SRS提供的关于其他参与者的信息。
The SRC may be involved in the conference from the very beginning or may join at some later point of time.
SRC可能从一开始就参与会议，也可能在稍后某个时间加入。
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
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
图5：作为SRC的会议焦点
The SRC or the SRS may initiate the Recording Session.
SRC或SRS可以发起记录会话。
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.
应注意，记录会话独立于在SIP对话级别和会话级别记录的CS。
Concerning media negotiation, regular SIP/SDP capabilities should be used, and existing transcoding capabilities and media encryption should not be precluded.
关于媒体协商，应使用常规SIP/SDP功能，不应排除现有转码功能和媒体加密。
When the SRC initiates the Recording Session for the purpose of conveying media to the SRS, it performs the following actions:
当SRC启动记录会话以向SRS传输介质时，它将执行以下操作：
o Is provisioned with a Unified Resource Identifier (URI) for the SRS; the URI is resolved through normal [RFC3263] procedures.
o 为SRS提供统一资源标识符（URI）；URI通过正常的[RFC3263]过程解析。
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 通过向SRS发送INVITE请求来启动对话框。按照[RFC3261]中规定的建立邀请发起对话的正常程序建立对话。
o Includes in the INVITE an indication that the session is established for the purpose of recording the associated media.
o 在INVITE中包括会话是为了记录相关媒体而建立的指示。
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 如果要立即启动复制的介质，则每个介质线都包含SDP属性“a=sendonly”；如果尚未准备好传输介质，则包含“a=inactive”。
o Replicates the media streams that are to be recorded and transmits the media to the SRS.
o 复制要记录的媒体流，并将媒体传输到SRS。
The Recording Session may replicate all media associated with the CS or only a subset.
记录会话可复制与CS相关联的所有媒体或仅复制子集。
When the SRS initiates the media Recording Session with the SRC, it performs the following actions:
SRS启动与SRC的媒体录制会话时，会执行以下操作：
o Is provisioned with a Unified Resource Identifier (URI) for the SRC; the URI is resolved through normal [RFC3263] procedures.
o 为SRC提供统一资源标识符（URI）；URI通过正常的[RFC3263]过程解析。
o Sends an INVITE request to the SRC.
o 向SRC发送INVITE请求。
o Includes in the INVITE an indication that the session is established for the purpose of recording the associated media.
o 在INVITE中包括会话是为了记录相关媒体而建立的指示。
o Identifies the sessions that are to be recorded. The actual mechanism of the identification depends on SRC policy.
o 标识要录制的会话。识别的实际机制取决于SRC策略。
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.
o 如果要立即启动录制会话，则每个媒体行都包含SDP属性“a=RecvoOnly”；如果尚未准备好接收媒体，则包含“a=inactive”。
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.
如果SRS事先不知道可记录哪些媒体流，则可以使用无报价邀请，这允许SRC进行初始SDP报价。
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".
SRS或SRC可通过将SDP方向属性更改为“非活动”来暂停记录，并通过将方向更改回“RecvoOnly”或“sendonly”来恢复记录。
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.
在仅涉及音频的基本会话中，两个UAs之间通常有两个音频/RTP流，用于在每个方向上传输媒体。当记录该介质时，两个流在发送到SRS之前可以在SRC处混合或不混合。在它们不混合的情况下，两个单独的流被发送到SRS，并且发送到SRS的SDP offer必须描述两个单独的媒体流。在混合情况下，单个混合媒体流被发送到SRS。
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].
使用标准SDP提供/应答交换分别协商CS和RS，这可能导致SRC必须在两个会话之间执行媒体转码。如果SRC不能执行媒体转码，它可以根据CS上协商的媒体限制SRS的报价中的媒体格式，或者如果它事先知道SRS支持的媒体格式，它可以限制CS上报价中包含的内容。然而，SRS通常将是一个功能更强的设备，它可以向SRC提供广泛的媒体格式选项，并且还可以使用[RFC5369]中详述的媒体转码器。
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.
会话记录可能是某些通信环境中的法规要求。这种环境可能会施加一种通常称为“无损记录”的要求。无损记录的整体解决方案可能涉及多层解决方案。解决方案的各个方面可能包括管理网络以获得适当的QoS、记录媒体的可靠传输，以及SRC和SRS中的某些SIPREC协议级功能。
The metadata model is defined in [REC-METADATA].
元数据模型在[REC-metadata]中定义。
The SRS obtains session recording metadata from the SRC. The metadata is transported via SIP-based mechanisms as specified in [REC-PROTOCOL]
SRS从SRC获取会话记录元数据。元数据通过[REC-PROTOCOL]中规定的基于SIP的机制传输
It is also possible that metadata is transported via non-SIP-based mechanisms, but these are considered out of scope.
元数据也可能通过非基于SIP的机制传输，但这些机制被认为超出了范围。
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.
也可以有没有元数据的RS会话；在这种情况下，SRS将通过其他方式接收元数据，或者根本不接收元数据。
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.
通常，参与要记录的会话的用户在会话开始时通过公告得到通知，或者可能在媒体中收到一些警告音。但是，SIPREC允许将记录呼叫的指示包括在与该CS相关联的SIP请求和响应中。
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.
SRC向所有SIP UAs提供通知，为其复制接收到的媒体以进行记录。如第3.1.2节所述，如果SRC充当SIP端点，则它还向本地用户提供通知。
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]
在初始会话建立期间或在已建立会话期间，记录感知UA可提供其关于在CS中记录媒体的偏好的指示。[REC-PROTOCOL]中规定了这方面的机制
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.
本文档没有针对IANA的操作。本文档提到SIP/SDP扩展。相关IANA注意事项在[REC-PROTOCOL]中进行了说明，该协议对这些注意事项进行了定义。
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.
录制会话基本上是一个标准的SIP对话和媒体会话，因此利用现有的SIP安全机制来保护录制会话和录制元数据。
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.
该体系结构的预期用途仅适用于用户意识到他们正在被记录的情况，并且该体系结构为SRC提供了通知用户他们正在被记录的手段。
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.
SRS有责任在接收和归档复制的媒体和记录元数据后对其进行保护。必须使用至少与原始内容强度相同（或更高）的密码对存储内容进行保护；但是，保护SRS存储和检索的机制不在本工作范围内。用于存储数据的密钥也必须由SRS安全维护，并且只能安全地释放给授权方。如何保护这些密钥、正确授权接收方或安全分发密钥材料也不在本工作范围内。
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.
RS的保护不应弱于CS的保护，并且可能需要更强，因为媒体被重新传输（允许更大的截获可能性）。这适用于信令和媒体路径。
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.
SRC必须对SRS进行身份验证，因为客户端必须确保它正在正确的记录系统上记录。SRS对SRC进行身份验证并不重要，但实现必须能够执行相互身份验证。
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.
在某些环境中，最好不要对媒体进行解密和重新加密。这意味着在CS和RS中协商和使用相同的媒体加密密钥。如果出于任何原因，媒体在CS上解密并在RS上重新加密，则必须使用新密钥。
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.
此协议记录的媒体的检索机制超出范围。检索机制的实现应该仔细考虑安全含义，因为检索者通常不是记录的调用的一方。寻回者应该仔细认证。检索上的加密套件应不低于RS上使用的加密套件，并且可能需要更强。
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.
感谢John Elwell、Brian Rosen、Alan Johnson、Cullen Jennings、Hadriel Kaplan、Henry Lum、Paul Kyzivat、Parthasarathi R、Ram Mohan R、Charles Eckel、Friso Feenstra和Dave Higton为本文件和工作组做出的重大贡献和协助。同时，感谢SIPREC工作组邮件列表的所有成员为这项工作提供了宝贵的投入。
[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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC 3263，2002年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC6341] Rehor, K., Portman, L., Hutton, A., and R. Jain, "Use Cases and Requirements for SIP-Based Media Recording (SIPREC)", RFC 6341, August 2011.
[RFC6341]Rehor，K.，Portman，L.，Hutton，A.，和R.Jain，“基于SIP的媒体记录（SIPREC）的用例和要求”，RFC 63412011年8月。
[REC-METADATA] Ravindranath, R., Ravindran, P., and P. Kyzivat, "Session Initiation Protocol (SIP) Recording Metadata", Work in Progress, February 2014.
[REC-METADATA]Ravindranath，R.，Ravindran，P.，和P.Kyzivat，“会话启动协议（SIP）记录元数据”，正在进行的工作，2014年2月。
[REC-PROTOCOL] Portman, L., Lum, H., Eckel, C., Johnston, A., and A. Hutton, "Session Recording Protocol", Work in Progress, February 2014.
[REC-协议]Portman，L.，Lum，H.，Eckel，C.，Johnston，A.，和A.Hutton，“会话记录协议”，正在进行的工作，2014年2月。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[RFC4353]Rosenberg，J.，“会话启动协议（SIP）会议框架”，RFC 4353，2006年2月。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575]Rosenberg，J.，Schulzrinne，H.，和O.Levin，“会议状态的会话启动协议（SIP）事件包”，RFC 45752006年8月。
[RFC5567] Melanchuk, T., "An Architectural Framework for Media Server Control", RFC 5567, June 2009.
[RFC5567]Melanchuk，T.，“媒体服务器控制的体系结构框架”，RFC5567，2009年6月。
[RFC5369] Camarillo, G., "Framework for Transcoding with the Session Initiation Protocol (SIP)", RFC 5369, October 2008.
[RFC5369]Camarillo，G.“会话启动协议（SIP）转码框架”，RFC 5369，2008年10月。
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, May 2000.
[RFC2804]IAB和IESG，“IETF关于窃听的政策”，RFC28042000年5月。
Authors' Addresses
作者地址
Andrew Hutton (editor) Unify Hofmannstrasse 51 81359 Munich Germany
安德鲁·赫顿（编辑）德国慕尼黑曼恩大街5181359号
EMail: andrew.hutton@unify.com
EMail: andrew.hutton@unify.com
Leon Portman (editor) NICE Systems 8 Hapnina Ra'anana 43017 Israel
利昂·波特曼（编辑）尼斯系统8哈普尼娜·拉阿纳纳43017以色列
EMail: leon.portman@gmail.com
EMail: leon.portman@gmail.com
Rajnish Jain IPC Systems 777 Commerce Drive Fairfield, CT 06825 USA
美国康涅狄格州费尔菲尔德商业大道777号拉尼什·詹IPC系统公司，邮编：06825
EMail: rajnish.jain@outlook.com
EMail: rajnish.jain@outlook.com
Ken Rehor Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
Ken Rehor Cisco Systems，Inc.美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134-1706
EMail: krehor@cisco.com
EMail: krehor@cisco.com