Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 6332 E. Friedrich
Category: Standards Track Cisco
ISSN: 2070-1721 July 2011
Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 6332 E. Friedrich
Category: Standards Track Cisco
ISSN: 2070-1721 July 2011
Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)
RTP控制协议（RTCP）扩展报告（XRs）的多播采集报告块类型
Abstract
摘要
In most RTP-based multicast applications, the RTP source sends inter-related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one or more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases, the RTP receiver can do a simple multicast join (in other cases, it is compelled to do so). For quality reporting, monitoring, and diagnostic purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called the Multicast Acquisition (MA) report block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XRs) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP).
在大多数基于RTP的多播应用程序中，RTP源发送相互关联的数据。由于这种相互依赖性，随机加入的RTP接收器通常无法在加入会话后立即开始使用多播数据。因此，它们通常会经历随机采集延迟。RTP接收机可以使用一种或多种不同的方法来实现快速捕获。然而，由于各种因素，快速采集方法的性能通常会有所不同。此外，在某些情况下，RTP接收器可以进行简单的多播连接（在其他情况下，它是被迫这样做的）。出于质量报告、监控和诊断目的，从RTP接收者处收集有关其采集和演示体验的详细信息非常重要。本文通过在RTP控制协议（RTCP）扩展报告（XRs）（RFC 3611）的框架内定义一种新的报告块类型，称为多播采集（MA）报告块，来解决这个问题。本文件还定义了会话描述协议（SDP）中新MA报告块类型的必要信令。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6332.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6332.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Multicast Acquisition (MA) Report Block . . . . . . . . . . . 4
4.1. Base Report . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Status Code Rules for New MA Methods . . . . . . . . . 6
4.1.2. Status Code Rules for the RAMS Method . . . . . . . . 6
4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 7
4.2.2. Private Extensions . . . . . . . . . . . . . . . . . . 10
5. Session Description Protocol Signaling . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 11
7.2. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 12
7.3. Multicast Acquisition Method Registry . . . . . . . . . . 12
7.4. Multicast Acquisition Report Block TLV Space Registry . . 12
7.5. Multicast Acquisition Status Code Space Registry . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Multicast Acquisition (MA) Report Block . . . . . . . . . . . 4
4.1. Base Report . . . . . . . . . . . . . . . . . . . . . . . 5
4.1.1. Status Code Rules for New MA Methods . . . . . . . . . 6
4.1.2. Status Code Rules for the RAMS Method . . . . . . . . 6
4.2. Extensions . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Vendor-Neutral Extensions . . . . . . . . . . . . . . 7
4.2.2. Private Extensions . . . . . . . . . . . . . . . . . . 10
5. Session Description Protocol Signaling . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7.1. RTCP XR Block Type . . . . . . . . . . . . . . . . . . . . 11
7.2. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 12
7.3. Multicast Acquisition Method Registry . . . . . . . . . . 12
7.4. Multicast Acquisition Report Block TLV Space Registry . . 12
7.5. Multicast Acquisition Status Code Space Registry . . . . . 13
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
9.2. Informative References . . . . . . . . . . . . . . . . . . 15
The RTP Control Protocol (RTCP) is the out-of-band control protocol for applications that use the Real-time Transport Protocol (RTP) for media transport [RFC3550]. In addition to providing minimal control functionality to RTP entities, RTCP also enables a basic-level monitoring of RTP sessions via sender and receiver reports. More statistically detailed monitoring as well as application-specific monitoring are usually achieved through the RTCP Extended Reports (XRs) [RFC3611].
RTP控制协议（RTCP）是用于使用实时传输协议（RTP）进行媒体传输的应用程序的带外控制协议[RFC3550]。除了为RTP实体提供最低限度的控制功能外，RTCP还可以通过发送方和接收方报告对RTP会话进行基本级别的监控。通常通过RTCP扩展报告（XRs）[RFC3611]实现更详细的统计监控以及特定于应用程序的监控。
In most RTP-based multicast applications such as the ones carrying video content, the RTP source sends inter-related data. Consequently, the RTP application may not be able to decode and present the data in an RTP packet before decoding the data in one or more earlier RTP packets and/or before acquiring some Reference Information about the content itself. Thus, RTP receivers that are randomly joining a multicast session often experience a random acquisition delay. In order to reduce this delay, [RFC6285] proposes an approach where an auxiliary unicast RTP session is established between a retransmission server and the joining RTP receiver. Over this unicast RTP session, the retransmission server provides the Reference Information, which is all the information the RTP receiver needs to rapidly acquire the multicast stream. This method is referred to as the Rapid Acquisition of Multicast RTP Sessions (RAMS). However, depending on the variability in the Source Filtering Group Management Protocol (SFGMP) processing times, the availability of network resources for rapid acquisition, and the nature of the RTP data, not all RTP receivers can acquire the multicast stream in the same amount of time. The performance of rapid acquisition may vary not only for different RTP receivers but also over time.
在大多数基于RTP的多播应用程序（如承载视频内容的应用程序）中，RTP源发送相互关联的数据。因此，在解码一个或多个先前RTP分组中的数据之前和/或在获取关于内容本身的一些参考信息之前，RTP应用可能无法解码和呈现RTP分组中的数据。因此，随机加入多播会话的RTP接收机通常会经历随机捕获延迟。为了减少这种延迟，[RFC6285]提出了一种方法，其中在重传服务器和加入的RTP接收器之间建立辅助单播RTP会话。在该单播RTP会话上，重传服务器提供参考信息，这是RTP接收器快速获取多播流所需的全部信息。这种方法被称为快速获取多播RTP会话（RAMS）。然而，根据源过滤组管理协议（SFGMP）处理时间的可变性、用于快速捕获的网络资源的可用性以及RTP数据的性质，并非所有RTP接收器都能在相同的时间内获取多播流。快速捕获的性能可能不仅因不同的RTP接收机而异，而且随着时间的推移也会有所不同。
To increase the visibility of the multicast service provider in its network, to diagnose slow multicast acquisition issues, and to collect the acquisition experiences of the RTP receivers, this document defines a new report block type, which is called the Multicast Acquisition (MA) report block, within the framework of RTCP XR. RTP receivers that use the method described in [RFC6285] may use this report every time they join a new multicast RTP session. RTP receivers that use a different method for rapid acquisition or those that do not use any method but rather do a simple multicast join may also use this report. This way, the multicast service provider can quantitatively compare the improvements achieved by different methods.
为了提高多播服务提供商在其网络中的可视性，诊断慢速多播采集问题，并收集RTP接收器的采集经验，本文档在RTCP XR框架内定义了一种新的报告块类型，称为多播采集（MA）报告块。使用[RFC6285]中所述方法的RTP接收器可在每次加入新的多播RTP会话时使用此报告。使用不同方法进行快速捕获的RTP接收器或不使用任何方法但进行简单多播连接的RTP接收器也可以使用此报告。这样，多播服务提供商就可以定量地比较不同方法所取得的改进。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
This document uses the acronyms and definitions from Section 3 of [RFC6285].
本文件使用[RFC6285]第3节中的首字母缩略词和定义。
This section defines the format of the MA report block. The base report is payload independent. An extension mechanism is provided where further optional payload-independent and payload-specific information can be included in the report as desired.
本节定义了MA报告块的格式。基本报告与有效负载无关。提供了一种扩展机制，其中可以根据需要在报告中包含更多可选的独立于有效负载和特定于有效负载的信息。
The OPTIONAL extensions that are defined in this document are primarily developed for the method presented in [RFC6285]. Other methods that provide rapid acquisition can define their own extensions to be used in the MA report block.
本文档中定义的可选扩展主要针对[RFC6285]中介绍的方法开发。提供快速采集的其他方法可以定义它们自己的扩展，以便在MA报告块中使用。
The packet format for the RTCP XR is defined in Section 2 of [RFC3611]. Each XR packet has a fixed-length field for version, padding, reserved bits, payload type (PT), length, synchronization source (SSRC) of packet sender as well as a variable-length field for report blocks. In the XR packets, the PT field is set to XR (207).
[RFC3611]第2节定义了RTCP XR的数据包格式。每个XR数据包都有一个用于数据包发送方版本、填充、保留位、有效负载类型（PT）、长度、同步源（SSRC）的固定长度字段，以及一个用于报告块的可变长度字段。在XR数据包中，PT字段设置为XR（207）。
It is better to send the MA report block after all the necessary information is collected and computed. Partial reporting is generally not useful as it cannot give the full picture of the multicast acquisition, and it causes additional complexity in terms of report block matching and correlation. The MA report block is only sent as a part of an RTCP compound packet, and it is sent in the primary multicast session.
最好在收集和计算完所有必要的信息后发送MA报告块。部分报告通常没有用处，因为它不能提供多播获取的完整信息，并且在报告块匹配和关联方面会导致额外的复杂性。MA报告块仅作为RTCP复合数据包的一部分发送，并在主多播会话中发送。
The need for reliability of the MA report block is not any greater than other report blocks or types. If desired, the report block could be repeated for redundancy purposes while respecting the RTCP scheduling algorithms.
MA报告块的可靠性要求不比其他报告块或报告类型更高。如果需要，可以出于冗余目的重复报告块，同时遵守RTCP调度算法。
Following the rules specified in [RFC3550], all integer fields in the base report and extensions defined below are carried in network-byte order, that is, most significant byte (octet) first, also known as big-endian. Unless otherwise stated, numeric constants are in decimal (base 10).
按照[RFC3550]中指定的规则，下面定义的基本报告和扩展中的所有整数字段都是按网络字节顺序进行的，即，最高有效字节（八位字节）优先，也称为big-endian。除非另有说明，否则数值常量为十进制（以10为基数）。
The base report format is shown in Figure 1.
基本报告格式如图1所示。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=11 | MA Method | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of the Primary Multicast Stream |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Rsvd. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=11 | MA Method | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of the Primary Multicast Stream |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Rsvd. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Base Report Format for the MA Report Block
图1:MA报告块的基本报告格式
o BT (8 bits): Field that denotes the type for this block format. The MA report block is identified by the constant 11.
o BT（8位）：表示此块格式类型的字段。MA报告块由常数11标识。
o MA Method (8 bits): Field that denotes the type of the MA method (e.g., simple join, RAMS, etc.). See Section 7.3 for the values registered with IANA.
o MA方法（8位）：表示MA方法类型的字段（例如，简单连接、RAM等）。有关IANA注册的数值，请参见第7.3节。
o Block Length (16 bits): The length of this report block, including the header, in 32-bit words minus one.
o 块长度（16位）：此报告块的长度，包括标题，以32位字减去1表示。
o SSRC of the Primary Multicast Stream (32 bits): Field that denotes the SSRC of the primary multicast stream.
o 主多播流的SSRC（32位）：表示主多播流的SSRC的字段。
o Status (16 bits): Field that denotes the status code for the MA operation.
o 状态（16位）：表示MA操作状态代码的字段。
This document defines several status codes and registers them with IANA in Section 7.5. If a new vendor-neutral status code will be defined, it MUST be registered with IANA according to the guidelines specified in Section 7.5. If the new status code is intended to be used privately by a vendor, there is no need for IANA management. Section 4.2.2 defines how a vendor defines and uses private extensions to convey its messages.
本文件定义了若干状态代码，并在第7.5节中向IANA登记。如果将定义新的供应商中立状态代码，则必须根据第7.5节规定的指南向IANA注册。如果新的状态代码打算由供应商私下使用，则无需IANA管理。第4.2.2节定义了供应商如何定义和使用专用扩展来传递其消息。
To indicate use of a private extension, the RTP receiver MUST set the Status field to zero. A private extension MUST NOT be used in an XR unless the RTP receiver knows from out-of-band methods that the entity that will receive and process the XR understands the private extension.
要指示使用专用扩展，RTP接收器必须将状态字段设置为零。除非RTP接收器通过带外方法知道将接收和处理XR的实体了解专用扩展，否则不得在XR中使用专用扩展。
o Rsvd. (16 bits): The RTP receiver MUST set this field to zero. The recipient MUST ignore this field when received.
o Rsvd。（16位）：RTP接收器必须将该字段设置为零。收件人在收到时必须忽略此字段。
If the multicast join was successful, meaning that at least one multicast packet was received, some additional information MUST be appended to the base report as described in Section 4.2.1.
如果多播加入成功，意味着至少接收到一个多播数据包，则必须按照第4.2.1节所述将一些附加信息附加到基本报告中。
Different MA methods usually use different status codes, although some status codes (e.g., a code indicating that multicast join has failed) can be common among multiple MA methods. The status code reported in the base report MUST always be within the scope of the particular MA method specified in the MA Method field.
不同的MA方法通常使用不同的状态代码，尽管一些状态代码（例如，指示多播加入失败的代码）在多个MA方法中可能是通用的。基本报告中报告的状态代码必须始终在“MA方法”字段中指定的特定MA方法的范围内。
In certain MA methods, the RTP receiver can generate a status code for its multicast acquisition attempt or can be told by another network element or RTP endpoint what the current status is via a response code. In such cases, the RTP receiver MAY report the value of the received response code as its status code if the response code has a higher priority. Each MA method needs to outline the rules pertaining to its response and status codes so that RTP receiver implementations can determine what to report in any given scenario.
在某些MA方法中，RTP接收器可以为其多播捕获尝试生成状态代码，或者可以由另一网络元件或RTP端点通过响应代码告知当前状态。在这种情况下，如果响应代码具有更高的优先级，则RTP接收机可以将接收到的响应代码的值报告为其状态代码。每个MA方法都需要概述与其响应和状态代码相关的规则，以便RTP接收器实现可以确定在任何给定场景中报告的内容。
In this section, we provide the status code rules for the RAMS method described in [RFC6285].
在本节中，我们提供了[RFC6285]中描述的RAMS方法的状态代码规则。
Section 11.6 of [RFC6285] defines several response codes. The 1xx-and 2xx-level response codes are informational and success response codes, respectively. If the RTP receiver receives a 1xx- or 2xx-level response code, then the RTP receiver MUST use one of the 1xxx-level status codes defined in Section 7.5 of this document. If the RTP receiver receives a 4xx- or 5xx-level response code (indicating receiver-side and server-side errors, respectively), then the RTP receiver MUST use the response code as its status code. In other words, the 4xx- and 5xx-level response codes have a higher priority than the 1xxx-level status codes.
[RFC6285]第11.6节定义了几个响应代码。1xx和2xx级别响应代码分别为信息性和成功响应代码。如果RTP接收器收到1xx或2xx级别的响应代码，则RTP接收器必须使用本文件第7.5节中定义的1xx级别状态代码之一。如果RTP接收器接收到4xx或5xx级别的响应代码（分别指示接收器端和服务器端错误），则RTP接收器必须使用响应代码作为其状态代码。换句话说，4xx和5xx级别响应代码的优先级高于1xxx级别状态代码。
To improve the reporting scope, it might be desirable to define new fields in the MA report block. Such fields are to be encoded as TLV elements as described below and sketched in Figure 2:
为了改进报告范围，可能需要在MA报告块中定义新字段。这些字段将编码为TLV元素，如下所述，如图2所示：
o Type: A single-octet identifier that defines the type of the parameter represented in this TLV element.
o 类型：定义此TLV元素中表示的参数类型的单个八位组标识符。
o Length: A two-octet field that indicates the length (in octets) of the TLV element excluding the Type and Length fields and the 8-bit Reserved field between them. Note that this length does not include any padding that is needed for alignment.
o 长度：两个八位字节字段，表示TLV元素的长度（以八位字节为单位），不包括类型字段和长度字段以及它们之间的8位保留字段。请注意，此长度不包括对齐所需的任何填充。
o Value: Variable-size set of octets that contains the specific value for the parameter.
o 值：包含参数特定值的可变大小的八位字节集。
In the extensions, the Reserved field MUST be set to zero and ignored on reception. If a TLV element does not fall on a 32-bit boundary, the last word MUST be padded to the boundary using further bits set to zero.
在扩展中，保留字段必须设置为零，并在接收时忽略。如果TLV元素不在32位边界上，则必须使用设置为零的其他位将最后一个字填充到边界。
In the MA report block, the RTP receiver MUST place any vendor-neutral or private extension after the base report.
在MA报告块中，RTP接收方必须在基本报告之后放置任何供应商中立或私有扩展。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Structure of a TLV Element
图2：TLV元件的结构
If the goal in defining new TLV elements is to extend the report block in a vendor-neutral manner, they need to be registered with IANA according to the guidelines provided in Section 7.4.
如果定义新TLV元素的目标是以供应商中立的方式扩展报告块，则需要根据第7.4节提供的指南向IANA注册这些元素。
This document defines several vendor-neutral extensions. First, we present the TLV elements that can be used by any RTP-based multicast application.
本文档定义了几个与供应商无关的扩展。首先，我们介绍了任何基于RTP的多播应用程序都可以使用的TLV元素。
o RTP Seqnum of the First Multicast Packet (16 bits): TLV element that specifies the RTP sequence number of the first multicast packet received for the primary multicast stream. If the multicast join was successful, this element MUST be included. If no multicast packet has been received, this element MUST NOT exist in the report block.
o 第一个多播数据包的RTP Seqnum（16位）：TLV元素，指定为主多播流接收的第一个多播数据包的RTP序列号。如果多播加入成功，则必须包含此元素。如果未接收到多播数据包，则报告块中不得存在此元素。
Type: 1
类型：1
o SFGMP Join Time (32 bits): TLV element that denotes the greater of zero or the time difference (in ms) between the instant the SFGMP Join message was sent and the instant the first packet was
o SFGMP连接时间（32位）：TLV元素，表示发送SFGMP连接消息的瞬间与发送第一个数据包的瞬间之间的时间差（毫秒）或零中的较大值
received in the multicast session. If the multicast join was successful, this element MUST be included. If no multicast packet has been received, this element MUST NOT exist in the report block.
在多播会话中接收。如果多播加入成功，则必须包含此元素。如果未接收到多播数据包，则报告块中不得存在此元素。
Type: 2
类型：2
o Application Request-to-Multicast Delta Time (32 bits): OPTIONAL TLV element that denotes the time difference (in ms) between the instant the application became aware it would join a new multicast session and the instant the first RTP packet was received from the primary multicast stream. If no such packet has been received, this element MUST NOT exist in the report block.
o Application Request to Multicast Delta Time（32位）：可选TLV元素，表示应用程序意识到它将加入新的多播会话的那一刻与从主多播流接收到第一个RTP数据包的那一刻之间的时间差（毫秒）。如果未接收到此类数据包，则此元素不得存在于报告块中。
Type: 3
类型：3
o Application Request-to-Presentation Delta Time (32 bits): OPTIONAL TLV element that denotes the time difference (in ms) between the instant the application became aware it would join a new multicast session and the instant the media was first presented. If the RTP receiver cannot successfully present the media, this element MUST NOT exist in the report block.
o Application Request to Presentation Delta Time（32位）：可选TLV元素，表示应用程序意识到它将加入新的多播会话的那一刻与媒体首次呈现的那一刻之间的时间差（毫秒）。如果RTP接收器无法成功呈现媒体，则报告块中不得存在此元素。
Type: 4
类型：4
We next present the TLV elements that can be used when the RTP receiver supports and uses the RAMS method described in [RFC6285]. However, if the RTP receiver does not send a rapid acquisition request, the following TLV elements MUST NOT exist in the MA report block. Some elements may or may not exist depending on whether or not the RTP receiver receives any packet from the unicast burst and/or the primary multicast stream. These are explained below.
接下来，我们将介绍当RTP接收器支持并使用[RFC6285]中所述的RAMS方法时可使用的TLV元件。但是，如果RTP接收器未发送快速采集请求，则MA报告块中不得存在以下TLV元素。根据RTP接收器是否从单播突发和/或主多播流接收任何分组，一些元素可能存在，也可能不存在。下文将对此进行解释。
o Application Request-to-RAMS Request Delta Time (32 bits): OPTIONAL TLV element that denotes the time difference (in ms) between the instant the application became aware it would request a rapid acquisition and the instant the rapid acquisition request was actually sent by the application.
o 应用程序请求到RAMS请求增量时间（32位）：可选TLV元素，表示应用程序意识到其将请求快速采集与应用程序实际发送快速采集请求之间的时间差（以毫秒为单位）。
Type: 11
类型：11
o RAMS Request-to-RAMS Information Delta Time (32 bits): OPTIONAL TLV element that denotes the time difference (in ms) between the instant the rapid acquisition request was sent and the instant the
o RAMS请求至RAMS信息增量时间（32位）：可选的TLV元素，表示发送快速采集请求的瞬间与接收请求的瞬间之间的时间差（毫秒）
first RAMS Information message was received in the unicast session. If no such message has been received, this element MUST NOT exist in the report block.
在单播会话中接收到第一条RAMS信息消息。如果未收到此类消息，则报告块中不得存在此元素。
Type: 12
类型：12
o RAMS Request-to-Burst Delta Time (32 bits): OPTIONAL TLV element that denotes the time difference (in ms) between the instant the rapid acquisition request was sent and the instant the first burst packet was received in the unicast session. If no burst packet has been received, this element MUST NOT exist in the report block.
o RAMS请求突发增量时间（32位）：可选TLV元素，表示在单播会话中发送快速捕获请求与接收到第一个突发数据包之间的时间差（毫秒）。如果未接收到突发数据包，则报告块中不得存在此元素。
Type: 13
类型：13
o RAMS Request-to-Multicast Delta Time (32 bits): OPTIONAL TLV element that denotes the time difference (in ms) between the instant the rapid acquisition request was sent and the instant the first RTP packet was received from the primary multicast stream. If no such packet has been received, this element MUST NOT exist in the report block.
o RAMS请求到多播增量时间（32位）：可选TLV元素，表示发送快速捕获请求与从主多播流接收第一个RTP数据包之间的时间差（毫秒）。如果未接收到此类数据包，则此元素不得存在于报告块中。
Type: 14
类型：14
o RAMS Request-to-Burst-Completion Delta Time (32 bits): OPTIONAL TLV element that denotes the time difference (in ms) between the instant the rapid acquisition request was sent and the instant the last burst packet was received in the unicast session. If no burst packet has been received, this element MUST NOT exist in the report block.
o RAMS请求突发完成增量时间（32位）：可选TLV元素，表示在单播会话中发送快速捕获请求的瞬间与接收到最后一个突发数据包的瞬间之间的时间差（毫秒）。如果未接收到突发数据包，则报告块中不得存在此元素。
Type: 15
类型：15
o Number of Duplicate Packets (32 bits): OPTIONAL TLV element that denotes the number of duplicate packets due to receiving the same packet in both unicast and primary multicast RTP sessions. If no RTP packet has been received from the primary multicast stream, this element MUST NOT exist. If no burst packet has been received in the unicast session, the value of this element MUST be set to zero.
o 重复数据包数（32位）：可选TLV元素，表示由于在单播和主多播RTP会话中接收相同数据包而导致的重复数据包数。如果没有从主多播流接收到RTP数据包，则该元素必须不存在。如果单播会话中未接收到突发数据包，则此元素的值必须设置为零。
Type: 16
类型：16
o Size of Burst-to-Multicast Gap (32 bits): OPTIONAL TLV element that denotes the greater of zero or the difference between the sequence number of the first multicast packet (received from the primary multicast stream) and the sequence number of the last burst packet minus 1 (considering the wrapping of the sequence
o 突发到多播间隙的大小（32位）：可选TLV元素，表示零或第一个多播数据包（从主多播流接收）的序列号与最后一个突发数据包的序列号减去1（考虑到序列的包装）之间的差值中的较大者
numbers). If no burst packet has been received in the unicast session or no RTP packet has been received from the primary multicast stream, this element MUST NOT exist in the report block.
数字）。如果在单播会话中未接收到突发数据包，或者未从主多播流接收到RTP数据包，则报告块中不得存在此元素。
Type: 17
类型：17
It is desirable to allow vendors to use private extensions in TLV format. The range of [128-254] of TLV Types is reserved for private extensions. IANA management for these extensions is unnecessary; they are the responsibility of individual vendors.
允许供应商使用TLV格式的私有扩展是可取的。TLV类型的[128-254]范围为专用扩展保留。这些扩展的IANA管理是不必要的；它们是个别供应商的责任。
Implementations use the structure depicted in Figure 3 for private extensions. Here, the private enterprise numbers are used from http://www.iana.org. This will ensure the uniqueness of the private extensions and avoid any collision.
实现使用图3中描述的私有扩展结构。这里，私营企业编号是从http://www.iana.org. 这将确保私有扩展的唯一性并避免任何冲突。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Enterprise Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Value :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Structure of a Private Extension
图3：私有扩展的结构
A new unilateral parameter is defined for the MA report block to be used with the Session Description Protocol (SDP) [RFC4566]. In the following ABNF [RFC5234], xr-format is used as defined in [RFC3611].
为要与会话描述协议（SDP）[RFC4566]一起使用的MA报告块定义了一个新的单边参数。在以下ABNF[RFC5234]中，使用[RFC3611]中定义的xr格式。
xr-format =/ multicast-acq-ext multicast-acq-ext = "multicast-acq"
xr format=/multicast acq ext multicast acq ext=“multicast acq”
Refer to Section 5.1 of [RFC3611] for a detailed description and the full syntax of the 'rtcp-xr' attribute.
有关“rtcp xr”属性的详细说明和完整语法，请参阅[RFC3611]的第5.1节。
The security considerations of [RFC3611] apply in this document as well.
[RFC3611]的安全注意事项也适用于本文件。
The information contained in MA reports could be stolen as with any other RTCP reports if proper protection mechanism(s) are not in place. If desired, similar to other RTCP XRs, the MA reports MAY be protected by using Secure RTP (SRTP) and Secure RTP Control Protocol (SRTCP) [RFC3711].
如果没有适当的保护机制，MA报告中包含的信息可能与任何其他RTCP报告一样被盗。如果需要，与其他RTCP XR类似，可以使用安全RTP（SRTP）和安全RTP控制协议（SRTCP）[RFC3711]来保护MA报告。
Malicious sniffing or otherwise obtaining MA report blocks can reveal performance characteristics of the RTP service and underlying network. This information is mostly available to an observer with the ability to capture RTP and RTCP session traffic. The contents and value of any private extension need to be studied when considering the necessity to secure the MA reports since application-level performance data might be present that is not otherwise available to an attacker, as with the required fields and vendor-neutral extensions.
恶意嗅探或以其他方式获取MA报告块可以揭示RTP服务和底层网络的性能特征。此信息主要可供能够捕获RTP和RTCP会话流量的观察者使用。在考虑保护MA报告的必要性时，需要研究任何私有扩展的内容和价值，因为可能存在攻击者无法获得的应用程序级性能数据，如所需字段和供应商中立扩展。
Using the MA reports to provide feedback into the acquisition of the multicast streams can introduce possible additional security implications. If a forged or otherwise modified MA report is received for an earlier acquisition attempt, invalid data can be used as input in later rapid acquisition attempts. For example, incorrectly small SFGMP join times could cause the unicast burst to be too short, leading to gaps in sequence numbers in the approach discussed in [RFC6285]. Additionally, forged reports could give the appearance that rapid acquisition is performing correctly when it is in fact failing, or vice versa. While integrity protection can be achieved in different ways, we RECOMMEND the use of SRTCP [RFC3711].
使用MA报告为多播流的获取提供反馈会引入可能的附加安全含义。如果在早期采集尝试中收到伪造或修改的MA报告，则在以后的快速采集尝试中可以使用无效数据作为输入。例如，SFGMP连接时间过小可能会导致单播突发时间太短，从而导致[RFC6285]中讨论的方法中的序列号出现间隔。此外，伪造的报告可能会让人觉得rapid acquisition在实际失败时运行正常，反之亦然。虽然完整性保护可以通过不同的方式实现，但我们建议使用SRTCP[RFC3711]。
The following contact information is provided for all registrations in this document:
本文件中提供了所有注册的以下联系信息：
Ali Begen abegen@cisco.com
阿里出生abegen@cisco.com
Type value 11 has been registered with IANA for the "Multicast Acquisition Report Block" in the RTCP XR Block Type Registry.
类型值11已向IANA注册，用于RTCP XR块类型注册表中的“多播采集报告块”。
The SDP [RFC4566] parameter 'multicast-acq' for the 'rtcp-xr' attribute has been registered in the RTCP XR SDP Parameters Registry.
“rtcp xr”属性的SDP[RFC4566]参数“multicast acq”已在rtcp xr SDP参数注册表中注册。
A new IANA registry for the MA methods has been created. The registry is called the "Multicast Acquisition Method Registry". This registry is to be managed by IANA according to the Specification Required policy of [RFC5226].
已经为MA方法创建了一个新的IANA注册表。该注册表称为“多播获取方法注册表”。IANA将根据[RFC5226]的规范要求政策管理此注册表。
The length of the MA Method field is a single octet, allowing 256 values. The registry is initialized with the following entries:
MA方法字段的长度为单个八位字节，允许256个值。注册表使用以下项进行初始化：
MA Method Description Reference
--------- ------------------------------------ -------------
0 Reserved [RFC6332]
1 Simple join (No explicit method) [RFC6332]
2 RAMS [RFC6285]
3-254 Unassigned Specification Required
255 Reserved [RFC6332]
MA Method Description Reference
--------- ------------------------------------ -------------
0 Reserved [RFC6332]
1 Simple join (No explicit method) [RFC6332]
2 RAMS [RFC6285]
3-254 Unassigned Specification Required
255 Reserved [RFC6332]
The MA Method values 0 and 255 are reserved for future use.
MA方法值0和255保留供将来使用。
Any registration for an unassigned value needs to contain the following information:
未分配值的任何注册都需要包含以下信息：
o Contact information of the one doing the registration, including at least name, address, and email.
o 注册人的联系信息，至少包括姓名、地址和电子邮件。
o A detailed description of how the MA method works.
o MA方法工作原理的详细说明。
A new IANA TLV space registry for the MA report block extensions has been created. The registry is called the "Multicast Acquisition Report Block TLV Space Registry". This registry is to be managed by the IANA according to the Specification Required policy of [RFC5226].
已为MA报告块扩展创建新的IANA TLV空间注册表。该注册表称为“多播获取报告块TLV空间注册表”。IANA将根据[RFC5226]的规范要求政策管理该注册表。
The length of the Type field in the TLV elements is a single octet, allowing 256 values. The registry is initialized with the following entries:
TLV元素中类型字段的长度为单个八位字节，允许256个值。注册表使用以下项进行初始化：
Type Description Reference
------- -------------------------------------------------- ---------
0 Reserved [RFC6332]
1 RTP Seqnum of the First Multicast Packet [RFC6332]
2 SFGMP Join Time [RFC6332]
3 Application Request-to-Multicast Delta Time [RFC6332]
4 Application Request-to-Presentation Delta Time [RFC6332]
5-10 Unassigned Specification Required
11 Application Request-to-RAMS Request Delta Time [RFC6332]
12 RAMS Request-to-RAMS Information Delta Time [RFC6332]
13 RAMS Request-to-Burst Delta Time [RFC6332]
14 RAMS Request-to-Multicast Delta Time [RFC6332]
15 RAMS Request-to-Burst-Completion Delta Time [RFC6332]
16 Number of Duplicate Packets [RFC6332]
17 Size of Burst-to-Multicast Gap [RFC6332]
18-127 Unassigned Specification Required
128-254 Reserved for private extensions [RFC6332]
255 Reserved [RFC6332]
Type Description Reference
------- -------------------------------------------------- ---------
0 Reserved [RFC6332]
1 RTP Seqnum of the First Multicast Packet [RFC6332]
2 SFGMP Join Time [RFC6332]
3 Application Request-to-Multicast Delta Time [RFC6332]
4 Application Request-to-Presentation Delta Time [RFC6332]
5-10 Unassigned Specification Required
11 Application Request-to-RAMS Request Delta Time [RFC6332]
12 RAMS Request-to-RAMS Information Delta Time [RFC6332]
13 RAMS Request-to-Burst Delta Time [RFC6332]
14 RAMS Request-to-Multicast Delta Time [RFC6332]
15 RAMS Request-to-Burst-Completion Delta Time [RFC6332]
16 Number of Duplicate Packets [RFC6332]
17 Size of Burst-to-Multicast Gap [RFC6332]
18-127 Unassigned Specification Required
128-254 Reserved for private extensions [RFC6332]
255 Reserved [RFC6332]
The Type values 0 and 255 are reserved for future use. The Type values between (and including) 128 and 254 are reserved for private extensions.
类型值0和255保留供将来使用。介于（包括）128和254之间的类型值保留给专用扩展。
Any registration for an unassigned Type value needs to contain the following information:
未分配类型值的任何注册都需要包含以下信息：
o Contact information of the one doing the registration, including at least name, address, and email.
o 注册人的联系信息，至少包括姓名、地址和电子邮件。
o A detailed description of what the new TLV element represents and how it is interpreted.
o 新TLV元素表示的内容以及如何解释的详细说明。
A new IANA TLV space registry for the status codes has been created. The registry is called the "Multicast Acquisition Status Code Space Registry". This registry is to be managed by the IANA according to the Specification Required policy of [RFC5226].
已为状态代码创建新的IANA TLV空间注册表。该注册表称为“多播获取状态代码空间注册表”。IANA将根据[RFC5226]的规范要求政策管理该注册表。
The length of the Status field is two octets, allowing 65536 codes. However, the status codes have been registered to allow for an easier classification. For example, the values between (and including) 1 and 1000 are primarily used by the MA method of simple join. The values between (and including) 1001 and 2000 are used by the MA method described in [RFC6285]. When registering new status codes for the existing MA methods or newly defined MA methods, registrants are
状态字段的长度为两个八位字节，允许使用65536个代码。但是，已注册状态代码，以便于分类。例如，介于（包括）1和1000之间的值主要由简单联接的MA方法使用。1001和2000之间（包括1001和2000）的值由[RFC6285]中所述的MA方法使用。为现有MA方法或新定义的MA方法注册新状态代码时，注册人
encouraged to allocate sufficient continuous space. Note that because of the limited space, not every MA method can be assigned 1000 different values for its status codes.
鼓励分配足够的连续空间。请注意，由于空间有限，并非每个MA方法都可以为其状态代码分配1000个不同的值。
The status code 65535 is reserved for future use. The registry is initialized with the following entries:
状态代码65535保留供将来使用。注册表使用以下项进行初始化：
Code Description Reference
--------- ------------------------------------------------ ---------
0 A private status code is included in the message [RFC6332]
1 Multicast join was successful [RFC6332]
2 Multicast join has failed [RFC6332]
3 A presentation error has occurred [RFC6332]
4 An unspecified RTP receiver internal error has
occurred [RFC6332]
5-1000 Unassigned
1001 RAMS has been successfully completed [RFC6332]
1002 No RAMS-R message has been sent [RFC6332]
1003 Invalid RAMS-I message syntax [RFC6332]
1004 RAMS-I message has timed out [RFC6332]
1005 RAMS unicast burst has timed out [RFC6332]
1006 An unspecified RTP receiver internal error has
occurred during RAMS [RFC6332]
1007 A presentation error has occurred during RAMS [RFC6332]
1008-65534 Unassigned
65535 Reserved [RFC6332]
Code Description Reference
--------- ------------------------------------------------ ---------
0 A private status code is included in the message [RFC6332]
1 Multicast join was successful [RFC6332]
2 Multicast join has failed [RFC6332]
3 A presentation error has occurred [RFC6332]
4 An unspecified RTP receiver internal error has
occurred [RFC6332]
5-1000 Unassigned
1001 RAMS has been successfully completed [RFC6332]
1002 No RAMS-R message has been sent [RFC6332]
1003 Invalid RAMS-I message syntax [RFC6332]
1004 RAMS-I message has timed out [RFC6332]
1005 RAMS unicast burst has timed out [RFC6332]
1006 An unspecified RTP receiver internal error has
occurred during RAMS [RFC6332]
1007 A presentation error has occurred during RAMS [RFC6332]
1008-65534 Unassigned
65535 Reserved [RFC6332]
Any registration for an unassigned status code needs to contain the following information:
未分配状态代码的任何注册都需要包含以下信息：
o Contact information of the one doing the registration, including at least name, address, and email.
o 注册人的联系信息，至少包括姓名、地址和电子邮件。
o A detailed description of what the new status code describes and how it is interpreted.
o 新状态代码描述的内容以及如何解释的详细说明。
This specification has greatly benefited from discussions with Michael Lague, Dong Hsu, Carol Iturralde, Xuan Zhong, Dave Oran, Tom Van Caenegem, and many others. The authors would like to thank each of these individuals for their contributions.
与Michael Lague、Dong Hsu、Carol Iturralde、宣中、Dave Oran、Tom Van Caenegem和其他许多人的讨论极大地促进了本规范的制定。作者要感谢每一位个人的贡献。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 35502003年7月。
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control Protocol Extended Reports (RTCP XR)", RFC 3611, November 2003.
[RFC3611]Friedman，T.，Caceres，R.，和A.Clark，“RTP控制协议扩展报告（RTCP XR）”，RFC 36112003年11月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC6285] Ver Steeg, B., Begen, A., Van Caenegem, T., and Z. Vax, "Unicast-Based Rapid Acquisition of Multicast RTP Sessions", RFC 6285, June 2011.
[RFC6285]Ver Steeg，B.，Begen，A.，Van Caenegem，T.，和Z.Vax，“基于单播的多播RTP会话的快速获取”，RFC 62852011年6月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
Authors' Addresses
作者地址
Ali Begen Cisco 181 Bay Street Toronto, ON M5J 2T3 Canada
Ali Begen Cisco位于加拿大多伦多湾街181号M5J 2T3
EMail: abegen@cisco.com
EMail: abegen@cisco.com
Eric Friedrich Cisco 1414 Massachusetts Ave. Boxborough, MA 01719 USA
Eric Friedrich Cisco美国马萨诸塞州伯斯堡马萨诸塞大道1414号01719
EMail: efriedri@cisco.com
EMail: efriedri@cisco.com