Internet Draft RTP MIB February 26, 1998
Real-Time Transport Protocol
Management Information Base
<draft-ietf-avt-rtp-mib-04.txt>
February 26, 1998
Mark Baugher
Intel Corporation
2111 N.E.25th Avenue
Hillsboro, Oregon 97124
mbaugher@intel.com
Bill Strahm
Intel Corporation
2111 N.E.25th Avenue
Hillsboro, Oregon 97124
Bill.Strahm@intel.com
Irina Suconick
Videoserver Corporation
63 Third Street
Burlington, Massachusetts 01803
isuconick@videoserver.com
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. Internet-Drafts are
working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or made
obsolete by other documents at any time. It is not
appropriate to use Internet-Drafts as reference material or to
cite them other than as a ``working draft'' or ``work inprogress.''
To learn the current status of any Internet-Draft, please
check the 1id-abstracts.txt listing contained in the Internet-
Drafts Shadow Directories on ftp.ietf.org, nic.nordu.net,
venera.isi.edu, or munnari.oz.au.
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 1]
Internet Draft RTP MIB February 26, 1998
1. Changes from Previous Draft
There were three main changes to the draft.
Section 4.3.3 was added to clarify that host systems may include data
gathered from RTCP data on streams that they are involved with.
rtpSessionIndex was changed to allow 2^31-1 indexes and also a note saying
that sessions are not required to be sequential. This is from some
questions about subagents allocating indexes out of an internal "sub-pool"
and the need to renumber indexes after a row deletion.
rtpSessionIfAddr was removed and rtpSessionIfIndex was made into an
InterfaceIndex. It was determined that all addresses will go through
an indexed interface, therefor it was complicated and confusing
maintaining the two objects.
2. Abstract
This memo defines an experimental Management Information Base
(MIB) for use with network management protocols in
TCP/IP-based internets. In particular, it defines objects for
managing Real-Time Transport Protocol systems [1]. Comments
should be made to the IETF Audio/Video Transport Working Group
at rem-conf@es.net.This memo does not specify a standard for the Internet
community.
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 2]
Internet Draft RTP MIB February 26, 1998
3. The Network Management Framework
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in RFC 2271 [2].
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
RFC 1155 [3], RFC 1212 [4] and RFC 1215 [5]. The second version,
called SMIv2, is described in RFC 1902 [6], RFC 1903 [7] and RFC
1904 [8].
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in RFC 1157 [9]. A second version of the SNMP message
protocol, which is not an Internet standards track protocol, is
called SNMPv2c and described in RFC 1901 [10] and RFC 1906 [11].
The third version of the message protocol is called SNMPv3 and
described in RFC 1906 [11], RFC 2272 [12] and RFC 2274 [13].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in RFC 1157 [9]. A second set of protocol operations
and associated PDU formats is described in RFC 1905 [14].
o A set of fundamental applications described in RFC 2273 [15] and
the view-based access control mechanism described in RFC 2275
[16].
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
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 theMIB.
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 3]
Internet Draft RTP MIB February 26, 1998
4. 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 [1].
RTP monitors may collect RTCP information on senders and receivers
to and from an RTP host or intermediate-system.
4.1 Components
The RTP MIB is structured around "session," "Receiver" and "Sender"
conceptual abstractions.
4.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 [1].
4.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 [1]. The sender is
also a source of RTCP Sender Report packets as specified in section 6 of [1].
4.1.3 A "Receiver" of a "stream of RTP packets" can be a unicast or
multicast Receiver as described in 4.2.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 [1].
4.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 [1].
Use of the RTP MIB for RTP Translators and Mixers, as defined in
section 7 of [1], is for further study.
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 4]
Internet Draft RTP MIB February 26, 1998
4.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 life time of an RTP session as
in a "help-desk" scenario.
4.2.2 RTP Monitors of multicast RTP sessions may be third-party, or
may be located in an RTP intermediate-system or in the 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.
4.2.3 Many host systems will want to keep track of streams beyond what
they are sending and receiving. In this mode a host system 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 RTP host that is sending a stream would use data from
its RTP stack to maintain the rtpSenderTable, however it may want to
maintain a rtpReceiverTable for endpoints that are receiving its stream.
To do this the host will collect RTCP data from the receivers of its
stream to build the rtpReceiverTable.
4.3 The Structure of the RTP MIB
There are three tables in the RTP MIB. The rtpSessionTable contains
objects that describe active sessions at the host, intermediate system,
or monitor. The rtpSenderTable contains information about senders
to the RTP session. The rtpRcvrTable contains information about
receivers of RTP session data.
For any particular RTP session, the rtpSessionMonitor object indicates
whether information about remote senders or receivers to the RTP
session are to be monitored. 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.
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 5]
Internet Draft RTP MIB February 26, 1998
5. DefinitionsRTP-MIB DEFINITIONS ::= BEGIN
IMPORTS
Counter32, Counter64, Gauge32, experimental, Integer32,
MODULE-IDENTITY, OBJECT-IDENTITY,
OBJECT-TYPE, Unsigned32 FROM SNMPv2-SMI
DisplayString, RowStatus, TAddress,
TDomain, TestAndIncr, TEXTUAL-CONVENTION,
TimeStamp, TruthValue FROM SNMPv2-TC
OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF;
InterfaceIndex FROM IF-MIB;
rtpMIB MODULE-IDENTITY
LAST-UPDATED "990222000Z"
ORGANIZATION "IETF AVT Working Group"
CONTACT-INFO
"Mark Baugher
Postal: Intel Corporation
2111 NE 25th Avenue
Hillsboro, OR 97124
United States
Tel: +1 503 264 3849
Email: mbaugher@intel.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: Videoserver Corporation
63 Third Street
Burlington, MA 01803
United States
Tel: +1 781-505-2155
Email: isuconick@videoserver.com"
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 6]
Internet Draft RTP MIB February 26, 1998
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 source.
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."
::= { experimental 77 }
-- ::== { mib-2 xx } to be assigned by IANA when going to Proposed
--
-- OBJECTS
--
rtpMIBObjects OBJECT IDENTIFIER ::= { rtpMIB 1 }
rtpAdmin OBJECT IDENTIFIER ::= { rtpMIB 2 }
rtpConformance OBJECT IDENTIFIER ::= { rtpMIB 3 }
rtpDomains OBJECT IDENTIFIER ::= { rtpMIB 4 }
rtpUDPDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"RTP over UDP transport domain over IPv4. This definition
uses the transport address type, snmpUDPAddress, which is
defined in SNMPv2-TM, 'Transport Mappings for Version 2 of
the Simple Network Management Protocol (SNMPv2)'."
REFERENCE "RFC 1906, sec. 2 " ::= { rtpDomains 1 }
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 7]
Internet Draft RTP MIB February 26, 1998
--
-- SESSION TABLE
--
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 SNMPv2'. For an RTP monitor
system, 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. The RTP agent is a monitor for a
paricular session only if rtpSessionMonitor is set to
'true(1)'."
::= { rtpMIBObjects 1 }
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 2 }
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 8]
Internet Draft RTP MIB February 26, 1998
rtpSessionEntry OBJECT-TYPE
SYNTAX RtpSessionEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Data in rtpSessionTable uniquely identify an RTP
session. A host RTP agent will create a read-only row for
each session to which packets are being sent or received.
An RTP session can 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 may permit row creation with the side
effect of causing the RTP System to join the session for
the purposes of gathering management information (thus
additional conceptual rows are created in the rtpRcvrTable
and rtpSenderTable). rtpSessionTable rows can be created
for RTP session monitoring purposes. Rows created by a
management application may be deleted via SNMP operations.
Rows created by a management application (rtSessionMonitor
is 'true(1)') are deleted by the management application.
When rtpSessionMonitor is 'false(2), rows are created by the
RTP Agent at the start of a session when one or more or more
senders or receivers are observed. Rows created by an RTP
agent are deleted when the session is over and there are no
rtpRcvrEntry and no rtpSenderEntry for this session."
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
}
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 9]
Internet Draft RTP MIB February 26, 1998
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'."
DEFVAL { rtpUDPDomain }
::= { rtpSessionEntry 2 }
rtpSessionRemAddr OBJECT-TYPE
SYNTAX TAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The remote destination transport address on which the
RTP data packet stream is sent and/or received. An RTP
Session is defined by a pair of destination transport
addresses. '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 rtpUDPDomain,
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. Cannot be changed if rtpSessionRowStatus
is 'active'."
::= { rtpSessionEntry 3 }
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 10]
Internet Draft RTP MIB February 26, 1998
rtpSessionLocAddr OBJECT-TYPE
SYNTAX TAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The local destination transport address on which the stream
of data packets is being sent and/or received. For unicast
RTP sessions, this is the local address of the
RTP session. For multicast RTP sessions, this object should
have the same value as rtpSessionRemoteAddr. See RFC 1889,
'RTP: A Transport Protocol for Real-Time Applications,' sec.
3. The transport service is identified by rtpSessionDomain.
For rtpUDPDomain, 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 the Internet Standard MIB. 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'."
DEFVAL { 0 }
::= { rtpSessionEntry 5 }
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 11]
Internet Draft RTP MIB February 26, 1998
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
(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 an
rtpSenderEntry is created for this session, 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
to have joined this session since this conceptual row was
created (rtpSessionStartTime). 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. Every time an
rtpRcvrEntry is created for this session, this counter
is incremented."
::= { rtpSessionEntry 7 }
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 12]
Internet Draft RTP MIB February 26, 1998
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
"Boolean, Set to 'true(1)' if senders or receivers in
addition to the local RTP System are to be monitored.
RTP Monitors MUST initialize to 'true(1)' and RTP
Hosts MUST initialize this 'false(2)'."
::= { 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 rtpSessionRemAddr and
rtpSessionLocAddr initialized before becoming 'active'.
A conceptual row that is in the 'notReady' or 'notInService'
state MAY be removed after 5 minutes."
::= { rtpSessionEntry 11 }
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 13]
Internet Draft RTP MIB February 26, 1998
--
-- 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 monitors create an entry
for each observed sender to an RTP Session as a side-effect
when a conceptual row in the rtpSessionTable is made
'active' by a manager."
::= { rtpMIBObjects 3 }
rtpSenderEntry OBJECT-TYPE
SYNTAX RtpSenderEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry contains information from a single RTP Synch-
ronization 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). Fate is shared with the rtpSessionIndex
conceptual row as well."
INDEX { rtpSessionIndex, rtpSenderSSRC }
::= { rtpSenderTable 1 }
RtpSenderEntry ::= SEQUENCE {
rtpSenderSSRC Unsigned32,
rtpSenderCNAME DisplayString,
rtpSenderAddr TAddress,
rtpSenderPackets Counter64,
rtpSenderOctets Counter64,
rtpSenderTool DisplayString,
rtpSRs Counter32,
rtpSenderSRTime TimeStamp,
rtpSenderPT INTEGER,
rtpSenderStartTime TimeStamp
}
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 14]
Internet Draft RTP MIB February 26, 1998
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 or receiver of an RTP stream (see RFC
1889, 'RTP: A Transport Protocol for Real-Time
Applications' sec.3)."
::= { rtpSenderEntry 1 }
rtpSenderCNAME OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..255))
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."
::= { 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
an RTP monitor, since rtpSenderStartTime."
::= { rtpSenderEntry 4 }
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 15]
Internet Draft RTP MIB February 26, 1998
rtpSenderOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of RTP octets sent by this sender, or observed by
an RTP monitor, since rtpSenderStartTime."
::= { rtpSenderEntry 5 }
rtpSenderTool OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..127))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Name of the application program source of the stream."
DEFVAL { ''H } -- Null if not available
::= { rtpSenderEntry 6 }
rtpSRs 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 }
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 16]
Internet Draft RTP MIB February 26, 1998
rtpSenderPT 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)."
::= { 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 }
--
-- 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
create an entry in this table for that receiver/sender
pair. 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 4 }
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 17]
Internet Draft RTP MIB February 26, 1998
rtpRcvrEntry OBJECT-TYPE
SYNTAX RtpRcvrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry contains information from a single RTP
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). Fate is shared with the
rtpSessionIndex conceptual row as well."
INDEX { rtpSessionIndex, rtpRcvrSRCSSRC, rtpRcvrSSRC }
::= { rtpRcvrTable 1 }
RtpRcvrEntry ::= SEQUENCE {
rtpRcvrSRCSSRC Unsigned32,
rtpRcvrSSRC Unsigned32,
rtpRcvrCNAME DisplayString,
rtpRcvrAddr TAddress,
rtpRcvrRTT Gauge32,
rtpRcvrLostPackets Counter64,
rtpRcvrJitter Gauge32,
rtpRRs Counter32,
rtpRcvrTool DisplayString,
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 }
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 18]
Internet Draft RTP MIB February 26, 1998
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 sender or receiver of an RTP stream (see RFC
1889, 'RTP: A Transport Protocol for Real-Time
Applications' sec.3)."
::= { rtpRcvrEntry 2 }
rtpRcvrCNAME OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..255))
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
"The unicast transport address of the receiver."
::= { 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 a sending host for the
particular reciever). Otherwise, the entity should return
'noSuchInstance' in response to queries against rtpRcvrRTT."
::= { rtpRcvrEntry 5 }
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 19]
Internet Draft RTP MIB February 26, 1998
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."
::= { rtpRcvrEntry 7 }
rtpRcvrTool OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..127))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Name of the application program source of the stream."
DEFVAL { ''H } -- Null if not available
::= { rtpRcvrEntry 8 }
rtpRRs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of Receiver Reports as observed by this receiver
since rtpSessionStartTime."
::= { rtpRcvrEntry 9 }
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 20]
Internet Draft RTP MIB February 26, 1998
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. It is the
value of SysUpTime at the time that the last RR was sent by
this receiver in the case of a 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. RTP monitors may not have this
information and should return 'noSuchInstance.'"
::= { rtpRcvrEntry 12 }
rtpRcvrOctets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of RTP octets received by this receiving RTP host
since rtpRcvrStartTime. RTP monitors may not have this
this information and should return 'noSuchInstance.'"
::= { rtpRcvrEntry 13 }
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 21]
Internet Draft RTP MIB February 26, 1998
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 }
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 22]
Internet Draft RTP MIB February 26, 1998
--
-- MODULE GROUPS
--
rtpGroups OBJECT IDENTIFIER ::= { rtpConformance 1 }
rtpSystemGroup OBJECT-GROUP
OBJECTS {
rtpSessionDomain,
rtpSessionRemAddr,
rtpSessionIfIndex,
rtpSessionSenderJoins,
rtpSessionReceiverJoins,
rtpSessionStartTime,
rtpSessionRowStatus,
rtpSessionByes,
rtpSessionMonitor,
rtpSenderCNAME,
rtpSenderAddr,
rtpSenderPackets,
rtpSenderOctets,
rtpSenderTool,
rtpSRs,
rtpSenderSRTime,
rtpSenderStartTime,
rtpRcvrCNAME,
rtpRcvrAddr,
rtpRcvrLostPackets,
rtpRcvrJitter,
rtpRcvrTool,
rtpRRs,
rtpRcvrRRTime,
rtpRcvrStartTime
}
STATUS current
DESCRIPTION
"Objects used by all RTP systems."
::= { rtpGroups 1 }
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 23]
Internet Draft RTP MIB February 26, 1998
rtpHostGroup OBJECT-GROUP
OBJECTS {
rtpSessionLocAddr,
rtpSenderPT,
rtpRcvrPT,
rtpRcvrRTT,
rtpRcvrOctets,
rtpRcvrPackets
}
STATUS current
DESCRIPTION
"Objects used by RTP host systems."
::= { rtpGroups 2 }
rtpMonitorGroup OBJECT-GROUP
OBJECTS {
rtpSessionNewIndex
}
STATUS current
DESCRIPTION
"Objects used by RTP monitor systems."
::= { rtpGroups 3 }
--
-- Compliance
--
rtpCompliances OBJECT IDENTIFIER ::= { rtpConformance 2 }
rtpHostCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Host implementations must comply."
MODULE RTP-MIB
MANDATORY-GROUPS { rtpSystemGroup }
GROUP rtpHostGroup
DESCRIPTION
"The objects in the rtpHostGroup MUST be
implemented in RTP host systems that are the source
or the destination of RTP data packets."
::= { rtpCompliances 1 }
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 24]
Internet Draft RTP MIB February 26, 1998
rtpMonitorCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"Monitor implementations must comply."
MODULE RTP-MIB
MANDATORY-GROUPS {
rtpSystemGroup,
rtpHostGroup
}
GROUP rtpMonitorGroup
DESCRIPTION
"The objects in the rtpMonitorGroup MUST be
implemented in RTP monitors."
OBJECT rtpSessionNewIndex
MIN-ACCESS not-accessible
DESCRIPTION
"RTP host 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 host 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."
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 25]
Internet Draft RTP MIB February 26, 1998
OBJECT rtpSessionRowStatus
MIN-ACCESS not-accessible
DESCRIPTION
"Row creation and deletion is OPTIONAL so
read-create access to this object is OPTIONAL."
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 NEED 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, the
RTP agent may return 'noSuchObject'."
OBJECT rtpSenderPT
MIN-ACCESS not-accessible
DESCRIPTION
"RTP monitor systems may recieve only the RTCP messages
and not the RTP messages that contain the payload type
information in the header. Thus implementation of this
object is OPTIONAL."
OBJECT rtpRcvrOctets
MIN-ACCESS not-accessible
DESCRIPTION
"RTP monitor systems may recieve 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 recieve 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."
::= { rtpCompliances 2 }
END
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 26]
Internet Draft RTP MIB February 26, 1998
6. Security Issues
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.
None of the read-only objects in this MIB reports a password, though
some SDES items such as the CNAME, 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 themselves, 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 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 [1]. 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 [1]."
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 27]
Internet Draft RTP MIB February 26, 1998
7. 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.
8. References
[1] H. Shulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP:
A Transport Protocol for real-time applications," RFC 1889.
[2] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2271, Cabletron
Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research,
January 1998
[3] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 1990
[4] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212,
Performance Systems International, Hughes LAN Systems, March 1991
[5] M. Rose, "A Convention for Defining Traps for use with the SNMP",
RFC 1215, Performance Systems International, March 1991
[6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure
of Management Information for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco
Systems, Inc., Dover Beach Consulting, Inc., International Network
Services, January 1996.
[7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual
Conventions for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc.,
Dover Beach Consulting, Inc., International Network Services,
January 1996.
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 28]
Internet Draft RTP MIB February 26, 1998
[8] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance
Statements for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc.,
Dover Beach Consulting, Inc., International Network Services,
January 1996.
[9] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
Management Protocol", RFC 1157, SNMP Research, Performance Systems
International, Performance Systems International, MIT Laboratory
for Computer Science, May 1990.
[10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, SNMP Research,
Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc.,
International Network Services, January 1996.
[11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport
Mappings for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc.,
Dover Beach Consulting, Inc., International Network Services,
January 1996.
[12] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems,
Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998.
[13] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for
version 3 of the Simple Network Management Protocol (SNMPv3)", RFC
2274, IBM T. J. Watson Research, January 1998.
[14] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
Operations for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc.,
Dover Beach Consulting, Inc., International Network Services,
January 1996.
[15] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC
2273, SNMP Research, Inc., Secure Computing Corporation, Cisco
Systems, January 1998
[16] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc.,
Cisco Systems, Inc., January 1998
Baugher, Strahm, Suconick Expires Aug 26, 1999 [Page 29]
