Internet Engineering Task Force (IETF) R. Ravindranath
Request for Comments: 7865 Cisco Systems
Category: Standards Track P. Ravindran
ISSN: 2070-1721 Nokia Networks
P. Kyzivat
Huawei
May 2016
Internet Engineering Task Force (IETF) R. Ravindranath
Request for Comments: 7865 Cisco Systems
Category: Standards Track P. Ravindran
ISSN: 2070-1721 Nokia Networks
P. Kyzivat
Huawei
May 2016
Session Initiation Protocol (SIP) Recording Metadata
会话启动协议（SIP）记录元数据
Abstract
摘要
Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document describes the metadata model as viewed by the Session Recording Server (SRS) and the recording metadata format.
会话记录是许多通信环境中的一项关键要求，例如呼叫中心和金融交易组织。在其中一些环境中，出于监管、法规遵从性和消费者保护的原因，必须记录所有呼叫。会话的记录通常通过向记录设备发送媒体流的副本来执行。本文档描述了会话记录服务器（SRS）查看的元数据模型和记录元数据格式。
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/rfc7865.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7865.
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 ....................................................3
2. Terminology .....................................................3
3. Definitions .....................................................4
4. Metadata Model ..................................................5
5. Recording Metadata Format from SRC to SRS .......................6
5.1. XML Data Format ............................................7
5.1.1. Namespace ...........................................7
5.1.2. 'recording' Element .................................7
6. Recording Metadata Classes ......................................7
6.1. Recording Session ..........................................8
6.1.1. Attributes ..........................................8
6.1.2. Linkages ............................................9
6.2. Communication Session Group ................................9
6.2.1. Attributes .........................................10
6.2.2. Linkages ...........................................10
6.3. Communication Session .....................................11
6.3.1. Attributes .........................................11
6.3.2. Linkages ...........................................12
6.4. CS-RS Association .........................................13
6.4.1. Attributes .........................................14
6.4.2. Linkages ...........................................14
6.5. Participant ...............................................14
6.5.1. Attributes .........................................15
6.5.2. Linkages ...........................................15
6.6. Participant-CS Association ................................16
6.6.1. Attributes .........................................17
6.6.2. Linkages ...........................................17
6.7. Media Stream ..............................................18
6.7.1. Attributes .........................................18
6.7.2. Linkages ...........................................19
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Definitions .....................................................4
4. Metadata Model ..................................................5
5. Recording Metadata Format from SRC to SRS .......................6
5.1. XML Data Format ............................................7
5.1.1. Namespace ...........................................7
5.1.2. 'recording' Element .................................7
6. Recording Metadata Classes ......................................7
6.1. Recording Session ..........................................8
6.1.1. Attributes ..........................................8
6.1.2. Linkages ............................................9
6.2. Communication Session Group ................................9
6.2.1. Attributes .........................................10
6.2.2. Linkages ...........................................10
6.3. Communication Session .....................................11
6.3.1. Attributes .........................................11
6.3.2. Linkages ...........................................12
6.4. CS-RS Association .........................................13
6.4.1. Attributes .........................................14
6.4.2. Linkages ...........................................14
6.5. Participant ...............................................14
6.5.1. Attributes .........................................15
6.5.2. Linkages ...........................................15
6.6. Participant-CS Association ................................16
6.6.1. Attributes .........................................17
6.6.2. Linkages ...........................................17
6.7. Media Stream ..............................................18
6.7.1. Attributes .........................................18
6.7.2. Linkages ...........................................19
6.8. Participant-Stream Association ............................19
6.8.1. Attributes .........................................20
6.8.2. Linkages ...........................................20
6.9. Syntax of XML Elements for Date and Time ..................21
6.10. Format of Unique ID ......................................21
6.11. Metadata Version Indicator ...............................21
7. Recording Metadata Snapshot Request Format .....................22
8. SIP Recording Metadata Examples ................................23
8.1. Complete SIP Recording Metadata Example ...................23
8.2. Partial Update of Recording Metadata XML Body .............25
9. XML Schema Definition for Recording Metadata ...................26
10. Security Considerations .......................................30
11. IANA Considerations ...........................................31
11.1. SIP Recording Metadata Schema Registration ...............31
12. References ....................................................31
12.1. Normative References .....................................31
12.2. Informative References ...................................32
Acknowledgements ..................................................34
Authors' Addresses ................................................34
6.8. Participant-Stream Association ............................19
6.8.1. Attributes .........................................20
6.8.2. Linkages ...........................................20
6.9. Syntax of XML Elements for Date and Time ..................21
6.10. Format of Unique ID ......................................21
6.11. Metadata Version Indicator ...............................21
7. Recording Metadata Snapshot Request Format .....................22
8. SIP Recording Metadata Examples ................................23
8.1. Complete SIP Recording Metadata Example ...................23
8.2. Partial Update of Recording Metadata XML Body .............25
9. XML Schema Definition for Recording Metadata ...................26
10. Security Considerations .......................................30
11. IANA Considerations ...........................................31
11.1. SIP Recording Metadata Schema Registration ...............31
12. References ....................................................31
12.1. Normative References .....................................31
12.2. Informative References ...................................32
Acknowledgements ..................................................34
Authors' Addresses ................................................34
Session recording is a critical requirement in many communications environments, such as call centers and financial trading organizations. In some of these environments, all calls must be recorded for regulatory, compliance, and consumer protection reasons. The recording of a session is typically performed by sending a copy of a media stream to a recording device. This document focuses on the recording metadata, which describes the Communication Session (CS). The document describes a metadata model as viewed by the Session Recording Server (SRS) and the recording metadata format, the requirements for which are described in [RFC6341] and the architecture for which is described in [RFC7245].
会话记录是许多通信环境中的一项关键要求，例如呼叫中心和金融交易组织。在其中一些环境中，出于监管、法规遵从性和消费者保护的原因，必须记录所有呼叫。会话的记录通常通过向记录设备发送媒体流的副本来执行。本文档重点介绍记录元数据，它描述了通信会话（CS）。本文档描述了会话记录服务器（SRS）查看的元数据模型和记录元数据格式，其要求见[RFC6341]，体系结构见[RFC7245]。
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]. This document only uses these key words when referencing normative statements in existing RFCs.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。本文件仅在引用现有RFC中的规范性声明时使用这些关键词。
Metadata model: A metadata model is an abstract representation of metadata using a Unified Modeling Language (UML) [UML] class diagram.
元数据模型：元数据模型是使用统一建模语言（UML）[UML]类图对元数据的抽象表示。
Metadata classes: Each block in the model represents a class. A class is a construct that is used as a blueprint to create instances (called "objects") of itself. The description of each class also has a representation of its attributes in a second compartment below the class name.
元数据类：模型中的每个块表示一个类。类是一种构造，用作创建自身实例（称为“对象”）的蓝图。每个类的描述在类名下面的第二个隔间中也有其属性的表示。
Attributes: Attributes represent the elements listed in each of the classes. The attributes of a class are listed in the second compartment below the class name. Each instance of a class conveys values for the attributes of that class. These values get added to the recording's metadata.
属性：属性表示每个类中列出的元素。类的属性列在类名下面的第二个隔间中。类的每个实例都传递该类属性的值。这些值将添加到录制的元数据中。
Linkages: Linkages represent the relationship between the classes in the model. Each linkage represents a logical connection between classes (or objects) in class diagrams (or object diagrams). The linkages used in the metadata model of this document are associations.
链接：链接表示模型中类之间的关系。每个链接表示类图（或对象图）中类（或对象）之间的逻辑连接。本文档元数据模型中使用的链接是关联。
This document also refers to the terminology defined in [RFC6341].
本文件还引用了[RFC6341]中定义的术语。
Metadata is the information that describes recorded media and the CS to which they relate. The diagram below shows a model for metadata as viewed by an SRS.
元数据是描述记录的媒体及其相关的CS的信息。下图显示了SRS查看的元数据模型。
+-------------------------------+ 1..*
| Recording Session (RS) |----+
+-------------------------------+ |
| 1..* | 1..* |
| | |
| | 0..* |
| +-----------------+ |
+------------+ | | Communication | |
| CS-RS | | | Session Group | |
| Association|--+ | (CS-Group) | |
| | | +-----------------+ |
+------------+ | | 0..1 |
| | |
| 0..* | 1..* |
+-------------------------------+ |
| Communication Session (CS) | |
| | |
+-------------------------------+ |
| 1..* | 0..1 |
+-----+ | |
| | 0..* | 0..* | 0..*
| +-------------+ receives +----------------+ |
| | Participant |----------| Media Stream |--+
| | |0..* 0..*| |
| | | | |
| | | | |
| | | sends | |
| | |----------| |
| | |1.* 0..*| |
| +-------------+ +----------------+
| | |
| | |
| +------------------------+------------+
| |
| |
| +------------------+ +----------------------+
| |Participant-CS | | Participant-Stream |
+-----------| Association | | Association |
| | | |
+------------------+ +----------------------+
+-------------------------------+ 1..*
| Recording Session (RS) |----+
+-------------------------------+ |
| 1..* | 1..* |
| | |
| | 0..* |
| +-----------------+ |
+------------+ | | Communication | |
| CS-RS | | | Session Group | |
| Association|--+ | (CS-Group) | |
| | | +-----------------+ |
+------------+ | | 0..1 |
| | |
| 0..* | 1..* |
+-------------------------------+ |
| Communication Session (CS) | |
| | |
+-------------------------------+ |
| 1..* | 0..1 |
+-----+ | |
| | 0..* | 0..* | 0..*
| +-------------+ receives +----------------+ |
| | Participant |----------| Media Stream |--+
| | |0..* 0..*| |
| | | | |
| | | | |
| | | sends | |
| | |----------| |
| | |1.* 0..*| |
| +-------------+ +----------------+
| | |
| | |
| +------------------------+------------+
| |
| |
| +------------------+ +----------------------+
| |Participant-CS | | Participant-Stream |
+-----------| Association | | Association |
| | | |
+------------------+ +----------------------+
The metadata model is a class diagram in UML. The model describes the structure of metadata in general by showing the classes, their attributes, and the relationships among the classes. Each block in the model above represents a class. The linkages between the classes represent the relationships, which can be associations or compositions. The metadata is conveyed from the Session Recording Client (SRC) to the SRS.
元数据模型是UML中的类图。该模型通过显示类、它们的属性以及类之间的关系来描述元数据的一般结构。上面模型中的每个块表示一个类。类之间的链接表示关系，可以是关联或组合。元数据从会话记录客户端（SRC）传输到SRS。
The model allows metadata describing CSs to be communicated to the SRS as a series of snapshots, each representing the state as seen by a single SRC at a particular instant in time. Metadata changes from one snapshot to another reflect changes in what is being recorded. For example, if a participant joins a conference, then the SRC sends the SRS a snapshot of metadata having that participant information (with attributes like (Name, AoR) tuple and associate-time). (Note: "AoR" means "Address-of-Record".)
该模型允许将描述CSs的元数据作为一系列快照传递给SRS，每个快照表示单个SRC在特定时刻看到的状态。从一个快照到另一个快照的元数据更改反映了所记录内容的更改。例如，如果参与者加入会议，则SRC向SRS发送具有该参与者信息的元数据快照（具有（名称、AoR）元组和关联时间等属性）。（注：“AoR”指“记录地址”。）
Some of the metadata is not required to be conveyed explicitly from the SRC to the SRS, if it can be obtained contextually by the SRS (e.g., from SIP or Session Description Protocol (SDP) signaling). For example, the 'label' attribute within the 'stream' XML element references an SDP "a=label" attribute that identifies an m-line within the Recording Session (RS) SDP. The SRS would learn the media properties from the media line.
如果可以通过SRS（例如，从SIP或会话描述协议（SDP）信令）上下文获得，则不需要将一些元数据从SRC显式地传送到SRS。例如，“stream”XML元素中的“label”属性引用一个SDP“a=label”属性，该属性标识录制会话（RS）SDP中的m线。SRS将从媒体线路学习媒体属性。
This section gives an overview of the recording metadata format. Some data from the metadata model is assumed to be made available to the SRS through SDP [RFC4566], and therefore this data is not represented in the XML document format specified in this document. SDP attributes describe different media formats like audio and video. The other metadata attributes, such as participant details, are represented in a new recording-specific XML document of type 'application/rs-metadata+xml'. The SDP "label" attribute [RFC4574] provides an identifier by which a metadata XML document can refer to a specific media description in the SDP sent from the SRC to the SRS.
本节概述了录制元数据格式。假设来自元数据模型的一些数据通过SDP[RFC4566]提供给SRS，因此该数据不以本文档中指定的XML文档格式表示。SDP属性描述不同的媒体格式，如音频和视频。其他元数据属性（如参与者详细信息）在类型为“application/rs metadata+XML”的新记录特定XML文档中表示。SDP“label”属性[RFC4574]提供了一个标识符，元数据XML文档可以通过该标识符引用从SRC发送到SRS的SDP中的特定媒体描述。
The XML document format can be used to represent either the complete metadata or a partial update to the metadata. The latter includes only elements that have changed compared to the previously reported metadata.
XML文档格式可用于表示元数据的完整或部分更新。后者仅包括与先前报告的元数据相比已更改的元素。
Every recording metadata XML document sent from the SRC to the SRS contains a 'recording' element. The 'recording' element acts as a container for all other elements in this XML document. A 'recording' object is an XML document. It has the XML declaration and contains an encoding declaration in the XML declaration, e.g., "<?xml version="1.0" encoding="UTF-8"?>". If the charset parameter of the MIME content type declaration is present and it is different from the encoding declaration, the charset parameter takes precedence.
从SRC发送到SRS的每个录制元数据XML文档都包含一个“录制”元素。“recording”元素充当此XML文档中所有其他元素的容器。“录制”对象是XML文档。它具有XML声明，并在XML声明中包含编码声明，例如“<？XML version=“1.0”encoding=“UTF-8”>”。如果MIME内容类型声明的charset参数存在并且与编码声明不同，则charset参数优先。
Every application conforming to this specification MUST accept the UTF-8 character encoding to ensure minimal interoperability.
符合本规范的每个应用程序都必须接受UTF-8字符编码，以确保最小的互操作性。
Syntax and semantic errors in an XML document should be reported to the originator, using application-specific mechanisms.
XML文档中的语法和语义错误应使用特定于应用程序的机制报告给发起人。
With the following URN, this document defines a new namespace URI for elements defined herein:
通过以下URN，本文档为此处定义的元素定义了一个新的名称空间URI：
urn:ietf:params:xml:ns:recording:1
urn:ietf:params:xml:ns:recording:1
The 'recording' element MUST contain an xmlns namespace attribute with a value of urn:ietf:params:xml:ns:recording:1. Exactly one 'recording' element MUST be present in every recording metadata XML document.
“recording”元素必须包含值为urn:ietf:params:xml:ns:recording:1的xmlns命名空间属性。每个录制元数据XML文档中必须正好有一个“录制”元素。
A 'recording' element MAY contain a 'dataMode' element indicating whether the XML document is a complete document or a partial update. If no 'dataMode' element is present, then the default value is "complete".
“recording”元素可能包含一个“dataMode”元素，指示XML文档是完整文档还是部分更新。如果不存在“dataMode”元素，则默认值为“complete”。
This section describes each class of the metadata model and the attributes of each class. This section also describes how different classes are linked and the XML element for each of them.
本节描述元数据模型的每个类以及每个类的属性。本节还描述了不同类的链接方式以及每个类的XML元素。
+-------------------------------+
| Recording Session (RS) |
+-------------------------------+
| | 1..* 0..*
| start-time |-------------- Media Stream
| end-time |
| |
| |
+-------------------------------+
| 1..* | 1..*
| |
| 0..* | 0..*
Communication Communication
Session (CS) Session Group (CS-Group)
+-------------------------------+
| Recording Session (RS) |
+-------------------------------+
| | 1..* 0..*
| start-time |-------------- Media Stream
| end-time |
| |
| |
+-------------------------------+
| 1..* | 1..*
| |
| 0..* | 0..*
Communication Communication
Session (CS) Session Group (CS-Group)
Each instance of an RS class, namely the RS object, represents a SIP session created between an SRC and SRS for the purpose of recording a CS.
RS类的每个实例，即RS对象，表示为记录CS而在SRC和SRS之间创建的SIP会话。
The RS object is represented in the XML schema using the 'recording' element, which in turn relies on the SIP/SDP session with which the XML document is associated to provide the attributes of the RS element.
RS对象在XML模式中使用“recording”元素表示，而“recording”元素又依赖与XML文档关联的SIP/SDP会话来提供RS元素的属性。
An RS class has the following attributes:
RS类具有以下属性：
o start-time - Represents the start time of an RS object.
o 开始时间-表示RS对象的开始时间。
o end-time - Represents the end time of an RS object.
o 结束时间-表示RS对象的结束时间。
'start-time' and 'end-time' attribute values are derivable from the Date header (if present in the SIP message) in the RS. In cases where the Date header is not present, 'start-time' is derivable from the time at which the SRS receives the notification of the SIP message to set up the RS, and 'end-time' is derivable from the time at which the SRS receives a disconnect on the RS SIP dialog.
“开始时间”和“结束时间”属性值可从RS中的日期标头（如果SIP消息中存在）派生。在日期标头不存在的情况下，“开始时间”可从SRS接收到SIP消息通知以设置RS的时间派生，并且“结束时间”可从SRS在RS SIP对话框上接收到断开连接的时间派生。
Each instance of an RS has:
RS的每个实例都有：
o Zero or more instances of CS-Groups.
o CS组的零个或多个实例。
o Zero or more instances of CS objects.
o CS对象的零个或多个实例。
o Zero or more instances of MediaStream objects.
o 零个或多个MediaStream对象实例。
Zero instances of CSs and CS-Groups in a 'recording' element are allowed to accommodate persistent recording scenarios. A persistent RS is a SIP dialog that is set up between the SRC and the SRS, even before any CS is set up. The metadata sent from the SRC to the SRS when the persistent RS SIP dialog is set up may not have any CS (and the related CS-Group) elements in the XML, as there may not be a session that is associated to the RS yet. For example, a phone acting as an SRC can set up an RS with the SRS, possibly even before the phone is part of a CS. Once the phone joins a CS, the same RS would be used to convey the CS metadata.
“录制”元素中的CSs和CS组的零实例可以容纳持久录制场景。持久RS是在SRC和SRS之间建立的SIP对话，甚至在建立任何CS之前。当设置持久RS SIP对话框时，从SRC发送到SRS的元数据在XML中可能没有任何CS（和相关CS组）元素，因为可能还没有与RS关联的会话。例如，充当SRC的电话可以使用SRS设置RS，甚至可能在电话成为CS的一部分之前。一旦手机加入了CS，同样的RS将用于传输CS元数据。
Recording Session (RS)
| 1..*
|
| 0..*
+-------------------------------+
| Communication Session |
| Group (CS-Group) |
+-------------------------------+
| group_id |
| associate-time |
| disassociate-time |
| |
+-------------------------------+
| 0..1
|
| 1..*
Communication Session (CS)
Recording Session (RS)
| 1..*
|
| 0..*
+-------------------------------+
| Communication Session |
| Group (CS-Group) |
+-------------------------------+
| group_id |
| associate-time |
| disassociate-time |
| |
+-------------------------------+
| 0..1
|
| 1..*
Communication Session (CS)
One instance of a CS-Group class, namely the CS-Group object, provides association or grouping of all related CSs. For example, in a contact center flow, a call can get transferred to multiple agents. Each of these can trigger the setup of a new CS. In cases where the SRC knows the related CSs, it can group them using the CS-Group element. The CS-Group object is represented in the XML schema using the 'group' element.
CS组类的一个实例，即CS组对象，提供所有相关CSs的关联或分组。例如，在呼叫中心流程中，一个呼叫可以转移到多个代理。每一个都可以触发新CS的设置。在SRC知道相关CSs的情况下，它可以使用CS group元素对它们进行分组。CS组对象在XML模式中使用“Group”元素表示。
A CS-Group has the following attributes:
CS组具有以下属性：
o group_id - This attribute groups different CSs that are related. The SRC (or the SRS) is responsible for ensuring the uniqueness of 'group_id' in cases where multiple SRCs interact with the same SRS. The mechanism by which the SRC groups the CS is outside the scope of this document.
o group_id-此属性将相关的不同CSs分组。当多个SRC与同一SRS交互时，SRC（或SRS）负责确保“group_id”的唯一性。SRC对CS进行分组的机制不在本文件范围内。
o associate-time - This is the time when a grouping is formed. The rules that determine how a grouping of different CS objects is done by the SRC are outside the scope of this document.
o 关联时间-这是形成分组的时间。决定SRC如何对不同CS对象进行分组的规则不在本文档范围内。
o disassociate-time - 'disassociate-time' for the CS-Group is calculated by the SRC as the time when the grouping ends.
o 解除关联时间-由SRC计算CS组的“解除关联时间”作为分组结束的时间。
The linkages between a CS-Group class and other classes are associations. A CS-Group is associated with the RS and CS in the following manner:
CS组类和其他类之间的联系是关联。CS组以以下方式与RS和CS关联：
o There are one or more RS objects per CS-Group.
o 每个CS组有一个或多个RS对象。
o Each CS-Group object has to be associated with one or more RSs. Here, each RS can be set up by the potentially different SRCs.
o 每个CS组对象必须与一个或多个RSs关联。在这里，每个RS可以由可能不同的SRC设置。
o There are one or more CSs per CS-Group (for example, in cases where the call is transferred). A CS cannot be associated with more than one CS-Group.
o 每个CS组有一个或多个CSs（例如，在呼叫转移的情况下）。CS不能与多个CS组关联。
Recording Communication
Session (RS) Session Group (CS-Group)
| 1..* | 0..1
| |
| 0..* | 1..*
+-------------------------------+
| Communication Session (CS) |
+-------------------------------+
| session_id |
| sipSessionID |
| reason |
| group-ref |
| start-time |
| stop-time |
+-------------------------------+
| |
| 0..* | 0..1
| |
| 0..* | 0..*
Participant Media Stream
Recording Communication
Session (RS) Session Group (CS-Group)
| 1..* | 0..1
| |
| 0..* | 1..*
+-------------------------------+
| Communication Session (CS) |
+-------------------------------+
| session_id |
| sipSessionID |
| reason |
| group-ref |
| start-time |
| stop-time |
+-------------------------------+
| |
| 0..* | 0..1
| |
| 0..* | 0..*
Participant Media Stream
A CS class and its object in the metadata model represent the CS and its properties as seen by the SRC. The CS object is represented in the XML schema using the 'session' element.
元数据模型中的CS类及其对象表示SRC看到的CS及其属性。CS对象在XML模式中使用“session”元素表示。
A CS class has the following attributes:
CS类具有以下属性：
o session_id - This attribute is used to uniquely identify an instance of a CS object, namely the 'session' XML element within the metadata XML document. 'session_id' is generated using the rules mentioned in Section 6.10.
o session_id-此属性用于唯一标识CS对象的实例，即元数据XML文档中的“session”XML元素会话_id’是使用第6.10节中提到的规则生成的。
o reason - This represents the reason why a CS was terminated. The value for this attribute is derived from the SIP Reason header [RFC3326] of the CS. There MAY be multiple instances of the 'reason' XML element inside a 'session' element. The 'reason' XML element has 'protocol' as an attribute, which indicates the protocol from which the reason string is derived. The default value for the 'protocol' attribute is "SIP". The 'reason' element can be derived from a SIP Reason header in the CS.
o 原因-这表示CS终止的原因。此属性的值源自CS的SIP原因头[RFC3326]。“session”元素中可能有多个“reason”XML元素实例。“reason”XML元素将“protocol”作为属性，它指示从中派生原因字符串的协议。“协议”属性的默认值为“SIP”。“reason”元素可以从CS中的SIP reason头派生。
o sipSessionID - This attribute carries a SIP Session-ID as defined in [SessionID]. Each CS object can have zero or more 'sipSessionID' elements. More than one 'sipSessionID' attribute may be present in a CS. For example, if three participants -- A, B, and C -- are in a conference that has a focus acting as an SRC, the metadata sent from the SRC to the SRS will likely have three 'sipSessionID' elements that correspond to the SIP dialogs that the focus has with each of the three participants.
o sipSessionID-此属性包含[SessionID]中定义的SIP会话ID。每个CS对象可以有零个或多个“sipSessionID”元素。CS中可能存在多个“sipSessionID”属性。例如，如果三个参与者（A、B和C）在一个焦点充当SRC的会议中，则从SRC发送到SRS的元数据可能有三个“sipSessionID”元素，它们对应于焦点与三个参与者中的每一个的SIP对话。
o group-ref - A 'group-ref' attribute MAY be present to indicate the group (identified by 'group_id') to which the enclosing session belongs.
o group ref-可能存在“group ref”属性，以指示封闭会话所属的组（由“group_id”标识）。
o start-time - This optional attribute represents the start time of the CS as seen by the SRC.
o 开始时间-此可选属性表示SRC看到的CS的开始时间。
o stop-time - This optional attribute represents the stop time of the CS as seen by the SRC.
o 停止时间-此可选属性表示SRC看到的CS的停止时间。
This document does not specify attributes relating to what should happen to a recording of a CS after it has been delivered to the SRS (e.g., how long to retain the recording, what access controls to apply). The SRS is assumed to behave in accordance with its local policy. The ability of the SRC to influence this policy is outside the scope of this document. However, if there are implementations where the SRC desires to specify its own policy preferences, this information could be sent as extension data attached to the CS.
本文件未规定CS记录在交付给SRS后应如何处理的相关属性（例如，记录保留多长时间，应用何种访问控制）。假定SRS的行为符合其本地政策。SRC影响本政策的能力不在本文件范围内。但是，如果存在SRC希望指定其自己的策略首选项的实现，则该信息可以作为附加到CS的扩展数据发送。
A CS is linked to the CS-Group, participant, MediaStream (MS), and RS classes by using the association relationship. The association between the CS and the participant allows the following:
CS通过使用关联关系链接到CS组、参与者、MediaStream（MS）和RS类。CS和参与者之间的关联允许以下情况：
o A CS will have zero or more participants.
o CS将有零个或多个参与者。
o A participant is associated with zero or more CSs. This includes participants who are not directly part of any CS. An example of such a case is participants in a pre-mixed media stream. The SRC may have knowledge of such participants but not have any signaling relationship with them. This might arise if one participant in a CS is a conference focus. To summarize, even if the SRC does not have direct signaling relationships with all participants in a CS, it should nevertheless create a participant object for each participant that it knows about.
o 参与者与零个或多个CSs关联。这包括不直接参与任何CS的参与者。这种情况的一个例子是预混合媒体流中的参与者。SRC可能了解此类参与者，但与他们没有任何信号关系。如果CS中的一名参与者是会议焦点，则可能会出现这种情况。总之，即使SRC与CS中的所有参与者没有直接的信令关系，它也应该为它所知道的每个参与者创建一个参与者对象。
o The model also allows participants in a CS that are not participants in the media. An example is the identity of a Third Party Call Control (3pcc) that has initiated a CS to two or more participants in the CS. Another example is the identity of a conference focus. Of course, a focus is probably in the media, but since it may only be there as a mixer, it may not report itself as a participant in any of the media streams.
o 该模型还允许CS中的参与者不是媒体参与者。一个例子是第三方呼叫控制（3pcc）的身份，该第三方呼叫控制已向CS中的两个或多个参与者发起CS。另一个例子是会议焦点的标识。当然，焦点可能在媒体中，但因为它可能只是作为混合器存在，所以它可能不会报告自己是任何媒体流中的参与者。
The association between the CS and the media stream allows the following:
CS和媒体流之间的关联允许以下情况：
o A CS will have zero or more streams.
o CS将具有零个或多个流。
o A stream can be associated with at most one CS. A stream in a persistent RS is not required to be associated with any CS before the CS is created, and hence the zero association is allowed.
o 一个流最多可以与一个CS相关联。在创建CS之前，持久RS中的流不需要与任何CS关联，因此允许零关联。
The association between the CS and the RS allows the following:
CS和RS之间的关联允许以下情况：
o Each instance of an RS has zero or more instances of CS objects.
o RS的每个实例都有零个或多个CS对象实例。
o Each CS has to be associated with one or more RSs. Each RS can be potentially set up by different SRCs.
o 每个CS必须与一个或多个RSs相关联。每个RS可能由不同的SRC设置。
1..* 0..*
Recording Communication
Session ----------+---------- Session
|
|
|
+-----------------------+
| CS-RS Association |
| |
+-----------------------+
| associate-time |
| disassociate-time |
| session_id |
+-----------------------+
1..* 0..*
Recording Communication
Session ----------+---------- Session
|
|
|
+-----------------------+
| CS-RS Association |
| |
+-----------------------+
| associate-time |
| disassociate-time |
| session_id |
+-----------------------+
The CS-RS Association class describes the association of a CS to an RS for a period of time. A single CS may be associated with different RSs (perhaps by different SRCs) and may be associated and dissociated several times.
CS-RS关联类描述一段时间内CS与RS的关联。单个CS可能与不同的RSs（可能由不同的SRC）关联，并且可能关联和分离多次。
The CS-RS Association class is represented in XML using the 'sessionrecordingassoc' XML element.
CS-RS关联类使用“sessionrecordingassoc”XML元素以XML表示。
The CS-RS Association class has the following attributes:
CS-RS关联类具有以下属性：
o associate-time - associate-time is calculated by the SRC as the time it sees a CS associated to an RS.
o 关联时间-关联时间由SRC计算为它看到与RS关联的CS的时间。
o disassociate-time - disassociate-time is calculated by the SRC as the time it sees a CS disassociate from an RS.
o 解除关联时间-解除关联时间由SRC计算为它看到CS与RS解除关联的时间。
o session_id - Each instance of this class MUST have a 'session_id' attribute that identifies the CS to which this association belongs.
o session_id-此类的每个实例都必须具有“session_id”属性，该属性标识此关联所属的CS。
The CS-RS Association class is linked to the CS and RS classes.
CS-RS关联类链接到CS和RS类。
Communication Session (CS)
| 0..*
|
| 0..*
+-------------------------------+
| Participant |
+-------------------------------+
| nameID |
| participant_id |
| |
+-------------------------------+
| 0..* 1..* |
receives| |sends
| 0..* 0..* |
Media Stream
Communication Session (CS)
| 0..*
|
| 0..*
+-------------------------------+
| Participant |
+-------------------------------+
| nameID |
| participant_id |
| |
+-------------------------------+
| 0..* 1..* |
receives| |sends
| 0..* 0..* |
Media Stream
A participant class and its objects have information about a device that is part of a CS and/or contributes/consumes media stream(s) belonging to a CS.
参与者类及其对象具有关于作为CS的一部分和/或贡献/使用属于CS的媒体流的设备的信息。
The participant object is represented in the XML schema using the 'participant' element.
参与者对象在XML模式中使用“参与者”元素表示。
A participant class has two attributes:
参与者类有两个属性：
o nameID - This attribute is a list of (Name, AoR) tuples. An AoR (Section 6 of [RFC3261]) can be either a SIP/SIPS/tel URI ("SIPS" means "SIP Secure"; the tel URI is discussed in [RFC3966]), a Fully Qualified Domain Name (FQDN), or an IP address. For example, the AoR may be drawn from the From header field or the P-Asserted-Identity header [RFC3325] field. The SRC's local policy is used to decide where to draw the AoR from. The Name parameter represents the participant name (SIP display name) or dialed number (when known). Multiple tuples are allowed for cases where a participant has more than one AoR. For example, a P-Asserted-Identity header can have both SIP and tel URIs.
o nameID-此属性是（Name，AoR）元组的列表。AoR（RFC3261第6节）可以是SIP/SIPS/tel URI（“SIPS”表示“SIP安全”；tel URI在[RFC3966]中讨论）、完全限定域名（FQDN）或IP地址。例如，AoR可以从from报头字段或P-Asserted-Identity报头[RFC3325]字段中提取。SRC的本地策略用于决定从何处提取AoR。Name参数表示参与者名称（SIP显示名称）或拨号号码（已知时）。对于参与者具有多个AoR的情况，允许使用多个元组。例如，P-Asserted-Identity报头可以同时具有SIP和tel URI。
o participant_id - This attribute is used to identify the 'participant' XML element within the XML document. It is generated using the rules mentioned in Section 6.10. This attribute MUST be used for all references to a participant within a CS-Group, and MAY be used to reference the same participant more globally.
o 参与者id-此属性用于标识XML文档中的“参与者”XML元素。它是使用第6.10节中提到的规则生成的。此属性必须用于CS组中对参与者的所有引用，并且可以用于更全局地引用同一参与者。
This document does not specify other attributes relating to participants (e.g., participant role, participant type). An SRC that has information regarding these attributes can provide this information as part of extension data to the 'participant' XML element from the SRC to the SRS.
本文档未指定与参与者相关的其他属性（例如，参与者角色、参与者类型）。具有这些属性相关信息的SRC可以将这些信息作为扩展数据的一部分从SRC提供给SRS的“participant”XML元素。
The participant class is linked to the MS and CS classes by using an association relationship. The association between the participant and the MS allows the following:
参与者类通过关联关系链接到MS和CS类。参与者与MS之间的关联允许以下情况：
o A participant will receive zero or more media streams.
o 参与者将收到零个或多个媒体流。
o A participant will send zero or more media streams. (The same participant provides multiple streams, e.g., audio and video.)
o 参与者将发送零个或多个媒体流。（同一参与者提供多个流，例如音频和视频。）
o A media stream will be received by zero or more participants. It is possible, though perhaps unlikely, that a stream is generated but sent only to the SRC and SRS, not to any participant -- for example, in conferencing where all participants are on hold and the SRC is collocated with the focus. Also, a media stream may be received by multiple participants (e.g., "whisper" calls, side conversations).
o 媒体流将由零个或多个参与者接收。有可能（尽管可能不太可能）生成流，但只发送给SRC和SRS，而不发送给任何参与者——例如，在所有参与者都处于等待状态且SRC与焦点并置的会议中。此外，媒体流可由多个参与者接收（例如，“耳语”呼叫、旁白对话）。
o A media stream will be sent by one or more participants (pre-mixed streams).
o 媒体流将由一个或多个参与者发送（预混合流）。
An example of a case where a participant receives zero or more streams is where a supervisor may have a side conversation with an agent while the agent converses with a customer.
参与者接收到零个或多个流的情况的一个示例是，当代理与客户交谈时，主管可能与代理进行旁白。
1..* 0..*
Communication
Session -----------+----------- Participant
|
|
|
+---------------------------+
| Participant-CS Association|
| |
| |
+---------------------------+
| associate-time |
| disassociate-time |
| param |
| participant_id |
| session_id |
+---------------------------+
1..* 0..*
Communication
Session -----------+----------- Participant
|
|
|
+---------------------------+
| Participant-CS Association|
| |
| |
+---------------------------+
| associate-time |
| disassociate-time |
| param |
| participant_id |
| session_id |
+---------------------------+
The Participant-CS Association class describes the association of a participant to a CS for a period of time. A participant may be associated to and dissociated from a CS several times (for example, connecting to a conference, then disconnecting, then connecting again).
Participant CS Association类描述一段时间内参与者与CS的关联。参与者可能会多次与CS关联或分离（例如，连接到会议，然后断开连接，然后再次连接）。
The Participant-CS Association object is represented in the XML schema using the 'participantsessionassoc' element.
参与者CS关联对象在XML模式中使用“participantsessionassoc”元素表示。
The Participant-CS Association class has the following attributes:
参与者CS关联类具有以下属性：
o associate-time - associate-time is calculated by the SRC as the time it sees a participant associated to a CS.
o 关联时间-关联时间由SRC计算为它看到与CS关联的参与者的时间。
o disassociate-time - disassociate-time is calculated by the SRC as the time it sees a participant disassociate from a CS. It is possible that a given participant can have multiple associate times / disassociate times within a given communication session.
o 解除关联时间-解除关联时间由SRC计算为参与者与CS解除关联的时间。在给定的通信会话中，给定的参与者可能有多个关联时间/解除关联时间。
o param - The capabilities here are those that are indicated in the Contact header as defined in Section 9 of [RFC3840]. For example, in a CS (which can be a conference), you can have participants who are playing the role of "focus". These participants do not contribute to media in the CS; however, they switch the media received from one participant to every other participant in the CS. Indicating the capabilities of the participants (here, "focus") would be useful for the recorder to learn about these kinds of participants. The capabilities are represented using the 'param' XML element in the metadata. The 'param' XML element encoding defined in [RFC4235] is used to represent the capability attributes in metadata. Each participant may have zero or more capabilities. A participant may use different capabilities, depending on the role it plays at a particular instance -- for example, if a participant moves across different CSs (e.g., due to transfer) or is simultaneously present in different CSs with different roles.
o param-此处的功能是指[RFC3840]第9节中定义的联系人标题中所示的功能。例如，在CS（可以是会议）中，您可以让参与者扮演“焦点”的角色。这些参与者不向CS中的媒体投稿；然而，他们将从一个参与者接收到的媒体切换到CS中的每个其他参与者。指出参与者的能力（这里称为“焦点”）将有助于记录者了解这些类型的参与者。这些功能使用元数据中的“param”XML元素表示。[RFC4235]中定义的“param”XML元素编码用于表示元数据中的能力属性。每个参与者可能没有或有更多的能力。参与者可能会使用不同的功能，这取决于它在特定实例中扮演的角色——例如，如果参与者在不同的CSs中移动（例如，由于传输），或者同时出现在具有不同角色的不同CSs中。
o participant_id - This attribute identifies the participant to which this association belongs.
o 参与者id-此属性标识此关联所属的参与者。
o session_id - This attribute identifies the session to which this association belongs.
o 会话\u id-此属性标识此关联所属的会话。
The Participant-CS Association class is linked to the participant and CS classes.
参与者CS关联类链接到参与者和CS类。
Participant
| 0..* 1..* |
receives| |sends
| 0..* 0..* |
+-------------------------+
| Media Stream |
0..1 0..* +-------------------------+
Communication ------------| |
Session | label |
| content-type |
| stream_id |
| session_id |
+-------------------------+
0..* |
|
|
1..* |
Recording Session
Participant
| 0..* 1..* |
receives| |sends
| 0..* 0..* |
+-------------------------+
| Media Stream |
0..1 0..* +-------------------------+
Communication ------------| |
Session | label |
| content-type |
| stream_id |
| session_id |
+-------------------------+
0..* |
|
|
1..* |
Recording Session
A MS class (and its objects) has the properties of media as seen by the SRC and sent to the SRS. Different snapshots of MS objects may be sent whenever there is a change in media (e.g., a direction change, like pause/resume, codec change, and/or participant change).
MS类（及其对象）具有SRC看到并发送给SRS的媒体属性。只要媒体发生变化（例如，方向变化，如暂停/恢复、编解码器变化和/或参与者变化），就可以发送MS对象的不同快照。
The MS object is represented in the XML schema using the 'stream' element.
MS对象在XML模式中使用“stream”元素表示。
A MS class has the following attributes:
MS类具有以下属性：
o label - The 'label' attribute within the 'stream' XML element references an SDP "a=label" attribute that identifies an m-line within the RS SDP. That m-line carries the media stream from the SRC to the SRS.
o label—“stream”XML元素中的“label”属性引用一个SDP“a=label”属性，该属性标识RS SDP中的一条m线。该m线将媒体流从SRC传送到SRS。
o content-type - The content of a MS element will be described in terms of the "a=content" attribute defined in Section 5 of [RFC4796]. If the SRC wishes to convey the content-type to the SRS, it does so by including an "a=content" attribute with the m-line in the RS SDP.
o 内容类型-MS元素的内容将根据[RFC4796]第5节中定义的“a=内容”属性进行描述。如果SRC希望将内容类型传递给SRS，那么它通过在RS-SDP中包含带有m行的“a=content”属性来实现。
o stream_id - Each 'stream' element has a unique 'stream_id' attribute that helps to uniquely identify the stream. This identifier is generated using the rules mentioned in Section 6.10.
o stream_id-每个“stream”元素都有一个唯一的“stream_id”属性，该属性有助于唯一地标识流。该标识符是使用第6.10节中提到的规则生成的。
o session_id - This attribute associates the stream with a specific 'session' element.
o session_id-此属性将流与特定的“session”元素相关联。
The metadata model can include media streams that are not being delivered to the SRS. For example, an SRC offers audio and video towards an SRS that accepts only audio in response. The metadata snapshots sent from the SRC to the SRS can continue to indicate the changes to the video stream as well.
元数据模型可以包括未传送到SRS的媒体流。例如，SRC向仅接受音频响应的SRS提供音频和视频。从SRC发送到SRS的元数据快照也可以继续指示对视频流的更改。
A MS class is linked to the participant and CS classes by using the association relationship. Details regarding associations with the participant are described in Section 6.5. Details regarding associations with the CS are mentioned in Section 6.3.
MS类通过关联关系链接到参与者和CS类。第6.5节描述了与参与者相关的详细信息。第6.3节中提到了与CS相关的详细信息。
+-------------------------+
| Participant-Stream |
| Association |
+-------------------------+ +-----------Participant
| associate-time | | 0..* | 1..* |
| disassociate-time |---+ receives| |sends
| send | | 0..* | 0..* |
| recv | | | |
| participant_id | | | |
+-------------------------+ | | |
+-----------Media Stream
+-------------------------+
| Participant-Stream |
| Association |
+-------------------------+ +-----------Participant
| associate-time | | 0..* | 1..* |
| disassociate-time |---+ receives| |sends
| send | | 0..* | 0..* |
| recv | | | |
| participant_id | | | |
+-------------------------+ | | |
+-----------Media Stream
A Participant-Stream Association class describes the association of a participant to a MS for a period of time, as a sender or as a receiver, or both.
参与者流关联类描述参与者作为发送者或接收者或两者在一段时间内与MS的关联。
This class is represented in XML using the 'participantstreamassoc' element.
此类使用“participantstreeamassoc”元素以XML表示。
A Participant-Stream Association class has the following attributes:
参与者流关联类具有以下属性：
o associate-time - This attribute indicates the time a participant started contributing to a MS.
o 关联时间-此属性表示参与者开始向MS捐款的时间。
o disassociate-time - This attribute indicates the time a participant stopped contributing to a MS.
o 解除关联时间-此属性表示参与者停止向MS捐款的时间。
o send - This attribute indicates whether a participant is contributing to a stream or not. This attribute has a value that points to a stream represented by its unique_id. The presence of this attribute indicates that a participant is contributing to a stream. If a participant stops contributing to a stream due to changes in a CS, a snapshot MUST be sent from the SRC to the SRS with no 'send' element for that stream.
o 发送-此属性指示参与者是否参与流。此属性具有一个值，该值指向由其唯一\u id表示的流。此属性的存在表示参与者正在为流作出贡献。如果参与者由于CS中的更改而停止对流进行贡献，则必须将快照从SRC发送到SRS，且该流没有“发送”元素。
o recv - This attribute indicates whether a participant is receiving a media stream or not. This attribute has a value that points to a stream represented by its unique_id. The presence of this attribute indicates that a participant is receiving a stream. If the participant stops receiving a stream due to changes in a CS (like hold), a snapshot MUST be sent from the SRC to the SRS with no 'recv' element for that stream.
o recv-此属性指示参与者是否正在接收媒体流。此属性具有一个值，该值指向由其唯一\u id表示的流。此属性的存在表示参与者正在接收流。如果参与者由于CS（如hold）中的更改而停止接收流，则必须从SRC向SRS发送快照，且该流没有“recv”元素。
o participant_id - This attribute points to the participant with which a 'stream' element is associated.
o 参与者id-此属性指向与“流”元素关联的参与者。
The 'participantstreamassoc' XML element is used to represent a participant association with a stream. The 'send' and 'recv' XML elements MUST be used to indicate whether a participant is contributing to a stream or receiving a stream. There MAY be multiple instances of the 'send' and 'recv' XML elements inside a 'participantstreamassoc' element. If a metadata snapshot is sent with a 'participantstreamassoc' element that does not have any 'send' and 'recv' elements, it means that the participant is neither contributing to any streams nor receiving any streams.
“participantstreamassoc”XML元素用于表示参与者与流的关联。“send”和“recv”XML元素必须用于指示参与者是参与流还是接收流。“participantstreamassoc”元素中可能有多个“send”和“recv”XML元素实例。如果发送元数据快照时使用的“participantstreamassoc”元素没有任何“send”和“recv”元素，则表示参与者既没有参与任何流，也没有接收任何流。
The Participant-Stream Association class is linked to the participant and MS classes.
参与者流关联类链接到参与者和MS类。
The XML elements 'associate-time', 'disassociate-time', 'start-time', and 'stop-time' contain strings representing the date and time. The value of these elements MUST follow the Instant Messaging and Presence Protocol (IMPP) date-time format [RFC3339]. Timestamps that contain "T" or "Z" MUST use the capitalized forms.
XML元素“关联时间”、“解除关联时间”、“开始时间”和“停止时间”包含表示日期和时间的字符串。这些元素的值必须遵循即时消息和状态协议（IMPP）日期时间格式[RFC3339]。包含“T”或“Z”的时间戳必须使用大写形式。
As a security measure, the 'timestamp' element MUST be included in all tuples, unless the exact time of the status change cannot be determined.
作为安全措施，“timestamp”元素必须包含在所有元组中，除非无法确定状态更改的确切时间。
A unique_id is generated in two steps:
通过两个步骤生成唯一的_id：
o The Universally Unique Identifier (UUID) is created using any of the procedures mentioned in Sections 4.3, 4.4, and 4.5 of [RFC4122]. The algorithm MUST ensure that it does not use any potentially personally identifying information to generate the UUIDs. If implementations are using a Name-Based UUID as defined in Section 4.3 of [RFC4122], a namespace ID generated using the guidance in Section 4.2 or 4.5 of [RFC4122] might be a good choice.
o 使用[RFC4122]第4.3、4.4和4.5节中提到的任何程序创建通用唯一标识符（UUID）。该算法必须确保不会使用任何潜在的个人识别信息来生成UUID。如果实现使用[RFC4122]第4.3节中定义的基于名称的UUID，则使用[RFC4122]第4.2节或第4.5节中的指南生成的命名空间ID可能是一个不错的选择。
o The UUID is encoded using base64 as defined in [RFC4648].
o UUID使用[RFC4648]中定义的base64编码。
The above-mentioned unique_id mechanism SHOULD be used for each metadata element. Multiple SRCs can refer to the same element/UUID (how each SRC learns the UUID here is beyond the scope of this document). If two SRCs use the same UUID, they MUST retain the UUID/element mapping. If the SRS detects that a UUID is mapped to more than one element at any point in time, it MUST treat this as an error. For example, the SRS may choose to reject or ignore the portions of metadata where it detects that the same UUID is mapped to an element that is different than the expected element (the SRS learns the mapped UUID when it sees an element for the first time in a metadata instance).
每个元数据元素都应使用上述唯一的_id机制。多个SRC可以引用同一个元素/UUID（这里每个SRC如何学习UUID超出了本文的范围）。如果两个SRC使用相同的UUID，则它们必须保留UUID/元素映射。如果SRS检测到UUID在任何时间点映射到多个元素，则必须将其视为错误。例如，SRS可以选择拒绝或忽略元数据的部分，其中它检测到相同的UUID映射到与预期元素不同的元素（SRS在元数据实例中第一次看到元素时学习映射的UUID）。
The Metadata version is defined to help the SRC and SRS know the version of metadata XML schema used. SRCs and SRSs that support this specification MUST use version 1 in the namespace (urn:ietf:params:xml:ns:recording:1) in all the XML documents. Implementations may not interoperate if the version implemented by the sender is not known by the receiver. No negotiation of versions is provided. The version number has no significance, although
定义元数据版本是为了帮助SRC和SRS了解所使用的元数据XML模式的版本。支持此规范的SRC和SRS必须在所有xml文档的命名空间（urn:ietf:params:xml:ns:recording:1）中使用版本1。如果接收方不知道发送方实现的版本，则实现可能无法互操作。未提供版本协商。版本号没有意义，但
documents that update or obsolete this document (possibly including drafts of such documents) should include a higher version number if the metadata XML schema changes.
如果元数据XML模式发生更改，则更新或废弃此文档的文档（可能包括此类文档的草稿）应包含更高的版本号。
The SRS can explicitly request a metadata snapshot from the SRC. To request a metadata snapshot, the SRS MUST send a SIP request message with an XML document having the namespace urn:ietf:params:xml:ns:recording:1. The XML document has the following elements:
SRS可以显式地从SRC请求元数据快照。要请求元数据快照，SRS必须发送SIP请求消息，其中包含一个XML文档，其名称空间为urn:ietf:params:XML:ns:recording:1。XML文档包含以下元素：
o A 'requestsnapshot' XML element MUST be present as the top-level element in the XML document.
o “requestsnapshot”XML元素必须作为XML文档中的顶级元素存在。
o A 'requestreason' XML element that indicates the reason (as a string) for requesting the snapshot MAY be present as a child XML element of 'requestsnapshot'.
o 指示请求快照的原因（作为字符串）的“requestreason”XML元素可能作为“requestsnapshot”的子XML元素存在。
The example below shows a metadata snapshot request from the SRS.
下面的示例显示了来自SRS的元数据快照请求。
<?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>
Example Metadata Snapshot Request from SRS to SRC
从SRS到SRC的元数据快照请求示例
The following example provides all the tuples involved in the recording metadata XML body.
下面的示例提供了记录元数据XML正文中涉及的所有元组。
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>complete</datamode>
<group group_id="7+OTCyoxTmqmqyA/1weDAg==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
<!-- Standardized extension -->
<call-center xmlns='urn:ietf:params:xml:ns:callcenter'>
<supervisor>sip:alice@atlanta.com</supervisor>
</call-center>
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</group>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>ab30317f1a784dc48ff824d0d3715d86;
remote=47755a9de7794ba387653f2099600ef2</sipSessionID>
<group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</session>
<participant participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor="sip:bob@biloxi.com">
<name xml:lang="it">Bob</name>
</nameID>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</participant>
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>complete</datamode>
<group group_id="7+OTCyoxTmqmqyA/1weDAg==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
<!-- Standardized extension -->
<call-center xmlns='urn:ietf:params:xml:ns:callcenter'>
<supervisor>sip:alice@atlanta.com</supervisor>
</call-center>
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</group>
<session session_id="hVpd7YQgRW2nD22h7q60JQ==">
<sipSessionID>ab30317f1a784dc48ff824d0d3715d86;
remote=47755a9de7794ba387653f2099600ef2</sipSessionID>
<group-ref>7+OTCyoxTmqmqyA/1weDAg==</group-ref>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</session>
<participant participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor="sip:bob@biloxi.com">
<name xml:lang="it">Bob</name>
</nameID>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</participant>
<participant participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor="sip:Paul@biloxi.com">
<name xml:lang="it">Paul</name>
</nameID>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</participant>
<stream stream_id="UAAMm5GRQKSCMVvLyl4rFw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>97</label>
</stream>
<stream stream_id="8zc6e0lYTlWIINA6GR+3ag=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>98</label>
</stream>
<stream stream_id="EiXGlc+4TruqqoDaNE76ag=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>99</label>
</stream>
<sessionrecordingassoc session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</sessionrecordingassoc>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participant participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<nameID aor="sip:Paul@biloxi.com">
<name xml:lang="it">Paul</name>
</nameID>
<!-- Standardized extension -->
<mydata xmlns='http://example.com/my'>
<structure>FOO!</structure>
<whatever>bar</whatever>
</mydata>
</participant>
<stream stream_id="UAAMm5GRQKSCMVvLyl4rFw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>96</label>
</stream>
<stream stream_id="i1Pz3to5hGk8fuXl+PbwCw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>97</label>
</stream>
<stream stream_id="8zc6e0lYTlWIINA6GR+3ag=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>98</label>
</stream>
<stream stream_id="EiXGlc+4TruqqoDaNE76ag=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<label>99</label>
</stream>
<sessionrecordingassoc session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</sessionrecordingassoc>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantsessionassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<associate-time>2010-12-16T23:41:07Z</associate-time>
</participantsessionassoc>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
</recording>
<participantstreamassoc
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<send>i1Pz3to5hGk8fuXl+PbwCw==</send>
<send>UAAMm5GRQKSCMVvLyl4rFw==</send>
<recv>8zc6e0lYTlWIINA6GR+3ag==</recv>
<recv>EiXGlc+4TruqqoDaNE76ag==</recv>
</participantstreamassoc>
<participantstreamassoc
participant_id="zSfPoSvdSDCmU3A3TRDxAw==">
<send>8zc6e0lYTlWIINA6GR+3ag==</send>
<send>EiXGlc+4TruqqoDaNE76ag==</send>
<recv>UAAMm5GRQKSCMVvLyl4rFw==</recv>
<recv>i1Pz3to5hGk8fuXl+PbwCw==</recv>
</participantstreamassoc>
</recording>
Example Metadata Snapshot from SRC to SRS
从SRC到SRS的元数据快照示例
The following example provides a partial update in the recording metadata XML body for the above example. The example has a snapshot that carries the disassociate-time for a participant from a session.
下面的示例为上面的示例提供了录制元数据XML正文中的部分更新。该示例有一个快照，其中包含参与者与会话的解除关联时间。
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<participant
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor="sip:bob@biloxi.com">
<name xml:lang="it">Bob</name>
</nameID>
</participant>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
</recording>
<?xml version="1.0" encoding="UTF-8"?>
<recording xmlns='urn:ietf:params:xml:ns:recording:1'>
<datamode>partial</datamode>
<participant
participant_id="srfBElmCRp2QB23b7Mpk0w==">
<nameID aor="sip:bob@biloxi.com">
<name xml:lang="it">Bob</name>
</nameID>
</participant>
<participantsessionassoc
participant_id="srfBElmCRp2QB23b7Mpk0w=="
session_id="hVpd7YQgRW2nD22h7q60JQ==">
<disassociate-time>2010-12-16T23:41:07Z</disassociate-time>
</participantsessionassoc>
</recording>
Partial Update of SIP Recording Example XML Body
SIP录制示例XML正文的部分更新
This section defines the XML schema for the recording metadata document.
本节定义了录制元数据文档的XML模式。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:recording:1"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:recording:1"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang -->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="https://www.w3.org/2001/xml.xsd"/>
<xs:element name="recording" type="tns:recording"/>
<xs:complexType name="recording">
<xs:sequence>
<xs:element name="datamode" type="tns:dataMode"
minOccurs="0"/>
<xs:element name="group" type="tns:group"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="session" type="tns:session"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="participant" type="tns:participant"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="stream" type="tns:stream"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="sessionrecordingassoc"
type="tns:sessionrecordingassoc"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="participantsessionassoc"
type="tns:participantsessionassoc"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="participantstreamassoc"
type="tns:participantstreamassoc"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
</xs:complexType>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:recording:1"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="urn:ietf:params:xml:ns:recording:1"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang -->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="https://www.w3.org/2001/xml.xsd"/>
<xs:element name="recording" type="tns:recording"/>
<xs:complexType name="recording">
<xs:sequence>
<xs:element name="datamode" type="tns:dataMode"
minOccurs="0"/>
<xs:element name="group" type="tns:group"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="session" type="tns:session"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="participant" type="tns:participant"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="stream" type="tns:stream"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="sessionrecordingassoc"
type="tns:sessionrecordingassoc"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="participantsessionassoc"
type="tns:participantsessionassoc"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="participantstreamassoc"
type="tns:participantstreamassoc"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="group">
<xs:sequence>
<xs:element name="associate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="disassociate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="group_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="session">
<xs:sequence>
<xs:element name="sipSessionID" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="reason" type="tns:reason"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="group-ref" type="xs:base64Binary"
minOccurs="0" maxOccurs="1"/>
<xs:element name="start-time" type="xs:dateTime"
minOccurs="0" maxOccurs="1"/>
<xs:element name="stop-time" type="xs:dateTime"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="session_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="sessionrecordingassoc">
<xs:sequence>
<xs:element name="associate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="disassociate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="session_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="group">
<xs:sequence>
<xs:element name="associate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="disassociate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="group_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="session">
<xs:sequence>
<xs:element name="sipSessionID" type="xs:string"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="reason" type="tns:reason"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="group-ref" type="xs:base64Binary"
minOccurs="0" maxOccurs="1"/>
<xs:element name="start-time" type="xs:dateTime"
minOccurs="0" maxOccurs="1"/>
<xs:element name="stop-time" type="xs:dateTime"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="session_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="sessionrecordingassoc">
<xs:sequence>
<xs:element name="associate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="disassociate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="session_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="participant">
<xs:sequence>
<xs:element name="nameID" type="tns:nameID"
maxOccurs='unbounded'/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="participant_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="participantsessionassoc">
<xs:sequence>
<xs:element name="associate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="disassociate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="param" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="pname" type="xs:string"
use="required"/>
<xs:attribute name="pval" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="participant_id" type="xs:base64Binary"
use="required"/>
<xs:attribute name="session_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="participant">
<xs:sequence>
<xs:element name="nameID" type="tns:nameID"
maxOccurs='unbounded'/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="participant_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="participantsessionassoc">
<xs:sequence>
<xs:element name="associate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="disassociate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="param" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="pname" type="xs:string"
use="required"/>
<xs:attribute name="pval" type="xs:string"
use="required"/>
</xs:complexType>
</xs:element>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="participant_id" type="xs:base64Binary"
use="required"/>
<xs:attribute name="session_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="participantstreamassoc">
<xs:sequence>
<xs:element name="send" type="xs:base64Binary"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="recv" type="xs:base64Binary"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="associate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="disassociate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="participant_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="stream">
<xs:sequence>
<xs:element name="label" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="stream_id" type="xs:base64Binary"
use="required"/>
<xs:attribute name="session_id" type="xs:base64Binary"/>
</xs:complexType>
<xs:simpleType name="dataMode">
<xs:restriction base="xs:string">
<xs:enumeration value="complete"/>
<xs:enumeration value="partial"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="nameID">
<xs:sequence>
<xs:element name="name" type ="tns:name" minOccurs="0"
maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="aor" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="participantstreamassoc">
<xs:sequence>
<xs:element name="send" type="xs:base64Binary"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="recv" type="xs:base64Binary"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="associate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:element name="disassociate-time" type="xs:dateTime"
minOccurs="0"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="participant_id" type="xs:base64Binary"
use="required"/>
</xs:complexType>
<xs:complexType name="stream">
<xs:sequence>
<xs:element name="label" type="xs:string"
minOccurs="0" maxOccurs="1"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
<xs:attribute name="stream_id" type="xs:base64Binary"
use="required"/>
<xs:attribute name="session_id" type="xs:base64Binary"/>
</xs:complexType>
<xs:simpleType name="dataMode">
<xs:restriction base="xs:string">
<xs:enumeration value="complete"/>
<xs:enumeration value="partial"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="nameID">
<xs:sequence>
<xs:element name="name" type ="tns:name" minOccurs="0"
maxOccurs="1"/>
</xs:sequence>
<xs:attribute name="aor" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="name">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="reason">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute type="xs:short" name="cause" use="required"/>
<xs:attribute type="xs:string" name="protocol" default="SIP"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="requestsnapshot" type="tns:requestsnapshot"/>
<xs:complexType name="requestsnapshot">
<xs:sequence>
<xs:element name="requestreason" type="tns:name"
minOccurs="0"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
</xs:complexType>
</xs:schema>
<xs:complexType name="name">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="optional"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="reason">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute type="xs:short" name="cause" use="required"/>
<xs:attribute type="xs:string" name="protocol" default="SIP"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:element name="requestsnapshot" type="tns:requestsnapshot"/>
<xs:complexType name="requestsnapshot">
<xs:sequence>
<xs:element name="requestreason" type="tns:name"
minOccurs="0"/>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'
processContents='lax'/>
</xs:sequence>
</xs:complexType>
</xs:schema>
This document describes an extensive set of metadata that may be recorded by the SRS. Most of the metadata could be considered private data. The procedures mentioned in the Security Considerations section of [RFC7866] MUST be followed by the SRC and the SRS for mutual authentication and to protect the content of the metadata in the RS.
本文档描述了SRS可能记录的大量元数据。大多数元数据都可以被视为私有数据。SRC和SRS必须遵守[RFC7866]安全注意事项部分中提到的程序，以进行相互认证，并保护RS中的元数据内容。
An SRC MAY, by policy, choose to limit the parts of the metadata sent to the SRS for recording. Also, the policy of the SRS might not require recording all the metadata it receives. For the sake of data minimization, the SRS MUST NOT record additional metadata that is not explicitly required by local policy. Metadata in storage needs to be provided with a level of security that is comparable to that of the recording session.
SRC可以根据策略选择限制发送给SRS进行记录的元数据部分。此外，SRS的策略可能不需要记录它接收到的所有元数据。为了最小化数据，SRS不得记录本地策略未明确要求的其他元数据。存储中的元数据需要提供与录制会话相当的安全级别。
This specification registers a new XML namespace and a new XML schema.
该规范注册了一个新的XML名称空间和一个新的XML模式。
URI: urn:ietf:params:xml:ns:recording:1
URI: urn:ietf:params:xml:ns:recording:1
Registrant Contact: IETF SIPREC working group, Ram Mohan R (rmohanr@cisco.com)
注册人联系人：IETF SIPREC工作组，Ram Mohan R(rmohanr@cisco.com)
XML: The registered XML schema is contained in Section 9.
XML：注册的XML模式包含在第9节中。
Its first line is <?xml version="1.0" encoding="UTF-8"?>, and its last line is </xs:schema>.
它的第一行是</xml version=“1.0”encoding=“UTF-8”>，最后一行是</xs:schema>。
[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>.
[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>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <http://www.rfc-editor.org/info/rfc3339>.
[RFC3339]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，DOI 10.17487/RFC3339，2002年7月<http://www.rfc-editor.org/info/rfc3339>.
[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>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <http://www.rfc-editor.org/info/rfc4122>.
[RFC4122]Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，DOI 10.17487/RFC4122，2005年7月<http://www.rfc-editor.org/info/rfc4122>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<http://www.rfc-editor.org/info/rfc4566>.
[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>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC4796] Hautakorpi, J. and G. Camarillo, "The Session Description Protocol (SDP) Content Attribute", RFC 4796, DOI 10.17487/RFC4796, February 2007, <http://www.rfc-editor.org/info/rfc4796>.
[RFC4796]Hautakorpi，J.和G.Camarillo，“会话描述协议（SDP）内容属性”，RFC 4796，DOI 10.17487/RFC4796，2007年2月<http://www.rfc-editor.org/info/rfc4796>.
[RFC7866] Portman, L., Lum, H., Ed., Eckel, C., Johnston, A., and A. Hutton, "Session Recording Protocol", RFC 7866, DOI 10.17487/RFC7866, May 2016, <http://www.rfc-editor.org/info/rfc7866>.
[RFC7866]Portman，L.，Lum，H.，Ed.，Eckel，C.，Johnston，A.，和A.Hutton，“会话记录协议”，RFC 7866，DOI 10.17487/RFC7866，2016年5月<http://www.rfc-editor.org/info/rfc7866>.
[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>.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason Header Field for the Session Initiation Protocol (SIP)", RFC 3326, DOI 10.17487/RFC3326, December 2002, <http://www.rfc-editor.org/info/rfc3326>.
[RFC3326]Schulzrinne，H.，Oran，D.，和G.Camarillo，“会话启动协议（SIP）的原因头字段”，RFC 3326，DOI 10.17487/RFC3326，2002年12月<http://www.rfc-editor.org/info/rfc3326>.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, DOI 10.17487/RFC3966, December 2004, <http://www.rfc-editor.org/info/rfc3966>.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，DOI 10.17487/RFC3966，2004年12月<http://www.rfc-editor.org/info/rfc3966>.
[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., "An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)", RFC 4235, DOI 10.17487/RFC4235, November 2005, <http://www.rfc-editor.org/info/rfc4235>.
[RFC4235]Rosenberg，J.，Schulzrinne，H.，和R.Mahy，Ed.，“会话启动协议（SIP）的邀请启动对话事件包”，RFC 4235，DOI 10.17487/RFC4235，2005年11月<http://www.rfc-editor.org/info/rfc4235>.
[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>.
[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>.
[SessionID] Jones, P., Salgueiro, G., Pearce, C., and P. Giralt, "End-to-End Session Identification in IP-Based Multimedia Communication Networks", Work in Progress, draft-ietf-insipid-session-id-22, April 2016.
[SessionID]Jones，P.，Salgueiro，G.，Pearce，C.，和P.Giralt，“基于IP的多媒体通信网络中的端到端会话识别”，正在进行的工作，草稿-ietf-INSPID-Session-id-22，2016年4月。
[UML] Object Management Group, "OMG Unified Modeling Language (UML)", 2011, <http://www.omg.org/spec/UML/2.4/>.
[UML]对象管理组，“OMG统一建模语言（UML）”，2011年<http://www.omg.org/spec/UML/2.4/>.
Acknowledgements
致谢
Thanks to John Elwell, Henry Lum, Leon Portman, De Villiers de Wet, Andrew Hutton, Deepanshu Gautam, Charles Eckel, Muthu Arul Mozhi Perumal, Michael Benenson, Hadriel Kaplan, Brian Rosen, Scott Orton, Ofir Roth, Mary Barnes, Ken Rehor, Gonzalo Salgueiro, Yaron Pdut, Alissa Cooper, Stephen Farrell, and Ben Campbell for their valuable comments and inputs.
感谢约翰·埃尔维尔、亨利·卢姆、利昂·波特曼、德维利埃·德韦特、安德鲁·赫顿、迪潘舒·高塔姆、查尔斯·埃克尔、穆图·阿鲁尔·莫齐·佩鲁马尔、迈克尔·贝内森、哈德里尔·卡普兰、布赖恩·罗森、斯科特·奥尔顿、奥菲尔·罗斯、玛丽·巴恩斯、肯·雷霍、冈萨洛·萨尔盖罗、雅伦·普杜特、艾莉莎·库珀、斯蒂芬·法雷尔、，以及Ben Campbell的宝贵意见和投入。
Thanks to Joe Hildebrand, Peter Saint-Andre, and Matt Miller for helping in writing the XML schema, and to Martin Thomson for validating the XML schema and providing comments on the same.
感谢Joe Hildebrand、Peter Saint Andre和Matt Miller帮助编写XML模式，感谢Martin Thomson验证XML模式并提供评论。
Authors' Addresses
作者地址
Ram Mohan Ravindranath Cisco Systems Cessna Business Park Bangalore, Karnataka India
Ram Mohan Ravindranath思科系统塞斯纳商业园印度卡纳塔克邦班加罗尔
Email: rmohanr@cisco.com
Email: rmohanr@cisco.com
Parthasarathi Ravindran Nokia Networks Bangalore, Karnataka India
印度卡纳塔克邦班加罗尔Parthasarathi Ravindran诺基亚网络公司
Email: partha@parthasarathi.co.in
Email: partha@parthasarathi.co.in
Paul Kyzivat Huawei Hudson, MA United States
保罗·基齐瓦特·哈得逊，马萨诸塞州，美国
Email: pkyzivat@alum.mit.edu
Email: pkyzivat@alum.mit.edu