Internet Engineering Task Force (IETF) K. Rehor, Ed.
Request for Comments: 6341 Cisco Systems
Category: Informational L. Portman, Ed.
ISSN: 2070-1721 NICE Systems
A. Hutton
Siemens Enterprise Communications
R. Jain
IPC Systems
August 2011
Internet Engineering Task Force (IETF) K. Rehor, Ed.
Request for Comments: 6341 Cisco Systems
Category: Informational L. Portman, Ed.
ISSN: 2070-1721 NICE Systems
A. Hutton
Siemens Enterprise Communications
R. Jain
IPC Systems
August 2011
Use Cases and Requirements for SIP-Based Media Recording (SIPREC)
基于SIP的媒体记录（SIPREC）的用例和要求
Abstract
摘要
Session recording is a critical requirement in many business communications environments, such as call centers and financial trading floors. In some of these environments, all calls must be recorded for regulatory and compliance reasons. In others, calls may be recorded for quality control or business analytics.
会话记录是许多业务通信环境中的一项关键要求，如呼叫中心和金融交易场所。在其中一些环境中，出于监管和法规遵从性原因，必须记录所有呼叫。在其他情况下，可能会记录通话以进行质量控制或业务分析。
Recording is typically performed by sending a copy of the session media to the recording devices. This document specifies requirements for extensions to SIP that will manage delivery of RTP media to a recording device. This is being referred to as SIP-based Media Recording.
通常通过向记录设备发送会话介质的副本来执行记录。本文档规定了SIP扩展的要求，该扩展将管理RTP介质到记录设备的交付。这被称为基于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/rfc6341.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6341.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 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 ....................................................2
2. Requirements Notation ...........................................4
3. Definitions .....................................................4
4. Use Cases .......................................................5
5. Requirements ...................................................10
6. Privacy Considerations .........................................13
7. Security Considerations ........................................14
8. Acknowledgements ...............................................15
9. Normative References ...........................................15
1. Introduction ....................................................2
2. Requirements Notation ...........................................4
3. Definitions .....................................................4
4. Use Cases .......................................................5
5. Requirements ...................................................10
6. Privacy Considerations .........................................13
7. Security Considerations ........................................14
8. Acknowledgements ...............................................15
9. Normative References ...........................................15
Session recording is a critical operational requirement in many businesses, especially where voice is used as a medium for commerce and customer support. A prime example where voice is used for trade is the financial industry. The call recording requirements in this industry are quite stringent. The recorded calls are used for dispute resolution and compliance. Other businesses, such as customer support call centers, typically employ call recording for quality control or business analytics, with different requirements.
会话录制是许多企业的一项关键运营要求，尤其是在语音被用作商业和客户支持媒介的情况下。在贸易中使用声音的一个主要例子是金融业。这个行业的通话记录要求非常严格。记录的通话用于解决争议和合规。其他业务，如客户支持呼叫中心，通常采用呼叫记录进行质量控制或业务分析，但要求不同。
Depending on the country and its regulatory requirements, financial trading floors typically must record all calls. In contrast, call centers typically only record a subset of the calls, and calls must not fail, regardless of the availability of the recording device.
根据国家及其监管要求，金融交易场所通常必须记录所有电话。相比之下，呼叫中心通常只记录呼叫的一个子集，无论录音设备是否可用，呼叫都不得失败。
Respecting the privacy rights and wishes of users engaged in a call is of paramount importance. In many jurisdictions, participants have a right to know that the session is being recorded or might be recorded, and they have a right to opt out, either by terminating the call or by demanding that the call not be recorded. Therefore, this
尊重通话用户的隐私权和意愿至关重要。在许多司法管辖区，参与者有权知道会话正在被录制或可能被录制，并且他们有权通过终止通话或要求不录制通话来选择退出。因此,
document contains requirements for being able to notify users that a call is being recorded and for users to be able to request that a call not be recorded. Use cases where users participating in a call are not informed that the call is or might be recorded are outside the scope of this document. In particular, lawful intercept is outside the scope of this document.
该文档包含能够通知用户正在录制通话以及用户能够请求不录制通话的要求。未通知参与呼叫的用户呼叫已被记录或可能被记录的用例不在本文档的范围内。特别是，合法拦截不在本文件范围内。
Furthermore, a one-size-fits-all model will not fit all markets where the scale and cost burdens vary widely and where needs differ for such solution capabilities as media injection, transcoding, and security. If a standardized solution supports all of the requirements from every recording market but doing so would be expensive for markets with lesser needs, then proprietary solutions for those markets will continue to propagate. Care must be taken, therefore, to make a standards-based solution support optionality and flexibility.
此外，一刀切的模式并不适用于规模和成本负担差异很大、对媒体注入、转码和安全性等解决方案功能的需求不同的所有市场。如果一个标准化的解决方案支持每个录音市场的所有要求，但这样做对于需求较少的市场来说代价高昂，那么这些市场的专有解决方案将继续传播。因此，必须注意使基于标准的解决方案支持可选性和灵活性。
This document specifies requirements for using SIP [RFC3261] between a Session Recording Client and a Session Recording Server to control the recording of media that has been transmitted in the context of a Communication Session. A Communication Session is the "call" between participants. The Session Recording Client is the source of the recorded media. The Session Recording Server is the sink of recorded media. It should be noted that the requirements for the protocol between a Session Recording Server and Session Recording Client have very similar requirements (such as codec and transport negotiation, encryption key interchange, and firewall traversal) as compared to regular SIP media sessions. The choice of SIP for session recording provides reuse of an existing protocol.
本文件规定了在会话记录客户端和会话记录服务器之间使用SIP[RFC3261]来控制在通信会话上下文中传输的媒体的记录的要求。通信会话是参与者之间的“呼叫”。会话录制客户端是录制媒体的来源。会话录制服务器是录制媒体的接收器。应当注意，与常规SIP媒体会话相比，会话记录服务器和会话记录客户端之间的协议要求具有非常相似的要求（例如编解码器和传输协商、加密密钥交换和防火墙穿越）。会话记录选择SIP提供了对现有协议的重用。
The recorded sessions can be any RTP media sessions, including voice, dual-tone multifrequency (DTMF) (as defined by [RFC4733]), video, and text (as defined by [RFC4103]).
记录的会话可以是任何RTP媒体会话，包括语音、双音多频（DTMF）（由[RFC4733]定义）、视频和文本（由[RFC4103]定义）。
An archived session recording is typically comprised of the Communication Session media content and the Communication Session Metadata. The Communication Session Metadata allows recording archives to be searched and filtered at a later time and allows a session to be played back in a meaningful way, e.g., with correct synchronization between the media. The Communication Session Metadata needs to be conveyed from the Session Recording Client to the Session Recording Server.
存档会话记录通常由通信会话媒体内容和通信会话元数据组成。通信会话元数据允许在以后搜索和过滤记录存档，并允许以有意义的方式（例如，通过媒体之间的正确同步）回放会话。通信会话元数据需要从会话记录客户端传输到会话记录服务器。
This document only considers active recording, where the Session Recording Client purposefully streams media to a Session Recording Server. Passive recording, where a recording device detects media directly from the network, is outside the scope of this document.
本文档仅考虑活动录制，其中会话录制客户端有意将媒体流传输到会话录制服务器。被动记录，即记录设备直接从网络检测媒体，不在本文件范围内。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] and indicate requirement levels for compliant mechanisms.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中的描述进行解释，并表示合规机制的要求级别。
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 Communication Session.
录制会话（RS）：在SRC和SRS之间创建的SIP会话，用于录制通信会话。
Figure 1 pictorially represents the relationship between a Recording Session and Communication Session.
图1以图形方式表示录制会话和通信会话之间的关系。
+-------------+ +-----------+
| | Communication Session | |
| A |<------------------------------------>| B |
| | | |
+-------------+ +-----------+
..................................................................
. Session .
. Recording .
. Client .
..................................................................
|
| Recording
| Session
|
v
+------------+
| Session |
| Recording |
| Server |
+------------+
+-------------+ +-----------+
| | Communication Session | |
| A |<------------------------------------>| B |
| | | |
+-------------+ +-----------+
..................................................................
. Session .
. Recording .
. Client .
..................................................................
|
| Recording
| Session
|
v
+------------+
| Session |
| Recording |
| Server |
+------------+
Figure 1
图1
Metadata: Information that describes recorded media and the CS to which they relate.
元数据：描述所记录媒体及其相关CS的信息。
Pause and Resume during a Communication Session: Pause: The action of temporarily discontinuing the transmission and collection of RS media. Resume: The action of recommencing the transmission and collection of RS media.
在通信会话期间暂停并恢复：暂停：暂时停止传输和收集RS媒体的动作。恢复：重新开始传输和收集RS媒体的动作。
Most security-related terms in this document are to be understood in the sense defined in [RFC4949]; such terms include, but are not limited to, "authentication", "confidentiality", "encryption", "identity", and "integrity".
本文件中的大多数安全相关术语应理解为[RFC4949]中定义的含义；这些术语包括但不限于“认证”、“保密”、“加密”、“身份”和“完整性”。
Use Case 1: Full-time Recording: One Recording Session for each Communication Session.
用例1：全时录制：每个通信会话一个录制会话。
For example, the diagram below shows the life cycle of Communication Sessions (CSs) and the relationship to the Recording Sessions (RS).
例如，下图显示了通信会话（CSs）的生命周期以及与录制会话（RS）的关系。
CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
RS |--- RS 1 ---| |--- RS 2 ---| |--- RS 3 ---|
t--->
RS |--- RS 1 ---| |--- RS 2 ---| |--- RS 3 ---|
t--->
Figure 2
图2
Record every CS for each specific extension/person.
记录每个特定分机/人员的每个CS。
The need to record all calls is typically due to business process purposes (such as transaction confirmation or dispute resolution) or to ensure compliance with governmental regulations. Applications include enterprise, contact center, and financial trading floors.
记录所有通话的需要通常是出于业务流程目的（如交易确认或争议解决）或确保遵守政府法规。应用包括企业、联络中心和金融交易大厅。
This is also commonly known as Total Recording.
这也称为总记录。
Use Case 2: Selective Recording: Start a Recording Session when a Communication Session to be recorded is established.
用例2：选择性录制：在建立要录制的通信会话时启动录制会话。
In this example, Communication Sessions 1 and 3 are recorded but CS 2 is not.
在此示例中，记录通信会话1和3，但不记录CS 2。
CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
CS |--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
RS |--- RS 1----| |--- RS 2 ---|
t--->
RS |--- RS 1----| |--- RS 2 ---|
t--->
Figure 3
图3
Use Case 3: Start/Stop a Recording Session during a Communication Session.
用例3：在通信会话期间启动/停止录制会话。
The Recording Session starts during a Communication Session, either manually via a user-controlled mechanism (e.g., a button on a user's phone) or automatically via an application (e.g., a contact center customer service application) or business event. A Recording Session ends either during the Communication Session or when the Communication Session ends. One or more Recording Sessions may record each Communication Session.
录制会话在通信会话期间启动，可以通过用户控制的机制（例如，用户电话上的按钮）手动启动，也可以通过应用程序（例如，呼叫中心客户服务应用程序）或业务事件自动启动。录制会话在通信会话期间或通信会话结束时结束。一个或多个记录会话可以记录每个通信会话。
CS |------------- Communication Session -----------|
CS |------------- Communication Session -----------|
RS |---- RS 1 ----| |---- RS 2 -----|
t--->
RS |---- RS 1 ----| |---- RS 2 -----|
t--->
Figure 4
图4
Use Case 4: Persistent Recording: A single Recording Session captures one or more Communication Sessions.
用例4：持久记录：单个记录会话捕获一个或多个通信会话。
|--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
|--- CS 1 ---| |--- CS 2 ---| |--- CS 3 ---|
RS |------------------- Recording Session ------------------|
t--->
RS |------------------- Recording Session ------------------|
t--->
Figure 5
图5
A Recording Session records continuously without interruption. Periods when there is no CS in progress must be reproduced upon playback (e.g., by recording silence during such periods, or by not recording such periods but marking them by means of metadata for utilization on playback, etc.). Applications include financial trading desks and emergency (first-responder) service bureaus. The length of a Persistent Recording Session is independent from the length of the actual Communication Sessions. Persistent Recording Sessions avoid issues such as media clipping that can occur due to delays in Recording Session establishment.
录制会话不间断地连续录制。回放时必须再现无CS进行中的时段（例如，通过在这些时段内记录静音，或通过不记录这些时段，但通过元数据标记这些时段，以便在回放时使用，等等）。应用包括金融交易台和应急（第一响应）服务局。持久记录会话的长度与实际通信会话的长度无关。持续录制会话可避免由于录制会话建立延迟而出现的媒体剪辑等问题。
The connection and attributes of media in the Recording Session are not dynamically signaled for each Communication Session before it can be recorded; however, codec re-negotiation is possible.
记录会话中的媒体的连接和属性在每个通信会话可以被记录之前不会被动态地发信号；但是，编解码器重新协商是可能的。
In some cases, more than one concurrent Communication Session (on a single end-user apparatus, e.g., trading-floor turret) is mixed into one Recording Session:
在某些情况下，多个并发通信会话（在单个终端用户设备上，例如交易台转台）混合到一个记录会话中：
|-------- CS 1 -------|
|-------- CS 2 -------|
|-------- CS 3 -------|
|-------- CS 1 -------|
|-------- CS 2 -------|
|-------- CS 3 -------|
RS |----------- Recording Session --------------|
t--->
RS |----------- Recording Session --------------|
t--->
Figure 6
图6
Use Case 5: Real-time Recording Controls.
用例5：实时记录控件。
For an active Recording Session, privacy or security reasons may demand not capturing a specific portion of a conversation. An example is for PCI (payment card industry) compliance where credit card information must be protected. One solution is not to record a caller speaking their credit card information.
对于活动录制会话，出于隐私或安全原因，可能需要不捕获会话的特定部分。一个例子是PCI（支付卡行业）合规性，其中必须保护信用卡信息。一种解决方法是不记录打电话的人说出他们的信用卡信息。
An example of a real-time control is Pause/Resume.
实时控件的一个示例是暂停/恢复。
Use Case 6: IVR / Voice Portal Recording.
用例6：IVR/语音入口录制。
Self-service Interactive Voice Response (IVR) applications may need to be recorded for application performance tuning or to meet compliance requirements.
可能需要录制自助式交互式语音应答（IVR）应用程序，以调整应用程序性能或满足法规遵从性要求。
Metadata about an IVR session recording must include session information and may include application context information (e.g., VoiceXML session variables, dialog names, etc.).
关于IVR会话记录的元数据必须包括会话信息，并且可能包括应用程序上下文信息（例如，VoiceXML会话变量、对话框名称等）。
Use Case 7: Enterprise Mobility Recording.
用例7：企业移动记录。
Many agents and enterprise workers whose calls are to be recorded are not located on company premises.
许多需要记录电话的代理人和企业员工不在公司场所。
Examples:
示例：
o Home-based agents or enterprise workers.
o 居家代理或企业员工。
o Mobile phones of knowledge workers (e.g., insurance agents, brokers, or physicians) when they conduct work-related (and legally required recording) calls.
o 知识型员工（如保险代理人、经纪人或医生）在进行工作相关（以及法律要求的录音）通话时使用的手机。
Use Case 8: Geographically distributed or centralized recording.
用例8：地理分布或集中记录。
Enterprises such as banks, insurance agencies, and retail stores may have many locations, possibly up to thousands of small sites. Frequently, only phones and network infrastructure are installed in branches, without local recording services. In cases where calls inside or between branches must be recorded, a centralized recording system in data centers together with telephony infrastructure (e.g., Private Branch Exchange (PBX)) may be deployed.
银行、保险机构和零售店等企业可能有许多地点，可能多达数千个小地点。分支机构通常只安装电话和网络基础设施，没有本地录音服务。如果必须记录分支内部或分支之间的呼叫，则可以在数据中心部署集中记录系统以及电话基础设施（例如，专用分支交换机（PBX））。
Use Case 9: Record complex call scenarios.
用例9：记录复杂的呼叫场景。
The following is an example of a scenario where one call that is recorded must be associated with a related call that also must be recorded.
下面是一个场景示例，其中一个已录制的呼叫必须与另一个也必须录制的相关呼叫相关联。
o A Customer is in a conversation with a Customer Service Agent.
o 客户正在与客户服务代理交谈。
o The Agent puts the Customer on hold in order to consult with a Supervisor.
o 代理人让客户暂停，以便与主管协商。
o The Agent enters into a conversation with the Supervisor.
o 代理与主管进行对话。
o The Agent disconnects from the Supervisor, then reconnects with the Customer.
o 代理与主管断开连接，然后与客户重新连接。
o The Supervisor call must be associated with the original Customer call.
o 主管呼叫必须与原始客户呼叫相关联。
Use Case 10: High availability and continuous recording.
用例10：高可用性和连续记录。
Specific deployment scenarios present different requirements for system availability, error handling, etc., including the following:
特定部署场景对系统可用性、错误处理等提出了不同的要求，包括以下内容：
o An SRS must always be available at call setup time.
o SRS必须在呼叫设置时始终可用。
o No loss of media recording can occur, including during failure of an SRS.
o 介质记录不会丢失，包括SRS故障期间。
o The Communication Session must be terminated (or suitable notification given to parties) in the event of a recording failure.
o 如果记录失败，必须终止通信会话（或向各方发出适当通知）。
Use Case 11: Record multi-channel, multimedia session.
用例11：录制多通道多媒体会话。
Some applications require the recording of more than one media stream, possibly of different types. Media are synchronized, either at storage or at playback.
一些应用程序需要记录多个媒体流，可能是不同类型的媒体流。媒体在存储或播放时同步。
Speech analytics technologies (e.g., word spotting, emotion detection, speaker identification) may require speaker-separated recordings for optimum performance.
语音分析技术（例如，单词识别、情感检测、说话人识别）可能需要分离说话人的录音以获得最佳性能。
Multi-modal contact centers may include audio, video, IM, or other interaction modalities.
多模式联络中心可包括音频、视频、IM或其他交互模式。
In trading-floor environments, in order to minimize storage and recording system resources, it may be preferable to mix multiple concurrent calls (Communication Sessions) on different handsets/ speakers on the same turret into a single recording session.
在交易场所环境中，为了最小化存储和录音系统资源，最好将同一转台上不同手机/扬声器上的多个并发呼叫（通信会话）混合到一个录音会话中。
Use Case 12: Real-time media processing.
用例12：实时媒体处理。
It must be possible for an SRS to support real-time media processing, such as speech analytics of trading-floor interactions. Real-time analytics may be employed for automatic intervention (stopping interaction or alerting) if, for example, a trader is not following regulations.
SRS必须能够支持实时媒体处理，如交易大厅交互的语音分析。实时分析可用于自动干预（停止交互或警报），例如，如果交易员不遵守规定。
Speaker separation is required in order to reliably detect who is saying specific phrases.
为了可靠地检测谁在说特定的短语，需要进行说话人分离。
The following are requirements for SIP-based Media Recording:
以下是基于SIP的媒体录制要求：
o REQ-001: The mechanism MUST provide a means for using the SIP protocol for establishing, maintaining, and terminating Recording Sessions between a Session Recording Client and a Session Recording Server.
o REQ-001：该机制必须提供使用SIP协议在会话记录客户端和会话记录服务器之间建立、维护和终止记录会话的方法。
o REQ-002: The mechanism MUST support the ability to record all CSs in their entirety.
o REQ-002：该机制必须支持完整记录所有CSs的能力。
o REQ-003: The mechanism MUST support the ability to record selected CSs in their entirety, according to policy.
o REQ-003：该机制必须支持根据策略完整记录所选CSs的能力。
o REQ-004: The mechanism MUST support the ability to record selected parts of selected CSs.
o REQ-004：该机制必须支持记录选定CSs的选定部分的功能。
o REQ-005: The mechanism MUST support the ability to record a CS without loss of media of RS (for example, clipping media at the beginning of the CS) due to RS recording preparation and also without impacting the quality or timing of the CS (for example, delaying the start of the CS while preparing for a recording session). See Use Case 4 in Section 4 for more details.
o REQ-005：该机制必须支持在不因RS记录准备而丢失RS介质（例如，在CS开头剪切介质）的情况下记录CS的能力，并且不影响CS的质量或定时（例如，在准备记录会话时延迟CS的启动）。有关更多详细信息，请参见第4节中的用例4。
o REQ-006: The mechanism MUST support the recording of IVR sessions.
o REQ-006：该机制必须支持IVR会话的记录。
o REQ-007: The mechanism MUST support the recording of the following RTP media types: voice, DTMF (as defined by [RFC4733]), video, and text (as defined by [RFC4103]).
o REQ-007：该机制必须支持以下RTP媒体类型的录制：语音、DTMF（定义见[RFC4733]）、视频和文本（定义见[RFC4103]）。
o REQ-008: The mechanism MUST support the ability for an SRC to deliver mixed audio streams from multiple Communication Sessions to an SRS.
o REQ-008：该机制必须支持SRC从多个通信会话向SRS传输混合音频流的能力。
Note: A mixed audio stream is where several related Communication Sessions are carried in a single Recording Session. A mixed-media stream is typically produced by a mixer function. The RS MAY be informed about the composition of the mixed streams through session metadata.
注：混合音频流是指在单个录制会话中进行多个相关通信会话的情况。混合媒体流通常由混合器功能产生。可以通过会话元数据向RS通知混合流的组成。
o REQ-009: The mechanism MUST support the ability for an SRC to deliver mixed audio streams from different parties of a given Communication Session to an SRS.
o REQ-009：该机制必须支持SRC将来自给定通信会话不同方的混合音频流传送到SRS的能力。
o REQ-010: The mechanism MUST support the ability to deliver to the SRS multiple media streams for a given CS.
o REQ-010：该机制必须支持为给定CS向SRS传输多个媒体流的能力。
o REQ-011: The mechanism MUST support the ability to pause and resume the transmission and collection of RS media.
o REQ-011：该机制必须支持暂停和恢复传输和收集RS介质的能力。
o REQ-012: The mechanism MUST include a means for providing the SRS with metadata describing CSs that are being recorded, including the media being used and the identifiers of parties involved.
o REQ-012：该机制必须包括向SRS提供描述正在记录的CSs的元数据的方法，包括正在使用的媒体和相关方的标识符。
o REQ-013: The mechanism MUST include a means for the SRS to be able to correlate RS media with CS participant media.
o REQ-013：该机制必须包括SRS能够将RS媒体与CS参与者媒体关联的方法。
o REQ-014: Metadata format must be agnostic of the transport protocol.
o REQ-014：元数据格式必须与传输协议无关。
o REQ-015: The mechanism MUST support a means to stop the recording.
o REQ-015：该机构必须支持停止记录的方法。
o REQ-016: The mechanism MUST support a means for a recording-aware UA involved in a CS to request at session establishment time that the CS should be recorded or should not be recorded, the honoring of such a request being dependent on policy.
o REQ-016：该机制必须支持一种方式，用于CS中涉及的记录感知UA在会话建立时请求记录或不记录CS，该请求的履行取决于策略。
o REQ-017: The mechanism MUST support a means for a recording-aware UA involved in a CS to request during a session that the recording of the CS should be started, paused, resumed, or stopped, the honoring of such a request being dependent on policy. Such recording-aware UAs MUST be notified about the outcome of such requests.
o REQ-017：该机制必须支持一种方式，用于CS中涉及的记录感知UA在会话期间请求启动、暂停、恢复或停止CS的记录，该请求的履行取决于策略。必须将此类请求的结果通知此类记录感知UAs。
o REQ-018: The mechanism MUST NOT prevent the application of tones or announcements during recording or at the start of a CS to support notification to participants that the call is being recorded or may be recorded.
o REQ-018：该机制不得阻止在录音期间或CS开始时应用音调或通知，以支持向参与者发出正在录音或可能录音呼叫的通知。
o REQ-019: The mechanism MUST provide a means of indicating to recording-aware UAs whether recording is taking place, for appropriate rendering at the user interface.
o REQ-019：该机制必须提供一种方法，用于指示感知记录的UAs是否正在进行记录，以便在用户界面上进行适当的渲染。
o REQ-020: The mechanism MUST provide a way for metadata to be conveyed to the SRS incrementally during the CS.
o REQ-020：该机制必须提供一种方式，使元数据在CS期间以增量方式传输到SRS。
o REQ-021: The mechanism MUST NOT prevent high-availability deployments.
o REQ-021：该机制不得阻止高可用性部署。
o REQ-022: The mechanism MUST provide means for facilitating synchronization of the recorded media streams and metadata.
o REQ-022：该机制必须提供促进记录的媒体流和元数据同步的方法。
o REQ-023: The mechanism MUST provide means for facilitating synchronization among the recorded media streams.
o REQ-023：该机制必须提供促进所记录媒体流之间同步的方法。
o REQ-024: The mechanism MUST provide means to relate recording and recording controls, such as start/stop/pause/resume, to the wall clock time.
o REQ-024：该机制必须提供将记录和记录控制（如开始/停止/暂停/恢复）与挂钟时间关联的方法。
o REQ-025: The mechanism MUST provide means for an SRS to authenticate the SRC on RS initiation.
o REQ-025：该机制必须为SRS提供在RS启动时验证SRC的方法。
o REQ-026: The mechanism MUST provide means for an SRC to authenticate the SRS on RS initiation.
o REQ-026：该机制必须为SRC提供在RS启动时验证SRS的方法。
o REQ-027: The mechanism MUST include a means for ensuring that the integrity of the metadata sent from the SRC to the SRS is an accurate representation of the original CS metadata.
o REQ-027：该机制必须包括确保从SRC发送到SRS的元数据的完整性是原始CS元数据的准确表示的方法。
o REQ-028: The mechanism MUST include a means for ensuring that the integrity of the media sent from the SRC to the SRS is an accurate representation of the original CS media.
o REQ-028：该机制必须包括确保从SRC发送至SRS的介质完整性是原始CS介质的准确表示的方法。
o REQ-029: The mechanism MUST include a means for ensuring the confidentiality of the metadata sent from the SRC to the SRS.
o REQ-029：该机制必须包括确保从SRC发送到SRS的元数据机密性的方法。
o REQ-030: The mechanism MUST provide a means to support RS confidentiality.
o REQ-030：该机制必须提供支持RS机密性的方法。
o REQ-031: The mechanism MUST support the ability to deliver to the SRS multiple media streams of the same media type (e.g., audio, video). One example is the case of delivering unmixed audio for each participant in the CS.
o REQ-031：该机制必须支持向SRS传输相同媒体类型（例如音频、视频）的多个媒体流的能力。一个例子是为CS中的每个参与者提供未混合的音频。
Respecting the privacy rights and wishes of users engaged in a call is of paramount importance. In many jurisdictions, participants have a right to know that the session is being recorded or might be recorded, and they have a right to opt out, either by terminating the call or by demanding that the call not be recorded. Therefore, this document contains requirements for being able to notify users that a call is being recorded and for users to be able to request that a call not be recorded. Use cases where users participating in a call are not informed that the call is or might be recorded are outside the scope of this document. In particular, lawful intercept is outside the scope of this document.
尊重通话用户的隐私权和意愿至关重要。在许多司法管辖区，参与者有权知道会话正在被录制或可能被录制，并且他们有权通过终止通话或要求不录制通话来选择退出。因此，本文档包含能够通知用户正在记录呼叫以及能够请求不记录呼叫的要求。未通知参与呼叫的用户呼叫已被记录或可能被记录的用例不在本文档的范围内。特别是，合法拦截不在本文件范围内。
Requirements for participant notification of recording vary widely by jurisdiction. In a given deployment, not all users will be authorized to stop the recording of a CS (although any user can terminate its participation in a CS). Typically, users within the domain that is carrying out the recording will be subject to policies of that domain concerning whether CSs are recorded. For example, in a call center, agents will be subject to policies of the call center and may or may not have the right to prevent the recording of a CS or part of a CS. Users calling into the call center, on the other hand, will typically have to ask the agent not to record the CS. If the agent is unable to prevent recording, or if the caller does not trust the agent, the only option generally is to terminate the CS.
参与者记录通知的要求因司法管辖区而异。在给定的部署中，并非所有用户都有权停止CS的录制（尽管任何用户都可以终止参与CS）。通常，域内执行录制的用户将遵守该域关于是否录制CSs的策略。例如，在呼叫中心，代理将遵守呼叫中心的政策，可能有权也可能没有权阻止录制CS或CS的一部分。另一方面，呼叫呼叫中心的用户通常必须要求代理不要记录CS。如果代理无法阻止录制，或者如果调用方不信任代理，通常唯一的选择是终止CS。
Privacy considerations also extend to what happens to a recording once it has been created. Typical issues are who can access the recording (e.g., receive a copy of the recording, view the metadata, play back the media, etc.), for what purpose the recording can be used (e.g., for training purposes, for quality control purposes, etc.), and for how long the recording is to be retained before deletion. These are typically policies of the domain that makes the recording, rather than policies of individual users involved in a recorded CS, whether those users be in the same domain or in a different domain. Taking the call center example again, agents might be made aware of call center policy regarding retention and use of recordings as part of their employment contract, and callers from outside the call center might be given some information about policy when notified that a CS will be recorded (e.g., through an announcement that says that calls may be recorded for quality purposes).
隐私方面的考虑也延伸到录制创建后会发生什么。典型的问题是谁可以访问记录（例如，接收记录副本、查看元数据、播放媒体等）、记录的用途（例如，用于培训目的、质量控制目的等），以及删除前记录的保留时间。这些通常是进行记录的域的策略，而不是记录的CS中涉及的单个用户的策略，无论这些用户是在同一域中还是在不同的域中。再次以呼叫中心为例，可能会让代理了解有关保留和使用录音作为其雇佣合同一部分的呼叫中心政策，并且当通知呼叫中心以外的呼叫者将录制CS时，可能会向他们提供一些有关政策的信息（例如，通过一项声明，声明可能出于质量目的对通话进行录音）。
This document does not specify any requirements for a user engaged in a CS to be able to dictate policy for what happens to a recording, or for such information to be conveyed from an SRC to an SRS. It is assumed that the SRS has access to policy applicable to its environment and can ensure that recordings are stored and used in accordance with that policy.
本文件未规定CS用户能够就记录发生的情况或此类信息从SRC传输至SRS的任何要求。假设SRS可以访问适用于其环境的策略，并可以确保按照该策略存储和使用记录。
Session recording has substantial security implications, for the SIP UAs being recorded, the SRC, and the SRS.
会话录制对正在录制的SIP UAs、SRC和SRS具有重大的安全影响。
For the SIP UAs involved in the Communication Session, the requirements in this document enable the UA to identify that a Communication Session is being recorded and to request that a given Communication Session not be subject to recording.
对于通信会话中涉及的SIP UAs，本文件中的要求使UA能够识别正在记录的通信会话，并请求不记录给定的通信会话。
Since humans don't typically look at or know about protocol signaling such as SIP, and indeed the SIP session might have originated through a Public Switched Telephone Network (PSTN) gateway without any ability to pass on in-signaling indications of recording, users can be notified of recording in the media itself through voice announcements, a visual indicator on the endpoint, or other means.
由于人类通常不会查看或了解诸如SIP之类的协议信令，而且实际上SIP会话可能是通过公共交换电话网（PSTN）网关发起的，没有任何能力传递记录的信令指示，因此可以通过语音通知通知用户在媒体中记录，端点上的视觉指示器或其他方式。
With regard to security implications of the protocol(s), clearly there is a need for authentication, authorization, and eavesdropping protection for the solution. The SRC needs to know the SRS it is communicating with is legitimate, and vice versa, even if they are in different domains. Both the signaling and media for the Recording Session need the ability to be authenticated and protected from eavesdropping. Requirements are detailed in Section 5.
关于协议的安全含义，显然需要对解决方案进行身份验证、授权和窃听保护。SRC需要知道与其通信的SRS是合法的，反之亦然，即使它们位于不同的域中。记录会话的信令和媒体都需要进行身份验证并防止窃听。要求详见第5节。
Communication Sessions and Recording Sessions can require different security levels both for signaling and media, depending on deployment configurations. For some environments, e.g., the SRS and SRC will be collocated in a secure network region, and therefore the RS will not require the same protection level as a CS that extends over a public network, for example. For other environments, the SRS can be located in a public cloud, for example, and the RS will require a higher protection level than the CS. For these reasons, there is not a direct relationship between the security level of Communication Sessions and the security level of Recording Sessions.
通信会话和录制会话可能需要不同的信令和媒体安全级别，具体取决于部署配置。对于某些环境，例如，SRS和SRC将并置在安全网络区域中，因此，例如，RS将不需要与扩展到公共网络上的CS相同的保护级别。例如，对于其他环境，SRS可以位于公共云中，RS将需要比CS更高的保护级别。由于这些原因，通信会话的安全级别与录制会话的安全级别之间没有直接关系。
A malicious or corrupt SRC can tamper with media and metadata relating to a CS before sending the data to an SRS. Also, CS media and signaling can be tampered with in the network prior to reaching an SRC, unless proper means are provided to ensure integrity protection during transmission on the CS. Means for ensuring the
恶意或损坏的SRC可以在将数据发送到SRS之前篡改与CS相关的媒体和元数据。此外，在到达SRC之前，可以在网络中篡改CS媒体和信令，除非提供了适当的方法来确保在CS上传输期间的完整性保护。确保安全的手段
correctness of media and metadata emitted by an SRC are outside the scope of this work. Other organizational and technical controls will need to be used to prevent tampering.
SRC发出的媒体和元数据的正确性不在本工作范围内。需要使用其他组织和技术控制来防止篡改。
Thanks to Dan Wing, Alan Johnson, Vijay Gurbani, Cullen Jennings, Hadriel Kaplan, Henry Lum, Dave Smith, Martin Palmer, Alissa Cooper, Deepanshu Gautam, Paul Kyzivat, Parthasarathi R, Ram Mohan R, and Charles Eckel for their significant contributions and assistance with this document and the SIPREC WG, and to all the members of the DISPATCH WG and SIPREC WG mailing lists for providing valuable input to this work.
感谢Dan Wing、Alan Johnson、Vijay Gurbani、Cullen Jennings、Hadriel Kaplan、Henry Lum、Dave Smith、Martin Palmer、Alissa Cooper、Deepansu Gautam、Paul Kyzivat、Parthasarathi R、Ram Mohan R和Charles Eckel为本文件和SIPREC工作组做出的重大贡献和协助，以及派遣工作组和SIPREC工作组邮件列表的所有成员，为这项工作提供有价值的投入。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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月。
[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation", RFC 4103, June 2005.
[RFC4103]Hellstrom，G.和P.Jones，“文本对话的RTP有效负载”，RFC 4103，2005年6月。
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
[RFC4733]Schulzrinne，H.和T.Taylor，“DTMF数字、电话音和电话信号的RTP有效载荷”，RFC 47332006年12月。
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007.
[RFC4949]Shirey，R.，“互联网安全词汇表，第2版”，FYI 36，RFC 4949，2007年8月。
Authors' Addresses
作者地址
Ken Rehor (editor) Cisco Systems 170 West Tasman Dr. Mail Stop SJC30/2/ San Jose, CA 95134 USA
Ken Rehor（编辑）思科系统170 West Tasman Dr.Mail Stop SJC30/2/美国加利福尼亚州圣何塞95134
EMail: krehor@cisco.com
EMail: krehor@cisco.com
Leon Portman (editor) NICE Systems 8 Hapnina Ra'anana 43017 Israel
利昂·波特曼（编辑）尼斯系统8哈普尼娜·拉阿纳纳43017以色列
EMail: leon.portman@nice.com
EMail: leon.portman@nice.com
Andrew Hutton Siemens Enterprise Communications
安德鲁·赫顿西门子企业通信公司
EMail: andrew.hutton@siemens-enterprise.com
URI: http://www.siemens-enterprise.com
EMail: andrew.hutton@siemens-enterprise.com
URI: http://www.siemens-enterprise.com
Rajnish Jain IPC Systems 777 Commerce Drive Fairfield, CT 06825 USA
美国康涅狄格州费尔菲尔德商业大道777号拉尼什·詹IPC系统公司，邮编：06825
EMail: rajnish.jain@ipc.com
EMail: rajnish.jain@ipc.com