Real-Time Transport Protocol Management Information Base
Extracted elements (28)
Inverse lookup tables are provided because without them a management application may be forced to perform expensive tree walks through large numbers of sessions, senders, or receivers when the primary index (rtpSessionIndex, SSRC) is not known in advance.
rtpRcvrRTT returns 'noSuchInstance' rather than a zero or invalid value when the RTP agent does not share a clock with the stream sender, because the RFC 1889 RTT algorithm produces meaningful results only when the monitor is also the sending host for that particular receiver.
Two separate compliance profiles (rtpHostCompliance and rtpMonitorCompliance) are defined because host systems have direct access to RTP packet data (payload type, octet counts, local address) while monitors may receive only RTCP and therefore cannot populate those objects.
The MIB module is specified in SMIv2; a translation to SMIv1 is possible but loses Counter64 objects (such as rtpSenderPackets, rtpSenderOctets, rtpRcvrLostPackets, rtpRcvrPackets, rtpRcvrOctets) since SMIv1 has no equivalent, and machine-readable SMIv2 annotations become textual descriptions.
A host monitor system MUST set the rtpSessionMonitor object to 'true(1)'; it does not have to accept management operations that create and destroy rows in rtpSessionTable.
A host RTP agent MUST create a read-only row in rtpSessionTable for each session on which packets are being sent or received, and rows MUST be created at the start of a session when one or more senders or receivers are observed.
An RTP monitor SHOULD permit row creation in rtpSessionTable with the side effect of causing the RTP system to join the multicast session for gathering management information, thereby populating rtpRcvrTable and rtpSenderTable.
Host implementations MUST comply with the rtpHostCompliance MODULE-COMPLIANCE, which mandates both rtpSystemGroup and rtpHostGroup; rtpMonitorGroup and rtpInverseGroup are optional for hosts.
Implementors of this MIB SHOULD implement the inverse lookup tables (rtpSessionInverseTable, rtpSenderInverseTable, rtpRcvrInverseTable) for multicast RTP sessions when table indexes are not available from other MIBs, to avoid expensive tree walks.
Monitor implementations must comply with rtpMonitorCompliance, which mandates rtpSystemGroup and rtpMonitorGroup; rtpHostGroup objects such as local address, payload type, and octet counts are optional for monitors that receive only RTCP.
Rows created by an RTP agent MUST be deleted when the session is over and there are no remaining rtpRcvrEntry or rtpSenderEntry for that session.
RTP hosts that receive RTP session packets MUST create an entry in rtpRcvrTable for each receiver/sender pair. RTP monitors must create an entry for each observed receiver as a side effect of activating an rtpSessionTable row.
RTP sending hosts MUST have an entry in rtpSenderTable for each stream being sent. RTP monitors MUST create an entry for each observed sender to a multicast RTP session when a conceptual row in rtpSessionTable is made active.
When rtpSessionMonitor is true(1), senders and receivers to the session MUST be monitored with entries in rtpSenderTable and rtpRcvrTable, populated from RTCP reports.
rtpRcvrRTT (Gauge32) reports the round-trip time measured using the RFC 1889 sec. 6 algorithm; it is meaningful only when the RTP agent shares a clock with the stream sender (i.e., the monitor is also the sending host). Otherwise, the entity must return 'noSuchInstance'.
rtpRcvrTable is indexed by {rtpSessionIndex, rtpRcvrSRCSSRC, rtpRcvrSSRC}, capturing receiver-side metrics: rtpRcvrLostPackets (Counter64), rtpRcvrJitter (Gauge32, delay variation per RFC 1889 sec. 6.3.1), rtpRcvrRRs (Counter32), rtpRcvrRTT (Gauge32), rtpRcvrPackets and rtpRcvrOctets (Counter64), and rtpRcvrPT (INTEGER 0..127).
rtpSenderTable is indexed by {rtpSessionIndex, rtpSenderSSRC} (Unsigned32 SSRC) and exposes per-sender fields: rtpSenderCNAME (Utf8String), rtpSenderAddr (TAddress), rtpSenderPackets and rtpSenderOctets (Counter64), rtpSenderTool (Utf8String, max 127 bytes), rtpSenderSRs (Counter32), rtpSenderSRTime (TimeStamp), and rtpSenderPT (INTEGER 0..127).
rtpSessionMonitor (TruthValue) controls whether remote senders and receivers are tracked via RTCP. RTP Monitors must initialize it to true(1); RTP Hosts should initialize it to false(2); host-monitor systems that receive RTCP from remote participants must set it to true(1).
rtpSessionNewIndex uses the SMIv2 TestAndIncr textual convention to allow a network manager to safely obtain a unique index for creating new rows in rtpSessionTable via SNMP Set operations; only the RTP agent may create rows when not acting as a monitor.
rtpSessionRowStatus (RowStatus) is 'active' while RTP or RTCP messages are being sent or received. A newly-created row must have all read-create objects initialized before becoming active; rows in 'notReady' or 'notInService' state may be removed after 5 minutes.
rtpSessionTable rows are keyed by rtpSessionIndex (Integer32 1..2147483647) and capture session-level state including rtpSessionDomain (TDomain), rtpSessionRemAddr and rtpSessionLocAddr (TAddress), rtpSessionIfIndex (InterfaceIndex), join/BYE counters, and rtpSessionMonitor (TruthValue).
The RTP MIB contains six tables: rtpSessionTable (active sessions), rtpSenderTable (per-sender statistics), rtpRcvrTable (per-receiver statistics), and three inverse lookup tables (rtpSessionInverseTable, rtpSenderInverseTable, rtpRcvrInverseTable) for efficient index retrieval.
The three inverse lookup tables (rtpSessionInverseTable, rtpSenderInverseTable, rtpRcvrInverseTable) are optional and indexed by network address and domain fields, enabling retrieval of session/sender/receiver rows without a full table walk; each contains only a creation timestamp (TimeStamp).
The RTP MIB module is assigned OID mib-2 87, establishing the root of the RTP-MIB object tree under the standard MIB-II hierarchy.
Encryption of RTCP packets (as defined in RFC 1889 sec. 9) may prevent third-party monitors from reading SDES and other RTCP data. RFC 1889 allows splitting a compound RTCP packet so that reception reports are sent in the clear while SDES information is encrypted, to accommodate third-party monitors.
SDES items such as CNAME exposed in rtpSenderCNAME and rtpRcvrCNAME may reveal system configuration; enterprises should restrict SNMP access to these objects based on their security policy, as they can provide an attacker with information about a system's services.
SET operations on read-write and read-create objects (rtpSessionNewIndex and five rtpSessionEntry objects: rtpSessionDomain, rtpSessionRemAddr, rtpSessionIfIndex, rtpSessionRowStatus, rtpSessionIfAddr) can affect monitor operation; these objects must be protected by an appropriate access control policy.
SNMPv1 alone is not a secure environment; implementers are recommended to use SNMPv3 with the User-based Security Model (RFC 2574) and View-based Access Control Model (RFC 2575) to properly restrict GET/SET access to MIB objects.