summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2959.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2959.txt')
-rw-r--r--doc/rfc/rfc2959.txt1739
1 files changed, 1739 insertions, 0 deletions
diff --git a/doc/rfc/rfc2959.txt b/doc/rfc/rfc2959.txt
new file mode 100644
index 0000000..06cab32
--- /dev/null
+++ b/doc/rfc/rfc2959.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Network Working Group M. Baugher
+Request for Comments: 2959 B. Strahm
+Category: Standards Track Intel Corp.
+ I. Suconick
+ VideoServer Corp.
+ October 2000
+
+
+ Real-Time Transport Protocol
+ Management Information Base
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ This memo defines a portion of the Management Information Base (MIB)
+ for use with network management protocols in the Internet community.
+ In particular, it defines objects for managing Real-Time Transport
+ Protocol (RTP) systems (RFC1889).
+
+Table of Contents
+
+ 1. The Network Management Framework ............................. 2
+ 2. Overview ..................................................... 3
+ 2.1 Components .................................................. 3
+ 2.2 Applicability of the MIB to RTP System Implementations ...... 4
+ 2.3 The Structure of the RTP MIB ................................ 4
+ 3 Definitions ................................................... 5
+ 4. Security Considerations ...................................... 26
+ 5. Acknowledgements ............................................. 27
+ 6. Intellectual Property ........................................ 27
+ 7. References ................................................... 28
+ 8. Authors' Addresses ........................................... 30
+ 9. Full Copyright Statement ..................................... 31
+
+
+
+
+
+
+
+Baugher, et al. Standards Track [Page 1]
+
+RFC 2959 RTP MIB October 2000
+
+
+1. The SNMP Management Framework
+
+ The SNMP Management Framework presently consists of five major
+ components:
+
+ o An overall architecture, described in RFC 2571 [RFC2571].
+
+ o Mechanisms for describing and naming objects and events for the
+ purpose of management. The first version of this Structure of
+ Management Information (SMI) is called SMIv1 and described in
+ STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
+ 1215 [RFC1215]. The second version, called SMIv2, is described
+ in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580
+ [RFC2580].
+
+ o Message protocols for transferring management information. The
+ first version of the SNMP message protocol is called SNMPv1 and
+ described in STD 15, RFC 1157 [RFC1157]. A second version of
+ the SNMP message protocol, which is not an Internet standards
+ track protocol, is called SNMPv2c and described in RFC 1901
+ [RFC1901] and RFC 1906 [RFC1906]. The third version of the
+ message protocol is called SNMPv3 and described in RFC 1906
+ [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
+
+ o Protocol operations for accessing management information. The
+ first set of protocol operations and associated PDU formats is
+ described in STD 15, RFC 1157 [RFC1157]. A second set of
+ protocol operations and associated PDU formats is described in
+ RFC 1905 [RFC1905].
+
+ o A set of fundamental applications described in RFC 2573
+ [RFC2573] and the view-based access control mechanism described
+ in RFC 2575 [RFC2575].
+
+ A more detailed introduction to the current SNMP Management Framework
+ can be found in RFC 2570 [RFC2570].
+
+ Managed objects are accessed via a virtual information store, termed
+ the Management Information Base or MIB. Objects in the MIB are
+ defined using the mechanisms defined in the SMI.
+
+ This memo specifies a MIB module that is compliant to the SMIv2. A
+ MIB conforming to the SMIv1 can be produced through the appropriate
+ translations. The resulting translated MIB must be semantically
+ equivalent, except where objects or events are omitted because no
+ translation is possible (use of Counter64). Some machine readable
+
+
+
+
+
+Baugher, et al. Standards Track [Page 2]
+
+RFC 2959 RTP MIB October 2000
+
+
+ information in SMIv2 will be converted into textual descriptions in
+ SMIv1 during the translation process. However, this loss of machine
+ readable information is not considered to change the semantics of the
+ MIB.
+
+2. Overview
+
+ An "RTP System" may be a host end-system that runs an application
+ program that sends or receives RTP data packets, or it may be an
+ intermediate-system that forwards RTP packets. RTP Control Protocol
+ (RTCP) packets are sent by senders and receivers to convey
+ information about RTP packet transmission and reception [RFC1889].
+ RTP monitors may collect RTCP information on senders and receivers to
+ and from an RTP host or intermediate-system.
+
+ 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 RFC 2119.
+
+2.1 Components
+
+ The RTP MIB is structured around "Session," "Receiver" and "Sender"
+ conceptual abstractions.
+
+ 2.1.1 An "RTP Session" is the "...association of participants
+ communicating with RTP. For each participant, the session is defined
+ by a particular pair of destination transport addresses (one network
+ address plus a port pair for RTP and RTCP). The destination
+ transport addresses may be common for all participants, as in the
+ case of IP multicast, or may be different for each, as in the case of
+ individual unicast addresses plus a common port pair," as defined in
+ section 3 of [RFC1889].
+
+ 2.1.2 A "Sender" is identified within an RTP session by a 32-bit
+ numeric "Synchronization Source," or "SSRC", value and is "...the
+ source of a stream of RTP packets" as defined in section 3 of
+ [RFC1889]. The sender is also a source of RTCP Sender Report packets
+ as specified in section 6 of [RFC1889].
+
+ 2.1.3 A "Receiver" of a "stream of RTP packets" can be a unicast or
+ multicast Receiver as described in 2.1.1, above. An RTP Receiver has
+ an SSRC value that is unique to the session. An RTP Receiver is a
+ source of RTCP Receiver Reports as specified in section 6 of
+ [RFC1889].
+
+
+
+
+
+
+
+Baugher, et al. Standards Track [Page 3]
+
+RFC 2959 RTP MIB October 2000
+
+
+2.2 Applicability of the MIB to RTP System Implementations
+
+ The RTP MIB may be used in two types of RTP implementations, RTP Host
+ Systems (end systems) and RTP Monitors, see section 3 of [RFC1889].
+ Use of the RTP MIB for RTP Translators and Mixers, as defined in
+ section 7 of [RFC1889], is for further study.
+
+ 2.2.1 RTP host Systems are end-systems that may use the RTP MIB to
+ collect RTP session and stream data that the host is sending or
+ receiving; these data may be used by a network manager to detect and
+ diagnose faults that occur over the lifetime of an RTP session as in
+ a "help-desk" scenario.
+
+ 2.2.2 RTP Monitors of multicast RTP sessions may be third-party or
+ may be located in the RTP host. RTP Monitors may use the RTP MIB to
+ collect RTP session and stream statistical data; these data may be
+ used by a network manager for capacity planning and other network-
+ management purposes. An RTP Monitor may use the RTP MIB to collect
+ data to permit a network manager to detect and diagnose faults in RTP
+ sessions or to permit a network manger to configure its operation.
+
+ 2.2.3 Many host systems will want to keep track of streams beyond
+ what they are sending and receiving. In a host monitor system, a
+ host agent would use RTP data from the host to maintain data about
+ streams it is sending and receiving, and RTCP data to collect data
+ about other hosts in the session. For example, an agent for an RTP
+ host that is sending a stream would use data from its RTP system to
+ maintain the rtpSenderTable, but it may want to maintain a
+ rtpRcvrTable for endpoints that are receiving its stream. To do this
+ the RTP agent will collect RTCP data from the receivers of its stream
+ to build the rtpRcvrTable. A host monitor system MUST set the
+ rtpSessionMonitor object to 'true(1)', but it does not have to accept
+ management operations that create and destroy rows in its
+ rtpSessionTable.
+
+2.3 The Structure of the RTP MIB
+
+ There are six tables in the RTP MIB. The rtpSessionTable contains
+ objects that describe active sessions at the host, or monitor. The
+ rtpSenderTable contains information about senders to the RTP session.
+ The rtpRcvrTable contains information about receivers of RTP session
+ data. The rtpSessionInverseTable, rtpSenderInverseTable, and
+ rtpRcvrInverseTable contain information to efficiently find indexes
+ into the rtpSessionTable, rtpSenderTable, and rtpRcvrTable,
+ respectively.
+
+
+
+
+
+
+Baugher, et al. Standards Track [Page 4]
+
+RFC 2959 RTP MIB October 2000
+
+
+ The reverse lookup tables (rtpSessionInverseTable,
+ rtpSenderInverseTable, and rtpRcvrInverseTable) are optional tables
+ to help management applications efficiently access conceptual rows in
+ other tables. Implementors of this MIB SHOULD implement these tables
+ for multicast RTP sessions when table indexes (rtpSessionIndex of
+ rtpSessionTable, rtpSenderSSRC of rtpSenderTable, and the SSRC pair
+ in the rtpRcvrTable) are not available from other MIBs. Otherwise,
+ the management application may be forced to perform expensive tree
+ walks through large numbers of sessions, senders, or receivers.
+
+ For any particular RTP session, the rtpSessionMonitor object
+ indicates whether remote senders or receivers to the RTP session are
+ to be monitored. If rtpSessionMonitor is true(1) then senders and
+ receivers to the session MUST be monitored with entries in the
+ rtpSenderTable and rtpRcvrTable. RTP sessions are monitored by the
+ RTP agent that updates rtpSenderTable and rtpRcvrTable objects with
+ information from RTCP reports from remote senders or remote receivers
+ respectively.
+
+ rtpSessionNewIndex is a global object that permits a network-
+ management application to obtain a unique index for conceptual row
+ creation in the rtpSessionTable. In this way the SNMP Set operation
+ MAY be used to configure a monitor.
+
+3. Definitions
+
+RTP-MIB DEFINITIONS ::= BEGIN
+IMPORTS
+ Counter32, Counter64, Gauge32, mib-2, Integer32,
+ MODULE-IDENTITY,
+ OBJECT-TYPE, Unsigned32 FROM SNMPv2-SMI
+ RowStatus, TAddress,
+ TDomain, TestAndIncr,
+ TimeStamp, TruthValue FROM SNMPv2-TC
+ OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF
+ Utf8String FROM SYSAPPL-MIB
+ InterfaceIndex FROM IF-MIB;
+
+rtpMIB MODULE-IDENTITY
+ LAST-UPDATED "200010020000Z" -- 2 October 2000
+ ORGANIZATION
+ "IETF AVT Working Group
+ Email: rem-conf@es.net"
+ CONTACT-INFO
+ "Mark Baugher
+ Postal: Intel Corporation
+ 2111 NE 25th Avenue
+ Hillsboro, OR 97124
+
+
+
+Baugher, et al. Standards Track [Page 5]
+
+RFC 2959 RTP MIB October 2000
+
+
+ United States
+ Tel: +1 503 466 8406
+ Email: mbaugher@passedge.com
+
+ Bill Strahm
+ Postal: Intel Corporation
+ 2111 NE 25th Avenue
+ Hillsboro, OR 97124
+ United States
+ Tel: +1 503 264 4632
+ Email: bill.strahm@intel.com
+
+ Irina Suconick
+ Postal: Ennovate Networks
+ 60 Codman Hill Rd.,
+ Boxboro, Ma 01719
+ Tel: +1 781-505-2155
+ Email: irina@ennovatenetworks.com"
+
+ DESCRIPTION
+ "The managed objects of RTP systems. The MIB is
+ structured around three types of information.
+ 1. General information about RTP sessions such
+ as the session address.
+ 2. Information about RTP streams being sent to
+ an RTP session by a particular sender.
+ 3. Information about RTP streams received on an
+ RTP session by a particular receiver from a
+ particular sender.
+ There are two types of RTP Systems, RTP hosts and
+ RTP monitors. As described below, certain objects
+ are unique to a particular type of RTP System. An
+ RTP host may also function as an RTP monitor.
+ Refer to RFC 1889, 'RTP: A Transport Protocol for
+ Real-Time Applications,' section 3.0, for definitions."
+ REVISION "200010020000Z" -- 2 October 2000
+ DESCRIPTION "Initial version of this MIB.
+ Published as RFC 2959."
+
+::= { mib-2 87 }
+
+--
+-- OBJECTS
+--
+rtpMIBObjects OBJECT IDENTIFIER ::= { rtpMIB 1 }
+rtpConformance OBJECT IDENTIFIER ::= { rtpMIB 2 }
+
+--
+
+
+
+Baugher, et al. Standards Track [Page 6]
+
+RFC 2959 RTP MIB October 2000
+
+
+-- SESSION NEW INDEX
+--
+rtpSessionNewIndex OBJECT-TYPE
+ SYNTAX TestAndIncr
+ MAX-ACCESS read-write
+ STATUS current
+ DESCRIPTION
+ "This object is used to assign values to rtpSessionIndex
+ as described in 'Textual Conventions for SMIv2'. For an RTP
+ system that supports the creation of rows, the network manager
+ would read the object, and then write the value back in
+ the Set that creates a new instance of rtpSessionEntry. If
+ the Set fails with the code 'inconsistentValue,' then the
+ process must be repeated; If the Set succeeds, then the object
+ is incremented, and the new instance is created according to
+ the manager's directions. However, if the RTP agent is not
+ acting as a monitor, only the RTP agent may create conceptual
+ rows in the RTP session table."
+ ::= { rtpMIBObjects 1 }
+
+--
+-- SESSION INVERSE TABLE
+--
+rtpSessionInverseTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF RtpSessionInverseEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Maps rtpSessionDomain, rtpSessionRemAddr, and rtpSessionLocAddr
+ TAddress pairs to one or more rtpSessionIndex values, each
+ describing a row in the rtpSessionTable. This makes it possible
+ to retrieve the row(s) in the rtpSessionTable corresponding to a
+ given session without having to walk the entire (potentially
+ large) table."
+ ::= { rtpMIBObjects 2 }
+
+rtpSessionInverseEntry OBJECT-TYPE
+ SYNTAX RtpSessionInverseEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Each entry corresponds to exactly one entry in the
+ rtpSessionTable - the entry containing the tuple,
+ rtpSessionDomain, rtpSessionRemAddr, rtpSessionLocAddr
+ and rtpSessionIndex."
+ INDEX { rtpSessionDomain, rtpSessionRemAddr, rtpSessionLocAddr,
+ rtpSessionIndex }
+ ::= { rtpSessionInverseTable 1 }
+
+
+
+Baugher, et al. Standards Track [Page 7]
+
+RFC 2959 RTP MIB October 2000
+
+
+RtpSessionInverseEntry ::= SEQUENCE {
+ rtpSessionInverseStartTime TimeStamp
+ }
+
+rtpSessionInverseStartTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of SysUpTime at the time that this row was
+ created."
+ ::= { rtpSessionInverseEntry 1 }
+
+--
+-- SESSION TABLE
+--
+rtpSessionTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF RtpSessionEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "There's one entry in rtpSessionTable for each RTP session
+ on which packets are being sent, received, and/or
+ monitored."
+ ::= { rtpMIBObjects 3 }
+
+rtpSessionEntry OBJECT-TYPE
+ SYNTAX RtpSessionEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Data in rtpSessionTable uniquely identify an RTP session. A
+ host RTP agent MUST create a read-only row for each session to
+ which packets are being sent or received. Rows MUST be created
+ by the RTP Agent at the start of a session when one or more
+ senders or receivers are observed. Rows created by an RTP agent
+ MUST be deleted when the session is over and there are no
+ rtpRcvrEntry and no rtpSenderEntry for this session. An RTP
+ session SHOULD be monitored to create management information on
+ all RTP streams being sent or received when the
+ rtpSessionMonitor has the TruthValue of 'true(1)'. An RTP
+ monitor SHOULD permit row creation with the side effect of
+ causing the RTP System to join the multicast session for the
+ purposes of gathering management information (additional
+ conceptual rows are created in the rtpRcvrTable and
+ rtpSenderTable). Thus, rtpSessionTable rows SHOULD be created
+ for RTP session monitoring purposes. Rows created by a
+ management application SHOULD be deleted via SNMP operations by
+
+
+
+Baugher, et al. Standards Track [Page 8]
+
+RFC 2959 RTP MIB October 2000
+
+
+ management applications. Rows created by management operations
+ are deleted by management operations by setting
+ rtpSessionRowStatus to 'destroy(6)'."
+ INDEX { rtpSessionIndex }
+ ::= { rtpSessionTable 1 }
+
+RtpSessionEntry ::= SEQUENCE {
+ rtpSessionIndex Integer32,
+ rtpSessionDomain TDomain,
+ rtpSessionRemAddr TAddress,
+ rtpSessionLocAddr TAddress,
+ rtpSessionIfIndex InterfaceIndex,
+ rtpSessionSenderJoins Counter32,
+ rtpSessionReceiverJoins Counter32,
+ rtpSessionByes Counter32,
+ rtpSessionStartTime TimeStamp,
+ rtpSessionMonitor TruthValue,
+ rtpSessionRowStatus RowStatus
+ }
+
+rtpSessionIndex OBJECT-TYPE
+ SYNTAX Integer32 (1..2147483647)
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The index of the conceptual row which is for SNMP purposes
+ only and has no relation to any protocol value. There is
+ no requirement that these rows are created or maintained
+ sequentially."
+ ::= { rtpSessionEntry 1 }
+
+rtpSessionDomain OBJECT-TYPE
+ SYNTAX TDomain
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The transport-layer protocol used for sending or receiving
+ the stream of RTP data packets on this session.
+ Cannot be changed if rtpSessionRowStatus is 'active'."
+ ::= { rtpSessionEntry 2 }
+
+rtpSessionRemAddr OBJECT-TYPE
+ SYNTAX TAddress
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The address to which RTP packets are sent by the RTP system.
+ In an IP multicast RTP session, this is the single address used
+
+
+
+Baugher, et al. Standards Track [Page 9]
+
+RFC 2959 RTP MIB October 2000
+
+
+ by all senders and receivers of RTP session data. In a unicast
+ RTP session this is the unicast address of the remote RTP system.
+ 'The destination address pair may be common for all participants,
+ as in the case of IP multicast, or may be different for each, as
+ in the case of individual unicast network address pairs.' See
+ RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,'
+ sec. 3. The transport service is identified by rtpSessionDomain.
+ For snmpUDPDomain, this is an IP address and even-numbered UDP
+ Port with the RTCP being sent on the next higher odd-numbered
+ port, see RFC 1889, sec. 5."
+ ::= { rtpSessionEntry 3 }
+
+rtpSessionLocAddr OBJECT-TYPE
+ SYNTAX TAddress
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The local address used by the RTP system. In an IP multicast
+ RTP session, rtpSessionRemAddr will be the same IP multicast
+ address as rtpSessionLocAddr. In a unicast RTP session,
+ rtpSessionRemAddr and rtpSessionLocAddr will have different
+ unicast addresses. See RFC 1889, 'RTP: A Transport Protocol for
+ Real-Time Applications,' sec. 3. The transport service is
+ identified by rtpSessionDomain. For snmpUDPDomain, this is an IP
+ address and even-numbered UDP Port with the RTCP being sent on
+ the next higher odd-numbered port, see RFC 1889, sec. 5."
+ ::= { rtpSessionEntry 4 }
+
+rtpSessionIfIndex OBJECT-TYPE
+ SYNTAX InterfaceIndex
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "The ifIndex value is set to the corresponding value
+ from IF-MIB (See RFC 2233, 'The Interfaces Group MIB using
+ SMIv2'). This is the interface that the RTP stream is being sent
+ to or received from, or in the case of an RTP Monitor the
+ interface that RTCP packets will be received on. Cannot be
+ changed if rtpSessionRowStatus is 'active'."
+ ::= { rtpSessionEntry 5 }
+
+rtpSessionSenderJoins OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of senders that have been observed to have
+ joined the session since this conceptual row was created
+
+
+
+Baugher, et al. Standards Track [Page 10]
+
+RFC 2959 RTP MIB October 2000
+
+
+ (rtpSessionStartTime). A sender 'joins' an RTP
+ session by sending to it. Senders that leave and then
+ re-join following an RTCP BYE (see RFC 1889, 'RTP: A
+ Transport Protocol for Real-Time Applications,' sec. 6.6)
+ or session timeout may be counted twice. Every time a new
+ RTP sender is detected either using RTP or RTCP, this counter
+ is incremented."
+ ::= { rtpSessionEntry 6 }
+
+rtpSessionReceiverJoins OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The number of receivers that have been been observed to
+ have joined this session since this conceptual row was
+ created (rtpSessionStartTime). A receiver 'joins' an RTP
+ session by sending RTCP Receiver Reports to the session.
+ Receivers that leave and then re-join following an RTCP BYE
+ (see RFC 1889, 'RTP: A Transport Protocol for Real-Time
+ Applications,' sec. 6.6) or session timeout may be counted
+ twice."
+ ::= { rtpSessionEntry 7 }
+
+rtpSessionByes OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A count of RTCP BYE (see RFC 1889, 'RTP: A Transport
+ Protocol for Real-Time Applications,' sec. 6.6) messages
+ received by this entity."
+ ::= { rtpSessionEntry 8 }
+
+rtpSessionStartTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of SysUpTime at the time that this row was
+ created."
+ ::= { rtpSessionEntry 9 }
+
+rtpSessionMonitor OBJECT-TYPE
+ SYNTAX TruthValue
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+
+
+
+Baugher, et al. Standards Track [Page 11]
+
+RFC 2959 RTP MIB October 2000
+
+
+ "Boolean, Set to 'true(1)' if remote senders or receivers in
+ addition to the local RTP System are to be monitored using RTCP.
+ RTP Monitors MUST initialize to 'true(1)' and RTP Hosts SHOULD
+ initialize this 'false(2)'. Note that because 'host monitor'
+ systems are receiving RTCP from their remote participants they
+ MUST set this value to 'true(1)'."
+ ::= { rtpSessionEntry 10 }
+
+rtpSessionRowStatus OBJECT-TYPE
+ SYNTAX RowStatus
+ MAX-ACCESS read-create
+ STATUS current
+ DESCRIPTION
+ "Value of 'active' when RTP or RTCP messages are being
+ sent or received by an RTP System. A newly-created
+ conceptual row must have the all read-create objects
+ initialized before becoming 'active'.
+ A conceptual row that is in the 'notReady' or 'notInService'
+ state MAY be removed after 5 minutes."
+ ::= { rtpSessionEntry 11 }
+
+--
+-- SENDER INVERSE TABLE
+--
+rtpSenderInverseTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF RtpSenderInverseEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Maps rtpSenderAddr, rtpSessionIndex, to the rtpSenderSSRC
+ index of the rtpSenderTable. This table allows management
+ applications to find entries sorted by rtpSenderAddr rather than
+ sorted by rtpSessionIndex. Given the rtpSessionDomain and
+ rtpSenderAddr, a set of rtpSessionIndex and rtpSenderSSRC values
+ can be returned from a tree walk. When rtpSessionIndex is
+ specified in the SNMP Get-Next operations, one or more
+ rtpSenderSSRC values may be returned."
+ ::= { rtpMIBObjects 4 }
+
+rtpSenderInverseEntry OBJECT-TYPE
+ SYNTAX RtpSenderInverseEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Each entry corresponds to exactly one entry in the
+ rtpSenderTable - the entry containing the index pair,
+ rtpSessionIndex, rtpSenderSSRC."
+ INDEX { rtpSessionDomain, rtpSenderAddr, rtpSessionIndex,
+
+
+
+Baugher, et al. Standards Track [Page 12]
+
+RFC 2959 RTP MIB October 2000
+
+
+ rtpSenderSSRC }
+ ::= { rtpSenderInverseTable 1 }
+
+RtpSenderInverseEntry ::= SEQUENCE {
+ rtpSenderInverseStartTime TimeStamp
+ }
+
+rtpSenderInverseStartTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of SysUpTime at the time that this row was
+ created."
+ ::= { rtpSenderInverseEntry 1 }
+
+--
+-- SENDERS TABLE
+--
+rtpSenderTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF RtpSenderEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Table of information about a sender or senders to an RTP
+ Session. RTP sending hosts MUST have an entry in this table
+ for each stream being sent. RTP receiving hosts MAY have an
+ entry in this table for each sending stream being received by
+ this host. RTP monitors MUST create an entry for each observed
+ sender to a multicast RTP Session as a side-effect when a
+ conceptual row in the rtpSessionTable is made 'active' by a
+ manager."
+ ::= { rtpMIBObjects 5 }
+
+rtpSenderEntry OBJECT-TYPE
+ SYNTAX RtpSenderEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Each entry contains information from a single RTP Sender
+ Synchronization Source (SSRC, see RFC 1889 'RTP: A Transport
+ Protocol for Real-Time Applications' sec.6). The session is
+ identified to the the SNMP entity by rtpSessionIndex.
+ Rows are removed by the RTP agent when a BYE is received
+ from the sender or when the sender times out (see RFC
+ 1889, Sec. 6.2.1) or when the rtpSessionEntry is deleted."
+ INDEX { rtpSessionIndex, rtpSenderSSRC }
+ ::= { rtpSenderTable 1 }
+
+
+
+Baugher, et al. Standards Track [Page 13]
+
+RFC 2959 RTP MIB October 2000
+
+
+RtpSenderEntry ::= SEQUENCE {
+ rtpSenderSSRC Unsigned32,
+ rtpSenderCNAME Utf8String,
+ rtpSenderAddr TAddress,
+ rtpSenderPackets Counter64,
+ rtpSenderOctets Counter64,
+ rtpSenderTool Utf8String,
+ rtpSenderSRs Counter32,
+ rtpSenderSRTime TimeStamp,
+ rtpSenderPT INTEGER,
+ rtpSenderStartTime TimeStamp
+ }
+
+rtpSenderSSRC OBJECT-TYPE
+ SYNTAX Unsigned32
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The RTP SSRC, or synchronization source identifier of the
+ sender. The RTP session address plus an SSRC uniquely
+ identify a sender to an RTP session (see RFC 1889, 'RTP: A
+ Transport Protocol for Real-Time Applications' sec.3)."
+ ::= { rtpSenderEntry 1 }
+
+rtpSenderCNAME OBJECT-TYPE
+ SYNTAX Utf8String
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The RTP canonical name of the sender."
+ ::= { rtpSenderEntry 2 }
+
+rtpSenderAddr OBJECT-TYPE
+ SYNTAX TAddress
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The unicast transport source address of the sender. In the
+ case of an RTP Monitor this address is the address that the
+ sender is using to send its RTCP Sender Reports."
+ ::= { rtpSenderEntry 3 }
+
+rtpSenderPackets OBJECT-TYPE
+ SYNTAX Counter64
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Count of RTP packets sent by this sender, or observed by
+
+
+
+Baugher, et al. Standards Track [Page 14]
+
+RFC 2959 RTP MIB October 2000
+
+
+ an RTP monitor, since rtpSenderStartTime."
+ ::= { rtpSenderEntry 4 }
+
+rtpSenderOctets OBJECT-TYPE
+ SYNTAX Counter64
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Count of non-header RTP octets sent by this sender, or observed
+ by an RTP monitor, since rtpSenderStartTime."
+ ::= { rtpSenderEntry 5 }
+
+rtpSenderTool OBJECT-TYPE
+ SYNTAX Utf8String (SIZE(0..127))
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Name of the application program source of the stream."
+ ::= { rtpSenderEntry 6 }
+
+rtpSenderSRs OBJECT-TYPE
+ SYNTAX Counter32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A count of the number of RTCP Sender Reports that have
+ been sent from this sender, or observed if the RTP entity
+ is a monitor, since rtpSenderStartTime."
+ ::= { rtpSenderEntry 7 }
+
+rtpSenderSRTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "rtpSenderSRTime is the value of SysUpTime at the time that
+ the last SR was received from this sender, in the case of a
+ monitor or receiving host. Or sent by this sender, in the
+ case of a sending host."
+ ::= { rtpSenderEntry 8 }
+
+rtpSenderPT OBJECT-TYPE
+ SYNTAX INTEGER (0..127)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Payload type from the RTP header of the most recently received
+ RTP Packet (see RFC 1889, 'RTP: A Transport Protocol for
+
+
+
+Baugher, et al. Standards Track [Page 15]
+
+RFC 2959 RTP MIB October 2000
+
+
+ Real-Time Applications' sec. 5)."
+ ::= { rtpSenderEntry 9 }
+
+rtpSenderStartTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of SysUpTime at the time that this row was
+ created."
+ ::= { rtpSenderEntry 10 }
+
+--
+-- RECEIVER INVERSE TABLE
+--
+rtpRcvrInverseTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF RtpRcvrInverseEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Maps rtpRcvrAddr and rtpSessionIndex to the rtpRcvrSRCSSRC and
+ rtpRcvrSSRC indexes of the rtpRcvrTable. This table allows
+ management applications to find entries sorted by rtpRcvrAddr
+ rather than by rtpSessionIndex. Given rtpSessionDomain and
+ rtpRcvrAddr, a set of rtpSessionIndex, rtpRcvrSRCSSRC, and
+ rtpRcvrSSRC values can be returned from a tree walk. When
+ rtpSessionIndex is specified in SNMP Get-Next operations, one or
+ more rtpRcvrSRCSSRC and rtpRcvrSSRC pairs may be returned."
+ ::= { rtpMIBObjects 6 }
+
+rtpRcvrInverseEntry OBJECT-TYPE
+ SYNTAX RtpRcvrInverseEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Each entry corresponds to exactly one entry in the
+ rtpRcvrTable - the entry containing the index pair,
+ rtpSessionIndex, rtpRcvrSSRC."
+ INDEX { rtpSessionDomain, rtpRcvrAddr, rtpSessionIndex,
+ rtpRcvrSRCSSRC, rtpRcvrSSRC }
+ ::= { rtpRcvrInverseTable 1 }
+
+RtpRcvrInverseEntry ::= SEQUENCE {
+ rtpRcvrInverseStartTime TimeStamp
+ }
+
+rtpRcvrInverseStartTime OBJECT-TYPE
+ SYNTAX TimeStamp
+
+
+
+Baugher, et al. Standards Track [Page 16]
+
+RFC 2959 RTP MIB October 2000
+
+
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of SysUpTime at the time that this row was
+ created."
+ ::= { rtpRcvrInverseEntry 1 }
+
+--
+-- RECEIVERS TABLE
+--
+rtpRcvrTable OBJECT-TYPE
+ SYNTAX SEQUENCE OF RtpRcvrEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Table of information about a receiver or receivers of RTP
+ session data. RTP hosts that receive RTP session packets
+ MUST create an entry in this table for that receiver/sender
+ pair. RTP hosts that send RTP session packets MAY create
+ an entry in this table for each receiver to their stream
+ using RTCP feedback from the RTP group. RTP monitors
+ create an entry for each observed RTP session receiver as
+ a side effect when a conceptual row in the rtpSessionTable
+ is made 'active' by a manager."
+ ::= { rtpMIBObjects 7 }
+
+rtpRcvrEntry OBJECT-TYPE
+ SYNTAX RtpRcvrEntry
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "Each entry contains information from a single RTP
+ Synchronization Source that is receiving packets from the
+ sender identified by rtpRcvrSRCSSRC (SSRC, see RFC 1889,
+ 'RTP: A Transport Protocol for Real-Time Applications'
+ sec.6). The session is identified to the the RTP Agent entity
+ by rtpSessionIndex. Rows are removed by the RTP agent when
+ a BYE is received from the sender or when the sender times
+ out (see RFC 1889, Sec. 6.2.1) or when the rtpSessionEntry is
+ deleted."
+ INDEX { rtpSessionIndex, rtpRcvrSRCSSRC, rtpRcvrSSRC }
+ ::= { rtpRcvrTable 1 }
+
+RtpRcvrEntry ::= SEQUENCE {
+ rtpRcvrSRCSSRC Unsigned32,
+ rtpRcvrSSRC Unsigned32,
+ rtpRcvrCNAME Utf8String,
+ rtpRcvrAddr TAddress,
+
+
+
+Baugher, et al. Standards Track [Page 17]
+
+RFC 2959 RTP MIB October 2000
+
+
+ rtpRcvrRTT Gauge32,
+ rtpRcvrLostPackets Counter64,
+ rtpRcvrJitter Gauge32,
+ rtpRcvrTool Utf8String,
+ rtpRcvrRRs Counter32,
+ rtpRcvrRRTime TimeStamp,
+ rtpRcvrPT INTEGER,
+ rtpRcvrPackets Counter64,
+ rtpRcvrOctets Counter64,
+ rtpRcvrStartTime TimeStamp
+ }
+
+rtpRcvrSRCSSRC OBJECT-TYPE
+ SYNTAX Unsigned32
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The RTP SSRC, or synchronization source identifier of the
+ sender. The RTP session address plus an SSRC uniquely
+ identify a sender or receiver of an RTP stream (see RFC
+ 1889, 'RTP: A Transport Protocol for Real-Time
+ Applications' sec.3)."
+ ::= { rtpRcvrEntry 1 }
+
+rtpRcvrSSRC OBJECT-TYPE
+ SYNTAX Unsigned32
+ MAX-ACCESS not-accessible
+ STATUS current
+ DESCRIPTION
+ "The RTP SSRC, or synchronization source identifier of the
+ receiver. The RTP session address plus an SSRC uniquely
+ identify a receiver of an RTP stream (see RFC 1889, 'RTP:
+ A Transport Protocol for Real-Time Applications' sec.3)."
+ ::= { rtpRcvrEntry 2 }
+
+rtpRcvrCNAME OBJECT-TYPE
+ SYNTAX Utf8String
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The RTP canonical name of the receiver."
+ ::= { rtpRcvrEntry 3 }
+
+rtpRcvrAddr OBJECT-TYPE
+ SYNTAX TAddress
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+
+
+
+Baugher, et al. Standards Track [Page 18]
+
+RFC 2959 RTP MIB October 2000
+
+
+ "The unicast transport address on which the receiver is
+ receiving RTP packets and/or RTCP Receiver Reports."
+ ::= { rtpRcvrEntry 4 }
+
+rtpRcvrRTT OBJECT-TYPE
+ SYNTAX Gauge32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The round trip time measurement taken by the source of the
+ RTP stream based on the algorithm described on sec. 6 of
+ RFC 1889, 'RTP: A Transport Protocol for Real-Time
+ Applications.' This algorithm can produce meaningful
+ results when the RTP agent has the same clock as the stream
+ sender (when the RTP monitor is also the sending host for the
+ particular receiver). Otherwise, the entity should return
+ 'noSuchInstance' in response to queries against rtpRcvrRTT."
+ ::= { rtpRcvrEntry 5 }
+
+rtpRcvrLostPackets OBJECT-TYPE
+ SYNTAX Counter64
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A count of RTP packets lost as observed by this receiver
+ since rtpRcvrStartTime."
+ ::= { rtpRcvrEntry 6 }
+
+rtpRcvrJitter OBJECT-TYPE
+ SYNTAX Gauge32
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "An estimate of delay variation as observed by this
+ receiver. (see RFC 1889, 'RTP: A Transport Protocol
+ for Real-Time Applications' sec.6.3.1 and A.8)."
+ ::= { rtpRcvrEntry 7 }
+
+rtpRcvrTool OBJECT-TYPE
+ SYNTAX Utf8String (SIZE(0..127))
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Name of the application program source of the stream."
+ ::= { rtpRcvrEntry 8 }
+
+rtpRcvrRRs OBJECT-TYPE
+ SYNTAX Counter32
+
+
+
+Baugher, et al. Standards Track [Page 19]
+
+RFC 2959 RTP MIB October 2000
+
+
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "A count of the number of RTCP Receiver Reports that have
+ been sent from this receiver, or observed if the RTP entity
+ is a monitor, since rtpRcvrStartTime."
+ ::= { rtpRcvrEntry 9 }
+
+rtpRcvrRRTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "rtpRcvrRRTime is the value of SysUpTime at the time that the
+ last RTCP Receiver Report was received from this receiver, in
+ the case of a monitor or RR receiver (the RTP Sender). It is
+ the value of SysUpTime at the time that the last RR was sent by
+ this receiver in the case of an RTP receiver sending the RR."
+ ::= { rtpRcvrEntry 10 }
+
+rtpRcvrPT OBJECT-TYPE
+ SYNTAX INTEGER (0..127)
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Static or dynamic payload type from the RTP header (see
+ RFC 1889, 'RTP: A Transport Protocol for Real-Time
+ Applications' sec. 5)."
+ ::= { rtpRcvrEntry 11 }
+
+rtpRcvrPackets OBJECT-TYPE
+ SYNTAX Counter64
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Count of RTP packets received by this RTP host receiver
+ since rtpRcvrStartTime."
+ ::= { rtpRcvrEntry 12 }
+
+rtpRcvrOctets OBJECT-TYPE
+ SYNTAX Counter64
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "Count of non-header RTP octets received by this receiving RTP
+ host since rtpRcvrStartTime."
+ ::= { rtpRcvrEntry 13 }
+
+
+
+
+Baugher, et al. Standards Track [Page 20]
+
+RFC 2959 RTP MIB October 2000
+
+
+rtpRcvrStartTime OBJECT-TYPE
+ SYNTAX TimeStamp
+ MAX-ACCESS read-only
+ STATUS current
+ DESCRIPTION
+ "The value of SysUpTime at the time that this row was
+ created."
+ ::= { rtpRcvrEntry 14 }
+
+--
+-- MODULE GROUPS
+--
+--
+-- There are two types of RTP Systems, RTP hosts and RTP Monitors.
+-- Thus there are three kinds of objects: 1) Objects common to both
+-- kinds of systems, 2) Objects unique to RTP Hosts and 3) Objects
+-- unique to RTP Monitors. There is a fourth group, 4) Objects that
+-- SHOULD be implemented by Multicast hosts and RTP Monitors
+
+rtpGroups OBJECT IDENTIFIER ::= { rtpConformance 1 }
+rtpSystemGroup OBJECT-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
+ }
+ STATUS current
+
+
+
+Baugher, et al. Standards Track [Page 21]
+
+RFC 2959 RTP MIB October 2000
+
+
+ DESCRIPTION
+ "Objects available to all RTP Systems."
+ ::= { rtpGroups 1 }
+
+rtpHostGroup OBJECT-GROUP
+ OBJECTS {
+ rtpSessionLocAddr,
+ rtpSenderPT,
+ rtpRcvrPT,
+ rtpRcvrRTT,
+ rtpRcvrOctets,
+ rtpRcvrPackets
+ }
+ STATUS current
+ DESCRIPTION
+ "Objects that are available to RTP Host systems, but may not
+ be available to RTP Monitor systems."
+ ::= { rtpGroups 2 }
+
+rtpMonitorGroup OBJECT-GROUP
+ OBJECTS {
+ rtpSessionNewIndex,
+ rtpSessionRowStatus
+ }
+ STATUS current
+ DESCRIPTION
+ "Objects used to create rows in the RTP Session Table. These
+ objects are not needed if the system does not create rows."
+ ::= { rtpGroups 3 }
+
+rtpInverseGroup OBJECT-GROUP
+ OBJECTS {
+ rtpSessionInverseStartTime,
+ rtpSenderInverseStartTime,
+ rtpRcvrInverseStartTime
+ }
+ STATUS current
+ DESCRIPTION
+ "Objects used in the Inverse Lookup Tables."
+ ::= { rtpGroups 4 }
+
+--
+-- Compliance
+--
+rtpCompliances OBJECT IDENTIFIER ::= { rtpConformance 2 }
+
+rtpHostCompliance MODULE-COMPLIANCE
+ STATUS current
+
+
+
+Baugher, et al. Standards Track [Page 22]
+
+RFC 2959 RTP MIB October 2000
+
+
+ DESCRIPTION
+ "Host implementations MUST comply."
+ MODULE RTP-MIB
+ MANDATORY-GROUPS {
+ rtpSystemGroup,
+ rtpHostGroup
+ }
+ GROUP rtpMonitorGroup
+ DESCRIPTION
+ "Host systems my optionally support row creation and deletion.
+ This would allow an RTP Host system to act as an RTP Monitor."
+ GROUP rtpInverseGroup
+ DESCRIPTION
+ "Multicast RTP Systems SHOULD implement the optional
+ tables."
+ OBJECT rtpSessionNewIndex
+ MIN-ACCESS not-accessible
+ DESCRIPTION
+ "RTP system implementations support of
+ row creation and deletion is OPTIONAL so
+ implementation of this object is OPTIONAL."
+ OBJECT rtpSessionDomain
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "RTP system implementation support of
+ row creation and deletion is OPTIONAL. When
+ it is not supported so write access is
+ OPTIONAL."
+ OBJECT rtpSessionRemAddr
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Row creation and deletion is OPTIONAL so
+ read-create access to this object is OPTIONAL."
+ OBJECT rtpSessionIfIndex
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Row creation and deletion is OPTIONAL so
+ read-create access to this object is OPTIONAL."
+ OBJECT rtpSessionRowStatus
+ MIN-ACCESS not-accessible
+ DESCRIPTION
+ "Row creation and deletion is OPTIONAL so
+ read-create access to this object is OPTIONAL."
+ OBJECT rtpSessionInverseStartTime
+ MIN-ACCESS not-accessible
+ DESCRIPTION
+ "Multicast RTP Systems SHOULD implement the optional
+ tables."
+
+
+
+Baugher, et al. Standards Track [Page 23]
+
+RFC 2959 RTP MIB October 2000
+
+
+ OBJECT rtpSenderInverseStartTime
+ MIN-ACCESS not-accessible
+ DESCRIPTION
+ "Multicast RTP Systems SHOULD implement the optional
+ tables."
+ OBJECT rtpRcvrInverseStartTime
+ MIN-ACCESS not-accessible
+ DESCRIPTION
+ "Multicast RTP Systems SHOULD implement the optional
+ tables."
+ ::= { rtpCompliances 1 }
+
+rtpMonitorCompliance MODULE-COMPLIANCE
+ STATUS current
+ DESCRIPTION
+ "Monitor implementations must comply. RTP Monitors are not
+ required to support creation or deletion."
+ MODULE RTP-MIB
+ MANDATORY-GROUPS {
+ rtpSystemGroup,
+ rtpMonitorGroup
+ }
+ GROUP rtpHostGroup
+ DESCRIPTION
+ "Monitor implementations may not have access to values in the
+ rtpHostGroup."
+ GROUP rtpInverseGroup
+ DESCRIPTION
+ "Multicast RTP Systems SHOULD implement the optional
+ tables."
+ OBJECT rtpSessionLocAddr
+ MIN-ACCESS not-accessible
+ DESCRIPTION
+ "RTP monitor sourcing of RTP or RTCP data packets
+ is OPTIONAL and implementation of this object is
+ OPTIONAL."
+ OBJECT rtpRcvrPT
+ MIN-ACCESS not-accessible
+ DESCRIPTION
+ "RTP monitor systems may not support
+ retrieval of the RTP Payload Type from the RTP
+ header (and may receive RTCP messages only). When
+ queried for the payload type information"
+ OBJECT rtpSenderPT
+ MIN-ACCESS not-accessible
+ DESCRIPTION
+ "RTP monitor systems may not support
+ retrieval of the RTP Payload Type from the RTP
+
+
+
+Baugher, et al. Standards Track [Page 24]
+
+RFC 2959 RTP MIB October 2000
+
+
+ header (and may receive RTCP messages only). When
+ queried for the payload type information."
+ OBJECT rtpRcvrOctets
+ MIN-ACCESS not-accessible
+ DESCRIPTION
+ "RTP monitor systems may receive only the RTCP messages
+ and not the RTP messages that contain the octet count
+ of the RTP message. Thus implementation of this
+ object is OPTIONAL"
+ OBJECT rtpRcvrPackets
+ MIN-ACCESS not-accessible
+ DESCRIPTION
+ "RTP monitor systems may receive only the RTCP messages
+ and not the RTP messages that contain the octet count
+ of the RTP message. Thus implementation of this
+ object is OPTIONAL."
+ OBJECT rtpSessionIfIndex
+ MIN-ACCESS read-only
+ DESCRIPTION
+ "Row creation and deletion is OPTIONAL so
+ read-create access to this object is OPTIONAL."
+ OBJECT rtpSessionInverseStartTime
+ MIN-ACCESS not-accessible
+ DESCRIPTION
+ "Multicast RTP Systems SHOULD implement the optional
+ tables."
+ OBJECT rtpSenderInverseStartTime
+ MIN-ACCESS not-accessible
+ DESCRIPTION
+ "Multicast RTP Systems SHOULD implement the optional
+ tables."
+ OBJECT rtpRcvrInverseStartTime
+ MIN-ACCESS not-accessible
+ DESCRIPTION
+ "Multicast RTP Systems SHOULD implement the optional
+ tables."
+ ::= { rtpCompliances 2 }
+END
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baugher, et al. Standards Track [Page 25]
+
+RFC 2959 RTP MIB October 2000
+
+
+4. Security Considerations
+
+ In most cases, MIBs are not themselves security risks; if SNMP
+ security is operating as intended, the use of a MIB to view
+ information about a system, or to change some parameter at the
+ system, is a tool, not a threat. However, there are a number of
+ management objects defined in this MIB that have a MAX-ACCESS clause
+ of read-write and/or read-create. Such objects may be considered
+ sensitive or vulnerable in some network environments. The support
+ for SET operations in a non-secure environment without proper
+ protection can have a negative effect on network operations.
+
+ None of the read-only objects in this MIB reports a password, though
+ some SDES [RFC1889] items such as the CNAME [RFC1889], the canonical
+ name, may be deemed sensitive depending on the security policies of a
+ particular enterprise. If access to these objects is not limited by
+ an appropriate access control policy, these objects can provide an
+ attacker with information about a system's configuration and the
+ services that that system is providing. Some enterprises view their
+ network and system configurations, as well as information about usage
+ and performance, as corporate assets; such enterprises may wish to
+ restrict SNMP access to most of the objects in the MIB. This MIB
+ supports read-write operations against rtpSessionNewIndex which has
+ the side effect of creating an entry in the rtpSessionTable when it
+ is written to. Five objects in rtpSessionEntry have read-create
+ access: rtpSessionDomain, rtpSessionRemAddr, rtpSessionIfIndex,
+ rtpSessionRowStatus, and rtpSessionIfAddr identify an RTP session to
+ be monitored on a particular interface. The values of these objects
+ are not to be changed once created, and initialization of these
+ objects affects only the monitoring of an RTP session and not the
+ operation of an RTP session on any host end-system. Since write
+ operations to rtpSessionNewIndex and the five objects in
+ rtpSessionEntry affect the operation of the monitor, write access to
+ these objects should be subject to the appropriate access control
+ policy.
+
+ Confidentiality of RTP and RTCP data packets is defined in section 9
+ of the RTP specification [RFC1889]. Encryption may be performed on
+ RTP packets, RTCP packets, or both. Encryption of RTCP packets may
+ pose a problem for third-party monitors though "For RTCP, it is
+ allowed to split a compound RTCP packet into two lower-layer packets,
+ one to be encrypted and one to be sent in the clear. For example,
+ SDES information might be encrypted while reception reports were sent
+ in the clear to accommodate third-party monitors [RFC1889]."
+
+ SNMPv1 by itself is not a secure environment. Even if the network
+ itself is secure (for example by using IPSec), there is no control as
+ to who on the secure network is allowed to access and GET/SET
+
+
+
+Baugher, et al. Standards Track [Page 26]
+
+RFC 2959 RTP MIB October 2000
+
+
+ (read/change/create/delete) the objects in this MIB. It is
+ recommended that the implementers consider the security features as
+ provided by the SNMPv3 framework. Specifically, the use of the
+ User-based Security Model RFC 2574 [RFC2574] and the View-based
+ Access Control Model RFC 2575 [RFC2575] is recommended. It is then a
+ customer/user responsibility to ensure that the SNMP entity giving
+ access to an instance of this MIB, is properly configured to give
+ access to the objects only to those principals (users) that have
+ legitimate rights to indeed GET or SET (change/create/delete) them.
+
+5. Acknowledgements
+
+ The authors wish to thank Bert Wijnen and the participants from the
+ ITU SG-16 management effort for their helpful comments. Alan Batie
+ and Bill Lewis from Intel also contributed greatly to the RTP MIB
+ through their review of various drafts of the MIB and their work on
+ the implementation of an SNMP RTP Monitor. Stan Naudus from 3Com and
+ John Du from Intel contributed to the original RTP MIB design and
+ co-authored the original RTP MIB draft documents; much of their work
+ remains in the current RTP MIB. Bill Fenner provided solid feedback
+ that improved the quality of the final document.
+
+6. Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+
+
+
+
+
+
+Baugher, et al. Standards Track [Page 27]
+
+RFC 2959 RTP MIB October 2000
+
+
+7. References
+
+ [RFC1889] Shulzrinne, H., Casner, S., Frederick, R. and V.
+ Jacobson, "RTP: A Transport Protocol for real-time
+ applications," RFC 1889, January 1996.
+
+ [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An
+ Architecture for Describing SNMP Management Frameworks",
+ RFC 2571, April 1999.
+
+ [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
+ of Management Information for TCP/IP-based Internets",
+ STD 16, RFC 1155, May 1990.
+
+ [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions",
+ STD 16, RFC 1212, March 1991.
+
+ [RFC1215] Rose, M., "A Convention for Defining Traps for use with
+ the SNMP", RFC 1215, March 1991.
+
+ [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+ Rose, M. and S. Waldbusser, "Structure of Management
+ Information Version 2 (SMIv2)", STD 58, RFC 2578, April
+ 1999.
+
+ [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+ Rose, M. and S. Waldbusser, "Textual Conventions for
+ SMIv2", STD 58, RFC 2579, April 1999.
+
+ [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
+ Rose, M. and S. Waldbusser, "Conformance Statements for
+ SMIv2", STD 58, RFC 2580, April 1999.
+
+ [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin,
+ "Simple Network Management Protocol", STD 15, RFC 1157,
+ May 1990.
+
+ [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+ "Introduction to Community-based SNMPv2", RFC 1901,
+ January 1996.
+
+ [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+ "Transport Mappings for Version 2 of the Simple Network
+ Management Protocol (SNMPv2)", RFC 1906, January 1996.
+
+
+
+
+
+
+
+Baugher, et al. Standards Track [Page 28]
+
+RFC 2959 RTP MIB October 2000
+
+
+ [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen,
+ "Message Processing and Dispatching for the Simple
+ Network Management Protocol (SNMP)", RFC 2572, April
+ 1999.
+
+ [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model
+ (USM) for version 3 of the Simple Network Management
+ Protocol (SNMPv3)", RFC 2574, April 1999.
+
+ [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
+ "Protocol Operations for Version 2 of the Simple Network
+ Management Protocol (SNMPv2)", RFC 1905, January 1996.
+
+ [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3
+ Applications", RFC 2573, April 1999.
+
+ [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
+ Access Control Model (VACM) for the Simple Network
+ Management Protocol (SNMP)", RFC 2575, April 1999.
+
+ [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart,
+ "Introduction to Version 3 of the Internet-standard
+ Network
+ Management Framework", RFC 2570, April 1999.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baugher, et al. Standards Track [Page 29]
+
+RFC 2959 RTP MIB October 2000
+
+
+8. Authors' Addresses
+
+ Mark Baugher
+ Intel Corporation
+ 2111 N.E.25th Avenue
+ Hillsboro, Oregon 97124
+ U.S.A.
+
+ EMail: mbaugher@passedge.com
+
+
+ Bill Strahm
+ Intel Corporation
+ 2111 N.E.25th Avenue
+ Hillsboro, Oregon 97124
+ U.S.A.
+
+ EMail: Bill.Strahm@intel.com
+
+
+ Irina Suconick
+ Ennovate Networks
+ 60 Codman Hill Rd.,
+ Boxboro, Ma 01719
+ U.S.A.
+
+ EMail: irina@ennovatenetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baugher, et al. Standards Track [Page 30]
+
+RFC 2959 RTP MIB October 2000
+
+
+9. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Baugher, et al. Standards Track [Page 31]
+