本备忘录状态
ThismemoprovidesinformationfortheInternetcommunity.Itdoes
notspecifyanInternetstandardofanykind.Distributionofthis
memoisunlimited.
版权声明
Copyright(C)TheInternetSociety(2001).
摘要
本备忘录定义了在Internet社区中用于网络治理协议的治理信息库（MIB）的一部分，非凡是定义了治理实时传输协议（RTP）系统（RFC1889）的对象。
目录
1.SNMP治理框架 2
2.概述 3
2.1组件 3
2.2MIB对于RTP系统应用的适用性 3
2.3RTPMIB的结构 4
3.定义 5
4.安全考虑（SecurityConsiderations） 24
5.致谢（Acknowledgements） 25
6.知识产权（IntellectualProperty） 25
7.引用（References） 25
8.作者地址（Authors'Addresses） 27
9.版权声明 28
1.SNMP治理框架
*SNMP治理框架目前包括五个主要的组成部分：
*总体框架，参见RFC2571[RFC2571]的叙述。
*用于治理目的的对象及事件的描述和命名机制。这个治理信息结构（SMI）的第一个版本称为SMIv1，参见STD16,RFC1155,STD16,RFC1212和RFC1215。第二版称为SMIv2，参见STD58,RFC2578[RFC2578],RFC2579[RFC2579]和RFC2580的描述。
*用于传输治理信息的消息协议。SNMP消息协议的第一版称为SNMPv1，由STD15,RFC1157[RFC1157]描述。SNMP消息协议的第二版——不是一项Internet标准跟踪协议——称为SNMPv2c，由RFC1901[RFC1901]andRFC1906[RFC1906]描述。消息协议的第三版称为SNMPv3，由RFC1906[RFC1906],RFC2572[RFC2572]和RFC2574[RFC2574]描述。
*访问治理信息的协议操作。采用PDU格式的第一个协议操作集合由STD15,RFC1157[RFC1157]描述，采用PDU格式的第二个协议操作集合由RFC1905[RFC1905]描述。
*RFC2573[RFC2573]描述了一系列基础应用，RFC2575[RFC2575]描述了基于视图的访问控制机制。
关于SNMP治理框架的更加具体的描述参见RFC2570[RFC2570]。
通过虚拟信息存储访问治理对象称为治理信息库或者MIB。MIB的对象使用SMI定义的机制定义。
本备忘录描述了适应SMIv2的MIB模型。通过适当的转化可以得到遵循SMIv1的MIB。转换后的MIB必须在语义上式等价的，除非不可能转换而不得不忽略的对象及事件（Counter64的使用)。SMIv2的一些机器易读的信息在转换的过程中必须转化成SMIv1的文本描述。不过这种极其易读信息的损失不认为是改变了MIB的语义。
2.概述
一个“RTP系统”可能是运行着发送或者接受RTP数据包的应用程序的主机终端系统，也可能是转发RTP包的中介系统。接收方和发送方通过发送RTP控制协议（RTCP）包交换RTP包传输和接收的信息[RFC1889]。RTP监视器可以在接收方或发送方上采集发往或者来自主机/中介系统的RTCP信息。
本文档中的要害字“必须”、“不能”、“需要”、“应”、“不应”、“应该”、“不应该”、“建议”、“可以”和“可选”的含义与RFC2119的解释一致。
2.1组件
RTPMIB是围绕着“Session”、“Receiver”和“Sender”等抽象概念建立的。
2.1.1按照[RFC1889]节3的定义，“RTP会话”是“...参与者与RTP通信的连接。每个参与者都有一个会话，会话是由一个特定的目标传输地址对定义的（网络地址和用于RTP及RTCP的一对端口）。可能所有的参与者使用同一个目标传输地址，比如IP多点传送的情况；也可能每个参与者都有不同的目标传输地址，比如单个的单点传送地址加上一个通用的端口对。”
2.1.2在RTP会话中“发送方”表示为一个32位的数字——“同步资源”或者“SRRC”，根据[RFC1889]节3的定义，它是“......RTP数据包流的源头”。
2.1.3如前面2.1.1节所述，“RTP数据包流”的“接收方”可以是单点传送，也可以是多点传送的接受者。RTP接收方有对于该会话唯一的SSRC值。如[RFC1889]节6所述，RTP接收方是RTCP接收方报告的一个来源。
2.2MIB对于RTP系统应用的适用性
RTPMIB可用于两种类型的RTP应用：
1、RTP主机系统（终端系统）和RTP监视器，参见[RFC1889]节3；
2、RTPMIB在RTP翻译器（Translators）和混合器中（Mixers）的应用——参见[RFC1889]节7——还有待于进一步研究。
2.2.1RTP主机系统是可以使用RTPMIB采集主机发送/接收RTP会话和RTP流数据的终端系统，网络治理员可以利用这些数据——比如在“帮助桌面”中——检查和诊断RTP会话生命期中出现的故障。
2.2.2多点传送RTP会话中的RTP监视器可以是第三方，也可以放在RTP主机上。RTP监视器可以使用RTPMIB采集RTP会话和流的统计数据，网络治理员可以利用这些数据编制网络容量计划或者用于其他的网络治理目标。RTP监视器可以通过RTPMIB采集数据以便网络治理员检查和诊断RTP会话故障或者设置其操作。
2.2.3许多主机系统需要保留自身收发数据以外的流的记录。在主机监视系统中，主机代理可以利用来自主机的RTP数据维护主机发送流和接收流的数据，利用其RTCP数据采集会话中其它主机的数据。举例来说，发送流的主机代理可以利用其RTP系统数据维护表rtpSenderTable，但是可能还需要为接收流的对方维护rtpRcvrTable表。要做到这一点，RTP代理必须从流的接收方采集RTCP数据构造rtpRcvrTable表。主机监视器系统必须（MUST）把对象rtpSessionMonitor设定为“true(1)”，但不一定要接受在其表中创建或者清除行的治理操作。
2.3RTPMIB的结构
在RTPMIB中有6个表。表rtpSessionTable包括描述主机或者监视器上的活动会话的对象。表tpSenderTable保存了RTP会话中发送方的信息。表rtpRcvrTable包含RTP会话数据中接收方的信息。表rtpSessionInverseTable、表rtpSenderInverseTable和表rtpRcvrInverseTable分别保存了有效查找rtpSessionTable，rtpSenderTable，和rtpRcvrTable索引的信息。
逆序检索表(rtpSessionInverseTable，rtpSenderInverseTable，和rtpRcvrInverseTable)是可选的表，用于帮助治理程序有效的访问其他表中的逻辑行。假如不能从其他方的MIB访问表索引（rtpSessionTable表的索引rtpSessionIndex、rtpSenderTable的索引rtpSenderSSRC、rtpRcvrTable的SSRC对），执行MIB的这一方应该为多点传送的RTP会话实现这些表。否则，治理程序就得遍历巨大的包括会话、发送方和接收方的树。
对于一些非凡的RTP会话，对象rtpSessionMonitor标明了是否需要对RTP会话中的远程的接收方或者发送方进行监视。假如rtpSessionMonitor为真（1），那么会话中的发送方和接收方都必须在rtpSenderTable和rtpRcvrTable中建立相应的条目予以监视。RTP代理负责监视RTP会话，根据来自远程发送方或者接收方的RTCP报告的信息分别更新相应的rtpSenderTable和rtpRcvrTable对象。
RtpSessionNewIndex是一个全局对象，使网络治理程序能够为在rtpSessionTable中创建的逻辑行保持一个索引。这样就可以使用SNMP的SET操作配置监视器。
3.定义
RTP-MIBDEFINITIONS::=BEGIN
IMPORTS
Counter32,Counter64,Gauge32,mib-2,Integer32,MODULE-IDENTITY,
OBJECT-TYPE,Unsigned32FROMSNMPv2-SMI
RowStatus,TAddress,
TDomain,TestAndIncr,
TimeStamp,TruthValueFROMSNMPv2-TC
OBJECT-GROUP,MODULE-COMPLIANCEFROMSNMPv2-CONF
Utf8StringFROMSYSAPPL-MIB
InterfaceIndexFROMIF-MIB;
rtpMIBMODULE-IDENTITY
LAST-UPDATED"200010020000Z"--2000年10月2日
ORGANIZATION
"IETFAVTWorkingGroup
Email:rem-conf@es.net"
CONTACT-INFO
"MarkBaugher
Postal:IntelCorporation
2111NE25thAvenue
Hillsboro,OR97124
UnitedStates
Tel:+15034668406
Email:mbaugher@passedge.com
BillStrahm
Postal:IntelCorporation
2111NE25thAvenue
Hillsboro,OR97124
UnitedStates
Tel:+15032644632
Email:bill.strahm@intel.com
IrinaSUConick
Postal:EnnovateNetworks
60CodmanHillRd.,
Boxboro,Ma01719
Tel:+1781-505-2155
Email:irina@ennovatenetworks.com"
说明
“RTP系统的治理对象。MIB是基于三种类型的信息建立的。
1.RTP会话的通用信息，如会话的地址。
2.关于某个特定的发送方发送到RTP会话的RTP流的信息。
3.关于某个特定的接收方通过RTP会话从特定的发送方接收的RTP流的信息。
RTP系统有两种类型，RTP主机和RTP监视器。如后面所讲的，特定的对象适用于特定类型的RTP系统。RTP主机也可以像RTP监视器一样运行。定义参见RFC1889“RTP：实时程序的传输协议”第三节。”
REVISION"200010020000Z"--2October2000
说明“MIB初始版本，公布为RFC2959”"
::={mib-287}
--
--OBJECTS
--
rtpMIBObjectsOBJECTIDENTIFIER::={rtpMIB1}
rtpConformanceOBJECTIDENTIFIER::={rtpMIB2}
--
--新会话索引（SESSIONNEWINDEX）
--
rtpSessionNewIndex对象类型
语法TestAndIncr
最高访问限制读写
状态当前
说明
“按照“SMIv2文本约定”的描述，这个对象用来为rtpSessionIndex赋值。对于支持创建行的RTP系统，网络治理员可以读取这个对象，然后使用SET方法回写创建新的rtpSessionEntry实例。假如SET返回错误码“inconsistentValue”，必须重复这个过程；假如SET成功，对象就增加了，按照治理员的指示创建了新的实例。但是假如RTP代理不是担任监视器的角色，只有RTP代理能够在RTP会话表中创建逻辑行。”
::={rtpMIBObjects1}
--
--会话逆序表（SESSIONINVERSETABLE）
--
rtpSessionInverseTable对象类型
语法SEQUENCEOFRtpSessionInverseEntry
最高访问限制不可访问
状态当前
说明
“把rtpSessionDomain,rtpSessionRemAddr和rtpSessionLocAddrTaddress对映射为一个或多个rtpSessionIndex值，每个值对应rtpSessionTable表的一行。这样不需要遍历整个（可能是巨大的）rtpSessionTable表，就可以获得与给定的会话对应的一行或者几行。”
::={rtpMIBObjects2}
rtpSessionInverseEntry对象类型
语法RtpSessionInverseEntry
最高访问限制不可访问
状态当前
说明
“每个条目与表rtpSessionTable一个确定的条目相对应——每个条目包括元组、rtpSessionDomain、rtpSessionRemAddr、rtpSessionLocAddr和rtpSessionIndex。”
INDEX{rtpSessionDomain,rtpSessionRemAddr,rtpSessionLocAddr,
rtpSessionIndex}
::={rtpSessionInverseTable1}
RtpSessionInverseEntry::=SEQUENCE{
rtpSessionInverseStartTimeTimeStamp
}
rtpSessionInverseStartTime对象类型
语法TimeStamp
最高访问限制只读
状态当前
说明
“本行创建时SysUpTime的值。”
::={rtpSessionInverseEntry1}
--
--会话表（SESSIONTABLE）
--
rtpSessionTable对象类型
语法SEQUENCEOFRtpSessionEntry
最高访问限制不个访问
状态当前
说明
“每个RTP会话——发送包、接收包和/或监视的会话——在rtpSessionTable表中都有对应的条目。”
::={rtpMIBObjects3}
rtpSessionEntry对象类型
语法RtpSessionEntry
最高访问限制不可访问
状态当前
说明
“rtpSessionTable中的数据唯一的标志了一个RTP会话。主机的RTP代理必须为每个发送包或接收包的会话建立一个只读的行。RTP代理必须在会话的一开始——在检测到一个或者多个发送方/接收方之前——创建行。会话结束后必须删除RTP创建的行，不应再有这个会话的rtpRcvrEntry和rtpSenderEntry条目。假如rtpSessionMonitor值为真“True（1）”，应监视会话中所有发送和接收的RTP流创建治理信息。RTP监视器应答应创建行，这样做的影响是造成RTP系统加入多点传送会话以收集治理信息（在rtpRcvrTable和rtpSenderTable表中增加额外的概念行）。因此表rtpSessionTable应只包含用于监视RTP会话的行，治理程序创建的行应通过SNMP操作删除，治理操作创建的行应由治理操作通过把rtpSessionRow的状态设为“destroy(6)”删除。”
INDEX{rtpSessionIndex}
::={rtpSessionTable1}
RtpSessionEntry::=SEQUENCE{
rtpSessionIndexInteger32,
rtpSessionDomainTDomain,
rtpSessionRemAddrTAddress,
rtpSessionLocAddrTAddress,
rtpSessionIfIndexInterfaceIndex,
rtpSessionSenderJoinsCounter32,
rtpSessionReceiverJoinsCounter32,
rtpSessionByesCounter32,
rtpSessionStartTimeTimeStamp,
rtpSessionMonitorTruthValue,
rtpSessionRowStatusRowStatus
}
rtpSessionIndex对象类型
语法Integer32(1..2147483647)
最高访问限制不可访问
状态当前
说明
“逻辑行的索引，仅用于SNMP，与任何协议值无关。没有必要继续创建或者维护这些行。”
::={rtpSessionEntry1}
rtpSessionDomain对象类型
语法TDomain
最高访问限制读/创建
状态当前
说明
“该会话发送或者接受RTP数据包流的传输层协议。假如rtpSessionRow处于激活（active）状态，不可改变。”
::={rtpSessionEntry2}
rtpSessionRemAddr对象类型
语法TAddress
最高访问限制读/创建
状态当前
说明
“RTP系统发送RTP包的目标地址。在IP多点传送RTP会话中，这是RTP会话数据的所有发送方和接收方使用的唯一地址。在单点传送RTP会话中，这是远程RTP系统的单点传送地址。‘所有的参与者可能共享一个目标地址，比如IP多点传送的情况；也可能各自具有不同的目标地址，比如单个的单点传送网络地址对’。参见RFC1889[RTP：实时程序的传输协议]第三节。传输服务由rtpSessionDomain标志。对于snmpUDPDomain，它是一个IP地址和一个偶数UDP端口，相邻较大的奇数端口发送RTCP，见RFC1889第五节。”
::={rtpSessionEntry3}
rtpSessionLocAddr对象类型
语法TAddress
最高访问限制只读
状态当前
说明
“RTP系统使用的本地地址。在IP多点传送RTP会话中，rtpSessionRemAddr是与rtpSessionLocAddr相同的IP多点传送地址。在单点传送RTP会话中，rtpSessionRemAddr和rtpSessionLocAddr具有不同的单点传送地址。参见RFC1889，‘RTP:实时程序的传输协议’第三节。传输服务由rtpSessionDomain标志。对于snmpUDPDomain，它是一个IP地址和一个偶数UDP端口，相邻较大的奇数端口发送RTCP，见RFC1889第五节。”
::={rtpSessionEntry4}
rtpSessionIfIndex对象类型
语法InterfaceIndex
最高访问限制读/创建
状态当前
说明
“ifIndex的值被设为IF-MIB的响应值(见RFC2233,‘应用SMIv2的界面组（InterfacesGroup）MIB’)。这是RTP流发送和接收的界面，对于RTP监视器则是接收RTCP包的界面。假如rtpSessionRowStatus为‘active’不可修改。”
::={rtpSessionEntry5}
rtpSessionSenderJoins对象类型
语法Counter32
最高访问限制只读
状态当前
说明
“自本概念行创建（rtpSessionStartTime）起检测到的参与会话的发送方的数目。发送方通过向会话发送数据参与会话。在RTCPBYE（见RFC1889，‘RTP：实时程序的传输协议’6.6节）之后中途离开又重新参与的发送方或者会话超时可能被重复计数。只要检测到新的RTP发送方，无论使用RTP还是RTCP，这个计数都会增加。”
::={rtpSessionEntry6}
rtpSessionReceiverJoins对象类型
语法Counter32
最高访问限制只读
状态当前
说明
“自本概念行创建（rtpSessionStartTime）起检测到的参与会话的接收方的数目。接收方通过向会话发送RTCP接收报告参与会话。在RTCPBYE（见RFC1889，‘RTP：实时程序的传输协议’6.6节）之后中途离开又重新参与的接收方或者会话超时可能被重复计数。”
::={rtpSessionEntry7}
rtpSessionByes对象类型
语法Counter32
最高访问限制只读
状态当前
说明
“该实体收到的RTCPBYE（见RFC1889，‘RTP：实时程序的传输协议’6.6节）消息的计数。”
::={rtpSessionEntry8}
rtpSessionStartTime对象类型
语法TimeStamp
最高访问限制只读
状态当前
说明
“该行创建时SysUpTime的值。”
::={rtpSessionEntry9}
rtpSessionMonitor对象类型
语法TruthValue
最高访问限制只读
状态当前
说明
“布尔值，假如除了本地RTP系统之外，还需要使用RTCP监视远程的发送方或者接收方，将该值设为真‘true(1)’。RTP监视器必须初始化为‘true(1)’，RTP主机则应初始化为‘false(2)’。注重，‘主机监视器’从远程伙伴接收RTCP，因此必须把这个值设为‘true(1)’。”
::={rtpSessionEntry10}
rtpSessionRowStatus对象类型
语法RowStatus
最高访问限制读/创建
状态当前
说明
“在一个RTP系统发送/接收RTP或RTCP消息时其值为‘Active’。新建的概念行在其所有读/创建对象初始化完成之前不会处于激活状态‘Active’。处于‘notReady’或者‘notInService’状态的概念行可能在5分钟之后删除。”
::={rtpSessionEntry11}
--
--发送方逆序表（SENDERINVERSETABLE）
--
rtpSenderInverseTable对象类型
语法SEQUENCEOFRtpSenderInverseEntry
最高访问限制不可访问
状态当前
说明
“把rtpSenderAddr和rtpSessionIndex映射成rtpSenderTable表的rtpSenderSSRC索引。该表答应治理程序根据rtpSenderAddr排序而不是根据rtpSessionIndex排序查找条目。给定了rtpSessionDomain和rtpSenderAddr，可以通过遍历树返回一系列的rtpSessionIndex和rtpSenderSSRC值。假如在SNMP的Get-Next操作中指定rtpSessionIndex，可以返回一个或多个rtpSenderSSRC值。”
::={rtpMIBObjects4}
rtpSenderInverseEntry对象类型
语法RtpSenderInverseEntry
最高访问限制不可访问
状态当前
说明
“每个条目都和rtpSenderTable表中确定的条目相对应——条目包含索引对、rtpSessionIndex和rtpSenderSSRC。”
INDEX{rtpSessionDomain,rtpSenderAddr,rtpSessionIndex,
rtpSenderSSRC}
::={rtpSenderInverseTable1}
RtpSenderInverseEntry::=SEQUENCE{
rtpSenderInverseStartTimeTimeStamp
}
rtpSenderInverseStartTime对象类型
语法TimeStamp
最高访问限制只读
状态当前
说明
“改行创建时SysUpTime的值。“
::={rtpSenderInverseEntry1}
--
--发送方表（SENDERSTABLE）
--
rtpSenderTable对象类型
语法SEQUENCEOFRtpSenderEntry
最高访问限制不可访问
状态当前
说明
“保存RTP会话中发送方的信息的表。必须为每个RTP流的发送主机在该表中建立相应的条目，该表还可能包含这些发送流的接收方主机的条目。假如rtpSessionTable的一个概念行被治理器（manager）激活（Active），则RTP监视器必须为多点传送会话中的每个检测到的发送方建立相应的条目。
::={rtpMIBObjects5}
rtpSenderEntry对象类型
语法RtpSenderEntry
最高访问限制不可访问
状态当前
说明
“每个条目包含一个RTP发送方同步资源（SSRC，见RFC1889‘RTP：实时程序的传输协议’）的信息。会话作为SNMP实体使用rtpSessionIndex区分。假如受到来自发送方的BYE消息，或者发送方超时（见RFC18896.2.1节），或者rtpSessionEntity被删除，RTP代理就删掉这一行。”
INDEX{rtpSessionIndex,rtpSenderSSRC}
::={rtpSenderTable1}
RtpSenderEntry::=SEQUENCE{
rtpSenderSSRCUnsigned32,
rtpSenderCNAMEUtf8String,
rtpSenderAddrTAddress,
rtpSenderPacketsCounter64,
rtpSenderOctetsCounter64,
rtpSenderToolUtf8String,
rtpSenderSRsCounter32,
rtpSenderSRTimeTimeStamp,
rtpSenderPTINTEGER,
rtpSenderStartTimeTimeStamp
}
rtpSenderSSRC对象类型
语法Unsigned32
最高访问限制不可访问
状态当前
说明
“RTPSSRC，或者说发送方的同步资源标识符。RTP会话地址加上SSRC唯一确定了某个RTP会话中的一个发送方（见RFC1889，‘RTP：实时程序的传输协议’第3节）。”
::={rtpSenderEntry1}
rtpSenderCNAME对象类型
语法Utf8String
最高访问限制只读
状态当前
说明
“发送方的RTP规范名称。”
::={rtpSenderEntry2}
rtpSenderAddr对象类型
语法TAddress
最高访问限制只读
状态当前
说明
“发送方的单点传送资源地址，对于RTP监视器它是发送方用来发送‘RTCP发送报告’的地址。”
::={rtpSenderEntry3}
rtpSenderPackets对象类型
语法Counter64
最高访问限制只读
状态当前
说明
“自rtpSenderStartTime起，该发送方发出的RTP包的个数，或者RTP监视器监测到的RTP包的个数。”
::={rtpSenderEntry4}
rtpSenderOctets对象类型
语法Counter64
最高访问限制只读
状态当前
说明
“自rtpSenderStartTime起，该发送方发出的非报头RTP8位字节数，或者RTP监视器监测到的字节数”
::={rtpSenderEntry5}
rtpSenderTool对象类型
语法Utf8String(SIZE(0..127))
最高访问限制只读
状态当前
说明
“流的应用程序资源名称。”
::={rtpSenderEntry6}
rtpSenderSRs对象类型
语法Counter32
最高访问限制只读
状态当前
说明
“自rtpSenderStartTime起，该发送方发出的‘RTCP发送报告’个数，假如RTP实体是一个监视器就是检测到的发送报告数。”
::={rtpSenderEntry7}
rtpSenderSRTime对象类型
语法TimeStamp
最高访问限制只读
状态当前
说明
“对于监视器或者接收主机而言，rtpSenderSRTime是最后一个SR收到的那一刻SysUpTime的值，对于发送主机则是发出最后一个SR的那一刻。”
::={rtpSenderEntry8}
rtpSenderPT对象类型
语法INTEGER(0..127)
最高访问限制只读
状态当前
说明
“最近收到的RTP包的RTP头中的有效载荷类型（见RFC1889‘RTP：实时程序的传输协议’）。”
::={rtpSenderEntry9}
rtpSenderStartTime对象类型
语法TimeStamp
最高访问限制只读
状态当前
说明
“该行创建时SysUpTime的值。”
::={rtpSenderEntry10}
--
--接收方逆序表（RECEIVERINVERSETABLE）
--
rtpRcvrInverseTable对象类型
语法SEQUENCEOFRtpRcvrInverseEntry
最高访问限制不可访问
状态当前
说明
“把rtpRcvrAddr和rtpSessionIndex映射成rtpRcvrTable的索引表rtpRcvrSRCssRC和rtpRcvrSSRC。该表答应治理程序根据rtpRcvrAddr排序查找条目，而不是根据rtpSessionIndex。对于给定的rtpSessionDomain和rtpRcvrAddr，通过遍历树可以返回一系列的rtpSessionIndex、rtpRcvrSRCSSRC和rtpRcvrSSRC值。假如在SNMP的Get-Next操作中指定了rtpSessionIndex，则返回一个或多个rtpRcvrSRCSSRC/rtpRcvrSSRC对。”
::={rtpMIBObjects6}
rtpRcvrInverseEntry对象类型
语法RtpRcvrInverseEntry
最高访问限制不可访问
状态当前
说明
“每一项恰恰与表rtpRcvrTable的一项对应，包括索引对、rtpSessionIndex、rtpRcvrSSRC。”
INDEX{rtpSessionDomain,rtpRcvrAddr,rtpSessionIndex,
rtpRcvrSRCSSRC,rtpRcvrSSRC}
::={rtpRcvrInverseTable1}
RtpRcvrInverseEntry::=SEQUENCE{
rtpRcvrInverseStartTimeTimeStamp
}
rtpRcvrInverseStartTime对象类型
语法TimeStamp
最高访问限制只读
状态当前
说明
“该行创建时SysUpTime的值。”
::={rtpRcvrInverseEntry1}
--
--接收方表（RECEIVERSTABLE）
--
rtpRcvrTable对象类型
语法SEQUENCEOFRtpRcvrEntry
最高访问限制不可访问e
状态当前
说明
“保存RTP会话数据中接收方（可能有多个）信息的表。必须为收/发对中接收RTP会话包的RTP主机在该表中创建相应的条目，使用RTP组的RTCP反馈信息，该表也可以为每个接收方创建相应的发送RTP会话包的主机条目。假如rtpSessionTable的某个概念行被治理器（manager）激活‘Active’，RTP监视器就为该会话中每个检测到的接收方创建相应的条目。”
::={rtpMIBObjects7}
rtpRcvrEntry对象类型
语法RtpRcvrEntry
最高访问限制不可访问
状态当前
说明
“每一项都保存了一个接收包的RTP同步资源的信息，相应的发送方由rtpRcvrSRCSSRC标识（SSRC，见RFC1889，‘RTP：实时程序的传输协议’节6）。RTP代理实体使用rtpSessionIndex标识会话。假如收到发送方的BYE消息、或者发送方超时、或者rtpSessionEntity被删除，RTP代理将删除该行。”
INDEX{rtpSessionIndex,rtpRcvrSRCSSRC,rtpRcvrSSRC}
::={rtpRcvrTable1}
RtpRcvrEntry::=SEQUENCE{
rtpRcvrSRCSSRCUnsigned32,
rtpRcvrSSRCUnsigned32,
rtpRcvrCNAMEUtf8String,
rtpRcvrAddrTAddress,
rtpRcvrRTTGauge32,
rtpRcvrLostPacketsCounter64,
rtpRcvrJitterGauge32,
rtpRcvrToolUtf8String,
rtpRcvrRRsCounter32,
rtpRcvrRRTimeTimeStamp,
rtpRcvrPTINTEGER,
rtpRcvrPacketsCounter64,
rtpRcvrOctetsCounter64,
rtpRcvrStartTimeTimeStamp
}
rtpRcvrSRCSSRC对象类型
语法Unsigned32
最高访问限制不可访问
状态当前
说明
“RTPSSRC，或者说发送方的同步资源标识符。RTP会话地址加上SSRC唯一确定了某个RTP会话中的一个发送方（见RFC1889，‘RTP：实时程序的传输协议’第3节）。”
::={rtpRcvrEntry1}
rtpRcvrSSRC对象类型
语法Unsigned32
最高访问限制不可访问
状态当前
说明
“RTPSSRC，或者说接收方的同步资源标识符。RTP会话地址加上SSRC唯一确定了某个RTP流中的一个发送方（见RFC1889，‘RTP：实时程序的传输协议’第3节）。”
::={rtpRcvrEntry2}
rtpRcvrCNAME对象类型
语法Utf8String
最高访问限制只读
状态当前
说明
“接收方的RTP规范名称。“
::={rtpRcvrEntry3}
rtpRcvrAddr对象类型
语法TAddress
最高访问限制只读
状态当前
说明
“接收方接收RTP包和/或RTCP接受报告的单点传送地址。”
::={rtpRcvrEntry4}
rtpRcvrRTT对象类型
语法Gauge32
最高访问限制只读
状态当前
说明
“基于RFC1889‘RTP：实时程序的传输协议’节6描述的算法，RTP流的源对往返时间的测度。假如RTP代理和流的发送方使用相同的时钟（对于特定的接收方来说RTP监视器同时也是发送主机），该算法能够产生有意义的结果。否则，该实体返回‘noSuchInstance’响应对rtpRcvrRTT的查询。”
::={rtpRcvrEntry5}
rtpRcvrLostPackets对象类型
语法Counter64
最高访问限制只读
状态当前
说明
“自rtpRcvrStartTime起该接收方检测到的丢失的RTP包的数量。”
::={rtpRcvrEntry6}
rtpRcvrJitter对象类型
语法Gauge32
最高访问限制只读
状态当前
说明
“对该接收方检测到的延迟变化的评估。（见RFC1889,‘RTP:实施程序的传输协议’节6.3.1及A.8）”
::={rtpRcvrEntry7}
rtpRcvrTool对象类型
语法Utf8String(SIZE(0..127))
最高访问限制只读
状态当前
说明
“流的应用程序资源名称。”
::={rtpRcvrEntry8}
rtpRcvrRRs对象类型
语法Counter32
最高访问限制只读
状态当前
说明
“自rtpRcvrStartTime起，该接收方发出的RTCP接收方报告的数量，对于RTP监视器则是其检测到的接收方报告数量。”
::={rtpRcvrEntry9}
rtpRcvrRRTime对象类型
语法TimeStamp
最高访问限制只读
状态当前
说明
“对于监视器或者RR接收方（RTP的发出者），rtpRcvrRRTime是收到最后一份RTCP接收方报告的那一刻SysUpTime的值。假如是RTP接收方发送RR的情况，它就是该接收方发出最后也各RR时SysUpTime的值。”
::={rtpRcvrEntry10}
rtpRcvrPT对象类型
语法INTEGER(0..127)
最高访问限制只读
状态当前
说明
“RTP头中动态或静态的有效载荷的类型。（见RFC1889，‘RTP：实时程序的传输协议’节5）”
::={rtpRcvrEntry11}
rtpRcvrPackets对象类型
语法Counter64
最高访问限制只读
状态当前
说明
“自rtpRcvrStartTime起，该RTP主机接收方收到的RTP包的数量。”
::={rtpRcvrEntry12}
rtpRcvrOctets对象类型
语法Counter64
最高访问限制只读
状态当前
说明
“自rtpRcvrStartTime起，该RTP接收主机收到的非RTP头的8位字节数。”
::={rtpRcvrEntry13}
rtpRcvrStartTime对象类型
语法TimeStamp
最高访问限制只读
状态当前
说明
“该行创建时SysUpTime的值。”
::={rtpRcvrEntry14}
--
--模型组（ODULEGROUPS）
--
--
--有两种类型的RTP系统：RTP主机和RTP监视器。因而有三种对象：1）适用于两种系统--的通用对象；2）仅用于RTP主机的对象；3）仅用于RTP监视器的对象。另外还有一组，--4）将用于多点传送主机和RTP监视器的对象
rtpGroupsOBJECTIDENTIFIER::={rtpConformance1}
rtpSystemGroupOBJECT-GROUP
OBJECTS{
rtpSessionDomain,
rtpSessionRemAddr,
rtpSessionIfIndex,
rtpSessionSenderJoins,
rtpSessionReceiverJoins,
rtpSessionStartTime,
rtpSessionByes,
rtpSessionMonitor,
rtpSenderCNAME,
rtpSenderAddr,
rtpSenderPackets,
rtpSenderOctets,
rtpSenderTool,
rtpSenderSRs,
rtpSenderSRTime,
rtpSenderStartTime,
rtpRcvrCNAME,
rtpRcvrAddr,
rtpRcvrLostPackets,
rtpRcvrJitter,
rtpRcvrTool,
rtpRcvrRRs,
rtpRcvrRRTime,
rtpRcvrStartTime
}
状态当前
说明
“适用于所有RTP系统的对象”
::={rtpGroups1}
rtpHostGroupOBJECT-GROUP
OBJECTS{
rtpSessionLocAddr,
rtpSenderPT,
rtpRcvrPT,
rtpRcvrRTT,
rtpRcvrOctets,
rtpRcvrPackets
}
状态当前
说明
“适用于RTP主机系统但可能不是用于RTP监视器系统的对象。”
::={rtpGroups2}
rtpMonitorGroupOBJECT-GROUP
OBJECTS{
rtpSessionNewIndex,
rtpSessionRowStatus
}
状态当前
说明
“在RTP会话表中创建行的对象，假如系统不创建行则不需要这些对象。”
::={rtpGroups3}
rtpInverseGroupOBJECT-GROUP
OBJECTS{
rtpSessionInverseStartTime,
rtpSenderInverseStartTime,
rtpRcvrInverseStartTime
}
状态当前
说明
“用于逆序查找表（InverseLookupTable）的对象。”
::={rtpGroups4}
--
--一致性（Compliance）
--
rtpCompliancesOBJECTIDENTIFIER::={rtpConformance2}
rtpHostComplianceMODULE-COMPLIANCE
状态当前
说明
“主机系统必须遵循。”
MODULERTP-MIB
MANDATORY-GROUPS{
rtpSystemGroup,
rtpHostGroup
}
GROUPrtpMonitorGroup
说明
“主机系统可以选择支持创建和删除行，从而可以作为RTP监视器使用。”
GROUPrtpInverseGroup
说明
“多点传送RTP系统应实现这个可选的表。”
OBJECTrtpSessionNewIndex
最低访问限制不可访问
说明
“RTP系统对创建行与删除行的支持是可选的，因而该对象的实现也是可选的。”
OBJECTrtpSessionDomain
最低访问限制只读
说明
“RTP系统对创建行与删除行的支持是可选的。假如不支持，写操作也是可选的。“
OBJECTrtpSessionRemAddr
最低访问限制只读
说明
“RTP系统对创建行与删除行的支持是可选的，因而该对象的读/创建操作也是可选的。”
OBJECTrtpSessionIfIndex
最低访问限制只读
说明
“行的创建与删除是可选的，因而该对象的读/创建操作也是可选的。”
OBJECTrtpSessionRowStatus
最低访问限制不可访问
说明
“行的创建与删除是可选的，因而该对象的读/创建操作也是可选的。”
OBJECTrtpSessionInverseStartTime
最低访问限制不可访问
说明
“多点传送RTP系统应实现该可选表。”
OBJECTrtpSenderInverseStartTime
最低访问限制不可访问
说明
“多点传送RTP系统应实现该可选表。”
OBJECTrtpRcvrInverseStartTime
最低访问限制不可访问
说明
“多点传送RTP系统应实现该可选表。”
::={rtpCompliances1}
rtpMonitorComplianceMODULE-COMPLIANCE
状态当前
说明
“监视器应用必须遵循。不要求RTP监视器支持创建和删除。”
MODULERTP-MIB
MANDATORY-GROUPS{
rtpSystemGroup,
rtpMonitorGroup
}
GROUPrtpHostGroup
说明
“监视器应用可能无法访问rtpHostGroup的值。”
GROUPrtpInverseGroup
说明
“多点传送RTP系统应实现该可选表。”
OBJECTrtpSessionLocAddr
最低访问限制不可访问
说明
“RTP监视器追踪RTP或者RTCP包的来源是可选的，因而该对象的应用也是可选的。”
OBJECTrtpRcvrPT
最低访问限制不可访问
说明
“RTP监视器可能不支持从RTP头中访问RTP由载荷类型（仅仅接收RTCP消息）。用于获取有效载荷类型信息。”
OBJECTrtpSenderPT
最低访问限制不可访问
说明
"RTPmonitorsystemsmaynotsupport
retrievaloftheRTPPayloadTypefromtheRTP
header(andmayreceiveRTCPmessagesonly).When
queriedforthepayloadtypeinformation."
OBJECTrtpRcvrOctets
最低访问限制不可访问
说明
“RTP监视器可能只接收RTCP消息，而不接收包含8位字节个数的RTP消息，因而该对象的应用是可选的。”
OBJECTrtpRcvrPackets
最低访问限制不可访问
说明
“RTP监视器可能只接收RTCP消息，而不接收包含8位字节个数的RTP消息，因而该对象的应用是可选的。”
OBJECTrtpSessionIfIndex
最低访问限制不可访问
说明
“行的创建和删除是可选的，因而该对象的读/创建访问也是可选的。”
OBJECTrtpSessionInverseStartTime
最低访问限制不可访问
说明
“多点传送RTP系统应实现这个可选的表。”
OBJECTrtpSenderInverseStartTime
最低访问限制不可访问
说明
“多点传送RTP系统应实现这个可选的表。”
OBJECTrtpRcvrInverseStartTime
最低访问限制不可访问
说明
“多点传送RTP系统应实现这个可选的表。”
::={rtpCompliances2}
END
4.安全考虑（SecurityConsiderations）
大多数情况下，MIB本身没有安全性风险；假如计划处理SNMP的安全性，查看系统的信息或者修改系统的某些参数时，MIB是一个工具而不是一个威胁。不过本MIB定义的治理对象中，由几个带有标明读写和/或读-创建的最高访问限制子句。这些对象可能被认为在某些网络环境下是敏感的或者说轻易受到攻击。在不安全的、缺乏适当保护的环境下，对SET操作的支持可能对网络操作带来负面的影响。
本MIB中没有一个只读对象会报告密码，尽管一些SDES[RFC1889]项如CANME——规范名——可能被认为敏感地依靠于某个特定公司的安全策略。假如没有适宜的访问控制策略限制对这些对象的访问，这些对象可能造成对系统配置信息和系统服务的攻击。有些企业既查看网络和系统配置，又浏览使用和性能的信息，甚至还有企业的资产状况，这样的企业可能会希望限制对MIB中大部分对象的SNMP访问。本MIB支持对rtpSessionNewIndex的读写操作，带来的副作用是在对该项进行写操作时，需要在表rtpSessionTable中创建相应的条目。rtpSessionEntry中有5个对象可以进行读/创建访问：rtpSessionDomain、rtpSessionRemAddr、rtpSessionIfIndex、rtpSessionRowStatus、和rtpSessionIfAddr确定了在特定界面上（interface）监视的一个RTP会话。这些对象的值一经创建就不能改变，对这些对象的初始化仅仅影响对会话的监视，而不影响主机终端系统对RTP会话的操作。因为rtpSessionNewIndex的写操作和rtpSessionEntry中的5个对象影响监视器的操作，对这些对象的写操作应该遵从适宜的访问控制策略。
RTP和RTCP数据包的机密性在RTP规范[RTP1899]中的节9中定义。可以对RTP包或者RTCP包加密，也可以对二者都加密。对RTCP包加密可能对第三方监视器带来问题，尽管“对于RTCP，答应把混合RTCP包分解成两个低层的包，一个加密而另一个明文发送。比如，可以把SDES信息加密，而接受报告则以明文发送以适应第三方监视器[RFC1889]。”
SNMPv1本身不是一个安全的环境。即使网络本身是可靠的（比如使用了IPSec），仍然没有这样的控制，以许可这个安全的网络上的某人访问并读写（GET/SET）MIB中的对象。建议应用者考虑SNMPv3框架提供的安全特性。非凡推荐使用基于用户的安全模型[RFC2574]和基于视图的访问控制模型[RFC2575]。最后，消费者/用户有责任保证用于访问本MIB实例的SNMP实体必须正确设置，以保证只有那些具有合法权限的主要用户才能访问这些对象并真正地读取（GET）或设定（SET）——更新、创建、删除——这些对象。
5.致谢（Acknowledgements）
笔者感谢BertWijnen和来自ITUSG-16治理计划的同仁，他们提出了很好的建议。Intel公司的AlanBatie和BillLewis也为RTPMIB作出了巨大的贡献，他们审阅了多份MIB草案并致力于SNMPRTP监视器的实现。3Com的StanNaudus和Intel的JohnDu为RTPMIB的最初设计作出了贡献，他们也参与了RTPMIB最初草案的写作；他们的工作仍然体现在现在的RTPMIB版本中。BillFenner为最终文本的完善提供了极好的资料。
6.知识产权（IntellectualProperty）
TheIETFtakesnopositionregardingthevalidityorscopeofany
intellectualpropertyorotherrightsthatmightbeclaimedto
pertaintotheimplementationoruseofthetechnologydescribedin
thisdocumentortheextenttowhichanylicenseundersuchrights
mightormightnotbeavailable;neitherdoesitrepresentthatit
hasmadeanyefforttoidentifyanysuchrights.Informationonthe
IETF'sprocedureswithrespecttorightsinstandards-trackand
standards-relateddocumentationcanbefoundinBCP-11.Copiesof
claimsofrightsmadeavailableforpublicationandanyassurancesof
licensestobemadeavailable,ortheresultofanattemptmadeto
oBTainagenerallicenseorpermissionfortheuseofsuch
proprietaryrightsbyimplementorsorusersofthisspecificationcan
beobtainedfromtheIETFSecretariat.
TheIETFinvitesanyinterestedpartytobringtoitsattentionany
copyrights,patentsorpatentapplications,orotherproprietary
rightswhichmaycovertechnologythatmayberequiredtopractice
thisstandard.PleaseaddresstheinformationtotheIETFExecutive
Director.
7.引用（References）
[RFC1889]Shulzrinne,H.,Casner,S.,Frederick,R.andV.
Jacobson,"RTP:ATransportProtocolforreal-time
applications,"RFC1889,January1996.
[RFC2571]Harrington,D.,Presuhn,R.andB.Wijnen,"An
ArchitectureforDescribingSNMPManagementFrameworks",
RFC2571,April1999.
[RFC1155]Rose,M.andK.McCloghrie,"StructureandIdentification
ofManagementInformationforTCP/IP-basedInternets",
STD16,RFC1155,May1990.
[RFC1212]Rose,M.andK.McCloghrie,"ConciseMIBDefinitions",
STD16,RFC1212,March1991.
[RFC1215]Rose,M.,"AConventionforDefiningTrapsforusewith
theSNMP",RFC1215,March1991.
[RFC2578]McCloghrie,K.,Perkins,D.,Schoenwaelder,J.,Case,J.,
Rose,M.andS.Waldbusser,"StructureofManagement
InformationVersion2(SMIv2)",STD58,RFC2578,April
1999.
[RFC2579]McCloghrie,K.,Perkins,D.,Schoenwaelder,J.,Case,J.,
Rose,M.andS.Waldbusser,"TextualConventionsfor
SMIv2",STD58,RFC2579,April1999.
[RFC2580]McCloghrie,K.,Perkins,D.,Schoenwaelder,J.,Case,J.,
Rose,M.andS.Waldbusser,"ConformanceStatementsfor
SMIv2",STD58,RFC2580,April1999.
[RFC1157]Case,J.,Fedor,M.,Schoffstall,M.andJ.Davin,
"SimpleNetworkManagementProtocol",STD15,RFC1157,
May1990.
[RFC1901]Case,J.,McCloghrie,K.,Rose,M.andS.Waldbusser,
"IntroductiontoCommunity-basedSNMPv2",RFC1901,
January1996.
[RFC1906]Case,J.,McCloghrie,K.,Rose,M.andS.Waldbusser,
"TransportMappingsforVersion2oftheSimpleNetwork
ManagementProtocol(SNMPv2)",RFC1906,January1996.
[RFC2572]Case,J.,HarringtonD.,PresuhnR.andB.Wijnen,
"MessageProcessingandDispatchingfortheSimple
NetworkManagementProtocol(SNMP)",RFC2572,April
1999.
[RFC2574]Blumenthal,U.andB.Wijnen,"User-basedSecurityModel
(USM)forversion3oftheSimpleNetworkManagement
Protocol(SNMPv3)",RFC2574,April1999.
[RFC1905]Case,J.,McCloghrie,K.,Rose,M.andS.Waldbusser,
"ProtocolOperationsforVersion2oftheSimpleNetwork
ManagementProtocol(SNMPv2)",RFC1905,January1996.
[RFC2573]Levi,D.,Meyer,P.andB.Stewart,"SNMPv3
Applications",RFC2573,April1999.
[RFC2575]Wijnen,B.,Presuhn,R.andK.McCloghrie,"View-based
AccessControlModel(VACM)fortheSimpleNetwork
ManagementProtocol(SNMP)",RFC2575,April1999.
[RFC2570]Case,J.,Mundy,R.,Partain,D.andB.Stewart,
"IntroductiontoVersion3oftheInternet-standard
Network
ManagementFramework",RFC2570,April1999.
8.作者地址（Authors'Addresses）
MarkBaugher
IntelCorporation
2111N.E.25thAvenue
Hillsboro,Oregon97124
U.S.A.
EMail:mbaugher@passedge.com
BillStrahm
IntelCorporation
2111N.E.25thAvenue
Hillsboro,Oregon97124
U.S.A.
EMail:Bill.Strahm@intel.com
IrinaSuconick
EnnovateNetworks
60CodmanHillRd.,
Boxboro,Ma01719
U.S.A.
EMail:irina@ennovatenetworks.com
9.版权声明
Copyright(C)TheInternetSociety(2000).AllRightsReserved.
Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseeXPlainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.
Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.
Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.
感谢
FundingfortheRFCEditorfunctioniscurrentlyprovidedbythe
InternetSociety.
