Internet Draft RTP MIB August 7, 1998
Real-Time Transport Protocol
Management Information Base
<draft-ietf-avt-rtp-mib-02.txt>
August 7, 1998
Mark Baugher
Intel Corporation
2111 N.E.25th Avenue
Hillsboro, Oregon 97124
mbaugher@intel.com
John Du
Intel Corporation
2111 N.E.25th Avenue
Hillsboro, Oregon 97124
John.Du@intel.com
Stan Naudus
3Com Corporation
2070 Chain Bridge Road
Vienna, Virginia 22182
Stan_Naudus@3Com.com
Status of this Memo
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 in
progress.''
To learn the current status of any Internet-Draft, please
check the 1id-abstracts.txt listing contained in the Internet-
Drafts Shadow Directories on ds.internic.net, nic.nordu.net,
venera.isi.edu, or munnari.oz.au.
Baugher, Du, Naudus Expires February 7, 1999 [Page 1]
Internet Draft RTP MIB August 7, 1998
1. Changes from Previous Draft
There is a large change introduced in this draft from the
previous draft: The tables for the RTP host and the
RTP monitor have been merged. The rtpInTable and rtpEgTable
have been removed and their objects are subsumed by the
rtpRcvrTable and rtpSenderTable, respectively. The rtpRRTable
and the rtpSRTable for RTP monitors are removed and their
objects are subsumed by the rtpRcvrTable and rtpSenderTable
respectively. rtpSessionMonitor has been added to the
rtpSessionTable to distinguish between sessions that are
being sourced or received by the local RTP System and sessions
that are being monitored by a third-party monitor or by a
local RTP System that may also be sending or receiving
RTP Session data.
For clarity an explicit address pair, rtpSessionLocAddr
and rtpSessionRemAddr have been added to the rtpSessionTable
to identify an RTP Session and replace the rtpEgDstAddr and
rtpInDstAddr objects. rtpSessionRemAddr replaces (renames)
rtpSessionAddr. Finally, rtpRRFracLost has been removed as an
object used by RTP monitors in favor of polling and computing
loss statistics in the network management application.
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.
3. The Network Management Framework
The SNMPv2 Network Management Framework consists of the
following major components:
Baugher, Du, Naudus Expires February 7, 1999 [Page 2]
Internet Draft RTP MIB August 7, 1998
RFC 1902 which defines the SMI, the mechanisms used for
describing and naming objects for the purpose of management.
RFC 1903 Textual Conventions for Version 2 of the Simple
Network Management Protocol (SNMPv2).
RFC 1904 Conformance Statements for Version 2 of the
Simple Network Management Protocol (SNMPv2).
RFC 1905 Protocol Operations for Version 2 of the
Simple Network Management Protocol (SNMPv2).
RFC 1906 Transport Mappings for Version 2 of the
Simple Network Management Protocol (SNMPv2).
RFC 1907 Management Information Base for Version 2 of
the Simple Network Management Protocol (SNMPv2).
RFC 1908 Coexistence between Version 1 and Version 2 of
the Internet-standard Network Management Framework.
The Framework permits new objects to be defined for the
purpose of experimentation and evaluation.
Managed objects are accessed via a virtual information store,
termed the Management Information Base or MIB. Within a given
MIB module, objects are defined using the SMI's OBJECT-TYPE
macro[2]. At a minimum, each object has a name, a syntax, an
access-level, and an implementation-status.
The name is an object identifier, an administratively assigned
name, which specifies an object type. The object type
together with an object instance serves to uniquely identify a
specific instantiation of the object. For human convenience,
we often use a textual string, termed the object descriptor,
to also refer to the object type.
The syntax of an object type defines the abstract data
structure corresponding to that object type. The ASN.1[3]
language is used for this purpose. However, RFC 1902
purposely restricts the ASN.1 constructs which may be used.
These restrictions are made for simplicity.
The access-level of an object type defines whether it makes
"protocol sense" to read and/or write the value of an instance
of the object type. (This access-level is independent of any
administrative authorization policy.)
The implementation-status of an object type indicates whether
the object is mandatory, optional, obsolete, or deprecated.
Baugher, Du, Naudus Expires February 7, 1999 [Page 3]
Internet Draft RTP MIB August 7, 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 Textual Conventions
A new data type, InterfaceIndex, is introduced as a textual convention
in this MIB document. Textual conventions enhance the readability of
the specification and can ease comparison with other specifications
if appropriate. It should be noted that the introduction of the
textual conventions has no effect on either the syntax nor the
semantics of any managed objects. The use of these is merely an
artifact of the explanatory method used. Objects defined in terms of
one of these methods are always encoded by means of the rules that
define the primitive type. Hence, no changes to the SMI or the SNMP
are necessary to accommodate these textual conventions which are
adopted merely for the convenience of readers and writers.
Baugher, Du, Naudus Expires February 7, 1999 [Page 4]
Internet Draft RTP MIB August 7, 1998
4.3 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.
4.3.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.3.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.4 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
sub-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, Du, Naudus Expires February 7, 1999 [Page 5]
Internet Draft RTP MIB August 7, 1998
4.5 SNMP Implementations
An RTP System that runs either a single application or multiple
applications with a single management-entity may be a practical
configuration for monitoring, translating or mixing. Host end-
-systems are the vast majority of RTP implementations, however,
a "monolithic" solution may be inadequate if management of
RTP end-systems proves to be truly useful. The RTP MIB contains
tables that may be shared among RTP application programs that run
concurrently on the same device - as many or most do. Sharing
occurs on a table basis.
Table sharing may be a problem for SNMP management entities on some
host operting systems: All SNMP management requests are sent to UDP
Port 161, and an Application Programming Interface (API) is needed to
facilitate this sharing. The API is specific to the host operating
system, and there are solutions provided by host operating system
vendors and by independent software vendors. There is also a
standardization effort within the IETF to at least define a standard
system-interface protocol that may be implemented in an API to permit
multiple management entities to share the object name space[4]. Whether
or not independent RTP application programs can cooperatively and
concurrently support the RTP MIB is outside the scope of this draft
document and will depend upon the operating system in question.
Baugher, Du, Naudus Expires February 7, 1999 [Page 6]
Internet Draft RTP MIB August 7, 1998
5. Definitions
RTP DEFINITIONS ::= BEGIN
IMPORTS
Counter32, Gauge32, experimental, Integer32,
IpAddress, 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;
rtp MODULE-IDENTITY
LAST-UPDATED "9807212000Z"
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
John Du
Postal: Intel Corporation
2111 NE 25th Avenue
Hillsboro, OR 97124
United States
Tel: +1 503 264 0636
Email: John.Du@intel.com
Stan Naudus
Postal: 3Com Corporation
2070 Chain Bridge Road
Vienna, VA
United States
Tel: +1 703 848 7710
Email: Stan_Naudus@3Com.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 source.
3. Information about RTP streams received on an
RTP Session by a particular receiver from a
particular sender.
Baugher, Du, Naudus Expires February 7, 1999 [Page 7]
Internet Draft RTP MIB August 7, 1998
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 }
InterfaceIndex ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The range of ifIndex. This is defined here since zero
is used to define an unnumbered interface."
SYNTAX Integer32
--
-- OBJECTS
--
rtpGlobals OBJECT IDENTIFIER ::= { rtp 1 }
rtpDomains OBJECT IDENTIFIER ::= { rtpGlobals 1 }
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, Du, Naudus Expires February 7, 1999 [Page 8]
Internet Draft RTP MIB August 7, 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 system is not a monitor, only
the RTP sub-agent may create conceptual rows in the
RTP session table."
::= { rtpGlobals 2 }
rtpSessionTable OBJECT-TYPE
SYNTAX SEQUENCE OF RtpSessionEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"There's one entry in the SessionTable for each RTP Session
on which packets are being sent, received, and/or
monitored."
::= { rtp 2 }
Baugher, Du, Naudus Expires February 7, 1999 [Page 9]
Internet Draft RTP MIB August 7, 1998
rtpSessionEntry OBJECT-TYPE
SYNTAX RtpSessionEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Data in rtpSessionTable uniquely identify an RTP
Session. A host sub-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)'. A
monitor sub-agent 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."
INDEX { rtpSessionIndex }
::= { rtpSessionTable 1 }
RtpSessionEntry ::= SEQUENCE {
rtpSessionIndex Integer32,
rtpSessionDomain TDomain,
rtpSessionRemAddr TAddress,
rtpSessionLocAddr TAddress,
rtpSessionIfIndex InterfaceIndex,
rtpSessionIfAddr IpAddress,
rtpSessionSenders Counter32,
rtpSessionReceivers Counter32,
rtpSessionByes Counter32,
rtpSessionStartTime TimeStamp,
rtpSessionMonitor TruthValue,
rtpSessionRowStatus RowStatus
}
rtpSessionIndex OBJECT-TYPE
SYNTAX Integer32 (1..65535)
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."
::= { rtpSessionEntry 1}
Baugher, Du, Naudus Expires February 7, 1999 [Page 10]
Internet Draft RTP MIB August 7, 1998
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 after 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 stream
of RTP data packets is being 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 an even-numbered UDP Port with the
RTCP being sent on the next higher odd-numbered port, see
RFC 1889, sec. 5. Cannot be changed after rtpSessionRowStatus
is 'active'."
::= { rtpSessionEntry 3 }
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 IP 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 an even-numbered
UDP Port with the RTCP being sent on the next higher
odd-numbered port, see RFC 1889, sec. 5."
::= { rtpSessionEntry 4 }
Baugher, Du, Naudus Expires February 7, 1999 [Page 11]
Internet Draft RTP MIB August 7, 1998
rtpSessionIfIndex OBJECT-TYPE
SYNTAX InterfaceIndex
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The ifIndex value is zero for interfaces that have an IP
address defined for the interface on which RTP data packets
are sent or received for this session. Otherwise this object
is set to the corresponding value from the Internet Standard
MIB. Cannot be changed after rtpSessionRowStatus is
'active'. A zero value for both rtpSessionIfIndex and
rtpSessionIfAddr indicates that the default interface be
used."
DEFVAL { 0 }
::= { rtpSessionEntry 5 }
rtpSessionIfAddr OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The IP Address of the interface on which the stream of RTP
data packets is being sent and/or received for interfaces that
have an IP Address. If rtpSessionIfIndex is non-zero, this
object should have the value 0.0.0.0. Cannot be changed after
rtpSessionRowStatus has become 'active'. A zero
value for both rtpSessionIfIndex and rtpSessionIfAddr
indicates that the default interface be used."
DEFVAL { 0 }
::= { rtpSessionEntry 6 }
rtpSessionSenders OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum number of senders observed by
the monitor since this conceptual row was created
(rtpSessionStartTime). 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."
::= { rtpSessionEntry 7 }
Baugher, Du, Naudus Expires February 7, 1999 [Page 12]
Internet Draft RTP MIB August 7, 1998
rtpSessionReceivers OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The maximum number of receivers that are
observed 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."
::= { rtpSessionEntry 8 }
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 9 }
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 10 }
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 Host Systems
MUST initialize this to 'false(2)'. RTP Monitors MUST
initialize to 'true(1)' and RTP Hosts MUST initialize this
'false(2)'."
::= { rtpSessionEntry 11 }
Baugher, Du, Naudus Expires February 7, 1999 [Page 13]
Internet Draft RTP MIB August 7, 1998
rtpSessionRowStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Value of 'active' when RTP or RTCP messages being sent or
received by an RTP System are being monitored. A manager-
created conceptual row must have the rtpSessionAddr initialized
by the manager before becoming 'active' A conceptual row that
is in the 'notReady' or 'notInService' state MAY be
removed after 5 minutes."
::= { rtpSessionEntry 12 }
--
-- 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. Sub-agents for RTP sending hosts MUST create an
entry in this table for each stream being sent. Sub-agents
for RTP monitors create an entry for each observed RTP Session
sender as a side-effect when a conceptual row in the
rtpSessionTable is made 'active' by a manager."
::= { rtp 3 }
rtpSenderEntry OBJECT-TYPE
SYNTAX RtpSenderEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry contains monitoring 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."
INDEX { rtpSessionIndex, rtpSenderSSRC }
::= { rtpSenderTable 1 }
Baugher, Du, Naudus Expires February 7, 1999 [Page 14]
Internet Draft RTP MIB August 7, 1998
RtpSenderEntry ::= SEQUENCE {
rtpSenderSSRC Unsigned32,
rtpSenderCNAME DisplayString,
rtpSenderAddr TAddress,
rtpSenderPackets Counter32,
rtpSenderOctets Counter32,
rtpSenderTool DisplayString,
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 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 Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of RTP packets sent by this sender, or observed by
an RTP monitor from RTCP Reports, since rtpSenderStartTime."
::= { rtpSenderEntry 4 }
Baugher, Du, Naudus Expires February 7, 1999 [Page 15]
Internet Draft RTP MIB August 7, 1998
rtpSenderOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of RTP octets sent by this sender, or observed by
an RTP monitor from RTCP Reports, since rtpSenderStartTime."
::= { rtpSenderEntry 5 }
rtpSenderTool OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..127))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Name of the application program that's the stream source."
DEFVAL { ''H } -- Null if not available
::= { 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
"The value is always zero if the source of the RTP Stream is
the local RTP System. Otherwise, rtpSenderSRTime is the
value of SysUpTime at the time that the last SR was received
from this sender, in the case of a monitor."
::= { rtpSenderEntry 8 }
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 }
Baugher, Du, Naudus Expires February 7, 1999 [Page 16]
Internet Draft RTP MIB August 7, 1998
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. Sub-agents for RTP hosts that receive RTP
Session packets create an entry in this table for that
receiver/sender pair Sub-agents for 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."
::= { rtp 4 }
rtpRcvrEntry OBJECT-TYPE
SYNTAX RtpRcvrEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"Each entry contains monitoring 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."
INDEX { rtpSessionIndex, rtpRcvrRemSSRC, rtpRcvrLocSSRC }
::= { rtpRcvrTable 1 }
Baugher, Du, Naudus Expires February 7, 1999 [Page 17]
Internet Draft RTP MIB August 7, 1998
RtpRcvrEntry ::= SEQUENCE {
rtpRcvrRemSSRC Unsigned32,
rtpRcvrLocSSRC Unsigned32,
rtpRcvrCNAME DisplayString,
rtpRcvrAddr TAddress,
rtpRcvrRTT Gauge32,
rtpRcvrLostPackets Counter32,
rtpRcvrLostOctets Counter32,
rtpRcvrJitter Gauge32,
rtpRcvrTool DisplayString,
rtpRcvrRRs Counter32,
rtpRcvrRRTime TimeStamp,
rtpRcvrPT INTEGER,
rtpRcvrPackets Counter32,
rtpRcvrOctets Counter32,
rtpRcvrStartTime TimeStamp
}
rtpRcvrRemSSRC 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 }
rtpRcvrLocSSRC 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 }
Baugher, Du, Naudus Expires February 7, 1999 [Page 18]
Internet Draft RTP MIB August 7, 1998
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 sub-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
'noSuchObject' in response to queries against rtpRcvrRTT."
::= { rtpRcvrEntry 5 }
rtpRcvrLostPackets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of RTP packets lost as observed by this receiver
since rtpRcvrStartTime."
::= { rtpRcvrEntry 6 }
rtpRcvrLostOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of RTP octets lost as observed by this receiver
since rtpRcvrStartTime."
::= { rtpRcvrEntry 7 }
rtpRcvrJitter OBJECT-TYPE
SYNTAX Gauge32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An estimate of delay variation as observed by this receiver."
::= { rtpRcvrEntry 8 }
Baugher, Du, Naudus Expires February 7, 1999 [Page 19]
Internet Draft RTP MIB August 7, 1998
rtpRcvrTool OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..127))
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Name of the application program that's receiving the stream."
DEFVAL { ''H } -- Null if not available
::= { rtpRcvrEntry 9 }
rtpRcvrRRs OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A count of Receiver Reports as observed by this receiver
since rtpSessionStartTime."
::= { rtpRcvrEntry 10 }
rtpRcvrRRTime OBJECT-TYPE
SYNTAX TimeStamp
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value is always zero if the receiver of the RTP Stream
is the local RTP System. Otherwise, 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 sent by this receiver, in the case of a receiving
host."
::= { rtpRcvrEntry 11 }
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 12 }
Baugher, Du, Naudus Expires February 7, 1999 [Page 20]
Internet Draft RTP MIB August 7, 1998
rtpRcvrPackets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of RTP packets received by this RTP host receiver since
rtpRcvrStartTime. RTP Sessions being monitored ('true(1)'
value for rtpSessionMonitor) may not have this information."
::= { rtpRcvrEntry 13 }
rtpRcvrOctets OBJECT-TYPE
SYNTAX Counter32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of RTP octets received by this receiving RTP host
since rtpRcvrStartTime. Monitored sessions (rtpSessionMonitor
is 'false') may not have this information."
::= { rtpRcvrEntry 14 }
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 15 }
--
-- MODULE GROUPS
--
Baugher, Du, Naudus Expires February 7, 1999 [Page 21]
Internet Draft RTP MIB August 7, 1998
rtpSystemGroup OBJECT-GROUP
OBJECTS {
rtpSessionDomain,
rtpSessionRemAddr,
rtpSessionIfIndex,
rtpSessionIfAddr,
rtpSessionSenders,
rtpSessionReceivers,
rtpSessionStartTime,
rtpSessionRowStatus,
rtpSessionByes,
rtpSessionMonitor,
rtpSenderCNAME,
rtpSenderAddr,
rtpSenderPackets,
rtpSenderOctets,
rtpSenderTool,
rtpSenderSRs,
rtpSenderSRTime,
rtpSenderStartTime,
rtpRcvrCNAME,
rtpRcvrAddr,
rtpRcvrLostPackets,
rtpRcvrJitter,
rtpRcvrTool,
rtpRcvrRRs,
rtpRcvrRRTime,
rtpRcvrStartTime
}
STATUS current
DESCRIPTION
"Objects used by all RTP systems."
::= { rtp 5 }
rtpHostGroup OBJECT-GROUP
OBJECTS {
rtpSessionLocAddr,
rtpSenderPT,
rtpRcvrPT,
rtpRcvrRTT,
rtpRcvrLostOctets,
rtpRcvrOctets,
rtpRcvrPackets
}
STATUS current
DESCRIPTION
"Objects used by RTP host systems."
::= { rtp 6 }
Baugher, Du, Naudus Expires February 7, 1999 [Page 22]
Internet Draft RTP MIB August 7, 1998
rtpMonitorGroup OBJECT-GROUP
OBJECTS {
rtpSessionNewIndex
}
STATUS current
DESCRIPTION
"Objects used by RTP monitor systems."
::= { rtp 7 }
rtpCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The management information of the objects in the
rtpISGroup is taken from the IP, UDP, RTP headers
and the required RTCP messages that are specified
in RFC 1889, 'RTP: A Transport Protocol for Real-Time
Applications', 6.4. rtpRcvrTool and rtpSenderTool are
not required fields in the RTCP SDES message so
a DEFVAL is provided for these objects."
MODULE RTP
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."
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 MAY NOT support
row creation and deletion."
OBJECT rtpSessionDomain
MIN-ACCESS read-only
DESCRIPTION
"RTP host system implementations MAY NOT support
row creation and deletion."
OBJECT rtpSessionRemAddr
MIN-ACCESS read-only
DESCRIPTION
"RTP host system implementations MAY NOT support
row creation and deletion."
Baugher, Du, Naudus Expires February 7, 1999 [Page 23]
Internet Draft RTP MIB August 7, 1998
OBJECT rtpSessionIfIndex
MIN-ACCESS read-only
DESCRIPTION
"RTP host system implementations MAY NOT support
row creation and deletion."
OBJECT rtpSessionIfAddr
MIN-ACCESS read-only
DESCRIPTION
"RTP host system implementations MAY NOT support
row creation and deletion."
OBJECT rtpSessionRowStatus
MIN-ACCESS not-accessible
DESCRIPTION
"RTP host system implementations MAY NOT support
row creation and deletion."
OBJECT rtpSessionLocAddr
MIN-ACCESS not-accessible
DESCRIPTION
"RTP monitor system implementations MAY NOT source
RTP or RTCP data packets."
OBJECT rtpRcvrPT
MIN-ACCESS not-accessible
DESCRIPTION
"RTP monitor system implementations 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, the
sub-agent MAY return 'noSuchObject'."
OBJECT rtpSenderPT
MIN-ACCESS not-accessible
DESCRIPTION
"RTP monitor system implementations 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, the
sub-agent MAY return 'noSuchObject'."
OBJECT rtpRcvrRTT
MIN-ACCESS not-accessible
DESCRIPTION
"The round-trip time calculation presented
on sec. 6 of RFC 1889, 'RTP: A Transport
Protocol for Real-Time Applications', may
be accurately computed by a monitor that uses
the same clock as a particular sender. In other
cases, the monitor SHOULD return 'noSuchObject'
in response to a Get that references rtpRcvrRTT."
Baugher, Du, Naudus Expires February 7, 1999 [Page 24]
Internet Draft RTP MIB August 7, 1998
OBJECT rtpRcvrLostOctets
MIN-ACCESS not-accessible
DESCRIPTION
"RTP monitor system implementations MAY NOT support
monitoring of this object when rtpSessionMonitor is
'true' since it is not obtainable from RTCP reports."
OBJECT rtpRcvrOctets
MIN-ACCESS not-accessible
DESCRIPTION
"RTP monitor system implementations MAY NOT support
monitoring of this object when rtpSessionMonitor is
'true' since it is not obtainable from RTCP reports."
OBJECT rtpRcvrPackets
MIN-ACCESS not-accessible
DESCRIPTION
"RTP monitor system implementations MAY NOT support
monitoring of this object when rtpSessionMonitor is
'true' since it is not obtainable from RTCP reports."
::= { rtp 8 }
END
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
Baugher, Du, Naudus Expires February 7, 1999 [Page 25]
Internet Draft RTP MIB August 7, 1998
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, Du, Naudus Expires February 7, 1999 [Page 26]
Internet Draft RTP MIB August 7, 1998
7. Acknowledgements
George Kajos and Irina Suconick from Videoserver recommended some
changes in the structure and organization of the RTP MIB that are
contained in this draft. Boris Bekkerman from 3Com identified
some problems in clarity and consistency of RTP MIB definitions.
Alan Batie and Bill Strahm from Intel have prototyped SNMP RTP
Monitors on FreeBSD and Windows NT, respectively. The Windows
implementation is being used at Intel. Bill Lewis from Intel
has written an RTP management application that is available in
binary form with the FreeBSD version of the SNMP RTP Monitor.
9. References
[1] H. Shulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP:
A Transport Protocol for real-time applications," RFC 1889.
[2] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser,
"Structure of Management Information for Version 2
of the Simple Network Management Protocol (SNMPv2)",
RFC 1902, January, 1996.
[3] Information processing systems -- Open Systems
Interconnection -- Specification of Basic Encoding Rules
for Abstract Notation One (ASN.1), International
Organization for Standardization. International Standard
8825, (December, 1987).
[4] M.Daniele, B. Wijnen, D. Francisco, "Agent Extensibility
(AgentX) Protocol, Version 1," RFC 2257, January 1998.
Baugher, Du, Naudus Expires February 7, 1999 [Page 27]
