Internet Draft RTP MIB November 16, 1998 Real-Time Transport Protocol Management Information Base November 16, 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. 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 ftp.ietf.org, nic.nordu.net, venera.isi.edu, or munnari.oz.au. Baugher, Strahm, Suconick Expires May 16, 1999 [Page 1] Internet Draft RTP MIB November 16, 1998 1. Changes from Previous Draft The RTP MIB has been restructured and objects have been renamed in this draft. The DEFINITIONS name has been changed from RTP to RTP-MIB and the MODULE-IDENTITY names has been changed from rtp to rtpMIB. To better align both the structure and naming with IETF norms, we changed the OBJECT IDENTIFIERS to be rtpMIBObjects, rtpAdmin, rtpConformance, and rtpDomains. rtpGlobals was dropped. The use of the term "sub-agent" was dropped in this draft to remove any confusion with specific implmentation alternatives that might be chosen for the RTP MIB. The DESCRIPTION clauses were clarified for rtpSessionRowStatus, rtpSessionReceivers and rtpSessionSenders. We also renamed rtpSessionReceivers to rtpSessionReceiverJoins and rtpSessionSenders to rtpSessionSenderJoins. rtpSenderSRTime and rtpRcvrRRTime no longer attach special meaning to the value of zero in their DESCRIPTIONS. rtpRcvrRTT DESCRIPTION specifies that 'noSuchInstance' should be returned rather than 'noSuchObject' when a value cannot be correctly computed for a particular conceptual row. Media octet and packet counters were changed from Counter32 to Counter64. rtpRcvrLostOctets was dropped from the RTP MIB. The Compliances section was broken into two sections, one for an RTP host and one for an RTP monitor. The redefinition of InterfaceIndex was dropped; InterfaceIndexOrZero is now used instead. 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 May 16, 1999 [Page 2] Internet Draft RTP MIB November 16, 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 the MIB. Baugher, Strahm, Suconick Expires May 16, 1999 [Page 3] Internet Draft RTP MIB November 16, 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.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. Baugher, Strahm, Suconick Expires May 16, 1999 [Page 4] Internet Draft RTP MIB November 16, 1998 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 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 May 16, 1999 [Page 5] Internet Draft RTP MIB November 16, 1998 5. Definitions RTP-MIB DEFINITIONS ::= BEGIN IMPORTS Counter32, Counter64, 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; InterfaceIndexOrZero FROM IF-MIB; rtpMIB MODULE-IDENTITY LAST-UPDATED "9811112000Z" 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 May 16, 1999 [Page 6] Internet Draft RTP MIB November 16, 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 May 16, 1999 [Page 7] Internet Draft RTP MIB November 16, 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 May 16, 1999 [Page 8] Internet Draft RTP MIB November 16, 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 InterfaceIndexOrZero, rtpSessionIfAddr IpAddress, rtpSessionSenderJoins Counter32, rtpSessionReceiverJoins Counter32, rtpSessionByes Counter32, rtpSessionStartTime TimeStamp, rtpSessionMonitor TruthValue, rtpSessionRowStatus RowStatus } Baugher, Strahm, Suconick Expires May 16, 1999 [Page 9] Internet Draft RTP MIB November 16, 1998 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} 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 May 16, 1999 [Page 10] Internet Draft RTP MIB November 16, 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 InterfaceIndexOrZero 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 if rtpSessionRowStatus is 'active'. A zero value for both rtpSessionIfIndex and rtpSessionIfAddr indicates that the default interface be used." DEFVAL { 0 } ::= { rtpSessionEntry 5 } Baugher, Strahm, Suconick Expires May 16, 1999 [Page 11] Internet Draft RTP MIB November 16, 1998 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 having an IP Address. If rtpSessionIfIndex is non-zero, this object should have the value 0.0.0.0. Cannot be changed if rtpSessionRowStatus is 'active'. A zero value for both rtpSessionIfIndex and rtpSessionIfAddr indicates that the default interface be used." DEFVAL { 0 } ::= { rtpSessionEntry 6 } 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 7 } 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 8 } Baugher, Strahm, Suconick Expires May 16, 1999 [Page 12] Internet Draft RTP MIB November 16, 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 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 Monitors MUST initialize to 'true(1)' and RTP Hosts MUST initialize this 'false(2)'." ::= { rtpSessionEntry 11 } 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 12 } Baugher, Strahm, Suconick Expires May 16, 1999 [Page 13] Internet Draft RTP MIB November 16, 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 May 16, 1999 [Page 14] Internet Draft RTP MIB November 16, 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 May 16, 1999 [Page 15] Internet Draft RTP MIB November 16, 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 May 16, 1999 [Page 16] Internet Draft RTP MIB November 16, 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 May 16, 1999 [Page 17] Internet Draft RTP MIB November 16, 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 May 16, 1999 [Page 18] Internet Draft RTP MIB November 16, 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 May 16, 1999 [Page 19] Internet Draft RTP MIB November 16, 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 May 16, 1999 [Page 20] Internet Draft RTP MIB November 16, 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 May 16, 1999 [Page 21] Internet Draft RTP MIB November 16, 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 May 16, 1999 [Page 22] Internet Draft RTP MIB November 16, 1998 -- -- MODULE GROUPS -- rtpGroups OBJECT IDENTIFIER ::= { rtpConformance 1 } rtpSystemGroup OBJECT-GROUP OBJECTS { rtpSessionDomain, rtpSessionRemAddr, rtpSessionIfIndex, rtpSessionIfAddr, 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 May 16, 1999 [Page 23] Internet Draft RTP MIB November 16, 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 May 16, 1999 [Page 24] Internet Draft RTP MIB November 16, 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." OBJECT rtpSessionIfAddr MIN-ACCESS read-only DESCRIPTION "Row creation and deletion is OPTIONAL so read-create access to this object is OPTIONAL." Baugher, Strahm, Suconick Expires May 16, 1999 [Page 25] Internet Draft RTP MIB November 16, 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 May 16, 1999 [Page 26] Internet Draft RTP MIB November 16, 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 May 16, 1999 [Page 27] Internet Draft RTP MIB November 16, 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 May 16, 1999 [Page 28] Internet Draft RTP MIB November 16, 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 May 16, 1999 [Page 29]