Internet Engineering Task Force (IETF) L. Portman
Request for Comments: 7866 NICE Systems
Category: Standards Track H. Lum, Ed.
ISSN: 2070-1721 Genesys
C. Eckel
Cisco
A. Johnston
Illinois Institute of Technology
A. Hutton
Unify
May 2016
Internet Engineering Task Force (IETF) L. Portman
Request for Comments: 7866 NICE Systems
Category: Standards Track H. Lum, Ed.
ISSN: 2070-1721 Genesys
C. Eckel
Cisco
A. Johnston
Illinois Institute of Technology
A. Hutton
Unify
May 2016
Session Recording Protocol
会话记录协议
Abstract
摘要
This document specifies the use of the Session Initiation Protocol (SIP), the Session Description Protocol (SDP), and the Real-time Transport Protocol (RTP) for delivering real-time media and metadata from a Communication Session (CS) to a recording device. The Session Recording Protocol specifies the use of SIP, SDP, and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. This document considers only active recording, where the SRC purposefully streams media to an SRS and all participating user agents (UAs) are notified of the recording. 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.
本文档规定了会话启动协议（SIP）、会话描述协议（SDP）和实时传输协议（RTP）的使用，用于将实时媒体和元数据从通信会话（CS）传送到记录设备。会话记录协议指定使用SIP、SDP和RTP在CS路径上的会话记录客户端（SRC）和记录设备上的会话记录服务器（SRS）之间建立记录会话（RS）。本文档仅考虑主动记录，其中SRC有意将媒体流传输至SRS，并将记录通知所有参与的用户代理（UAs）。被动记录，即记录设备直接从网络检测媒体（例如，使用端口镜像技术），不在本文档范围内。此外，合法拦截不在本文件范围内。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc7866.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7866.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 ....................................................4
2. Terminology .....................................................4
3. Definitions .....................................................4
4. Scope ...........................................................4
5. Overview of Operations ..........................................5
5.1. Delivering Recorded Media ..................................5
5.2. Delivering Recording Metadata ..............................8
5.3. Receiving Recording Indications and Providing Recording
Preferences ................................................9
6. SIP Handling ...................................................11
6.1. Procedures at the SRC .....................................11
6.1.1. Initiating a Recording Session .....................11
6.1.2. SIP Extensions for Recording Indications
and Preferences ....................................12
6.2. Procedures at the SRS .....................................12
6.3. Procedures for Recording-Aware User Agents ................12
7. SDP Handling ...................................................13
7.1. Procedures at the SRC .....................................13
7.1.1. SDP Handling in the RS .............................13
7.1.1.1. Handling Media Stream Updates .............14
7.1.2. Recording Indication in the CS .....................15
7.1.3. Recording Preference in the CS .....................16
7.2. Procedures at the SRS .....................................16
7.3. Procedures for Recording-Aware User Agents ................18
7.3.1. Recording Indication ...............................18
7.3.2. Recording Preference ...............................19
8. RTP Handling ...................................................20
8.1. RTP Mechanisms ............................................20
8.1.1. RTCP ...............................................20
8.1.2. RTP Profile ........................................21
8.1.3. SSRC ...............................................21
1. Introduction ....................................................4
2. Terminology .....................................................4
3. Definitions .....................................................4
4. Scope ...........................................................4
5. Overview of Operations ..........................................5
5.1. Delivering Recorded Media ..................................5
5.2. Delivering Recording Metadata ..............................8
5.3. Receiving Recording Indications and Providing Recording
Preferences ................................................9
6. SIP Handling ...................................................11
6.1. Procedures at the SRC .....................................11
6.1.1. Initiating a Recording Session .....................11
6.1.2. SIP Extensions for Recording Indications
and Preferences ....................................12
6.2. Procedures at the SRS .....................................12
6.3. Procedures for Recording-Aware User Agents ................12
7. SDP Handling ...................................................13
7.1. Procedures at the SRC .....................................13
7.1.1. SDP Handling in the RS .............................13
7.1.1.1. Handling Media Stream Updates .............14
7.1.2. Recording Indication in the CS .....................15
7.1.3. Recording Preference in the CS .....................16
7.2. Procedures at the SRS .....................................16
7.3. Procedures for Recording-Aware User Agents ................18
7.3.1. Recording Indication ...............................18
7.3.2. Recording Preference ...............................19
8. RTP Handling ...................................................20
8.1. RTP Mechanisms ............................................20
8.1.1. RTCP ...............................................20
8.1.2. RTP Profile ........................................21
8.1.3. SSRC ...............................................21
8.1.4. CSRC ...............................................22
8.1.5. SDES ...............................................22
8.1.5.1. CNAME .....................................22
8.1.6. Keepalive ..........................................22
8.1.7. RTCP Feedback Messages .............................23
8.1.7.1. Full Intra Request ........................23
8.1.7.2. Picture Loss Indication ...................23
8.1.7.3. Temporary Maximum Media Stream Bit
Rate Request ..............................24
8.1.8. Symmetric RTP/RTCP for Sending and Receiving .......24
8.2. Roles .....................................................25
8.2.1. SRC Acting as an RTP Translator ....................26
8.2.1.1. Forwarding Translator .....................26
8.2.1.2. Transcoding Translator ....................26
8.2.2. SRC Acting as an RTP Mixer .........................27
8.2.3. SRC Acting as an RTP Endpoint ......................28
8.3. RTP Session Usage by SRC ..................................28
8.3.1. SRC Using Multiple m-lines .........................28
8.3.2. SRC Using Mixing ...................................29
8.4. RTP Session Usage by SRS ..................................30
9. Metadata .......................................................31
9.1. Procedures at the SRC .....................................31
9.2. Procedures at the SRS .....................................33
10. Persistent Recording ..........................................35
11. IANA Considerations ...........................................36
11.1. Registration of Option Tags ..............................36
11.1.1. "siprec" Option Tag ...............................36
11.1.2. "record-aware" Option Tag .........................36
11.2. Registration of Media Feature Tags .......................36
11.2.1. Feature Tag for the SRC ...........................36
11.2.2. Feature Tag for the SRS ...........................37
11.3. New Content-Disposition Parameter Registrations ..........37
11.4. SDP Attributes ...........................................38
11.4.1. "record" SDP Attribute ............................38
11.4.2. "recordpref" SDP Attribute ........................38
12. Security Considerations .......................................39
12.1. Authentication and Authorization .........................39
12.2. RTP Handling .............................................40
12.3. Metadata .................................................41
12.4. Storage and Playback .....................................41
13. References ....................................................41
13.1. Normative References .....................................41
13.2. Informative References ...................................42
Acknowledgements ..................................................44
Authors' Addresses ................................................45
8.1.4. CSRC ...............................................22
8.1.5. SDES ...............................................22
8.1.5.1. CNAME .....................................22
8.1.6. Keepalive ..........................................22
8.1.7. RTCP Feedback Messages .............................23
8.1.7.1. Full Intra Request ........................23
8.1.7.2. Picture Loss Indication ...................23
8.1.7.3. Temporary Maximum Media Stream Bit
Rate Request ..............................24
8.1.8. Symmetric RTP/RTCP for Sending and Receiving .......24
8.2. Roles .....................................................25
8.2.1. SRC Acting as an RTP Translator ....................26
8.2.1.1. Forwarding Translator .....................26
8.2.1.2. Transcoding Translator ....................26
8.2.2. SRC Acting as an RTP Mixer .........................27
8.2.3. SRC Acting as an RTP Endpoint ......................28
8.3. RTP Session Usage by SRC ..................................28
8.3.1. SRC Using Multiple m-lines .........................28
8.3.2. SRC Using Mixing ...................................29
8.4. RTP Session Usage by SRS ..................................30
9. Metadata .......................................................31
9.1. Procedures at the SRC .....................................31
9.2. Procedures at the SRS .....................................33
10. Persistent Recording ..........................................35
11. IANA Considerations ...........................................36
11.1. Registration of Option Tags ..............................36
11.1.1. "siprec" Option Tag ...............................36
11.1.2. "record-aware" Option Tag .........................36
11.2. Registration of Media Feature Tags .......................36
11.2.1. Feature Tag for the SRC ...........................36
11.2.2. Feature Tag for the SRS ...........................37
11.3. New Content-Disposition Parameter Registrations ..........37
11.4. SDP Attributes ...........................................38
11.4.1. "record" SDP Attribute ............................38
11.4.2. "recordpref" SDP Attribute ........................38
12. Security Considerations .......................................39
12.1. Authentication and Authorization .........................39
12.2. RTP Handling .............................................40
12.3. Metadata .................................................41
12.4. Storage and Playback .....................................41
13. References ....................................................41
13.1. Normative References .....................................41
13.2. Informative References ...................................42
Acknowledgements ..................................................44
Authors' Addresses ................................................45
This document specifies the mechanism to record a Communication Session (CS) by delivering real-time media and metadata from the CS to a recording device. In accordance with the architecture [RFC7245], the Session Recording Protocol specifies the use of SIP, the Session Description Protocol (SDP), and RTP to establish a Recording Session (RS) between the Session Recording Client (SRC), which is on the path of the CS, and a Session Recording Server (SRS) at the recording device. SIP is also used to deliver metadata to the recording device, as specified in [RFC7865]. Metadata is information that describes recorded media and the CS to which they relate. The Session Recording Protocol intends to satisfy the SIP-based Media Recording (SIPREC) requirements listed in [RFC6341]. In addition to the Session Recording Protocol, this document specifies extensions for user agents (UAs) that are participants in a CS to receive recording indications and to provide preferences for recording.
本文档规定了通过将实时媒体和元数据从CS传送到记录设备来记录通信会话（CS）的机制。根据体系结构[RFC7245]，会话记录协议指定使用SIP、会话描述协议（SDP）和RTP在CS路径上的会话记录客户端（SRC）和记录设备上的会话记录服务器（SRS）之间建立记录会话（RS）。SIP还用于将元数据传送到记录设备，如[RFC7865]中所述。元数据是描述记录的媒体及其相关的CS的信息。会话记录协议旨在满足[RFC6341]中列出的基于SIP的媒体记录（SIPREC）要求。除了会话录制协议外，本文档还指定了作为CS参与者的用户代理（UAs）的扩展，以接收录制指示并提供录制首选项。
This document considers only active recording, where the SRC purposefully streams media to an SRS and all participating UAs are notified of the recording. 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, in accordance with [RFC2804].
本文件仅考虑主动记录，其中SRC有意将媒体流传输至SRS，且所有参与的UAs均收到记录通知。被动记录，即记录设备直接从网络检测媒体（例如，使用端口镜像技术），不在本文档范围内。此外，根据[RFC2804]，合法拦截不在本文件范围内。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
This document refers to the core definitions provided in the architecture document [RFC7245].
本文件引用了体系结构文件[RFC7245]中提供的核心定义。
Section 8 uses the definitions provided in "RTP: A Transport Protocol for Real-Time Applications" [RFC3550].
第8节使用了“RTP：实时应用的传输协议”[RFC3550]中提供的定义。
The scope of the Session Recording Protocol includes the establishment of the RSs and the reporting of the metadata. The scope also includes extensions supported by UAs participating in the CS, such as an indication of recording. The UAs need not be recording aware in order to participate in a CS being recorded.
会话记录协议的范围包括RSs的建立和元数据的报告。该范围还包括参与CS的UAs支持的扩展，例如记录指示。UAs无需记录感知，即可参与正在记录的CS。
The items in the following list, which is not exhaustive, do not represent the protocol itself and are considered out of scope for the Session Recording Protocol:
以下列表中的项目并非详尽无遗，并不代表协议本身，被视为超出会话记录协议的范围：
o Delivering recorded media in real time as the CS media
o 以CS介质的形式实时传送录制的介质
o Specifications of criteria to select a specific CS to be recorded or triggers to record a certain CS in the future
o 用于选择要记录的特定CS或用于在将来记录特定CS的触发器的标准规范
o Recording policies that determine whether the CS should be recorded and whether parts of the CS are to be recorded
o 确定是否应记录CS以及是否要记录CS部分的记录策略
o Retention policies that determine how long a recording is stored
o 确定记录存储时间的保留策略
o Searching and accessing the recorded media and metadata
o 搜索和访问录制的媒体和元数据
o Policies governing how CS users are made aware of recording
o 管理如何让CS用户了解录制的策略
o Delivering additional RS metadata through a non-SIP mechanism
o 通过非SIP机制交付额外的RS元数据
This section is informative and provides a description of recording operations.
本节内容丰富，并对记录操作进行了说明。
Section 6 describes the SIP communication in an RS between an SRC and an SRS, as well as the procedures for recording-aware UAs participating in a CS. Section 7 describes SDP handling in an RS, and the procedures for recording indications and recording preferences. Section 8 describes RTP handling in an RS. Section 9 describes the mechanism to deliver recording metadata from the SRC to the SRS.
第6节描述了SRC和SRS之间RS中的SIP通信，以及记录参与CS的感知UAs的过程。第7节描述了RS中的SDP处理，以及记录指示和记录首选项的程序。第8节描述了RS中的RTP处理。第9节描述了将记录元数据从SRC传递到SRS的机制。
As mentioned in the architecture document [RFC7245], there are a number of types of call flows based on the location of the SRC. The sample call flows discussed in Section 5.1 provide a quick overview of the operations between the SRC and the SRS.
如体系结构文档[RFC7245]中所述，基于SRC的位置，有多种类型的调用流。第5.1节中讨论的示例调用流快速概述了SRC和SRS之间的操作。
When a SIP Back-to-Back User Agent (B2BUA) with SRC functionality routes a call from UA A to UA B, the SRC has access to the media path between the UAs. When the SRC is aware that it should be recording the conversation, the SRC can cause the B2BUA to relay the media between UA A and UA B. The SRC then establishes the RS with the SRS and sends replicated media towards the SRS.
当具有SRC功能的SIP背靠背用户代理（B2BUA）将呼叫从UA a路由到UA B时，SRC可以访问UA之间的媒体路径。当SRC意识到它应该记录对话时，SRC可以使B2BUA在UA A和UA B之间中继媒体。然后，SRC用SRS建立RS，并向SRS发送复制媒体。
An endpoint may also have SRC functionality, where the endpoint itself establishes the RS to the SRS. Since the endpoint has access to the media in the CS, the endpoint can send replicated media towards the SRS.
端点还可以具有SRC功能，其中端点本身建立到SRS的RS。由于端点可以访问CS中的媒体，因此端点可以向SRS发送复制的媒体。
The example call flows in Figures 1 and 2 show an SRC establishing an RS towards an SRS. Figure 1 illustrates UA A acting as the SRC. Figure 2 illustrates a B2BUA acting as the SRC. Note that the SRC can choose when to establish the RS independent of the CS, even though the example call flows suggest that the SRC is establishing the RS (message (5) in Figure 2) after the CS is established.
图1和图2中的示例调用流显示了一个SRC，它向SRS建立一个RS。图1说明了UA A作为SRC的作用。图2显示了充当SRC的B2BUA。请注意，SRC可以选择何时独立于CS建立RS，即使示例调用流表明SRC在CS建立后正在建立RS（图2中的消息（5））。
UA A/SRC UA B SRS
|(1) CS INVITE | |
|---------------------->| |
| (2) 200 OK | |
|<----------------------| |
| | |
|(3) RS INVITE with SDP | |
|--------------------------------------------->|
| | (4) 200 OK with SDP |
|<---------------------------------------------|
|(5) CS RTP | |
|======================>| |
|<======================| |
|(6) RS RTP | |
|=============================================>|
|=============================================>|
| | |
|(7) CS BYE | |
|---------------------->| |
|(8) RS BYE | |
|--------------------------------------------->|
| | |
UA A/SRC UA B SRS
|(1) CS INVITE | |
|---------------------->| |
| (2) 200 OK | |
|<----------------------| |
| | |
|(3) RS INVITE with SDP | |
|--------------------------------------------->|
| | (4) 200 OK with SDP |
|<---------------------------------------------|
|(5) CS RTP | |
|======================>| |
|<======================| |
|(6) RS RTP | |
|=============================================>|
|=============================================>|
| | |
|(7) CS BYE | |
|---------------------->| |
|(8) RS BYE | |
|--------------------------------------------->|
| | |
Figure 1: Basic Recording Call Flow with UA as SRC
图1：UA作为SRC的基本记录呼叫流
UA A SRC UA B SRS
|(1) CS INVITE | | |
|------------->| | |
| |(2) CS INVITE | |
| |---------------------->| |
| | (3) 200 OK | |
| |<----------------------| |
| (4) 200 OK | | |
|<-------------| | |
| |(5) RS INVITE with SDP | |
| |--------------------------------------------->|
| | | (6) 200 OK with SDP |
| |<---------------------------------------------|
|(7) CS RTP | | |
|=============>|======================>| |
|<=============|<======================| |
| |(8) RS RTP | |
| |=============================================>|
| |=============================================>|
|(9) CS BYE | | |
|------------->| | |
| |(10) CS BYE | |
| |---------------------->| |
| |(11) RS BYE | |
| |--------------------------------------------->|
| | | |
UA A SRC UA B SRS
|(1) CS INVITE | | |
|------------->| | |
| |(2) CS INVITE | |
| |---------------------->| |
| | (3) 200 OK | |
| |<----------------------| |
| (4) 200 OK | | |
|<-------------| | |
| |(5) RS INVITE with SDP | |
| |--------------------------------------------->|
| | | (6) 200 OK with SDP |
| |<---------------------------------------------|
|(7) CS RTP | | |
|=============>|======================>| |
|<=============|<======================| |
| |(8) RS RTP | |
| |=============================================>|
| |=============================================>|
|(9) CS BYE | | |
|------------->| | |
| |(10) CS BYE | |
| |---------------------->| |
| |(11) RS BYE | |
| |--------------------------------------------->|
| | | |
Figure 2: Basic Recording Call Flow with B2BUA as SRC
图2:B2BUA作为SRC的基本记录调用流
The call flow shown in Figure 2 can also apply to the case of a centralized conference with a mixer. For clarity, ACKs to INVITEs and 200 OKs to BYEs are not shown. The conference focus can provide the SRC functionality, since the conference focus has access to all the media from each conference participant. When a recording is requested, the SRC delivers the metadata and the media streams to the SRS. Since the conference focus has access to a mixer, the SRC may choose to mix the media streams from all participants as a single mixed media stream towards the SRS.
图2所示的呼叫流也适用于带有混音器的集中式会议。为清楚起见，未显示对邀请的确认和对是的200确认。会议焦点可以提供SRC功能，因为会议焦点可以访问来自每个会议参与者的所有媒体。当请求录制时，SRC将元数据和媒体流传递给SRS。由于会议焦点可以访问混合器，SRC可以选择将来自所有参与者的媒体流作为朝向SRS的单个混合媒体流进行混合。
An SRC can use a single RS to record multiple CSs. Every time the SRC wants to record a new call, the SRC updates the RS with a new SDP offer to add new recorded streams to the RS and to correspondingly also update the metadata for the new call.
SRC可以使用单个RS记录多个CSs。每当SRC想要记录新呼叫时，SRC用新的SDP提供更新RS，以向RS添加新的记录流，并相应地更新新呼叫的元数据。
An SRS can also establish an RS to an SRC, although it is beyond the scope of this document to define how an SRS would specify which calls to record.
SRS还可以向SRC建立RS，尽管定义SRS如何指定要记录的调用超出了本文档的范围。
The SRC is responsible for the delivery of metadata to the SRS. The SRC may provide an initial metadata snapshot about recorded media streams in the initial INVITE content in the RS. Subsequent metadata updates can be represented as a stream of events in UPDATE [RFC3311] or re-INVITE requests sent by the SRC. These metadata updates are normally incremental updates to the initial metadata snapshot to optimize on the size of updates. However, the SRC may also decide to send a new metadata snapshot at any time.
SRC负责向SRS交付元数据。SRC可以提供关于RS中初始邀请内容中记录的媒体流的初始元数据快照。后续元数据更新可以表示为SRC发送的更新[RFC3311]或重新邀请请求中的事件流。这些元数据更新通常是对初始元数据快照的增量更新，以优化更新的大小。但是，SRC也可能决定随时发送新的元数据快照。
Metadata is transported in the body of INVITE or UPDATE messages. Certain metadata, such as the attributes of the recorded media stream, is located in the SDP of the RS.
元数据在INVITE或UPDATE消息体中传输。某些元数据，例如记录的媒体流的属性，位于RS的SDP中。
The SRS has the ability to send a request to the SRC to ask for a new metadata snapshot update from the SRC. This can happen when the SRS fails to understand the current stream of incremental updates for whatever reason -- for example, when the SRS loses the current state due to internal failure. The SRS may optionally attach a reason along with the snapshot request. This request allows both the SRC and the SRS to synchronize the states with a new metadata snapshot so that further incremental metadata updates will be based on the latest metadata snapshot. Similar to the metadata content, the metadata snapshot request is transported as content in UPDATE or INVITE messages sent by the SRS in the RS.
SRS能够向SRC发送请求，请求SRC更新新的元数据快照。当SRS由于任何原因无法理解当前的增量更新流时（例如，当SRS由于内部故障而丢失当前状态时），就会发生这种情况。SRS可以选择在快照请求中附加原因。此请求允许SRC和SRS使用新的元数据快照同步状态，以便进一步的增量元数据更新将基于最新的元数据快照。与元数据内容类似，元数据快照请求在RS中的SRS发送的更新或邀请消息中作为内容传输。
SRC SRS
| |
|(1) INVITE (metadata snapshot 1) |
|---------------------------------------------------->|
| (2) 200 OK |
|<----------------------------------------------------|
|(3) ACK |
|---------------------------------------------------->|
|(4) RTP |
|====================================================>|
|====================================================>|
|(5) UPDATE (metadata update 1) |
|---------------------------------------------------->|
| (6) 200 OK |
|<----------------------------------------------------|
|(7) UPDATE (metadata update 2) |
|---------------------------------------------------->|
| (8) 200 OK |
|<----------------------------------------------------|
| (9) UPDATE (metadata snapshot request) |
|<----------------------------------------------------|
| (10) 200 OK |
|---------------------------------------------------->|
| (11) INVITE (metadata snapshot 2 + SDP offer) |
|---------------------------------------------------->|
| (12) 200 OK (SDP answer) |
|<----------------------------------------------------|
| (13) UPDATE (metadata update 1 based on snapshot 2) |
|---------------------------------------------------->|
| (14) 200 OK |
|<----------------------------------------------------|
SRC SRS
| |
|(1) INVITE (metadata snapshot 1) |
|---------------------------------------------------->|
| (2) 200 OK |
|<----------------------------------------------------|
|(3) ACK |
|---------------------------------------------------->|
|(4) RTP |
|====================================================>|
|====================================================>|
|(5) UPDATE (metadata update 1) |
|---------------------------------------------------->|
| (6) 200 OK |
|<----------------------------------------------------|
|(7) UPDATE (metadata update 2) |
|---------------------------------------------------->|
| (8) 200 OK |
|<----------------------------------------------------|
| (9) UPDATE (metadata snapshot request) |
|<----------------------------------------------------|
| (10) 200 OK |
|---------------------------------------------------->|
| (11) INVITE (metadata snapshot 2 + SDP offer) |
|---------------------------------------------------->|
| (12) 200 OK (SDP answer) |
|<----------------------------------------------------|
| (13) UPDATE (metadata update 1 based on snapshot 2) |
|---------------------------------------------------->|
| (14) 200 OK |
|<----------------------------------------------------|
Figure 3: Delivering Metadata via SIP UPDATE
图3：通过SIP更新交付元数据
5.3. Receiving Recording Indications and Providing Recording Preferences
5.3. 接收录制指示并提供录制首选项
The SRC is responsible for providing recording indications to the participants in the CS. A recording-aware UA supports receiving recording indications via the SDP "a=record" attribute, and it can specify a recording preference in the CS by including the SDP "a=recordpref" attribute. The recording attribute is a declaration by the SRC in the CS to indicate whether recording is taking place. The recording preference attribute is a declaration by the recording-aware UA in the CS to indicate its recording preference. A UA that does not want to be recorded may still be notified that recording is occurring, for a number of reasons (e.g., it was not capable of
SRC负责向CS参与者提供记录指示。记录感知UA支持通过SDP“A=record”属性接收记录指示，并且它可以通过包括SDP“A=recordpref”属性在CS中指定记录首选项。recording属性是CS中SRC的声明，用于指示是否正在进行录制。录制首选项属性是CS中录制感知UA的声明，用于指示其录制首选项。不希望被记录的UA可能仍然会被通知正在进行记录，原因有很多（例如，它无法
indicating its preference, its preference was ignored). If this occurs, the UA's only mechanism to avoid being recorded is to terminate its participation in the session.
表示其偏好，其偏好被忽略）。如果发生这种情况，UA避免被记录的唯一机制是终止其参与会话。
To illustrate how the attributes are used, if UA A is initiating a call to UA B and UA A is also an SRC that is performing the recording, then UA A provides the recording indication in the SDP offer with a=record:on. Since UA A is the SRC, UA A receives the recording indication from the SRC directly. When UA B receives the SDP offer, UA B will see that recording is happening on the other endpoint of this session. Since UA B is not an SRC and does not provide any recording preference, the SDP answer does not contain a=record or a=recordpref.
为了说明如何使用这些属性，如果UA A正在发起对UA B的呼叫，并且UA A也是执行录制的SRC，则UA A在SDP报价中提供录制指示，其中A=record:on。由于UA A是SRC，UA A直接从SRC接收记录指示。当UA B收到SDP要约时，UA B将看到正在该会话的另一个端点上进行录制。由于UA B不是SRC且不提供任何录制首选项，因此SDP答案不包含a=record或a=recordpref。
UA A UA B
(SRC) |
| |
| [SRC recording starts] |
|(1) INVITE (SDP offer + a=record:on) |
|---------------------------------------------------->|
| (2) 200 OK (SDP answer) |
|<----------------------------------------------------|
|(3) ACK |
|---------------------------------------------------->|
|(4) RTP |
|<===================================================>|
| |
| [UA B wants to set preference to no recording] |
| (5) INVITE (SDP offer + a=recordpref:off) |
|<----------------------------------------------------|
| [SRC honors the preference and stops recording] |
|(6) 200 OK (SDP answer + a=record:off) |
|---------------------------------------------------->|
| (7) ACK |
|<----------------------------------------------------|
UA A UA B
(SRC) |
| |
| [SRC recording starts] |
|(1) INVITE (SDP offer + a=record:on) |
|---------------------------------------------------->|
| (2) 200 OK (SDP answer) |
|<----------------------------------------------------|
|(3) ACK |
|---------------------------------------------------->|
|(4) RTP |
|<===================================================>|
| |
| [UA B wants to set preference to no recording] |
| (5) INVITE (SDP offer + a=recordpref:off) |
|<----------------------------------------------------|
| [SRC honors the preference and stops recording] |
|(6) 200 OK (SDP answer + a=record:off) |
|---------------------------------------------------->|
| (7) ACK |
|<----------------------------------------------------|
Figure 4: Recording Indication and Recording Preference
图4：记录指示和记录偏好
After the call is established and recording is in progress, UA B later decides to change the recording preference to no recording and sends a re-INVITE with the "a=recordpref" attribute. It is up to the SRC to honor the preference, and in this case the SRC decides to stop the recording and updates the recording indication in the SDP answer.
在建立呼叫并进行录音后，UA B随后决定将录音首选项更改为无录音，并发送一个具有“a=recordpref”属性的重新邀请。由SRC决定是否遵守首选项，在这种情况下，SRC决定停止录制并更新SDP应答中的录制指示。
Note that UA B could have explicitly indicated a recording preference in (2), the 200 OK for the original INVITE. Indicating a preference of no recording in an initial INVITE or an initial response to an INVITE may reduce the chance of a user being recorded in the first place.
请注意，UA B可以在（2）中明确表示录制首选项，即原始邀请的200 OK。指示在初始邀请中不记录的偏好或对邀请的初始响应可以降低用户首先被记录的机会。
An RS is a SIP session with specific extensions applied, and these extensions are listed in the procedures below for the SRC and the SRS. When an SRC or an SRS receives a SIP session that is not an RS, it is up to the SRC or the SRS to determine what to do with the SIP session.
RS是应用了特定扩展的SIP会话，这些扩展在下面的SRC和SRS过程中列出。当SRC或SRS接收到不是RS的SIP会话时，由SRC或SRS决定如何处理SIP会话。
The SRC can initiate an RS by sending a SIP INVITE request to the SRS. The SRC and the SRS are identified in the From and To headers, respectively.
SRC可以通过向SRS发送SIP INVITE请求来启动RS。SRC和SRS分别在From和To标头中标识。
The SRC MUST include the "+sip.src" feature tag in the Contact URI, defined in this specification as an extension to [RFC3840], for all RSs. An SRS uses the presence of the "+sip.src" feature tag in dialog creating and modifying requests and responses to confirm that the dialog being created is for the purpose of an RS. In addition, when an SRC sends a REGISTER request to a registrar, the SRC MAY include the "+sip.src" feature tag to indicate that it is an SRC.
对于所有RSs，SRC必须在联系人URI中包含“+sip.SRC”特性标记，在本规范中定义为[RFC3840]的扩展。SRS在创建和修改请求和响应的对话框中使用“+sip.src”功能标签，以确认正在创建的对话框用于RS。此外，当src向注册器发送注册请求时，src可能包括“+sip.src”功能标签，以指示它是src。
Since SIP Caller Preferences extensions are optional to implement for routing proxies, there is no guarantee that an RS will be routed to an SRC or SRS. A new option tag, "siprec", is introduced. As per [RFC3261], only an SRC or an SRS can accept this option tag in an RS. An SRC MUST include the "siprec" option tag in the Require header when initiating an RS so that UAs that do not support the Session Recording Protocol extensions will simply reject the INVITE request with a 420 (Bad Extension) response.
由于SIP呼叫者首选项扩展是为路由代理实现的可选扩展，因此不能保证RS将路由到SRC或SRS。引入了一个新的选项标签“siprec”。根据[RFC3261]，只有SRC或SRS可以在RS中接受此选项标记。SRC在启动RS时必须在Require标头中包含“siprec”选项标记，以便不支持会话记录协议扩展的UAs将简单地拒绝INVITE请求，并给出420（错误扩展）响应。
When an SRC receives a new INVITE, the SRC MUST only consider the SIP session as an RS when both the "+sip.srs" feature tag and the "siprec" option tag are included in the INVITE request.
当SRC接收到新的邀请时，SRC必须只考虑SIP会话作为RS，当“+SIP.SRS”特征标签和“SIPREC”选项标签都包含在邀请请求中。
For the CS, the SRC MUST provide recording indications to all participants in the CS. A participant UA in a CS can indicate that it is recording aware by providing the "record-aware" option tag, and the SRC MUST provide recording indications in the new SDP "a=record" attribute described in Section 7 below. In the absence of the "record-aware" option tag -- meaning that the participant UA is not recording aware -- an SRC MUST provide recording indications through other means, such as playing a tone in-band or having a signed participant contract in place.
对于CS，SRC必须向CS中的所有参与者提供记录指示。CS中的参与者UA可以通过提供“记录感知”选项标记来表示其记录感知，SRC必须在下文第7节中描述的新SDP“A=记录”属性中提供记录指示。在没有“记录感知”选项标签的情况下——这意味着参与者UA没有记录感知——SRC必须通过其他方式提供记录指示，例如在乐队中播放音调或签署参与者合同。
An SRC in the CS may also indicate itself as a session recording client by including the "+sip.src" feature tag. A recording-aware participant can learn that an SRC is in the CS and can set the recording preference for the CS with the new SDP "a=recordpref" attribute described in Section 7.
CS中的SRC还可以通过包含“+sip.SRC”特性标记来将自己指示为会话记录客户端。记录感知参与者可以了解到SRC在CS中，并且可以使用第7节中描述的新SDP“A=recordpref”属性设置CS的记录首选项。
When an SRS receives a new INVITE, the SRS MUST only consider the SIP session as an RS when both the "+sip.src" feature tag and the "siprec" option tag are included in the INVITE request.
当SRS收到新的邀请时，SRS必须只考虑SIP会话作为RS，当“+SIP.Src”特征标签和“SIPREC”选项标签都包含在邀请请求中。
The SRS can initiate an RS by sending a SIP INVITE request to the SRC. The SRS and the SRC are identified in the From and To headers, respectively.
SRS可以通过向SRC发送SIP INVITE请求来启动RS。SRS和SRC分别在From和To标头中标识。
The SRS MUST include the "+sip.srs" feature tag in the Contact URI, as per [RFC3840], for all RSs. An SRC uses the presence of this feature tag in dialog creation and modification requests and responses to confirm that the dialog being created is for the purpose of an RS (REQ-030 in [RFC6341]). In addition, when an SRS sends a REGISTER request to a registrar, the SRS SHOULD include the "+sip.srs" feature tag to indicate that it is an SRS.
根据[RFC3840]，对于所有RSs，SRS必须在联系人URI中包含“+sip.SRS”功能标签。SRC在对话框创建和修改请求及响应中使用此功能标签，以确认创建的对话框用于RS（RFC6341中的REQ-030）。此外，当SRS向注册器发送注册请求时，SRS应包括“+sip.SRS”特性标签，以指示它是SRS。
An SRS MUST include the "siprec" option tag in the Require header as per [RFC3261] when initiating an RS so that UAs that do not support the Session Recording Protocol extensions will simply reject the INVITE request with a 420 (Bad Extension) response.
根据[RFC3261]，在启动RS时，SRS必须在Require报头中包含“siprec”选项标签，以便不支持会话记录协议扩展的UAs将简单地以420（坏扩展）响应拒绝INVITE请求。
A recording-aware UA is a participant in the CS that supports the SIP and SDP extensions for receiving recording indications and for requesting recording preferences for the call. A recording-aware UA MUST indicate that it can accept the reporting of recording indications provided by the SRC with a new "record-aware" option tag
感知录音的UA是支持SIP和SDP扩展以接收录音指示和请求呼叫录音偏好的CS中的参与者。记录感知UA必须表明其可以接受SRC提供的带有新“记录感知”选项标签的记录指示报告
when initiating or establishing a CS; this means including the "record-aware" option tag in the Supported header in the initial INVITE request or response.
启动或建立CS时；这意味着在初始邀请请求或响应中的受支持标头中包含“记录感知”选项标记。
A recording-aware UA MUST provide a recording indication to the end user through an appropriate user interface, indicating whether recording is on, off, or paused for each medium. Appropriate user interfaces may include real-time notification or previously established agreements that use of the device is subject to recording. Some UAs that are automatons (e.g., Interactive Voice Response (IVR), media server, Public Switched Telephone Network (PSTN) gateway) may not have a user interface to render a recording indication. When such a UA indicates recording awareness, the UA SHOULD render the recording indication through other means, such as passing an in-band tone on the PSTN gateway, putting the recording indication in a log file, or raising an application event in a VoiceXML dialog. These UAs MAY also choose not to indicate recording awareness, thereby relying on whatever mechanism an SRC chooses to indicate recording, such as playing a tone in-band.
记录感知UA必须通过适当的用户界面向最终用户提供记录指示，指示每个媒体的记录是打开、关闭还是暂停。适当的用户界面可包括实时通知或先前建立的关于设备的使用服从于记录的协议。一些自动化UAs（例如，交互式语音响应（IVR）、媒体服务器、公共交换电话网络（PSTN）网关）可能没有用户界面来呈现录制指示。当此类UA指示记录感知时，UA应通过其他方式呈现记录指示，例如在PSTN网关上传递带内音调、将记录指示放入日志文件或在VoiceXML对话框中引发应用程序事件。这些UAs也可以选择不指示录制感知，从而依赖于SRC选择的指示录制的任何机制，例如在频带中播放音调。
The SRC and SRS follow the SDP offer/answer model described in [RFC3264]. The procedures for the SRC and SRS describe the conventions used in an RS.
SRC和SRS遵循[RFC3264]中描述的SDP提供/应答模型。SRC和SRS的程序描述了RS中使用的约定。
Since the SRC does not expect to receive media from the SRS, the SRC typically sets each media stream of the SDP offer to only send media, by qualifying them with the "a=sendonly" attribute, according to the procedures in [RFC3264].
由于SRC不期望从SRS接收媒体，SRC通常通过使用“a=sendonly”属性限定SDP提供的每个媒体流，根据[RFC3264]中的过程，将其设置为仅发送媒体。
The SRC sends recorded streams of participants to the SRS, and the SRC MUST provide a "label" attribute ("a=label"), as per [RFC4574], on each media stream in order to identify the recorded stream with the rest of the metadata. The "a=label" attribute identifies each recorded media stream, and the label name is mapped to the Media Stream Reference in the metadata as per [RFC7865]. The scope of the "a=label" attribute only applies to the SDP and metadata conveyed in the bodies of the SIP request or response that the label appeared in. Note that a recorded stream is distinct from a CS stream; the metadata provides a list of participants that contribute to each recorded stream.
SRC向SRS发送记录的参与者流，SRC必须根据[RFC4574]在每个媒体流上提供一个“标签”属性（“a=标签”），以便用其余元数据标识记录的流。“a=label”属性标识每个记录的媒体流，标签名称根据[RFC7865]映射到元数据中的媒体流引用。“a=label”属性的范围仅适用于SDP和标签出现在SIP请求或响应主体中的元数据。注意，记录的流不同于CS流；元数据提供了参与每个记录流的参与者列表。
Figure 5 shows an example SDP offer from an SRC with both audio and video recorded streams. Note that this example contains unfolded lines longer than 72 characters; these lines are captured between <allOneLine> tags.
图5显示了SRC提供的一个示例SDP，其中包含音频和视频记录流。请注意，此示例包含长度超过72个字符的展开行；这些行在<allOneLine>标记之间捕获。
v=0
o=SRC 2890844526 2890844526 IN IP4 198.51.100.1
s=-
c=IN IP4 198.51.100.1
t=0 0
m=audio 12240 RTP/AVP 0 4 8
a=sendonly
a=label:1
m=video 22456 RTP/AVP 98
a=rtpmap:98 H264/90000
<allOneLine>
a=fmtp:98 profile-level-id=42A01E;
sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
</allOneLine>
a=sendonly
a=label:2
m=audio 12242 RTP/AVP 0 4 8
a=sendonly
a=label:3
m=video 22458 RTP/AVP 98
a=rtpmap:98 H264/90000
<allOneLine>
a=fmtp:98 profile-level-id=42A01E;
sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
</allOneLine>
a=sendonly
a=label:4
v=0
o=SRC 2890844526 2890844526 IN IP4 198.51.100.1
s=-
c=IN IP4 198.51.100.1
t=0 0
m=audio 12240 RTP/AVP 0 4 8
a=sendonly
a=label:1
m=video 22456 RTP/AVP 98
a=rtpmap:98 H264/90000
<allOneLine>
a=fmtp:98 profile-level-id=42A01E;
sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
</allOneLine>
a=sendonly
a=label:2
m=audio 12242 RTP/AVP 0 4 8
a=sendonly
a=label:3
m=video 22458 RTP/AVP 98
a=rtpmap:98 H264/90000
<allOneLine>
a=fmtp:98 profile-level-id=42A01E;
sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
</allOneLine>
a=sendonly
a=label:4
Figure 5: Sample SDP Offer from SRC with Audio and Video Streams
图5:SRC提供的带有音频和视频流的SDP示例
Over the lifetime of an RS, the SRC can add and remove recorded streams to and from the RS for various reasons -- for example, when a CS stream is added to or removed from the CS, or when a CS is created or terminated if an RS handles multiple CSs. To remove a recorded stream from the RS, the SRC sends a new SDP offer where the port of the media stream to be removed is set to zero, according to the procedures in [RFC3264]. To add a recorded stream to the RS, the SRC sends a new SDP offer by adding a new media stream description or by reusing an old media stream that had been previously disabled, according to the procedures in [RFC3264].
在RS的生命周期内，SRC可以出于各种原因向RS添加或从RS中删除记录的流——例如，在CS中添加或删除CS流时，或者在RS处理多个CSs时创建或终止CS时。为了从RS中删除记录的流，SRC发送一个新的SDP要约，其中根据[RFC3264]中的过程，要删除的媒体流的端口设置为零。为了向RS添加记录的流，SRC根据[RFC3264]中的程序，通过添加新的媒体流描述或通过重用先前已禁用的旧媒体流来发送新的SDP报价。
The SRC can temporarily discontinue streaming and collection of recorded media from the SRC to the SRS for reasons such as masking the recording. In this case, the SRC sends a new SDP offer and sets the media stream to inactive (a=inactive) for each recorded stream to be paused, as per the procedures in [RFC3264]. To resume streaming and collection of recorded media, the SRC sends a new SDP offer and sets the media stream to sendonly (a=sendonly). Note that a CS may itself change the media stream direction by updating the SDP -- for example, by setting a=inactive for SDP hold. Media stream direction changes in the CS are conveyed in the metadata by the SRC. When a CS media stream is changed to or from inactive, the effect on the corresponding RS media stream is governed by SRC policy. The SRC MAY have a local policy to pause an RS media stream when the corresponding CS media stream is inactive, or it MAY leave the RS media stream as sendonly.
SRC可以暂时停止从SRC到SRS的记录媒体的流式传输和收集，原因包括屏蔽记录。在这种情况下，SRC根据[RFC3264]中的程序发送新的SDP提议，并将每个要暂停的记录流的媒体流设置为非活动（a=非活动）。要恢复录制媒体的流式传输和收集，SRC将发送新的SDP报价，并将媒体流设置为sendonly（a=sendonly）。请注意，CS本身可以通过更新SDP来更改媒体流方向——例如，通过为SDP hold设置a=inactive。CS中的媒体流方向更改由SRC在元数据中传送。当CS媒体流更改为非活动或从非活动更改为非活动时，对相应RS媒体流的影响由SRC策略控制。SRC可以具有当相应的CS媒体流处于非活动状态时暂停RS媒体流的本地策略，或者它可以将RS媒体流保留为仅发送。
While there are existing mechanisms for providing an indication that a CS is being recorded, these mechanisms are usually delivered on the CS media streams, such as playing an in-band tone or an announcement to the participants. A new "record" SDP attribute is introduced to allow the SRC to indicate recording state to a recording-aware UA in a CS.
虽然存在用于提供正在记录CS的指示的现有机制，但是这些机制通常在CS媒体流上传送，例如播放带内音调或向参与者发布公告。引入了一个新的“记录”SDP属性，以允许SRC向CS中的记录感知UA指示记录状态。
The "record" SDP attribute appears at the media level or session level in either an SDP offer or answer. When the attribute is applied at the session level, the indication applies to all media streams in the SDP. When the attribute is applied at the media level, the indication applies to that one media stream only, and that overrides the indication if also set at the session level. Whenever the recording indication needs to change, such as termination of recording, the SRC MUST initiate a re-INVITE or UPDATE to update the SDP "a=record" attribute.
“记录”SDP属性出现在SDP报价或应答中的媒体级别或会话级别。当在会话级别应用该属性时，该指示将应用于SDP中的所有媒体流。当在媒体级别应用该属性时，该指示仅适用于该媒体流，如果在会话级别也设置了该指示，则该指示将覆盖该指示。每当录制指示需要更改时，例如终止录制，SRC必须启动重新邀请或更新，以更新SDP“a=record”属性。
The following is the ABNF [RFC5234] of the "record" attribute:
以下是“记录”属性的ABNF[RFC5234]：
attribute =/ record-attr ; attribute defined in RFC 4566
属性=/记录属性；RFC 4566中定义的属性
record-attr = "record:" indication
indication = "on" / "off" / "paused"
record-attr = "record:" indication
indication = "on" / "off" / "paused"
on: Recording is in progress.
on:正在录制。
off: No recording is in progress.
关闭：没有正在录制。
paused: Recording is in progress but media is paused.
暂停：正在录制，但媒体已暂停。
When the SRC receives the "a=recordpref" SDP in an SDP offer or answer, the SRC chooses to honor the preference to record based on local policy at the SRC. If the SRC makes a change in recording state, the SRC MUST report the new recording state in the "a=record" attribute in the SDP answer or in a subsequent SDP offer.
当SRC在SDP报价或应答中收到“a=recordpref”SDP时，SRC会根据SRC的本地策略选择优先记录。如果SRC更改了录制状态，则SRC必须在SDP应答或后续SDP报价中的“a=record”属性中报告新的录制状态。
Typically, the SRS only receives RTP streams from the SRC; therefore, the SDP offer/answer from the SRS normally sets each media stream to receive media, by setting them with the "a=recvonly" attribute, according to the procedures of [RFC3264]. When the SRS is not ready to receive a recorded stream, the SRS sets the media stream as inactive in the SDP offer or answer by setting it with an "a=inactive" attribute, according to the procedures of [RFC3264]. When the SRS is ready to receive recorded streams, the SRS sends a new SDP offer and sets the media streams with an "a=recvonly" attribute.
通常，SRS仅从SRC接收RTP流；因此，来自SRS的SDP提供/应答通常通过根据[rfc326]的过程将每个媒体流设置为具有“a＝recvonly”属性来接收媒体。当SRS未准备好接收记录的流时，SRS根据[RFC3264]的过程，通过将媒体流设置为“a=非活动”属性，将其设置为SDP提供或应答中的非活动媒体流。当SRS准备接收记录的流时，SRS发送一个新的SDP提供，并将媒体流设置为“a=recvonly”属性。
Figure 6 shows an example of an SDP answer from the SRS for the SDP offer from Figure 5. Note that this example contains unfolded lines longer than 72 characters; these lines are captured between <allOneLine> tags.
图6显示了SRS对图5中SDP报价的SDP回答示例。请注意，此示例包含长度超过72个字符的展开行；这些行在<allOneLine>标记之间捕获。
v=0
o=SRS 0 0 IN IP4 198.51.100.20
s=-
c=IN IP4 198.51.100.20
t=0 0
m=audio 10000 RTP/AVP 0
a=recvonly
a=label:1
m=video 10002 RTP/AVP 98
a=rtpmap:98 H264/90000
<allOneLine>
a=fmtp:98 profile-level-id=42A01E;
sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
</allOneLine>
a=recvonly
a=label:2
m=audio 10004 RTP/AVP 0
a=recvonly
a=label:3
m=video 10006 RTP/AVP 98
a=rtpmap:98 H264/90000
<allOneLine>
a=fmtp:98 profile-level-id=42A01E;
sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
</allOneLine>
a=recvonly
a=label:4
v=0
o=SRS 0 0 IN IP4 198.51.100.20
s=-
c=IN IP4 198.51.100.20
t=0 0
m=audio 10000 RTP/AVP 0
a=recvonly
a=label:1
m=video 10002 RTP/AVP 98
a=rtpmap:98 H264/90000
<allOneLine>
a=fmtp:98 profile-level-id=42A01E;
sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
</allOneLine>
a=recvonly
a=label:2
m=audio 10004 RTP/AVP 0
a=recvonly
a=label:3
m=video 10006 RTP/AVP 98
a=rtpmap:98 H264/90000
<allOneLine>
a=fmtp:98 profile-level-id=42A01E;
sprop-parameter-sets=Z0IACpZTBYmI,aMljiA==
</allOneLine>
a=recvonly
a=label:4
Figure 6: Sample SDP Answer from SRS with Audio and Video Streams
图6：带音频和视频流的SRS SDP应答示例
Over the lifetime of an RS, the SRS can remove recorded streams from the RS for various reasons. To remove a recorded stream from the RS, the SRS sends a new SDP offer where the port of the media stream to be removed is set to zero, according to the procedures in [RFC3264].
在RS的生存期内，SRS可以出于各种原因从RS移除记录的流。为了从RS中删除记录的流，SRS发送一个新的SDP提供，其中根据[RFC3264]中的过程，要删除的媒体流的端口设置为零。
The SRS MUST NOT add recorded streams in the RS when the SRS sends a new SDP offer. Similarly, when the SRS starts an RS, the SRS MUST initiate the INVITE without an SDP offer to let the SRC generate the SDP offer with the streams to be recorded.
当SRS发送新的SDP报价时，SRS不得在RS中添加记录的流。类似地，当SRS启动RS时，SRS必须在没有SDP offer的情况下启动INVITE，以使SRC使用要记录的流生成SDP offer。
The sequence diagram in Figure 7 shows an example where the SRS is initially not ready to receive recorded streams and later updates the RS when the SRS is ready to record.
图7中的序列图显示了一个示例，其中SRS最初未准备好接收记录的流，随后在SRS准备好记录时更新RS。
SRC SRS
| |
|(1) INVITE (SDP offer) |
|---------------------------------------------------->|
| [not ready to record]
| (2) 200 OK with SDP inactive |
|<----------------------------------------------------|
|(3) ACK |
|---------------------------------------------------->|
| ... |
| [ready to record]
| (4) re-INVITE with SDP recvonly |
|<----------------------------------------------------|
|(5) 200 OK with SDP sendonly |
|---------------------------------------------------->|
| (6) ACK |
|<----------------------------------------------------|
|(7) RTP |
|====================================================>|
| ... |
|(8) BYE |
|---------------------------------------------------->|
| (9) OK |
|<----------------------------------------------------|
SRC SRS
| |
|(1) INVITE (SDP offer) |
|---------------------------------------------------->|
| [not ready to record]
| (2) 200 OK with SDP inactive |
|<----------------------------------------------------|
|(3) ACK |
|---------------------------------------------------->|
| ... |
| [ready to record]
| (4) re-INVITE with SDP recvonly |
|<----------------------------------------------------|
|(5) 200 OK with SDP sendonly |
|---------------------------------------------------->|
| (6) ACK |
|<----------------------------------------------------|
|(7) RTP |
|====================================================>|
| ... |
|(8) BYE |
|---------------------------------------------------->|
| (9) OK |
|<----------------------------------------------------|
Figure 7: SRS Responding to Offer with a=inactive
图7：SRS响应a=非活动的报价
When a recording-aware UA receives an SDP offer or answer that includes the "a=record" attribute, the UA provides to the end user an indication as to whether the recording is on, off, or paused for each medium, based on the most recently received "a=record" SDP attribute for that medium.
当记录感知UA接收到包括“a=记录”属性的SDP提供或应答时，UA根据最近接收到的该介质的“a=记录”SDP属性，向最终用户提供关于每个介质的记录是打开、关闭还是暂停的指示。
When a CS is traversed through multiple UAs such as a B2BUA or a conference focus, each UA involved in the CS that is aware that the CS is being recorded MUST provide the recording indication through the "a=record" attribute to all other parties in the CS.
当CS穿越多个UA（如B2BUA或会议焦点）时，CS中的每个UA如果知道CS正在被记录，则必须通过“a=记录”属性向CS中的所有其他方提供记录指示。
It is possible that more than one SRC is in the call path of the same CS, but the recording indication attribute does not provide any hint as to which SRC or how many SRCs are recording. An endpoint knows only that the call is being recorded. Furthermore, this attribute is not used as a request for a specific SRC to start or stop recording.
同一个CS的调用路径中可能有多个SRC，但recording indication属性不提供任何关于哪个SRC或记录了多少SRC的提示。端点只知道正在录制呼叫。此外，此属性不用作特定SRC启动或停止录制的请求。
A participant in a CS MAY set the recording preference in the CS to be recorded or not recorded at session establishment or during the session. A new "recordpref" SDP attribute is introduced, and the participant in the CS may set this recording preference attribute in any SDP offer/answer at session establishment time or during the session. The SRC is not required to honor the recording preference from a participant, based on local policies at the SRC, and the participant can learn the recording indication through the "a=record" SDP attribute as described in Section 7.3.1.
CS中的参与者可以在会话建立时或会话期间在CS中设置要录制或不录制的录制首选项。引入了一个新的“recordpref”SDP属性，CS中的参与者可以在会话建立时或会话期间在任何SDP提供/应答中设置此录制首选项属性。根据SRC的本地政策，SRC无需遵守参与者的录制偏好，参与者可通过第7.3.1节所述的“a=record”SDP属性了解录制指示。
The SDP "a=recordpref" attribute can appear at the media level or session level and can appear in an SDP offer or answer. When the attribute is applied at the session level, the recording preference applies to all media streams in the SDP. When the attribute is applied at the media level, the recording preference applies to that one media stream only, and that overrides the recording preference if also set at the session level. The UA can change the recording preference by changing the "a=recordpref" attribute in a subsequent SDP offer or answer. The absence of the "a=recordpref" attribute in the SDP indicates that the UA has no recording preference.
SDP“a=recordpref”属性可以出现在媒体级别或会话级别，也可以出现在SDP报价或应答中。在会话级别应用该属性时，录制首选项将应用于SDP中的所有媒体流。当在媒体级别应用该属性时，录制首选项仅应用于该媒体流，如果在会话级别也设置了该属性，则会覆盖录制首选项。UA可以通过在后续SDP报价或应答中更改“a=recordpref”属性来更改录制首选项。SDP中缺少“a=recordpref”属性表示UA没有录制首选项。
The following is the ABNF of the "recordpref" attribute:
以下是“recordpref”属性的ABNF：
attribute =/ recordpref-attr ; attribute defined in RFC 4566
属性=/recordpref attr；RFC 4566中定义的属性
recordpref-attr = "a=recordpref:" pref
pref = "on" / "off" / "pause" / "nopreference"
recordpref-attr = "a=recordpref:" pref
pref = "on" / "off" / "pause" / "nopreference"
on: Sets the preference to record if it has not already been started. If the recording is currently paused, the preference is to resume recording.
on：如果尚未启动，则将首选项设置为录制。如果录制当前已暂停，则首选恢复录制。
off: Sets the preference for no recording. If recording has already been started, then the preference is to stop the recording.
关闭：设置不录制的首选项。如果已开始录制，则首选停止录制。
pause: If the recording is currently in progress, sets the preference to pause the recording.
暂停：如果录制当前正在进行，则将首选项设置为暂停录制。
nopreference: Indicates that the UA has no preference regarding recording.
nopreference：表示UA对录制没有偏好。
This section provides recommendations and guidelines for RTP and the Real-time Transport Control Protocol (RTCP) in the context of SIPREC [RFC6341]. In order to communicate most effectively, the SRC, the SRS, and any recording-aware UAs should utilize the mechanisms provided by RTP in a well-defined and predictable manner. It is the goal of this document to make the reader aware of these mechanisms and to provide recommendations and guidelines.
本节在SIPREC[RFC6341]的上下文中提供RTP和实时传输控制协议（RTCP）的建议和指南。为了最有效地进行通信，SRC、SRS和任何感知记录的UAs应以明确定义和可预测的方式利用RTP提供的机制。本文件的目的是让读者了解这些机制，并提供建议和指导方针。
This section briefly describes important RTP/RTCP constructs and mechanisms that are particularly useful within the context of SIPREC.
本节简要介绍在SIPREC环境中特别有用的重要RTP/RTCP结构和机制。
The RTP data transport is augmented by a control protocol (RTCP) to allow monitoring of the data delivery. RTCP, as defined in [RFC3550], is based on the periodic transmission of control packets to all participants in the RTP session, using the same distribution mechanism as the data packets. Support for RTCP is REQUIRED, per [RFC3550], and it provides, among other things, the following important functionality in relation to SIPREC:
RTP数据传输通过控制协议（RTCP）进行扩展，以允许监控数据传输。[RFC3550]中定义的RTCP基于向RTP会话中的所有参与者定期传输控制数据包，使用与数据包相同的分发机制。根据[RFC3550]，需要对RTCP的支持，它提供了与SIPREC相关的以下重要功能：
1) Feedback on the quality of the data distribution
1) 对数据分发质量的反馈
This feedback from the receivers may be used to diagnose faults in the distribution. As such, RTCP is a well-defined and efficient mechanism for the SRS to inform the SRC, and for the SRC to inform recording-aware UAs, of issues that arise with respect to the reception of media that is to be recorded.
来自接收器的反馈可用于诊断配电系统中的故障。因此，RTCP是SRS通知SRC以及SRC通知记录感知UAs有关接收待记录媒体的问题的一种定义良好且高效的机制。
2) Including a persistent transport-level identifier -- the CNAME, or canonical name -- for an RTP source
2) 包括RTP源的持久传输级别标识符——CNAME或规范名称
The synchronization source (SSRC) [RFC3550] identifier may change if a conflict is discovered or a program is restarted, in which case receivers can use the CNAME to keep track of each participant. Receivers may also use the CNAME to associate
如果发现冲突或重新启动程序，同步源（SSRC）[RFC3550]标识符可能会更改，在这种情况下，接收器可以使用CNAME跟踪每个参与者。接收者也可以使用CNAME进行关联
multiple data streams from a given participant in a set of related RTP sessions -- for example, to synchronize audio and video. Synchronization of media streams is also facilitated by the NTP and RTP timestamps included in RTCP packets by data senders.
来自一组相关RTP会话中给定参与者的多个数据流——例如，用于同步音频和视频。数据发送方在RTCP数据包中包含的NTP和RTP时间戳也促进了媒体流的同步。
The RECOMMENDED RTP profiles for the SRC, SRS, and recording-aware UAs are "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] when using encrypted RTP streams, and "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)" [RFC4585] when using non-encrypted media streams. However, as these are not requirements, some implementations may use "The Secure Real-time Transport Protocol (SRTP)" [RFC3711] and "RTP Profile for Audio and Video Conferences with Minimal Control" [RFC3551]. Therefore, it is RECOMMENDED that the SRC, SRS, and recording-aware UAs not rely entirely on RTP/SAVPF or RTP/AVPF for core functionality that may be at least partially achievable using RTP/SAVP and RTP/AVP.
SRC、SRS和记录感知UAs的推荐RTP配置文件为“基于实时传输控制协议（RTCP）的反馈（RTP/SAVPF）的扩展安全RTP配置文件”[RFC5124]，当使用加密RTP流时，以及“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”[RFC4585]使用非加密媒体流时。然而，由于这些不是要求，一些实现可能会使用“安全实时传输协议（SRTP）”[RFC3711]和“用于具有最小控制的音频和视频会议的RTP配置文件”[RFC3551]。因此，建议SRC、SRS和记录感知UAs不完全依赖RTP/SAVP或RTP/AVPF来实现核心功能，这些核心功能至少可以部分使用RTP/SAVP和RTP/AVP实现。
AVPF and SAVPF provide an improved RTCP timer model that allows more flexible transmission of RTCP packets in response to events, rather than strictly according to bandwidth. AVPF-based codec control messages provide efficient mechanisms for an SRC, an SRS, and recording-aware UAs to handle events such as scene changes, error recovery, and dynamic bandwidth adjustments. These messages are discussed in more detail later in this document.
AVPF和SAVPF提供了一种改进的RTCP定时器模型，允许更灵活地传输RTCP数据包以响应事件，而不是严格按照带宽。基于AVPF的编解码器控制消息为SRC、SRS和记录感知UAs提供了有效的机制，以处理场景更改、错误恢复和动态带宽调整等事件。本文档后面将更详细地讨论这些消息。
SAVP and SAVPF provide media encryption, integrity protection, replay protection, and a limited form of source authentication. They do not contain or require a specific keying mechanism.
SAVP和SAVPF提供媒体加密、完整性保护、重播保护和有限形式的源身份验证。它们不包含或不需要特定的键控机制。
The SSRC, as defined in [RFC3550], is carried in the RTP header and in various fields of RTCP packets. It is a random 32-bit number that is required to be globally unique within an RTP session. It is crucial that the number be chosen with care, in order that participants on the same network or starting at the same time are not likely to choose the same number. Guidelines regarding SSRC value selection and conflict resolution are provided in [RFC3550].
[RFC3550]中定义的SSRC在RTP报头和RTCP数据包的各个字段中携带。它是一个随机的32位数字，要求在RTP会话中全局唯一。选择号码时要小心，这一点至关重要，因为在同一网络上或在同一时间开始的参与者不太可能选择相同的号码。[RFC3550]中提供了有关SSRC值选择和冲突解决的指南。
The SSRC may also be used to separate different sources of media within a single RTP session. For this reason, as well as for conflict resolution, it is important that the SRC, SRS, and recording-aware UAs handle changes in SSRC values and properly identify the reason for the change. The CNAME values carried in RTCP facilitate this identification.
SSRC还可用于在单个RTP会话内分离不同的媒体源。因此，为了解决冲突，SRC、SRS和记录感知UAs必须处理SSRC值的变化，并正确识别变化的原因。RTCP中携带的CNAME值有助于识别。
The contributing source (CSRC), as defined in [RFC3550], identifies the source of a stream of RTP packets that has contributed to the combined stream produced by an RTP mixer. The mixer inserts a list of the SSRC identifiers of the sources that contributed to the generation of a particular packet into the RTP header of that packet. This list is called the CSRC list. It is RECOMMENDED that an SRC or recording-aware UA, when acting as a mixer, set the CSRC list accordingly, and that the SRC and SRS interpret the CSRC list per [RFC3550] when received.
[RFC3550]中定义的贡献源（CSC）标识RTP数据包流的源，该RTP数据包流已贡献给RTP混合器产生的组合流。混合器将有助于生成特定分组的源的SSRC标识符的列表插入该分组的RTP报头中。该名单称为中国证监会名单。建议SRC或录音感知UA在充当混音器时相应地设置CSC列表，并且SRC和SRS在收到时根据[RFC3550]解释CSC列表。
The Source Description (SDES), as defined in [RFC3550], contains an SSRC/CSRC identifier followed by a list of zero or more items that carry information about the SSRC/CSRC. End systems send one SDES packet containing their own source identifier (the same as the SSRC in the fixed RTP header). A mixer sends one SDES packet containing a chunk for each CSRC from which it is receiving SDES information, or multiple complete SDES packets if there are more than 31 such sources.
[RFC3550]中定义的来源描述（SDES）包含SSRC/CSC标识符，后跟零个或多个项目的列表，其中包含有关SSRC/CSC的信息。终端系统发送一个包含其自身源标识符的SDES数据包（与固定RTP报头中的SSRC相同）。混频器发送一个SDES数据包，其中包含从中接收SDES信息的每个CSC的数据块，或者如果有超过31个这样的源，则发送多个完整的SDES数据包。
The ability to identify individual CSRCs is important in the context of SIPREC. Metadata [RFC7865] provides a mechanism to achieve this at the signaling level. SDES provides a mechanism at the RTP level.
在SIPREC的背景下，识别单个CSRC的能力非常重要。元数据[RFC7865]提供了在信令级别实现这一点的机制。SDES在RTP级别提供了一种机制。
The Canonical End-Point Identifier (CNAME), as defined in [RFC3550], provides the binding from the SSRC identifier to an identifier for the source (sender or receiver) that remains constant. It is important that the SRC and recording-aware UAs generate CNAMEs appropriately and that the SRC and SRS interpret and use them for this purpose. Guidelines for generating CNAME values are provided in "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)" [RFC7022].
[RFC3550]中定义的规范端点标识符（CNAME）提供了从SSRC标识符到保持不变的源（发送方或接收方）标识符的绑定。SRC和记录感知UAs正确生成CNAME，SRC和SRS对此进行解释和使用，这一点很重要。“选择RTP控制协议（RTCP）规范名称（CNAMEs）的指南”[RFC7022]中提供了生成CNAME值的指南。
It is anticipated that media streams in SIPREC may exist in an inactive state for extended periods of time for any of a number of valid reasons. In order for the bindings and any pinholes in NATs/firewalls to remain active during such intervals, it is RECOMMENDED that the SRC, SRS, and recording-aware UAs follow the keepalive procedure recommended in "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows" [RFC6263] for all RTP media streams.
预计SIPREC中的媒体流可能由于许多有效原因中的任何一个而在长时间内处于非活动状态。为了使NAT/防火墙中的绑定和任何针孔在这些间隔期间保持活动状态，建议SRC、SRS和记录感知UAs遵循“保持与RTP/RTP控制协议（RTCP）流相关的NAT映射活动的应用机制”中建议的keepalive过程[RFC6263]对于所有RTP媒体流。
"Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)" [RFC5104] specifies extensions to the messages defined in AVPF [RFC4585]. Support for and proper usage of these messages are important to SRC, SRS, and recording-aware UA implementations. Note that these messages are applicable only when using the AVPF or SAVPF RTP profiles.
“带反馈的RTP视听配置文件（AVPF）中的编解码器控制消息”[RFC5104]指定对AVPF[RFC4585]中定义的消息的扩展。对这些消息的支持和正确使用对于SRC、SRS和记录感知UA实现非常重要。请注意，这些消息仅在使用AVPF或SAVPF RTP配置文件时适用。
A Full Intra Request (FIR) command, when received by the designated media sender, requires that the media sender send a decoder refresh point at the earliest opportunity. Using a decoder refresh point implies refraining from using any picture sent prior to that point as a reference for the encoding process of any subsequent picture sent in the stream.
当指定的媒体发送方收到完整的内部请求（FIR）命令时，要求媒体发送方尽早发送解码器刷新点。使用解码器刷新点意味着避免使用在该点之前发送的任何图片作为流中发送的任何后续图片的编码过程的参考。
Decoder refresh points, especially Intra or Instantaneous Decoding Refresh (IDR) pictures for H.264 video codecs, are in general several times larger in size than predicted pictures. Thus, in scenarios in which the available bit rate is small, the use of a decoder refresh point implies a delay that is significantly longer than the typical picture duration.
解码器刷新点，特别是用于H.264视频编解码器的帧内或瞬时解码刷新（IDR）图片，通常比预测图片大几倍。因此，在可用比特率小的场景中，解码器刷新点的使用意味着显著长于典型图片持续时间的延迟。
"XML Schema for Media Control" [RFC5168] defines an Extensible Markup Language (XML) Schema for video fast update. Implementations are discouraged from using the method described in [RFC5168], except for purposes of backward compatibility. Implementations SHOULD use FIR messages instead.
“媒体控制的XML模式”[RFC5168]定义了用于视频快速更新的可扩展标记语言（XML）模式。不鼓励实现使用[RFC5168]中描述的方法，除非出于向后兼容性的目的。实现应该使用FIR消息。
To make sure that a common mechanism exists between the SRC and SRS, the SRS MUST support both mechanisms (FIR and SIP INFO), using FIR messages when negotiated successfully with the SRC and using SIP INFO otherwise.
为了确保SRC和SRS之间存在公共机制，SRS必须支持这两种机制（FIR和SIP信息），在与SRC成功协商时使用FIR消息，否则使用SIP信息。
Picture Loss Indication (PLI), as defined in [RFC4585], informs the encoder of the loss of an undefined amount of coded video data belonging to one or more pictures. [RFC4585] recommends using PLI instead of FIR messages to recover from errors. FIR is appropriate only in situations where not sending a decoder refresh point would render the video unusable for the users. Examples where sending FIR messages is appropriate include a multipoint conference when a new
[RFC4585]中定义的图片丢失指示（PLI）通知编码器属于一个或多个图片的未定义数量的编码视频数据丢失。[RFC4585]建议使用PLI而不是FIR消息从错误中恢复。FIR仅适用于不发送解码器刷新点会导致用户无法使用视频的情况。发送FIR消息是合适的示例包括当新消息出现时的多点会议
user joins the conference and no regular decoder refresh point interval is established, and a video-switching Multipoint Control Unit (MCU) that changes streams.
用户加入会议，不建立常规解码器刷新点间隔，并且视频切换多点控制单元（MCU）改变流。
Appropriate use of PLI and FIR is important to ensure, with minimum overhead, that the recorded video is usable (e.g., the necessary reference frames exist for a player to render the recorded video).
适当使用PLI和FIR对于以最小的开销确保录制的视频可用（例如，播放器渲染录制的视频时存在必要的参考帧）非常重要。
A receiver, translator, or mixer uses the Temporary Maximum Media Stream Bit Rate Request (TMMBR) [RFC5104] to request a sender to limit the maximum bit rate for a media stream to the provided value. Appropriate use of TMMBR facilitates rapid adaptation to changes in available bandwidth.
接收器、转换器或混频器使用临时最大媒体流比特率请求（TMMBR）[RFC5104]请求发送器将媒体流的最大比特率限制在提供的值内。适当使用TMMBR有助于快速适应可用带宽的变化。
If it is likely that the new value indicated by TMMBR will be valid for the remainder of the session, the TMMBR sender is expected to perform a renegotiation of the session upper limit using the session signaling protocol. Therefore, for SIPREC, implementations are RECOMMENDED to use TMMBR for temporary changes and renegotiation of bandwidth via SDP offer/answer for more permanent changes.
如果TMMBR指示的新值可能在会话的剩余时间内有效，则TMMBR发送方应使用会话信令协议重新协商会话上限。因此，对于SIPREC，建议使用TMMBR进行临时更改，并通过SDP offer/answer重新协商带宽，以实现更持久的更改。
Within an SDP offer/answer exchange, RTP entities choose the RTP and RTCP transport addresses (i.e., IP addresses and port numbers) on which to receive packets. When sending packets, the RTP entities may use the same source port or a different source port than those signaled for receiving packets. When the transport address used to send and receive RTP is the same, it is termed "symmetric RTP" [RFC4961]. Likewise, when the transport address used to send and receive RTCP is the same, it is termed "symmetric RTCP" [RFC4961].
在SDP提供/应答交换中，RTP实体选择接收数据包的RTP和RTCP传输地址（即IP地址和端口号）。当发送分组时，RTP实体可以使用与接收分组的信号相同的源端口或不同的源端口。当用于发送和接收RTP的传输地址相同时，称为“对称RTP”[RFC4961]。同样，当用于发送和接收RTCP的传输地址相同时，它被称为“对称RTCP”[RFC4961]。
When sending RTP, the use of symmetric RTP is REQUIRED. When sending RTCP, the use of symmetric RTCP is REQUIRED. Although an SRS will not normally send RTP, it will send RTCP as well as receive RTP and RTCP. Likewise, although an SRC will not normally receive RTP from the SRS, it will receive RTCP as well as send RTP and RTCP.
发送RTP时，需要使用对称RTP。发送RTCP时，需要使用对称RTCP。虽然SRS通常不会发送RTP，但它会发送RTCP以及接收RTP和RTCP。同样，尽管SRC通常不会从SRS接收RTP，但它将接收RTCP以及发送RTP和RTCP。
Note: Symmetric RTP and symmetric RTCP are different from RTP/RTCP multiplexing [RFC5761].
注：对称RTP和对称RTCP不同于RTP/RTCP多路复用[RFC5761]。
An SRC has the task of gathering media from the various UAs in one or more CSs and forwarding the information to the SRS within the context of a corresponding RS. There are numerous ways in which an SRC may do this, including, but not limited to, appearing as a UA within a CS, or as a B2BUA between UAs within a CS.
SRC的任务是从一个或多个CSs中的各种UAs收集媒体，并在相应RS的上下文中将信息转发给SRS。SRC可以通过多种方式实现这一点，包括但不限于在CS中显示为UA，或在CS中显示为UAs之间的B2BUA。
(Recording Session) +---------+
+------------SIP------->| |
| +------RTP/RTCP----->| SRS |
| | +-- Metadata -->| |
| | | +---------+
v v |
+---------+
| SRC |
|---------| (Communication Session) +---------+
| |<----------SIP---------->| |
| UA-A | | UA-B |
| |<-------RTP/RTCP-------->| |
+---------+ +---------+
(Recording Session) +---------+
+------------SIP------->| |
| +------RTP/RTCP----->| SRS |
| | +-- Metadata -->| |
| | | +---------+
v v |
+---------+
| SRC |
|---------| (Communication Session) +---------+
| |<----------SIP---------->| |
| UA-A | | UA-B |
| |<-------RTP/RTCP-------->| |
+---------+ +---------+
Figure 8: UA as SRC
图8:UA作为SRC
(Recording Session) +---------+
+------------SIP------->| |
| +------RTP/RTCP----->| SRS |
| | +-- Metadata -->| |
| | | +---------+
v v |
+---------+
| SRC |
+---------+ |---------| +---------+
| |<----SIP----->| |<----SIP----->| |
| UA-A | | B2BUA | | UA-B |
| |<--RTP/RTCP-->| |<--RTP/RTCP-->| |
+---------+ +---------+ +---------+
|_______________________________________________|
(Communication Session)
(Recording Session) +---------+
+------------SIP------->| |
| +------RTP/RTCP----->| SRS |
| | +-- Metadata -->| |
| | | +---------+
v v |
+---------+
| SRC |
+---------+ |---------| +---------+
| |<----SIP----->| |<----SIP----->| |
| UA-A | | B2BUA | | UA-B |
| |<--RTP/RTCP-->| |<--RTP/RTCP-->| |
+---------+ +---------+ +---------+
|_______________________________________________|
(Communication Session)
Figure 9: B2BUA as SRC
图9:B2BUA作为SRC
The following subsections define a set of roles an SRC may choose to play, based on its position with respect to a UA within a CS, and an SRS within an RS. A CS and a corresponding RS are independent sessions; therefore, an SRC may play a different role within a CS than it does within the corresponding RS.
以下小节根据SRC在CS中相对于UA的位置以及RS中的SRS定义了SRC可以选择扮演的一组角色。CS和相应RS是独立会话；因此，SRC在CS中扮演的角色可能与在相应RS中扮演的角色不同。
The SRC may act as a translator, as defined in [RFC3550]. A defining characteristic of a translator is that it forwards RTP packets with their SSRC identifier intact. There are two types of translators: one that simply forwards, and another that performs transcoding (e.g., from one codec to another) in addition to forwarding.
SRC可充当[RFC3550]中定义的翻译人员。转换器的一个定义特征是，它转发RTP数据包时，其SSRC标识符保持不变。有两种类型的转换器：一种只是转发，另一种除了转发之外还执行转码（例如，从一个编解码器到另一个编解码器）。
When acting as a forwarding translator, RTP received as separate streams from different sources (e.g., from different UAs with different SSRCs) cannot be mixed by the SRC and MUST be sent separately to the SRS. All RTCP reports MUST be passed by the SRC between the UAs and the SRS, such that the UAs and SRS are able to detect any SSRC collisions.
当充当转发转换器时，SRC不能混合从不同来源（例如，来自具有不同SSRC的不同UAs）作为单独流接收的RTP，必须单独发送给SRS。所有RTCP报告必须由SRC在UAs和SRS之间传递，以便UAs和SRS能够检测任何SSRC冲突。
RTCP Sender Reports generated by a UA sending a stream MUST be forwarded to the SRS. RTCP Receiver Reports generated by the SRS MUST be forwarded to the relevant UA.
UA发送流生成的RTCP发送方报告必须转发给SRS。SRS生成的RTCP接收方报告必须转发给相关UA。
UAs may receive multiple sets of RTCP Receiver Reports -- one or more from other UAs participating in the CS, and one from the SRS participating in the RS. A UA SHOULD process the RTCP Receiver Reports from the SRS if it is recording aware.
UAs可能会收到多组RTCP接收器报告——一组或多组来自参与CS的其他UAs，另一组来自参与RS的SRS。UA应处理来自SRS的RTCP接收器报告（如果其记录感知）。
If SRTP is used on both the CS and the RS, decryption and/or re-encryption may occur. For example, if different keys are used, it will occur. If the same keys are used, it need not occur. Section 12 provides additional information on SRTP and keying mechanisms.
如果在CS和RS上同时使用SRTP，则可能发生解密和/或重新加密。例如，如果使用不同的键，则会发生这种情况。如果使用相同的键，则无需执行此操作。第12节提供了有关SRTP和键控机制的附加信息。
If packet loss occurs, either from the UA to the SRC or from the SRC to the SRS, the SRS SHOULD detect and attempt to recover from the loss. The SRC does not play a role in this, other than forwarding the associated RTP and RTCP packets.
如果发生从UA到SRC或从SRC到SRS的数据包丢失，SRS应检测并尝试从丢失中恢复。SRC除了转发相关的RTP和RTCP数据包外，在这方面不起作用。
When acting as a transcoding translator, an SRC MAY perform transcoding (e.g., from one codec to another), and this may result in a different rate of packets between what the SRC receives on the CS and what the SRC sends on the RS. As when acting as a forwarding translator, RTP received as separate streams from different sources (e.g., from different UAs with different SSRCs) cannot be mixed by the SRC and MUST be sent separately to the SRS. All RTCP reports MUST be passed by the SRC between the UAs and the SRS, such that the UAs and SRS are able to detect any SSRC collisions.
当充当转码转换器时，SRC可以执行转码（例如，从一个编解码器到另一个编解码器），并且这可能导致SRC在CS上接收的数据包和SRC在RS上发送的数据包之间的不同速率。当充当转发转换器时，RTP作为来自不同源的单独流接收（例如，来自具有不同SSRC的不同UAs）不能由SRC混合，必须单独发送给SRS。所有RTCP报告必须由SRC在UAs和SRS之间传递，以便UAs和SRS能够检测任何SSRC冲突。
RTCP Sender Reports generated by a UA sending a stream MUST be forwarded to the SRS. RTCP Receiver Reports generated by the SRS MUST be forwarded to the relevant UA. The SRC may need to manipulate the RTCP Receiver Reports to take into account any transcoding that has taken place.
UA发送流生成的RTCP发送方报告必须转发给SRS。SRS生成的RTCP接收方报告必须转发给相关UA。SRC可能需要操纵RTCP接收器报告，以考虑已发生的任何转码。
UAs may receive multiple sets of RTCP Receiver Reports -- one or more from other UAs participating in the CS, and one from the SRS participating in the RS. A recording-aware UA SHOULD be prepared to process the RTCP Receiver Reports from the SRS, whereas a recording-unaware UA may discard such RTCP packets as irrelevant.
UAs可能会收到多组RTCP接收器报告——一个或多个来自参与CS的其他UAs，一个来自参与RS的SRS。感知记录的UA应该准备好处理来自SRS的RTCP接收器报告，而不知道记录的UA可能会丢弃不相关的RTCP数据包。
If SRTP is used on both the CS and the RS, decryption and/or re-encryption may occur. For example, if different keys are used, it will occur. If the same keys are used, it need not occur. Section 12 provides additional information on SRTP and keying mechanisms.
如果在CS和RS上同时使用SRTP，则可能发生解密和/或重新加密。例如，如果使用不同的键，则会发生这种情况。如果使用相同的键，则无需执行此操作。第12节提供了有关SRTP和键控机制的附加信息。
If packet loss occurs, either from the UA to the SRC or from the SRC to the SRS, the SRS SHOULD detect and attempt to recover from the loss. The SRC does not play a role in this, other than forwarding the associated RTP and RTCP packets.
如果发生从UA到SRC或从SRC到SRS的数据包丢失，SRS应检测并尝试从丢失中恢复。SRC除了转发相关的RTP和RTCP数据包外，在这方面不起作用。
In the case of the SRC acting as an RTP mixer, as defined in [RFC3550], the SRC combines RTP streams from different UAs and sends them towards the SRS using its own SSRC. The SSRCs from the contributing UA SHOULD be conveyed as CSRC identifiers within this stream. The SRC may make timing adjustments among the received streams and generate its own timing on the stream sent to the SRS. Optionally, an SRC acting as a mixer can perform transcoding and can even cope with different codings received from different UAs. RTCP Sender Reports and Receiver Reports are not forwarded by an SRC acting as a mixer, but there are requirements for forwarding RTCP Source Description (SDES) packets. The SRC generates its own RTCP Sender Reports and Receiver Reports toward the associated UAs and SRS.
在SRC充当RTP混合器的情况下，如[RFC3550]中所定义，SRC组合来自不同UAs的RTP流，并使用其自身的SSRC将其发送至SRS。来自作出贡献的UA的SSRC应作为该流中的CSRC标识符传送。SRC可以在接收到的流之间进行定时调整，并在发送到SRS的流上生成其自己的定时。可选地，充当混合器的SRC可以执行转码，甚至可以处理从不同ua接收的不同编码。RTCP发送方报告和接收方报告不由充当混音器的SRC转发，但需要转发RTCP源描述（SDES）数据包。SRC向相关的UAs和SRS生成自己的RTCP发送方报告和接收方报告。
The use of SRTP between the SRC and the SRS for the RS is independent of the use of SRTP between the UAs and the SRC for the CS. Section 12 provides additional information on SRTP and keying mechanisms.
RS的SRC和SRS之间使用SRTP独立于UAs和CS的SRC之间使用SRTP。第12节提供了有关SRTP和键控机制的附加信息。
If packet loss occurs from the UA to the SRC, the SRC SHOULD detect and attempt to recover from the loss. If packet loss occurs from the SRC to the SRS, the SRS SHOULD detect and attempt to recover from the loss.
如果从UA到SRC发生数据包丢失，SRC应检测并尝试从丢失中恢复。如果从SRC到SRS发生数据包丢失，SRS应检测并尝试从丢失中恢复。
The case of the SRC acting as an RTP endpoint, as defined in [RFC3550], is similar to the mixer case, except that the RTP session between the SRC and the SRS is considered completely independent from the RTP session that is part of the CS. The SRC can, but need not, mix RTP streams from different participants prior to sending to the SRS. RTCP between the SRC and the SRS is completely independent of RTCP on the CS.
[RFC3550]中定义的SRC作为RTP端点的情况类似于混音器情况，不同之处在于SRC和SRS之间的RTP会话被认为完全独立于作为CS一部分的RTP会话。SRC可以但不需要在发送到SRS之前混合来自不同参与者的RTP流。SRC和SRS之间的RTCP完全独立于CS上的RTCP。
The use of SRTP between the SRC and the SRS for the RS is independent of the use of SRTP between the UAs and SRC for the CS. Section 12 provides additional information on SRTP and keying mechanisms.
RS的SRC和SRS之间使用SRTP独立于UAs和CS的SRC之间使用SRTP。第12节提供了有关SRTP和键控机制的附加信息。
If packet loss occurs from the UA to the SRC, the SRC SHOULD detect and attempt to recover from the loss. If packet loss occurs from the SRC to the SRS, the SRS SHOULD detect and attempt to recover from the loss.
如果从UA到SRC发生数据包丢失，SRC应检测并尝试从丢失中恢复。如果从SRC到SRS发生数据包丢失，SRS应检测并尝试从丢失中恢复。
There are multiple ways that an SRC may choose to deliver recorded media to an SRS. In some cases, it may use a single RTP session for all media within the RS, whereas in others it may use multiple RTP sessions. The following subsections provide examples of basic RTP session usage by the SRC, including a discussion of how the RTP constructs and mechanisms covered previously are used. An SRC may choose to use one or more of the RTP session usages within a single RS. For the purpose of base interoperability between SRC and SRS, an SRC MUST support separate m-lines in SDP, one per CS media direction. The set of RTP session usages described is not meant to be exhaustive.
SRC可以选择多种方式将记录的媒体传送给SRS。在某些情况下，它可以对RS内的所有媒体使用单个RTP会话，而在其他情况下，它可以使用多个RTP会话。以下小节提供了SRC使用基本RTP会话的示例，包括如何使用前面介绍的RTP构造和机制的讨论。SRC可以选择在单个RS内使用一个或多个RTP会话用法。为了SRC和SRS之间的基本互操作性，SRC必须支持SDP中的独立m线，每个CS媒体方向一条。所描述的一组RTP会话用法并不意味着详尽无遗。
When using multiple m-lines, an SRC includes each m-line in an SDP offer to the SRS. The SDP answer from the SRS MUST include all m-lines, with any rejected m-lines indicated with a zero port, per [RFC3264]. Having received the answer, the SRC starts sending media to the SRS as indicated in the answer. Alternatively, if the SRC deems the level of support indicated in the answer to be unacceptable, it may initiate another SDP offer/answer exchange in which an alternative RTP session usage is negotiated.
当使用多条m线时，SRC将每条m线包含在向SRS提供的SDP报价中。根据[RFC3264]，SRS的SDP应答必须包括所有m线，任何被拒绝的m线都用零端口表示。收到应答后，SRC开始向SRS发送媒体，如应答中所示。或者，如果SRC认为答案中指示的支持级别不可接受，则可以启动另一个SDP提供/应答交换，在该交换中协商替代RTP会话使用。
In order to preserve the mapping of media to participant within the CSs in the RS, the SRC SHOULD map each unique CNAME within the CSs to a unique CNAME within the RS. Additionally, the SRC SHOULD map each unique combination of CNAME/SSRC within the CSs to a unique CNAME/SSRC within the RS. In doing so, the SRC may act as an RTP translator or as an RTP endpoint.
为了保留媒体与RS中CSs内参与者的映射，SRC应将CSs内的每个唯一CNAME映射到RS内的唯一CNAME。此外，SRC应将CSs内CNAME/SSRC的每个唯一组合映射到RS内的唯一CNAME/SSRC。这样做，SRC可以充当RTP转换器或RTP端点。
Figure 10 illustrates a case in which each UA represents a participant contributing two RTP sessions (e.g., one for audio and one for video), each with a single SSRC. The SRC acts as an RTP translator and delivers the media to the SRS using four RTP sessions, each with a single SSRC. The CNAME and SSRC values used by the UAs within their media streams are preserved in the media streams from the SRC to the SRS.
图10说明了一种情况，其中每个UA代表一个参与者参与两个RTP会话（例如，一个用于音频，一个用于视频），每个会话都有一个SSRC。SRC充当RTP转换器，并使用四个RTP会话（每个会话带有一个SSRC）将媒体传送到SRS。UAs在其媒体流中使用的CNAME和SSRC值保存在从SRC到SRS的媒体流中。
+---------+
+------------SSRC Aa--->| |
| + --------SSRC Av--->| |
| | +------SSRC Ba--->| SRS |
| | | +---SSRC Bv--->| |
| | | | +---------+
| | | |
| | | |
+---------+ +----------+ +---------+
| |---SSRC Aa-->| SRC |<--SSRC Ba---| |
| UA-A | |(CNAME-A, | | UA-B |
|(CNAME-A)|---SSRC Av-->| CNAME-B) |<--SSRC Bv---|(CNAME-B)|
+---------+ +----------+ +---------+
+---------+
+------------SSRC Aa--->| |
| + --------SSRC Av--->| |
| | +------SSRC Ba--->| SRS |
| | | +---SSRC Bv--->| |
| | | | +---------+
| | | |
| | | |
+---------+ +----------+ +---------+
| |---SSRC Aa-->| SRC |<--SSRC Ba---| |
| UA-A | |(CNAME-A, | | UA-B |
|(CNAME-A)|---SSRC Av-->| CNAME-B) |<--SSRC Bv---|(CNAME-B)|
+---------+ +----------+ +---------+
Figure 10: SRC Using Multiple m-lines
图10：使用多条m线的SRC
When using mixing, the SRC combines RTP streams from different participants and sends them towards the SRS using its own SSRC. The SSRCs from the contributing participants SHOULD be conveyed as CSRC identifiers. The SRC includes one m-line for each RTP session in an SDP offer to the SRS. The SDP answer from the SRS MUST include all m-lines, with any rejected m-lines indicated with a zero port, per [RFC3264]. Having received the answer, the SRC starts sending media to the SRS as indicated in the answer.
当使用混合时，SRC组合来自不同参与者的RTP流，并使用自己的SSRC将其发送到SRS。贡献参与者的SSRC应作为中国证监会标识符传达。SRC在向SRS提供的SDP中为每个RTP会话包括一条m线。根据[RFC3264]，SRS的SDP应答必须包括所有m线，任何被拒绝的m线都用零端口表示。收到应答后，SRC开始向SRS发送媒体，如应答中所示。
In order to preserve the mapping of media to participant within the CSs in the RS, the SRC SHOULD map each unique CNAME within the CSs to a unique CNAME within the RS. Additionally, the SRC SHOULD map each unique combination of CNAME/SSRC within the CSs to a unique
为了保留媒体到RS中CSs内参与者的映射，SRC应将CSs内的每个唯一CNAME映射到RS内的唯一CNAME。此外，SRC应将CSs内CNAME/SSRC的每个唯一组合映射到唯一CNAME
CNAME/SSRC within the RS. The SRC MUST avoid SSRC collisions, rewriting SSRCs if necessary when used as CSRCs in the RS. In doing so, the SRC acts as an RTP mixer.
RS中的CNAME/SSRC。SRC必须避免SSRC冲突，当在RS中用作CSRC时，必要时重写SSRC。在这样做时，SRC充当RTP混频器。
In the event that the SRS does not support this usage of CSRC values, it relies entirely on the SIPREC metadata to determine the participants included within each mixed stream.
如果SRS不支持使用CSC值，则完全依赖SIPREC元数据来确定每个混合流中包含的参与者。
Figure 11 illustrates a case in which each UA represents a participant contributing two RTP sessions (e.g., one for audio and one for video), each with a single SSRC. The SRC acts as an RTP mixer and delivers the media to the SRS using two RTP sessions, mixing media from each participant into a single RTP session containing a single SSRC and two CSRCs.
图11说明了一种情况，其中每个UA代表一个参与者参与两个RTP会话（例如，一个用于音频，一个用于视频），每个会话都有一个SSRC。SRC充当RTP混合器，并使用两个RTP会话将媒体传送到SRS，将来自每个参与者的媒体混合到包含一个SSRC和两个CSRC的单个RTP会话中。
SSRC Sa +---------+
+-------CSRC Aa,Ba--->| |
| | |
| SSRC Sv | SRS |
| +---CSRC Av,Bv--->| |
| | +---------+
| |
+----------+
+---------+ | SRC | +---------+
| |---SSRC Aa-->|(CNAME-S, |<--SSRC Ba---| |
| UA-A | | CNAME-A, | | UA-B |
|(CNAME-A)|---SSRC Av-->| CNAME-B) |<--SSRC Bv---|(CNAME-B)|
+---------+ +----------+ +---------+
SSRC Sa +---------+
+-------CSRC Aa,Ba--->| |
| | |
| SSRC Sv | SRS |
| +---CSRC Av,Bv--->| |
| | +---------+
| |
+----------+
+---------+ | SRC | +---------+
| |---SSRC Aa-->|(CNAME-S, |<--SSRC Ba---| |
| UA-A | | CNAME-A, | | UA-B |
|(CNAME-A)|---SSRC Av-->| CNAME-B) |<--SSRC Bv---|(CNAME-B)|
+---------+ +----------+ +---------+
Figure 11: SRC Using Mixing
图11：使用混合的SRC
An SRS that supports recording an audio CS MUST support SRC usage of separate audio m-lines in SDP, one per CS media direction. An SRS that supports recording a video CS MUST support SRC usage of separate video m-lines in SDP, one per CS media direction. Therefore, for an SRS supporting a typical audio call, the SRS has to support receiving at least two audio m-lines. For an SRS supporting a typical audio and video call, the SRS has to support receiving at least four total m-lines in the SDP -- two audio m-lines and two video m-lines.
支持录制音频CS的SRS必须支持SRC在SDP中使用单独的音频m线，每个CS媒体方向一条。支持录制视频CS的SRS必须支持SRC在SDP中使用单独的视频m线，每个CS媒体方向一条。因此，对于支持典型音频呼叫的SRS，SRS必须支持接收至少两条音频m线。对于支持典型音频和视频呼叫的SRS，SRS必须支持在SDP中接收至少四条m线——两条音频m线和两条视频m线。
These requirements allow an SRS to be implemented that supports video only, without requiring support for audio recording. They also allow an SRS to be implemented that supports recording only one direction of one stream in a CS -- for example, an SRS designed to record security monitoring cameras that only send (not receive) video without any audio. These requirements were not written to prevent
这些要求允许实现仅支持视频的SRS，而不需要支持音频录制。它们还允许实现支持在CS中只记录一个流的一个方向的SRS——例如，设计用于记录只发送（不接收）没有任何音频的视频的安全监控摄像机的SRS。这些要求并不是为了防止
other modes from being implemented and used, such as using a single m-line and mixing the separate audio streams together. Rather, the requirements were written to provide a common base mode to implement for the sake of interoperability. It is important to note that an SRS implementation supporting the common base mode may not record all media streams in a CS if a participant supports more than one m-line in a video call, such as one for camera and one for presentation. SRS implementations may support other modes as well, but they have to at least support the modes discussed above, such that they interoperate in the common base mode for basic interoperability.
其他模式，例如使用单个m线和将单独的音频流混合在一起。相反，编写需求是为了提供一个通用的基本模式来实现互操作性。重要的是要注意，如果参与者在视频呼叫中支持多条m线（例如一条用于照相机，一条用于演示），则支持公共基本模式的SRS实现可能不会在CS中记录所有媒体流。SRS实现也可能支持其他模式，但它们必须至少支持上面讨论的模式，以便它们在基本互操作性的公共基本模式下进行互操作。
Some metadata attributes are contained in SDP, and others are contained in a new content type called "application/rs-metadata". The format of the metadata is described as part of the mechanism in [RFC7865]. A new "disposition-type" of Content-Disposition is defined for the purpose of carrying metadata. The value is "recording-session", which indicates that the "application/rs-metadata" content contains metadata to be handled by the SRS.
一些元数据属性包含在SDP中，另一些元数据属性包含在称为“应用程序/rs元数据”的新内容类型中。元数据的格式在[RFC7865]中描述为机制的一部分。为了承载元数据，定义了内容处置的新“处置类型”。该值为“录制会话”，表示“应用程序/rs元数据”内容包含SRS要处理的元数据。
The SRC MUST send metadata to the SRS in an RS. The SRC SHOULD send metadata as soon as it becomes available and whenever it changes. Cases in which an SRC may be justified in waiting temporarily before sending metadata include:
SRC必须向RS中的SRS发送元数据。SRC应在元数据可用时以及在元数据更改时立即发送元数据。SRC有理由在发送元数据之前暂时等待的情况包括：
o waiting for a previous metadata exchange to complete (i.e., the SRC cannot send another SDP offer until the previous offer/answer completes and may also prefer not to send an UPDATE during this time).
o 等待上一次元数据交换完成（即，在上一次报价/应答完成之前，SRC无法发送另一个SDP报价，并且在此期间可能不希望发送更新）。
o constraining the signaling rate on the RS.
o 限制RS上的信令速率。
o sending metadata when key events occur, rather than for every event that has any impact on metadata.
o 在关键事件发生时发送元数据，而不是为每个对元数据有任何影响的事件发送元数据。
The SRC may also be configured to suppress certain metadata out of concern for privacy or perceived lack of need for it to be included in the recording.
SRC还可被配置为出于对隐私的关注或感知到不需要将其包括在记录中而抑制某些元数据。
Metadata sent by the SRC is categorized as either a full metadata snapshot or a partial update. A full metadata snapshot describes all metadata associated with the RS. The SRC MAY send a full metadata snapshot at any time. The SRC MAY send a partial update only if a full metadata snapshot has been sent previously.
SRC发送的元数据分为完整元数据快照或部分更新。完整元数据快照描述与RS关联的所有元数据。SRC可随时发送完整元数据快照。只有在之前已发送完整元数据快照的情况下，SRC才能发送部分更新。
The SRC MAY send metadata (either a full metadata snapshot or a partial update) in an INVITE request, an UPDATE request [RFC3311], or a 200 response to an offerless INVITE from the SRS. If the metadata contains a reference to any SDP labels, the request containing the metadata MUST also contain an SDP offer that defines those labels.
SRC可以在INVITE请求、更新请求[RFC3311]或对来自SRS的无报价邀请的200响应中发送元数据（完整元数据快照或部分更新）。如果元数据包含对任何SDP标签的引用，则包含元数据的请求还必须包含定义这些标签的SDP提供。
When a SIP message contains both an SDP offer and metadata, the request body MUST have content type "multipart/mixed", with one subordinate body part containing the SDP offer and another containing the metadata. When a SIP message contains only an SDP offer or metadata, the "multipart/mixed" container is optional.
当SIP消息同时包含SDP提供和元数据时，请求正文必须具有内容类型“multipart/mixed”，其中一个附属正文部分包含SDP提供，另一个包含元数据。当SIP消息仅包含SDP提供或元数据时，“多部分/混合”容器是可选的。
The SRC SHOULD include a full metadata snapshot in the initial INVITE request establishing the RS. If metadata is not yet available (e.g., an RS established in the absence of a CS), the SRC SHOULD send a full metadata snapshot as soon as metadata becomes available.
SRC应在建立RS的初始INVITE请求中包含完整的元数据快照。如果元数据尚不可用（例如，在没有CS的情况下建立RS），SRC应在元数据可用后立即发送完整的元数据快照。
If the SRC receives a snapshot request from the SRS, it MUST immediately send a full metadata snapshot.
如果SRC收到SRS的快照请求，它必须立即发送完整的元数据快照。
Figure 12 illustrates an example of a full metadata snapshot sent by the SRC in the initial INVITE request:
图12展示了SRC在初始INVITE请求中发送的完整元数据快照示例：
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
INVITE sip:recorder@example.com SIP/2.0
Via: SIP/2.0/TCP src.example.com;branch=z9hG4bKdf6b622b648d9
From: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-09839247
To: <sip:recorder@example.com>
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
CSeq: 101 INVITE
Max-Forwards: 70
Require: siprec
Accept: application/sdp, application/rs-metadata
Contact: <sip:2000@src.example.com>;+sip.src
Content-Type: multipart/mixed;boundary=foobar
Content-Length: [length]
--foobar
Content-Type: application/sdp
--foobar
Content-Type: application/sdp
v=0
o=SRS 2890844526 2890844526 IN IP4 198.51.100.1
s=-
c=IN IP4 198.51.100.1
t=0 0
m=audio 12240 RTP/AVP 0 4 8
a=sendonly
a=label:1
v=0
o=SRS 2890844526 2890844526 IN IP4 198.51.100.1
s=-
c=IN IP4 198.51.100.1
t=0 0
m=audio 12240 RTP/AVP 0 4 8
a=sendonly
a=label:1
--foobar Content-Type: application/rs-metadata Content-Disposition: recording-session
--foobar内容类型：应用程序/rs元数据内容处置：录制会话
[metadata content]
[元数据内容]
Figure 12: Sample INVITE Request for the Recording Session
图12：录制会话的邀请请求示例
The SRS receives metadata updates from the SRC in INVITE and UPDATE requests. Since the SRC can send partial updates based on the previous update, the SRS needs to keep track of the sequence of updates from the SRC.
SRS在INVITE和UPDATE请求中从SRC接收元数据更新。由于SRC可以基于先前的更新发送部分更新，SRS需要跟踪SRC的更新顺序。
In the case of an internal failure at the SRS, the SRS may fail to recognize a partial update from the SRC. The SRS may be able to recover from the internal failure by requesting a full metadata snapshot from the SRC. Certain errors, such as syntax errors or semantic errors in the metadata information, are likely caused by an
如果SRS出现内部故障，SRS可能无法识别来自SRC的部分更新。SRS可以通过从SRC请求完整元数据快照来从内部故障中恢复。某些错误，例如元数据信息中的语法错误或语义错误，可能是由
error on the SRC side, and it is likely that the same error will occur again even when a full metadata snapshot is requested. In order to avoid repeating the same error, the SRS can simply terminate the RS when a syntax error or semantic error is detected in the metadata.
SRC端出错，即使请求完整元数据快照，也可能再次发生相同的错误。为了避免重复相同的错误，SRS可以在元数据中检测到语法错误或语义错误时简单地终止RS。
The SRS MAY explicitly request a full metadata snapshot by sending an UPDATE request. This request MUST contain a body with Content-Disposition type "recording-session" and MUST NOT contain an SDP body. The SRS MUST NOT request a full metadata snapshot in an UPDATE response or in any other SIP transaction. The format of the content is "application/rs-metadata", and the body is an XML document, the format of which is defined in [RFC7865]. Figure 13 shows an example:
SRS可以通过发送更新请求来明确请求完整元数据快照。此请求必须包含内容处置类型为“录制会话”的正文，并且不得包含SDP正文。SRS不得在更新响应或任何其他SIP事务中请求完整元数据快照。内容格式为“应用程序/rs元数据”，正文为XML文档，其格式在[RFC7865]中定义。图13显示了一个示例：
UPDATE sip:2000@src.example.com SIP/2.0
Via: SIP/2.0/UDP srs.example.com;branch=z9hG4bKdf6b622b648d9
To: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-098392474
From: <sip:recorder@example.com>;tag=1234567890
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
CSeq: 1 UPDATE
Max-Forwards: 70
Require: siprec
Contact: <sip:recorder@srs.example.com>;+sip.srs
Accept: application/sdp, application/rs-metadata
Content-Disposition: recording-session
Content-Type: application/rs-metadata
Content-Length: [length]
UPDATE sip:2000@src.example.com SIP/2.0
Via: SIP/2.0/UDP srs.example.com;branch=z9hG4bKdf6b622b648d9
To: <sip:2000@example.com>;tag=35e195d2-947d-4585-946f-098392474
From: <sip:recorder@example.com>;tag=1234567890
Call-ID: d253c800-b0d1ea39-4a7dd-3f0e20a
CSeq: 1 UPDATE
Max-Forwards: 70
Require: siprec
Contact: <sip:recorder@srs.example.com>;+sip.srs
Accept: application/sdp, application/rs-metadata
Content-Disposition: recording-session
Content-Type: application/rs-metadata
Content-Length: [length]
<?xml version="1.0" encoding="UTF-8"?>
<requestsnapshot xmlns='urn:ietf:params:xml:ns:recording:1'>
<requestreason xml:lang="it">SRS internal error</requestreason>
</requestsnapshot>
<?xml version="1.0" encoding="UTF-8"?>
<requestsnapshot xmlns='urn:ietf:params:xml:ns:recording:1'>
<requestreason xml:lang="it">SRS internal error</requestreason>
</requestsnapshot>
Figure 13: Metadata Request
图13：元数据请求
Note that UPDATE was chosen for the SRS to request a metadata snapshot, because it can be sent regardless of the state of the dialog. This was seen as better than requiring support for both UPDATE and re-INVITE messages for this operation.
请注意，选择更新是为了让SRS请求元数据快照，因为无论对话框的状态如何，都可以发送元数据快照。这被认为比需要支持此操作的更新和重新邀请消息要好。
When the SRC receives a request for a metadata snapshot, it MUST immediately provide a full metadata snapshot in a separate INVITE or UPDATE transaction. Any subsequent partial updates will not be dependent on any metadata sent prior to this full metadata snapshot.
当SRC收到元数据快照请求时，它必须立即在单独的INVITE或UPDATE事务中提供完整的元数据快照。任何后续部分更新将不依赖于在此完整元数据快照之前发送的任何元数据。
The metadata received by the SRS can contain ID elements used to cross-reference one element to another. An element containing the definition of an ID and an element containing a reference to that ID will often be received from the same SRC. It is also valid for those elements to be received from different SRCs -- for example, when each endpoint in the same CS acts as an SRC to record the call and a common ID refers to the same CS. The SRS MUST NOT consider this an error.
SRS接收的元数据可以包含用于将一个元素交叉引用到另一个元素的ID元素。包含ID定义的元素和包含对该ID的引用的元素通常会从同一SRC接收。从不同的SRC接收这些元素也是有效的——例如，当同一个CS中的每个端点充当SRC来记录调用，并且公共ID引用同一个CS时。SRS不能认为这是一个错误。
Persistent recording is a specific use case addressing REQ-005 in [RFC6341], where an RS can be established in the absence of a CS. The SRC continuously records media in an RS to the SRS even in the absence of a CS for all UAs that are part of persistent recording. By allocating recorded streams and continuously sending recorded media to the SRS, the SRC does not have to prepare new recorded streams with a new SDP offer when a new CS is created and also does not impact the timing of the CS. The SRC only needs to update the metadata when new CSs are created.
持久记录是[RFC6341]中的一个特定用例寻址REQ-005，其中可以在没有CS的情况下建立RS。SRC连续地将RS中的媒体记录到SRS，即使对于作为持续记录一部分的所有UAs没有CS。通过分配记录的流并连续地向SRS发送记录的媒体，SRC在创建新CS时不必使用新的SDP提供来准备新的记录流，并且也不影响CS的定时。SRC只需要在创建新CSs时更新元数据。
When there is no CS running on the devices with persistent recording, there is no recorded media to stream from the SRC to the SRS. In certain environments where a Network Address Translator (NAT) is used, a minimum amount of flow activity is typically required to maintain the NAT binding for each port opened. Agents that support Interactive Connectivity Establishment (ICE) solve this problem. For non-ICE agents, in order not to lose the NAT bindings for the RTP/RTCP ports opened for the recorded streams, the SRC and SRS SHOULD follow the recommendations provided in [RFC6263] to maintain the NAT bindings.
如果在具有持久记录的设备上没有运行CS，则没有记录的媒体可从SRC流到SRS。在使用网络地址转换器（NAT）的某些环境中，通常需要最少的流活动来维护每个打开端口的NAT绑定。支持交互式连接建立（ICE）的代理解决了这个问题。对于非ICE代理，为了不丢失为记录流打开的RTP/RTCP端口的NAT绑定，SRC和SRS应遵循[RFC6263]中提供的建议来维护NAT绑定。
This specification registers two option tags. The required information for this registration, as specified in [RFC3261], is as follows.
本规范注册了两个选项标签。[RFC3261]中规定的本次注册所需信息如下。
Name: siprec
姓名：siprec
Description: This option tag is for identifying that the SIP session is for the purpose of an RS. This is typically not used in a Supported header. When present in a Require header in a request, it indicates that the UA is either an SRC or SRS capable of handling an RS.
描述：此选项标签用于标识SIP会话是否用于RS。这通常不用于受支持的标头中。当存在于请求的Require报头中时，它表示UA是能够处理RS的SRC或SRS。
Name: record-aware
名称：记录感知
Description: This option tag is to indicate the ability of the UA to receive recording indicators in media-level or session-level SDP. When present in a Supported header, it indicates that the UA can receive recording indicators in media-level or session-level SDP.
描述：此选项标签用于指示UA在媒体级或会话级SDP中接收记录指示器的能力。当出现在受支持的报头中时，它表示UA可以在媒体级或会话级SDP中接收记录指示器。
This document registers two new media feature tags in the SIP tree per the process defined in [RFC2506] and [RFC3840].
本文档按照[RFC2506]和[RFC3840]中定义的流程在SIP树中注册两个新的媒体功能标签。
Media feature tag name: sip.src
媒体功能标签名称：sip.src
ASN.1 Identifier: 1.3.6.1.8.4.27
ASN.1标识符：1.3.6.1.8.4.27
Summary of the media feature indicated by this tag: This feature tag indicates that the UA is a Session Recording Client for the purpose of an RS.
此标签指示的媒体功能摘要：此功能标签指示UA是用于RS的会话记录客户端。
Values appropriate for use with this feature tag: boolean
适用于此功能标记的值：布尔值
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is only useful for an RS.
功能标签主要用于以下应用程序、协议、服务或协商机制：此功能标签仅对RS有用。
Examples of typical use: Routing the request to a Session Recording Server.
典型用法示例：将请求路由到会话录制服务器。
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
Media feature tag name: sip.srs
媒体功能标签名称：sip.srs
ASN.1 Identifier: 1.3.6.1.8.4.28
ASN.1标识符：1.3.6.1.8.4.28
Summary of the media feature indicated by this tag: This feature tag indicates that the UA is a Session Recording Server for the purpose of an RS.
此标签指示的媒体功能摘要：此功能标签指示UA是用于RS的会话记录服务器。
Values appropriate for use with this feature tag: boolean
适用于此功能标记的值：布尔值
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: This feature tag is only useful for an RS.
功能标签主要用于以下应用程序、协议、服务或协商机制：此功能标签仅对RS有用。
Examples of typical use: Routing the request to a Session Recording Client.
典型用法示例：将请求路由到会话记录客户端。
Security Considerations: Security considerations for this media feature tag are discussed in Section 11.1 of RFC 3840.
安全注意事项：RFC 3840第11.1节讨论了此媒体功能标签的安全注意事项。
This document registers a new "disposition-type" value in the Content-Disposition header: recording-session.
本文档在内容处置标题：录制会话中注册一个新的“处置类型”值。
recording-session: The body describes either
录制会话：正文描述
* metadata about the RS
* 关于RS的元数据
or
或
* the reason for the metadata snapshot request
* 元数据快照请求的原因
as determined by the MIME value indicated in the Content-Type.
由内容类型中指示的MIME值确定。
This document registers the following new SDP attributes.
本文档注册了以下新的SDP属性。
Contact names: Leon Portman, leon.portman@nice.com; Henry Lum, henry.lum@genesyslab.com
联系人姓名：利昂·波特曼，利昂。portman@nice.com; 亨利，亨利。lum@genesyslab.com
Attribute name: record
属性名称：记录
Long-form attribute name: Recording Indication
长格式属性名称：记录指示
Type of attribute: session level or media level
属性类型：会话级别或媒体级别
Subject to charset: no
以字符集为准：否
This attribute provides the recording indication for the session or media stream.
此属性提供会话或媒体流的录制指示。
Allowed attribute values: on, off, paused
允许的属性值：打开、关闭、暂停
Contact names: Leon Portman, leon.portman@nice.com; Henry Lum, henry.lum@genesyslab.com
联系人姓名：利昂·波特曼，利昂。portman@nice.com; 亨利，亨利。lum@genesyslab.com
Attribute name: recordpref
属性名称：recordpref
Long-form attribute name: Recording Preference
长格式属性名称：录制首选项
Type of attribute: session level or media level
属性类型：会话级别或媒体级别
Subject to charset: no
以字符集为准：否
This attribute provides the recording preference for the session or media stream.
此属性提供会话或媒体流的录制首选项。
Allowed attribute values: on, off, pause, nopreference
允许的属性值：开、关、暂停、引用
The RS is fundamentally a standard SIP dialog [RFC3261]; therefore, the RS can reuse any of the existing SIP security mechanisms available for securing the session signaling, the recorded media, and the metadata. The use cases and requirements document [RFC6341] outlines the general security considerations, and this document describes specific security recommendations.
RS基本上是一个标准的SIP对话[RFC3261]；因此，RS可以重用可用于保护会话信令、记录的媒体和元数据的任何现有SIP安全机制。用例和需求文档[RFC6341]概述了一般安全注意事项，本文档描述了具体的安全建议。
The SRC and SRS MUST support SIP with Transport Layer Security (TLS) version 1.2, SHOULD follow the best practices when using TLS as per [RFC7525], and MAY use Session Initiation Protocol Secure (SIPS) with TLS as per [RFC5630]. The RS MUST be at least as secure as the CS; this means using at least the same strength of cipher suite as the CS if the CS is secured. For example, if the CS uses SIPS for signaling and RTP/SAVP for media, then the RS may not use SIP or plain RTP unless other equivalent security measures are in effect, since doing so would mean an effective security downgrade. Examples of other potentially equivalent security mechanisms include mutually authenticated TLS for the RS signaling channel or an appropriately protected network path for the RS media component.
SRC和SRS必须支持具有传输层安全（TLS）版本1.2的SIP，在按照[RFC7525]使用TLS时应遵循最佳实践，并且可以按照[RFC5630]使用TLS的会话启动协议安全（SIPS）。RS必须至少与CS一样安全；这意味着如果CS是安全的，则至少使用与CS相同强度的密码套件。例如，如果CS使用SIP作为信令，RTP/SAVP作为媒体，则RS可能不使用SIP或普通RTP，除非其他等效安全措施生效，因为这样做将意味着有效的安全降级。其他潜在等效安全机制的示例包括用于RS信令信道的相互认证tl或用于RS媒体组件的适当保护的网络路径。
At the transport level, the RS uses TLS authentication to validate the authenticity of the SRC and SRS. The SRC and SRS MUST implement TLS mutual authentication for establishing the RS. Whether the SRC/SRS chooses to use TLS mutual authentication is a deployment decision. In deployments where a UA acts as its own SRC, this requires that the UA have its own certificate as needed for TLS mutual authentication. In deployments where the SRC and the SRS are in the same administrative domain and have some other means of assuring authenticity, the SRC and SRS may choose not to authenticate each other or to have the SRC authenticate the SRS only. In deployments where the SRS can be hosted on a different administrative domain, it is important to perform mutual authentication to ensure the authenticity of both the SRC and the SRS before transmitting any recorded media. The risk of not authenticating the SRS is that the recording may be sent to an entity other than the intended SRS, allowing a sensitive call recording to be received by an attacker. On the other hand, the risk of not authenticating the SRC is that an SRS will accept calls from an unknown SRC and allow potential forgery of call recordings.
在传输级别，RS使用TLS身份验证来验证SRC和SRS的真实性。SRC和SRS必须实施TLS相互认证以建立RS。SRC/SRS是否选择使用TLS相互认证是部署决策。在UA充当自己的SRC的部署中，这要求UA拥有TLS相互认证所需的自己的证书。在SRC和SRS位于同一管理域中且具有某些其他确保真实性的方法的部署中，SRC和SRS可以选择不相互验证或让SRC仅验证SRS。在SRS可以托管在不同管理域的部署中，在传输任何记录的媒体之前，执行相互身份验证以确保SRC和SRS的真实性非常重要。未对SRS进行身份验证的风险在于，可能会将记录发送到预期SRS以外的实体，从而允许攻击者接收敏感呼叫记录。另一方面，不认证SRC的风险是SRS将接受来自未知SRC的呼叫，并允许潜在的伪造呼叫记录。
There may be scenarios in which the signaling between the SRC and SRS is not direct, e.g., a SIP proxy exists between the SRC and the SRS. In such scenarios, each hop is subject to the TLS mutual authentication constraint, and transitive trust at each hop is
可能存在SRC和SRS之间的信令不直接的场景，例如，SRC和SRS之间存在SIP代理。在这种情况下，每个跃点都受到TLS相互身份验证约束的约束，并且每个跃点上的可传递信任是可传递的
utilized. Additionally, an SRC or SRS may use other existing SIP mechanisms available, including, but not limited to, Digest authentication [RFC3261], asserted identity [RFC3325], and connected identity [RFC4916].
利用。此外，SRC或SRS可以使用其他可用的现有SIP机制，包括但不限于摘要认证[rfc326]、断言标识[RFC3325]和连接标识[RFC4916]。
The SRS may have its own set of recording policies to authorize recording requests from the SRC. The use of recording policies is outside the scope of the Session Recording Protocol.
SRS可以有自己的一组记录策略来授权SRC的记录请求。录制策略的使用超出会话录制协议的范围。
In many scenarios, it will be critical for the media transported between the SRC and the SRS to be protected. Media encryption is an important element in the overall SIPREC solution; therefore, the SRC and the SRS MUST support RTP/SAVP [RFC3711] and RTP/SAVPF [RFC5124]. RTP/SAVP and RTP/SAVPF provide media encryption, integrity protection, replay protection, and a limited form of source authentication. They do not contain or require a specific keying mechanism. At a minimum, the SRC and SRS MUST support the SDP security descriptions key negotiation mechanism [RFC4568]. For cases in which Datagram Transport Layer Security for Secure RTP (DTLS-SRTP) is used to encrypt a CS media stream, an SRC may use SRTP Encrypted Key Transport (EKT) [EKT-SRTP] in order to use SRTP-SDES in the RS without needing to re-encrypt the media.
在许多情况下，保护SRC和SRS之间传输的介质至关重要。媒体加密是SIPREC整体解决方案中的一个重要元素；因此，SRC和SRS必须支持RTP/SAVP[RFC3711]和RTP/SAVPF[RFC5124]。RTP/SAVP和RTP/SAVPF提供媒体加密、完整性保护、重播保护和有限形式的源身份验证。它们不包含或不需要特定的键控机制。SRC和SRS至少必须支持SDP安全描述密钥协商机制[RFC4568]。对于使用用于安全RTP的数据报传输层安全性（DTLS-SRTP）来加密CS媒体流的情况，SRC可以使用SRTP加密密钥传输（EKT）[EKT-SRTP]以便在RS中使用SRTP-SDE，而无需重新加密媒体。
Note: When using EKT in this manner, it is possible for participants in the CS to send traffic that appears to be from other participants and have this forwarded by the SRC to the SRS within the RS. If this is a concern (e.g., the RS is intended for audit or compliance purposes), EKT is not an appropriate choice.
注意：当以这种方式使用EKT时，CS中的参与者可能发送来自其他参与者的流量，并由SRC转发给RS中的SRS。如果这是一个问题（例如，RS用于审计或合规目的），EKT不是一个合适的选择。
When RTP/SAVP or RTP/SAVPF is used, an SRC can choose to use the same keys or different keys in the RS than those used in the CS. Some SRCs are designed to simply replicate RTP packets from a CS media stream to the SRS, in which case the SRC will use the same key in the RS as the key used in the CS. In this case, the SRC MUST secure the SDP containing the keying material in the RS with at least the same level of security as in the CS. The risk of lowering the level of security in the RS is that it will effectively become a downgrade attack on the CS, since the same key is used for both the CS and the RS.
当使用RTP/SAVP或RTP/SAVPF时，SRC可以选择在RS中使用与CS中使用的相同或不同的密钥。一些SRC被设计为简单地将RTP包从CS媒体流复制到SRS，在这种情况下，SRC将在RS中使用与CS中使用的密钥相同的密钥。在这种情况下，SRC必须以至少与CS相同的安全级别在RS中保护包含密钥材料的SDP。降低RS中的安全级别的风险在于，它将有效地成为CS上的降级攻击，因为CS和RS都使用相同的密钥。
SRCs that decrypt an encrypted CS media stream and re-encrypt it when sending it to the SRS MUST use a different key than what is used for the CS media stream, to ensure that it is not possible for someone who has the key for the CS media stream to access recorded data they
对加密的CS媒体流进行解密并在将其发送到SRS时重新加密的SRC必须使用与CS媒体流不同的密钥，以确保拥有CS媒体流密钥的人无法访问他们记录的数据
are not authorized to access. In order to maintain a comparable level of security, the key used in the RS SHOULD be of equivalent strength to, or greater strength than, that used in the CS.
未被授权访问。为了保持可比的安全级别，RS中使用的密钥的强度应与CS中使用的密钥的强度相等，或大于CS中使用的密钥的强度。
Metadata contains sensitive information, such as the address of record of the participants and other extension data placed by the SRC. It is essential to protect the content of the metadata in the RS. Since metadata is a content type transmitted in SIP signaling, metadata SHOULD be protected at the transport level by SIPS/TLS.
元数据包含敏感信息，例如参与者的记录地址和SRC放置的其他扩展数据。必须保护RS中元数据的内容。由于元数据是SIP信令中传输的内容类型，因此应通过SIPS/TLS在传输级别保护元数据。
While storage and playback of the call recording are beyond the scope of this document, it is worthwhile to mention here that it is also important for the recording storage and playback to provide a level of security that is comparable to the CS. It would defeat the purpose of securing both the CS and the RS mentioned in the previous sections if the recording can be easily played back with a simple, unsecured HTTP interface without any form of authentication or authorization.
虽然呼叫记录的存储和回放不在本文档的范围内，但值得在此提及的是，记录存储和回放提供与CS相当的安全级别也很重要。如果可以使用简单、不安全的HTTP接口轻松播放录音，而无需任何形式的身份验证或授权，则无法实现前几节中提到的保护CS和RS的目的。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2506] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, DOI 10.17487/RFC2506, March 1999, <http://www.rfc-editor.org/info/rfc2506>.
[RFC2506]Holtman，K.，Mutz，A.，和T.Hardie，“媒体功能标签注册程序”，BCP 31，RFC 2506，DOI 10.17487/RFC2506，1999年3月<http://www.rfc-editor.org/info/rfc2506>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，DOI 10.17487/RFC3264，2002年6月<http://www.rfc-editor.org/info/rfc3264>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 3550，DOI 10.17487/RFC3550，2003年7月<http://www.rfc-editor.org/info/rfc3550>.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, <http://www.rfc-editor.org/info/rfc3840>.
[RFC3840]Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，DOI 10.17487/RFC3840，2004年8月<http://www.rfc-editor.org/info/rfc3840>.
[RFC4574] Levin, O. and G. Camarillo, "The Session Description Protocol (SDP) Label Attribute", RFC 4574, DOI 10.17487/RFC4574, August 2006, <http://www.rfc-editor.org/info/rfc4574>.
[RFC4574]Levin，O.和G.Camarillo，“会话描述协议（SDP）标签属性”，RFC 4574，DOI 10.17487/RFC4574，2006年8月<http://www.rfc-editor.org/info/rfc4574>.
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.，和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC7245] Hutton, A., Ed., Portman, L., Ed., Jain, R., and K. Rehor, "An Architecture for Media Recording Using the Session Initiation Protocol", RFC 7245, DOI 10.17487/RFC7245, May 2014, <http://www.rfc-editor.org/info/rfc7245>.
[RFC7245]Hutton，A.，Ed.，Portman，L.，Ed.，Jain，R.，和K.Rehor，“使用会话启动协议的媒体记录架构”，RFC 7245，DOI 10.17487/RFC72452014年5月<http://www.rfc-editor.org/info/rfc7245>.
[RFC7865] Ravindranath, R., Ravindran, P., and P. Kyzivat, "Session Initiation Protocol (SIP) Recording Metadata", RFC 7865, DOI 10.17487/RFC7865, May 2016, <http://www.rfc-editor.org/info/rfc7865>.
[RFC7865]Ravindranath，R.，Ravindran，P.，和P.Kyzivat，“会话启动协议（SIP）记录元数据”，RFC 7865，DOI 10.17487/RFC7865，2016年5月<http://www.rfc-editor.org/info/rfc7865>.
[EKT-SRTP] Mattsson, J., Ed., McGrew, D., Wing, D., and F. Andreasen, "Encrypted Key Transport for Secure RTP", Work in Progress, draft-ietf-avtcore-srtp-ekt-03, October 2014.
[EKT-SRTP]Mattsson，J.，Ed.，McGrew，D.，Wing，D.，和F.Andreasen，“安全RTP的加密密钥传输”，正在进行的工作，草稿-ietf-avtcore-SRTP-EKT-032014年10月。
[RFC2804] IAB and IESG, "IETF Policy on Wiretapping", RFC 2804, DOI 10.17487/RFC2804, May 2000, <http://www.rfc-editor.org/info/rfc2804>.
[RFC2804]IAB和IESG，“IETF关于窃听的政策”，RFC 2804，DOI 10.17487/RFC2804，2000年5月<http://www.rfc-editor.org/info/rfc2804>.
[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 2002, <http://www.rfc-editor.org/info/rfc3311>.
[RFC3311]Rosenberg，J.，“会话启动协议（SIP）更新方法”，RFC 3311，DOI 10.17487/RFC3311，2002年10月<http://www.rfc-editor.org/info/rfc3311>.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November 2002, <http://www.rfc-editor.org/info/rfc3325>.
[RFC3325]Jennings，C.，Peterson，J.，和M.Watson，“在可信网络中声明身份的会话启动协议（SIP）的专用扩展”，RFC 3325，DOI 10.17487/RFC3325，2002年11月<http://www.rfc-editor.org/info/rfc3325>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <http://www.rfc-editor.org/info/rfc3551>.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，DOI 10.17487/RFC3551，2003年7月<http://www.rfc-editor.org/info/rfc3551>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 3711，DOI 10.17487/RFC3711，2004年3月<http://www.rfc-editor.org/info/rfc3711>.
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, <http://www.rfc-editor.org/info/rfc4568>.
[RFC4568]Andreasen，F.，Baugher，M.和D.Wing，“媒体流的会话描述协议（SDP）安全描述”，RFC 4568，DOI 10.17487/RFC4568，2006年7月<http://www.rfc-editor.org/info/rfc4568>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 4585，DOI 10.17487/RFC4585，2006年7月<http://www.rfc-editor.org/info/rfc4585>.
[RFC4916] Elwell, J., "Connected Identity in the Session Initiation Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 2007, <http://www.rfc-editor.org/info/rfc4916>.
[RFC4916]Elwell，J.“会话启动协议（SIP）中的连接标识”，RFC 4916，DOI 10.17487/RFC4916，2007年6月<http://www.rfc-editor.org/info/rfc4916>.
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, <http://www.rfc-editor.org/info/rfc4961>.
[RFC4961]Wing，D，“对称RTP/RTP控制协议（RTCP）”，BCP 131，RFC 4961，DOI 10.17487/RFC49611907年7月<http://www.rfc-editor.org/info/rfc4961>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5104]Wenger，S.，Chandra，U.，Westerlund，M.，和B.Burman，“带反馈的RTP视听配置文件（AVPF）中的编解码器控制消息”，RFC 5104，DOI 10.17487/RFC5104，2008年2月<http://www.rfc-editor.org/info/rfc5104>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5124]Ott，J.和E.Carrara，“基于实时传输控制协议（RTCP）的反馈扩展安全RTP配置文件（RTP/SAVPF）”，RFC 5124DOI 10.17487/RFC5124，2008年2月<http://www.rfc-editor.org/info/rfc5124>.
[RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for Media Control", RFC 5168, DOI 10.17487/RFC5168, March 2008, <http://www.rfc-editor.org/info/rfc5168>.
[RFC5168]Levin，O.，Even，R.，和P.Hagendof，“媒体控制的XML模式”，RFC 5168，DOI 10.17487/RFC5168，2008年3月<http://www.rfc-editor.org/info/rfc5168>.
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, DOI 10.17487/RFC5630, October 2009, <http://www.rfc-editor.org/info/rfc5630>.
[RFC5630]Audet，F.“会话启动协议（SIP）中SIPS URI方案的使用”，RFC 5630，DOI 10.17487/RFC5630，2009年10月<http://www.rfc-editor.org/info/rfc5630>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <http://www.rfc-editor.org/info/rfc5761>.
[RFC5761]Perkins，C.和M.Westerlund，“在单个端口上多路复用RTP数据和控制数据包”，RFC 5761，DOI 10.17487/RFC5761，2010年4月<http://www.rfc-editor.org/info/rfc5761>.
[RFC6263] Marjou, X. and A. Sollaud, "Application Mechanism for Keeping Alive the NAT Mappings Associated with RTP / RTP Control Protocol (RTCP) Flows", RFC 6263, DOI 10.17487/RFC6263, June 2011, <http://www.rfc-editor.org/info/rfc6263>.
[RFC6263]Marjou，X.和A.Sollaud，“保持与RTP/RTP控制协议（RTCP）流相关的NAT映射活动的应用机制”，RFC 6263，DOI 10.17487/RFC6263，2011年6月<http://www.rfc-editor.org/info/rfc6263>.
[RFC6341] Rehor, K., Ed., Portman, L., Ed., Hutton, A., and R. Jain, "Use Cases and Requirements for SIP-Based Media Recording (SIPREC)", RFC 6341, DOI 10.17487/RFC6341, August 2011, <http://www.rfc-editor.org/info/rfc6341>.
[RFC6341]Rehor，K.，Ed.，Portman，L.，Ed.，Hutton，A.，和R.Jain，“基于SIP的媒体记录（SIPREC）的用例和要求”，RFC 6341，DOI 10.17487/RFC6341，2011年8月<http://www.rfc-editor.org/info/rfc6341>.
[RFC7022] Begen, A., Perkins, C., Wing, D., and E. Rescorla, "Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)", RFC 7022, DOI 10.17487/RFC7022, September 2013, <http://www.rfc-editor.org/info/rfc7022>.
[RFC7022]Begen，A.，Perkins，C.，Wing，D.，和E.Rescorla，“选择RTP控制协议（RTCP）规范名称（CNAMEs）的指南”，RFC 7022，DOI 10.17487/RFC7022，2013年9月<http://www.rfc-editor.org/info/rfc7022>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525]Sheffer，Y.，Holz，R.，和P.Saint Andre，“安全使用传输层安全性（TLS）和数据报传输层安全性（DTLS）的建议”，BCP 195，RFC 7525，DOI 10.17487/RFC7525，2015年5月<http://www.rfc-editor.org/info/rfc7525>.
Acknowledgements
致谢
We want to thank John Elwell, Paul Kyzivat, Partharsarathi R, Ram Mohan R, Hadriel Kaplan, Adam Roach, Miguel Garcia, Thomas Stach, Muthu Perumal, Dan Wing, and Magnus Westerlund for their valuable comments and inputs to this document.
我们要感谢John Elwell、Paul Kyzivat、Partharsarathi R、Ram Mohan R、Hadriel Kaplan、Adam Roach、Miguel Garcia、Thomas Stach、Muthu Perumal、Dan Wing和Magnus Westerlund对本文件的宝贵意见和投入。
Authors' Addresses
作者地址
Leon Portman NICE Systems 22 Zarhin Street P.O. Box 690 Ra'anana 4310602 Israel
Leon Portman NICE Systems以色列Ra'anana 4310602 Zarhin街22号邮政信箱690号
Email: leon.portman@gmail.com
Email: leon.portman@gmail.com
Henry Lum (editor) Genesys 1380 Rodick Road, Suite 201 Markham, Ontario L3R4G5 Canada
Henry Lum（编辑）Genesys加拿大安大略省马卡姆市罗迪克路1380号201室L3R4G5
Email: henry.lum@genesyslab.com
Email: henry.lum@genesyslab.com
Charles Eckel Cisco 170 West Tasman Drive San Jose, CA 95134 United States
美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
Email: eckelcu@cisco.com
Email: eckelcu@cisco.com
Alan Johnston Illinois Institute of Technology Bellevue, WA United States
艾伦·约翰斯顿伊利诺伊理工学院，华盛顿州，美国
Email: alan.b.johnston@gmail.com
Email: alan.b.johnston@gmail.com
Andrew Hutton Unify Brickhill Street Milton Keynes MK15 0DJ United Kingdom
Andrew Hutton Unified Brickhill Street Milton Keynes MK15 0DJ英国
Email: andrew.hutton@unify.com
Email: andrew.hutton@unify.com