idnits 2.17.1 draft-ietf-avt-rtp-mib-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 37 longer pages, the longest (page 1) being 65 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 33 instances of too long lines in the document, the longest one being 21 characters in excess of 72. ** There are 23 instances of lines with control characters in the document. ** The abstract seems to contain references ([RFC1889]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 305 has weird spacing: '... "This objec...' == Line 306 has weird spacing: '...entions for ...' == Line 307 has weird spacing: '...ws, the netwo...' == Line 308 has weird spacing: '...ead the objec...' == Line 309 has weird spacing: '...nstance of rt...' == (5 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 16, 2000) is 8836 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1889 (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 ** Downref: Normative reference to an Historic RFC: RFC 1157 ** Downref: Normative reference to an Historic RFC: RFC 1901 ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) ** Obsolete normative reference: RFC 2570 (Obsoleted by RFC 3410) Summary: 21 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Audio Video Transport Group Mark Baugher 2 Internet-Draft Intel Corp. 3 Expires August 16, 2000 Irina Suconick 4 VideoServer Corp. 5 Bill Strahm 6 Intel Corp. 7 February 16, 2000 9 Real-Time Transport Protocol 10 Management Information Base 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of section 10 of RFC2026. Internet-Drafts are 17 working documents of the Internet Engineering Task Force 18 (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months. Internet-Drafts may be updated, replaced, or made 22 obsolete by other documents at any time. It is not 23 appropriate to use Internet-Drafts as reference material or to 24 cite them other than as a ``working draft'' or ``work in progress.'' 25 To learn the current status of any Internet-Draft, please 26 check the 1id-abstracts.txt listing contained in the Internet- 27 Drafts Shadow Directories on ftp.ietf.org, nic.nordu.net, 28 venera.isi.edu, or munnari.oz.au. 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 37 Copyright (C) The Internet Society (1999). All Rights Reserved. 39 Abstract 41 This memo defines a portion of the Management Information Base 42 (MIB) for use with network management protocols in the Internet 43 community. In particular, it defines objects for managing Real-Time 44 Transport Protocol(RTP) systems [RFC1889]. 46 Table of Contents 48 1 The Network Management Framework ................................ 3 49 2 Overview ........................................................ 4 50 2.1 Components .................................................... 4 51 2.2 Applicability of the MIB to RTP System Implementations ........ 5 52 2.3 The Structure of the RTP MIB .................................. 5 53 3 Definitions ..................................................... 7 54 4 Security Issues ................................................. 33 55 5 Acknowledgements ................................................ 34 56 6 Intellectual Property ........................................... 34 57 7 References ...................................................... 34 58 8 Authors Addresses ............................................... 37 59 9 Full Copyright Statement ........................................ 37 60 1. The SNMP Management Framework 62 The SNMP Management Framework presently consists of five major 63 components: 65 o An overall architecture, described in RFC 2571 [RFC2571]. 67 o Mechanisms for describing and naming objects and events for the 68 purpose of management. The first version of this Structure of 69 Management Information (SMI) is called SMIv1 and described in 70 STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 71 1215 [RFC1215]. The second version, called SMIv2, is described 72 in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 73 [RFC2580]. 75 o Message protocols for transferring management information. The 76 first version of the SNMP message protocol is called SNMPv1 and 77 described in STD 15, RFC 1157 [RFC1157]. A second version of the 78 SNMP message protocol, which is not an Internet standards track 79 protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] 80 and RFC 1906 [RFC1906]. The third version of the message 81 protocol is called SNMPv3 and described in RFC 1906 [RFC1906], 82 RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 84 o Protocol operations for accessing management information. The 85 first set of protocol operations and associated PDU formats is 86 described in STD 15, RFC 1157 [RFC1157]. A second set of 87 protocol operations and associated PDU formats is described in 88 RFC 1905 [RFC1905]. 90 o A set of fundamental applications described in RFC 2573 91 [RFC2573] and the view-based access control mechanism described 92 in RFC 2575 [RFC2575]. 94 A more detailed introduction to the current SNMP Management Framework 95 can be found in RFC 2570 [RFC2570]. 97 Managed objects are accessed via a virtual information store, termed 98 the Management Information Base or MIB. Objects in the MIB are 99 defined using the mechanisms defined in the SMI. 101 This memo specifies a MIB module that is compliant to the SMIv2. A 102 MIB conforming to the SMIv1 can be produced through the appropriate 103 translations. The resulting translated MIB must be semantically 104 equivalent, except where objects or events are omitted because no 105 translation is possible (use of Counter64). Some machine readable 106 information in SMIv2 will be converted into textual descriptions in 107 SMIv1 during the translation process. However, this loss of machine 108 readable information is not considered to change the semantics of the 109 MIB. 111 2. Overview 113 An "RTP System" may be a host end-system that runs an application 114 program that sends or receives RTP data packets, or it may be an 115 intermediate-system that forwards RTP packets. RTP Control 116 Protocol (RTCP) packets are sent by senders and receivers to 117 convey information about RTP packet transmission and reception [RFC1889]. 118 RTP monitors may collect RTCP information on senders and receivers 119 to and from an RTP host or intermediate-system. 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 122 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 123 "OPTIONAL" in this document are to be interpreted as described in 124 RFC 2119. 126 2.1 Components 128 The RTP MIB is structured around "Session," "Receiver" and "Sender" 129 conceptual abstractions. 131 2.1.1 An "RTP Session" is the "...association of participants 132 communicating with RTP. For each participant, the session is 133 defined by a particular pair of destination transport addresses 134 (one network address plus a port pair for RTP and RTCP). The 135 destination transport addresses may be common for all participants, 136 as in the case of IP multicast, or may be different for each, as in 137 the case of individual unicast addresses plus a common port pair," 138 as defined in section 3 of [RFC1889]. 140 2.1.2 A "Sender" is identified within an RTP session by a 32-bit 141 numeric "Synchronization Source," or "SSRC", value and is "...the 142 source of a stream of RTP packets" as defined in section 3 of [RFC1889]. 143 The sender is also a source of RTCP Sender Report packets as specified 144 in section 6 of [RFC1889]. 146 2.1.3 A "Receiver" of a "stream of RTP packets" can be a unicast or 147 multicast Receiver as described in 2.1.1, above. An RTP Receiver has 148 an SSRC value that is unique to the session. An RTP Receiver is a 149 source of RTCP Receiver Reports as specified in section 6 of [RFC1889]. 151 2.2 Applicability of the MIB to RTP System Implementations 153 The RTP MIB may be used in two types of RTP implementations, RTP Host 154 Systems (end systems) and RTP Monitors, see section 3 of [RFC1889]. 155 Use of the RTP MIB for RTP Translators and Mixers, as defined in 156 section 7 of [RFC1889], is for further study. 158 2.2.1 RTP host Systems are end-systems that may use the RTP MIB 159 to collect RTP session and stream data that the host is sending or 160 receiving; these data may be used by a network manager to detect and 161 diagnose faults that occur over the lifetime of an RTP session as 162 in a "help-desk" scenario. 164 2.2.2 RTP Monitors of multicast RTP sessions may be third-party or 165 may be located in an RTP intermediate-system or in the RTP host. RTP 166 Monitors may use the RTP MIB to collect RTP session and stream 167 statistical data; these data may be used by a network manager for 168 capacity planning and other network-management purposes. An RTP 169 Monitor may use the RTP MIB to collect data to permit a network 170 manager to detect and diagnose faults in RTP sessions or to permit 171 a network manger to configure its operation. 173 2.2.3 Many host systems will want to keep track of streams beyond what 174 they are sending and receiving. In a host monitor system, a host agent would 175 use RTP data from the host to maintain data about streams it is sending 176 and receiving, and RTCP data to collect data about other hosts in the 177 session. For example an agent for an RTP host that is sending a stream would 178 use data from its RTP system to maintain the rtpSenderTable, but it may 179 want to maintain a rtpRcvrTable for endpoints that are receiving its stream. 180 To do this the RTP agent will collect RTCP data from the receivers of its 181 stream to build the rtpRcvrTable. A host monitor system MUST set the 182 rtpSessionMonitor object to 'true(1)', but it does not have to accept 183 management operations that create and destroy rows in its rtpSessionTable. 185 2.3 The Structure of the RTP MIB 187 There are six tables in the RTP MIB. The rtpSessionTable contains 188 objects that describe active sessions at the host, intermediate system, 189 or monitor. The rtpSenderTable contains information about senders 190 to the RTP session. The rtpRcvrTable contains information about 191 receivers of RTP session data. The rtpSessionInverseTable, 192 rtpSenderInverseTable, and rtpRcvrInverseTable contain information 193 to efficiently find indexes into the rtpSessionTable, rtpSenderTable, 194 and rtpRcvrTable, respectively. 196 The reverse lookup tables (rtpSessionInverseTable, 197 rtpSenderInverseTable, and rtpRcvrInverseTable) are optional tables 198 to help management applications efficiently access conceptual rows in 199 other tables. Implementors of this MIB SHOULD implement these tables 200 for multicast RTP sessions when table indexes (rtpSessionIndex of 201 rtpSessionTable, rtpSenderSSRC of rtpSenderTable, and the SSRC pair in 202 the rtpRcvrTable) are not available from other MIBs. Otherwise, the 203 management application may be forced to perform expensive tree walks 204 through large numbers of sessions, senders, or receivers. 206 For any particular RTP session, the rtpSessionMonitor object indicates 207 whether remote senders or receivers to the RTP session are to be monitored. 208 RTP sessions are monitored by the RTP agent that updates rtpSenderTable 209 and rtpRcvrTable objects with information from RTCP reports from remote 210 senders or remote receivers respectively. 212 rtpSessionNewIndex is a global object that permits a network-management 213 application to obtain a unique index for conceptual row creation 214 in the rtpSessionTable. In this way the SNMP Set operation may 215 be used to configure a monitor. 217 3. Definitions 218 RTP-MIB DEFINITIONS ::= BEGIN 219 IMPORTS 220 Counter32, Counter64, Gauge32, mib-2, Integer32, 221 MODULE-IDENTITY, OBJECT-IDENTITY, 222 OBJECT-TYPE, Unsigned32 FROM SNMPv2-SMI 223 RowStatus, TAddress, 224 TDomain, TestAndIncr, 225 TimeStamp, TruthValue FROM SNMPv2-TC 226 OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF 227 Utf8String FROM SYSAPPL-MIB 228 InterfaceIndex FROM IF-MIB; 230 rtpMIB MODULE-IDENTITY 231 LAST-UPDATED "9910200000Z" 232 ORGANIZATION 233 "IETF AVT Working Group 234 Email: rem-conf@es.net" 235 CONTACT-INFO 236 "Mark Baugher 237 Postal: Intel Corporation 238 2111 NE 25th Avenue 239 Hillsboro, OR 97124 240 United States 241 Tel: +1 503 466 8406 242 Email: mbaugher@intel.com 244 Bill Strahm 245 Postal: Intel Corporation 246 2111 NE 25th Avenue 247 Hillsboro, OR 97124 248 United States 249 Tel: +1 503 264 4632 250 Email: bill.strahm@intel.com 252 Irina Suconick 253 Postal: Videoserver Corporation 254 63 Third Street 255 Burlington, MA 01803 256 United States 257 Tel: +1 781-505-2155 258 Email: isuconick@videoserver.com" 259 DESCRIPTION 260 "The managed objects of RTP systems. The MIB is 261 structured around three types of information. 262 1. General information about RTP sessions such 263 as the session address. 264 2. Information about RTP streams being sent to 265 an RTP session by a particular sender. 266 3. Information about RTP streams received on an 267 RTP session by a particular receiver from a 268 particular sender. 269 There are two types of RTP Systems, RTP hosts and 270 RTP monitors. As described below, certain objects 271 are unique to a particular type of RTP System. An 272 RTP host may also function as an RTP monitor. 273 Refer to RFC 1889, 'RTP: A Transport Protocol for 274 Real-Time Applications,' section 3.0, for definitions." 275 REVISION "9910200000Z" 276 DESCRIPTION "Initial version of this MIB. 277 Published as RFC xxx." -- RFC-Editor assigns xxx 279 ::= { mib-2 xxx } -- to be assigned by IANA 281 -- 282 -- OBJECTS 283 -- 284 rtpMIBObjects OBJECT IDENTIFIER ::= { rtpMIB 1 } 285 rtpConformance OBJECT IDENTIFIER ::= { rtpMIB 2 } 286 rtpDomains OBJECT IDENTIFIER ::= { rtpMIB 3 } 288 rtpUDPDomain OBJECT-IDENTITY 289 STATUS current 290 DESCRIPTION 291 "RTP over UDP transport domain over IPv4. This definition 292 uses the transport address type, snmpUDPAddress, which is 293 defined in SNMPv2-TM, 'Transport Mappings for Version 2 of 294 the Simple Network Management Protocol (SNMPv2)'." 295 REFERENCE "RFC 1906, sec. 2 " ::= { rtpDomains 1 } 297 -- 298 -- SESSION NEW INDEX 299 -- 300 rtpSessionNewIndex OBJECT-TYPE 301 SYNTAX TestAndIncr 302 MAX-ACCESS read-write 303 STATUS current 304 DESCRIPTION 305 "This object is used to assign values to rtpSessionIndex 306 as described in 'Textual Conventions for SNMPv2'. For an RTP 307 system that supports the creation of rows, the network manager 308 would read the object, and then write the value back in 309 the Set that creates a new instance of rtpSessionEntry. If 310 the Set fails with the code 'inconsistentValue,' then the 311 process must be repeated; If the Set succeeds, then the object 312 is incremented, and the new instance is created according to 313 the manager's directions. However, if the RTP agent is not acting 314 as a monitor, only the RTP agent may create conceptual rows in the 315 RTP session table." 316 ::= { rtpMIBObjects 1 } 318 -- 319 -- SESSION INVERSE TABLE 320 -- 321 rtpSessionInverseTable OBJECT-TYPE 322 SYNTAX SEQUENCE OF RtpSessionInverseEntry 323 MAX-ACCESS not-accessible 324 STATUS current 325 DESCRIPTION 326 "Maps rptSessionDomain, rtpSessionRemAddr, and 327 rtpSessionLocAddr to an unsigned integer index, 328 rtpSessionInverseIndex, which has the rtpSessionIndex 329 value that maps to the same rtpSessionDomain, 330 rtpSessionRemAddr, and rtpSessionLocAddr in the 331 rtpSessionTable. rtpSessionIndex can thereby be 332 retrieved based upon the domain and TAdress pair 333 that uniquely define an RTP Session." 334 ::= { rtpMIBObjects 2 } 336 rtpSessionInverseEntry OBJECT-TYPE 337 SYNTAX RtpSessionInverseEntry 338 MAX-ACCESS not-accessible 339 STATUS current 340 DESCRIPTION 341 "Each entry corresponds to exactly one entry in the 342 rtpSessionTable - the entry containing the triple, 343 rtpSessionDomain, rtpSessionRemAddr, and rtpSessionLocAddr." 344 INDEX { rtpSessionDomain, rtpSessionRemAddr, rtpSessionLocAddr, 345 rtpSessionIndex } 346 ::= { rtpSessionInverseTable 1 } 348 RtpSessionInverseEntry ::= SEQUENCE { 349 rtpSessionInverseStartTime TimeStamp 350 } 352 rtpSessionInverseStartTime OBJECT-TYPE 353 SYNTAX TimeStamp 354 MAX-ACCESS read-only 355 STATUS current 356 DESCRIPTION 357 "The value of SysUpTime at the time that this row was 358 created." 359 ::= { rtpSessionInverseEntry 1 } 361 -- 362 -- SESSION TABLE 363 -- 364 rtpSessionTable OBJECT-TYPE 365 SYNTAX SEQUENCE OF RtpSessionEntry 366 MAX-ACCESS not-accessible 367 STATUS current 368 DESCRIPTION 369 "There's one entry in rtpSessionTable for each RTP session 370 on which packets are being sent, received, and/or 371 monitored." 372 ::= { rtpMIBObjects 3 } 374 rtpSessionEntry OBJECT-TYPE 375 SYNTAX RtpSessionEntry 376 MAX-ACCESS not-accessible 377 STATUS current 378 DESCRIPTION 379 "Data in rtpSessionTable uniquely identify an RTP session. A host 380 RTP agent will create a read-only row for each session to which 381 packets are being sent or received. Rows are created by the 382 RTP Agent at the start of a session when one or more senders or 383 receivers are observed. Rows created by an RTP agent are deleted 384 when the session is over and there are no rtpRcvrEntry and no 385 rtpSenderEntry for this session. An RTP session can be monitored 386 to create management information on all RTP streams being sent or 387 received when the rtpSessionMonitor has the TruthValue of 'true(1)'. 388 An RTP monitor may permit row creation with the side effect of 389 causing the RTP System to join the multicast session for the 390 purposes of gathering management information (additional conceptual 391 rows are created in the rtpRcvrTable and rtpSenderTable). Thus, 392 rtpSessionTable rows can be created for RTP session monitoring 393 purposes. Rows created by a management application may be deleted 394 via SNMP operations by management applications. Rows created by 395 management operations are deleted by management operations by setting 396 rtpSessionRowStatus to 'destroy(6)'." 397 INDEX { rtpSessionIndex } 398 ::= { rtpSessionTable 1 } 400 RtpSessionEntry ::= SEQUENCE { 401 rtpSessionIndex Integer32, 402 rtpSessionDomain TDomain, 403 rtpSessionRemAddr TAddress, 404 rtpSessionLocAddr TAddress, 405 rtpSessionIfIndex InterfaceIndex, 406 rtpSessionSenderJoins Counter32, 407 rtpSessionReceiverJoins Counter32, 408 rtpSessionByes Counter32, 409 rtpSessionStartTime TimeStamp, 410 rtpSessionMonitor TruthValue, 411 rtpSessionRowStatus RowStatus 412 } 414 rtpSessionIndex OBJECT-TYPE 415 SYNTAX Integer32 (1..2147483647) 416 MAX-ACCESS not-accessible 417 STATUS current 418 DESCRIPTION 419 "The index of the conceptual row which is for SNMP purposes 420 only and has no relation to any protocol value. There is 421 no requirement that these rows are created or maintained 422 sequentially." 423 ::= { rtpSessionEntry 1 } 425 rtpSessionDomain OBJECT-TYPE 426 SYNTAX TDomain 427 MAX-ACCESS read-create 428 STATUS current 429 DESCRIPTION 430 "The transport-layer protocol used for sending or receiving 431 the stream of RTP data packets on this session. 432 Cannot be changed if rtpSessionRowStatus is 'active'." 433 ::= { rtpSessionEntry 2 } 435 rtpSessionRemAddr OBJECT-TYPE 436 SYNTAX TAddress 437 MAX-ACCESS read-create 438 STATUS current 439 DESCRIPTION 440 "The address to which RTP packets are sent by the RTP system. In an 441 IP multicast RTP session, this is the single address used by all 442 senders and receivers of RTP session data. In a unicast RTP session 443 this is the unicast address of the remote RTP system. 'The 444 destination address pair may be common for all participants, as in 445 the case of IP multicast, or may be different for each, as in the 446 case of individual unicast network address pairs.' See RFC 1889, 447 'RTP: A Transport Protocol for Real-Time Applications,' sec. 3. 448 The transport service is identified by rtpSessionDomain. For 449 rtpUDPDomain, this is an IP address and even-numbered UDP Port 450 with the RTCP being sent on the next higher odd-numbered port, 451 see RFC 1889, sec. 5. Cannot be changed if rtpSessionRowStatus 452 is 'active'." 453 ::= { rtpSessionEntry 3 } 455 rtpSessionLocAddr OBJECT-TYPE 456 SYNTAX TAddress 457 MAX-ACCESS read-only 458 STATUS current 459 DESCRIPTION 460 "The local address used by the RTP system. In an IP multicast RTP 461 session, rtpSessionRemAddr will be the same IP multicast address as 462 rtpSessionLocAddr. In a unicast RTP session, rtpSessionRemAddr and 463 rtpSessionLocAddr will have different unicast addresses. See RFC 464 1889, 'RTP: A Transport Protocol for Real-Time Applications,' sec. 465 3. The transport service is identified by rtpSessionDomain. For 466 rtpUDPDomain, this is an IP address and even-numbered UDP Port 467 with the RTCP being sent on the next higher odd-numbered port, 468 see RFC 1889, sec. 5." 469 ::= { rtpSessionEntry 4 } 471 rtpSessionIfIndex OBJECT-TYPE 472 SYNTAX InterfaceIndex 473 MAX-ACCESS read-create 474 STATUS current 475 DESCRIPTION 476 "The ifIndex value is set to the corresponding value 477 from IF-MIB (See RFC 2233, 'The Interfaces Group MIB using 478 SMIv2'). This is the interface that the RTP stream is being sent 479 to or received from, or in the case of an RTP Monitor the 480 interface that RTCP packets will be received on. Cannot be 481 changed if rtpSessionRowStatus is 'active'." 482 ::= { rtpSessionEntry 5 } 484 rtpSessionSenderJoins OBJECT-TYPE 485 SYNTAX Counter32 486 MAX-ACCESS read-only 487 STATUS current 488 DESCRIPTION 489 "The number of senders that have been observed to have 490 joined the session since this conceptual row was created 491 (rtpSessionStartTime). A sender 'joins' an RTP 492 session by sending to it. Senders that leave and then 493 re-join following an RTCP BYE (see RFC 1889, 'RTP: A 494 Transport Protocol for Real-Time Applications,' sec. 6.6) 495 or session timeout may be counted twice. Every time a new 496 RTP sender is detected either using RTP or RTCP, this counter 497 is incremented." 498 ::= { rtpSessionEntry 6 } 500 rtpSessionReceiverJoins OBJECT-TYPE 501 SYNTAX Counter32 502 MAX-ACCESS read-only 503 STATUS current 504 DESCRIPTION 505 "The number of receivers that have been been observed to 506 have joined this session since this conceptual row was 507 created (rtpSessionStartTime). A receiver 'joins' an RTP 508 session by sending RTCP Receiver Reports to the session. 509 Receivers that leave and then re-join following an RTCP BYE 510 (see RFC 1889, 'RTP: A Transport Protocol for Real-Time 511 Applications,' sec. 6.6) or session timeout may be counted 512 twice." 513 ::= { rtpSessionEntry 7 } 515 rtpSessionByes OBJECT-TYPE 516 SYNTAX Counter32 517 MAX-ACCESS read-only 518 STATUS current 519 DESCRIPTION 520 "A count of RTCP BYE (see RFC 1889, 'RTP: A Transport 521 Protocol for Real-Time Applications,' sec. 6.6) messages 522 received by this entity." 523 ::= { rtpSessionEntry 8 } 525 rtpSessionStartTime OBJECT-TYPE 526 SYNTAX TimeStamp 527 MAX-ACCESS read-only 528 STATUS current 529 DESCRIPTION 530 "The value of SysUpTime at the time that this row was 531 created." 532 ::= { rtpSessionEntry 9 } 534 rtpSessionMonitor OBJECT-TYPE 535 SYNTAX TruthValue 536 MAX-ACCESS read-only 537 STATUS current 538 DESCRIPTION 539 "Boolean, Set to 'true(1)' if senders or receivers in 540 addition to the local RTP System are to be monitored using RTCP. 541 RTP Monitors MUST initialize to 'true(1)' and RTP Hosts SHOULD 542 initialize this 'false(2)'. Note that because 'host monitor' 543 systems are receiving RTCP from their remote participants they 544 MUST set this value to 'true(1)'." 545 ::= { rtpSessionEntry 10 } 547 rtpSessionRowStatus OBJECT-TYPE 548 SYNTAX RowStatus 549 MAX-ACCESS read-create 550 STATUS current 551 DESCRIPTION 552 "Value of 'active' when RTP or RTCP messages are being 553 sent or received by an RTP System. A newly-created 554 conceptual row must have the all read-create objects 555 initialized before becoming 'active'. 556 A conceptual row that is in the 'notReady' or 'notInService' 557 state MAY be removed after 5 minutes." 558 ::= { rtpSessionEntry 11 } 560 -- 561 -- SENDER INVERSE TABLE 562 -- 563 rtpSenderInverseTable OBJECT-TYPE 564 SYNTAX SEQUENCE OF RtpSenderInverseEntry 565 MAX-ACCESS not-accessible 566 STATUS current 567 DESCRIPTION 568 "Maps rtpSenderAddr, rtpSessionIndex, to the rtpSenderSSRC 569 index of the rtpSenderTable. This table allows management 570 applications to find entries sorted by rtpSenderAddr rather than 571 sorted by rtpSessionIndex. Given the rtpSessionDomain and 572 rtpSenderAddr, a set of rtpSessionIndex and rtpSenderSSRC values 573 can be returned from a tree walk. When rtpSessionIndex is 574 specified in the SNMP Get-Next operations, one or more 575 rtpSenderSSRC values may be returned." 576 ::= { rtpMIBObjects 4 } 578 rtpSenderInverseEntry OBJECT-TYPE 579 SYNTAX RtpSenderInverseEntry 580 MAX-ACCESS not-accessible 581 STATUS current 582 DESCRIPTION 583 "Each entry corresponds to exactly one entry in the 584 rtpSenderTable - the entry containing the index pair, 585 rtpSessionIndex, rtpSenderSSRC." 586 INDEX { rtpSessionDomain, rtpSenderAddr, rtpSessionIndex, 587 rtpSenderSSRC } 588 ::= { rtpSenderInverseTable 1 } 590 RtpSenderInverseEntry ::= SEQUENCE { 591 rtpSenderInverseStartTime TimeStamp 592 } 594 rtpSenderInverseStartTime OBJECT-TYPE 595 SYNTAX TimeStamp 596 MAX-ACCESS read-only 597 STATUS current 598 DESCRIPTION 599 "The value of SysUpTime at the time that this row was 600 created." 601 ::= { rtpSenderInverseEntry 1 } 603 -- 604 -- SENDERS TABLE 605 -- 606 rtpSenderTable OBJECT-TYPE 607 SYNTAX SEQUENCE OF RtpSenderEntry 608 MAX-ACCESS not-accessible 609 STATUS current 610 DESCRIPTION 611 "Table of information about a sender or senders to an RTP 612 Session. RTP sending hosts MUST have an entry in this table 613 for each stream being sent. RTP receiving hosts MAY have an 614 entry in this table for each sending stream being received 615 by this host. RTP monitors create an entry for each observed 616 sender to a multicast RTP Session as a side-effect when a 617 conceptual row in the rtpSessionTable is made 'active' by a 618 manager." 619 ::= { rtpMIBObjects 5 } 621 rtpSenderEntry OBJECT-TYPE 622 SYNTAX RtpSenderEntry 623 MAX-ACCESS not-accessible 624 STATUS current 625 DESCRIPTION 626 "Each entry contains information from a single RTP Sender 627 Synchronization Source (SSRC, see RFC 1889 'RTP: A Transport 628 Protocol for Real-Time Applications' sec.6). The session is 629 identified to the the SNMP entity by rtpSessionIndex. 630 Rows are removed by the RTP agent when a BYE is received 631 from the sender or when the sender times out (see RFC 632 1889, Sec. 6.2.1) or when the rtpSessionEntry is deleted." 633 INDEX { rtpSessionIndex, rtpSenderSSRC } 634 ::= { rtpSenderTable 1 } 636 RtpSenderEntry ::= SEQUENCE { 637 rtpSenderSSRC Unsigned32, 638 rtpSenderCNAME Utf8String, 639 rtpSenderAddr TAddress, 640 rtpSenderPackets Counter64, 641 rtpSenderOctets Counter64, 642 rtpSenderTool Utf8String, 643 rtpSenderSRs Counter32, 644 rtpSenderSRTime TimeStamp, 645 rtpSenderPT INTEGER, 646 rtpSenderStartTime TimeStamp 647 } 649 rtpSenderSSRC OBJECT-TYPE 650 SYNTAX Unsigned32 651 MAX-ACCESS not-accessible 652 STATUS current 653 DESCRIPTION 654 "The RTP SSRC, or synchronization source identifier of the 655 sender. The RTP session address plus an SSRC uniquely 656 identify a sender to an RTP session (see RFC 1889, 'RTP: A 657 Transport Protocol for Real-Time Applications' sec.3)." 658 ::= { rtpSenderEntry 1 } 660 rtpSenderCNAME OBJECT-TYPE 661 SYNTAX Utf8String 662 MAX-ACCESS read-only 663 STATUS current 664 DESCRIPTION 665 "The RTP canonical name of the sender." 666 ::= { rtpSenderEntry 2 } 668 rtpSenderAddr OBJECT-TYPE 669 SYNTAX TAddress 670 MAX-ACCESS read-only 671 STATUS current 672 DESCRIPTION 673 "The unicast transport source address of the sender. In the case of 674 an RTP Monitor this address is the address that the sender is using 675 to send its RTCP Sender Reports." 676 ::= { rtpSenderEntry 3 } 678 rtpSenderPackets OBJECT-TYPE 679 SYNTAX Counter64 680 MAX-ACCESS read-only 681 STATUS current 682 DESCRIPTION 683 "Count of RTP packets sent by this sender, or observed by 684 an RTP monitor, since rtpSenderStartTime." 685 ::= { rtpSenderEntry 4 } 687 rtpSenderOctets OBJECT-TYPE 688 SYNTAX Counter64 689 MAX-ACCESS read-only 690 STATUS current 691 DESCRIPTION 692 "Count of RTP octets sent by this sender, or observed by 693 an RTP monitor, since rtpSenderStartTime. This value does not include Header Octets." 694 ::= { rtpSenderEntry 5 } 696 rtpSenderTool OBJECT-TYPE 697 SYNTAX Utf8String (SIZE(0..127)) 698 MAX-ACCESS read-only 699 STATUS current 700 DESCRIPTION 701 "Name of the application program source of the stream." 702 ::= { rtpSenderEntry 6 } 704 rtpSenderSRs OBJECT-TYPE 705 SYNTAX Counter32 706 MAX-ACCESS read-only 707 STATUS current 708 DESCRIPTION 709 "A count of the number of RTCP Sender Reports that have 710 been sent from this sender, or observed if the RTP entity 711 is a monitor, since rtpSenderStartTime." 712 ::= { rtpSenderEntry 7 } 714 rtpSenderSRTime OBJECT-TYPE 715 SYNTAX TimeStamp 716 MAX-ACCESS read-only 717 STATUS current 718 DESCRIPTION 719 "rtpSenderSRTime is the value of SysUpTime at the time that 720 the last SR was received from this sender, in the case of a 721 monitor or receiving host. Or sent by this sender, in the 722 case of a sending host." 723 ::= { rtpSenderEntry 8 } 725 rtpSenderPT OBJECT-TYPE 726 SYNTAX INTEGER (0..127) 727 MAX-ACCESS read-only 728 STATUS current 729 DESCRIPTION 730 "Payload type from the RTP header of the most recently received 731 RTP Packet (see RFC 1889, 'RTP: A Transport Protocol for 732 Real-Time Applications' sec. 5)." 733 ::= { rtpSenderEntry 9 } 735 rtpSenderStartTime OBJECT-TYPE 736 SYNTAX TimeStamp 737 MAX-ACCESS read-only 738 STATUS current 739 DESCRIPTION 740 "The value of SysUpTime at the time that this row was 741 created." 742 ::= { rtpSenderEntry 10 } 744 -- 745 -- RECEIVER INVERSE TABLE 746 -- 747 rtpRcvrInverseTable OBJECT-TYPE 748 SYNTAX SEQUENCE OF RtpRcvrInverseEntry 749 MAX-ACCESS not-accessible 750 STATUS current 751 DESCRIPTION 752 "Maps rtpRcvrAddr and rtpSessionIndex to the rtpRcvrSRCSSRC and 753 rtpRcvrSSRC indexes of the rtpRcvrTable. This table allows 754 management applications to find entries sorted by rtpRcvrAddr 755 rather than by rtpSessionIndex. Given rtpSessionDomain and 756 rtpRcvrAddr, a set of rtpSessionIndex, rtpRcvrSRCSSRC, and 757 rtpRcvrSSRC values can be returned from a tree walk. When 758 rtpSessionIndex is specified in SNMP Get-Next operations, one or 759 more rtpRcvrSRCSSRC and rtpRcvrSSRC pairs may be returned." 760 ::= { rtpMIBObjects 6 } 762 rtpRcvrInverseEntry OBJECT-TYPE 763 SYNTAX RtpRcvrInverseEntry 764 MAX-ACCESS not-accessible 765 STATUS current 766 DESCRIPTION 767 "Each entry corresponds to exactly one entry in the 768 rtpRcvrTable - the entry containing the index pair, 769 rtpSessionIndex, rtpRcvrSSRC." 770 INDEX { rtpSessionDomain, rtpRcvrAddr, rtpSessionIndex, 771 rtpRcvrSRCSSRC, rtpRcvrSSRC } 772 ::= { rtpRcvrInverseTable 1 } 774 RtpRcvrInverseEntry ::= SEQUENCE { 775 rtpRcvrInverseStartTime TimeStamp 776 } 778 rtpRcvrInverseStartTime OBJECT-TYPE 779 SYNTAX TimeStamp 780 MAX-ACCESS read-only 781 STATUS current 782 DESCRIPTION 783 "The value of SysUpTime at the time that this row was 784 created." 785 ::= { rtpRcvrInverseEntry 1 } 787 -- 788 -- RECEIVERS TABLE 789 -- 790 rtpRcvrTable OBJECT-TYPE 791 SYNTAX SEQUENCE OF RtpRcvrEntry 792 MAX-ACCESS not-accessible 793 STATUS current 794 DESCRIPTION 795 "Table of information about a receiver or receivers of RTP 796 session data. RTP hosts that receive RTP session packets 797 MUST create an entry in this table for that receiver/sender 798 pair. RTP hosts that send RTP session packets MAY create 799 an entry in this table for each receiver to their stream 800 using RTCP feedback from the RTP group. RTP monitors 801 create an entry for each observed RTP session receiver as 802 a side effect when a conceptual row in the rtpSessionTable 803 is made 'active' by a manager." 804 ::= { rtpMIBObjects 7 } 806 rtpRcvrEntry OBJECT-TYPE 807 SYNTAX RtpRcvrEntry 808 MAX-ACCESS not-accessible 809 STATUS current 810 DESCRIPTION 811 "Each entry contains information from a single RTP 812 Synchronization Source that is receiving packets from the 813 sender identified by rtpRcvrSRCSSRC (SSRC, see RFC 1889, 814 'RTP: A Transport Protocol for Real-Time Applications' 815 sec.6). The session is identified to the the SNMP entity by 816 rtpSessionIndex. Rows are removed by the RTP agent when 817 a BYE is received from the sender or when the sender times 818 out (see RFC 1889, Sec. 6.2.1) or when the rtpSessionEntry is 819 deleted." 820 INDEX { rtpSessionIndex, rtpRcvrSRCSSRC, rtpRcvrSSRC } 821 ::= { rtpRcvrTable 1 } 823 RtpRcvrEntry ::= SEQUENCE { 824 rtpRcvrSRCSSRC Unsigned32, 825 rtpRcvrSSRC Unsigned32, 826 rtpRcvrCNAME Utf8String, 827 rtpRcvrAddr TAddress, 828 rtpRcvrRTT Gauge32, 829 rtpRcvrLostPackets Counter64, 830 rtpRcvrJitter Gauge32, 831 rtpRcvrTool Utf8String, 832 rtpRcvrRRs Counter32, 833 rtpRcvrRRTime TimeStamp, 834 rtpRcvrPT INTEGER, 835 rtpRcvrPackets Counter64, 836 rtpRcvrOctets Counter64, 837 rtpRcvrStartTime TimeStamp 838 } 840 rtpRcvrSRCSSRC OBJECT-TYPE 841 SYNTAX Unsigned32 842 MAX-ACCESS not-accessible 843 STATUS current 844 DESCRIPTION 845 "The RTP SSRC, or synchronization source identifier of the 846 sender. The RTP session address plus an SSRC uniquely 847 identify a sender or receiver of an RTP stream (see RFC 848 1889, 'RTP: A Transport Protocol for Real-Time 849 Applications' sec.3)." 850 ::= { rtpRcvrEntry 1 } 852 rtpRcvrSSRC OBJECT-TYPE 853 SYNTAX Unsigned32 854 MAX-ACCESS not-accessible 855 STATUS current 856 DESCRIPTION 857 "The RTP SSRC, or synchronization source identifier of the 858 receiver. The RTP session address plus an SSRC uniquely 859 identify a receiver of an RTP stream (see RFC 1889, 'RTP: 860 A Transport Protocol for Real-Time Applications' sec.3)." 861 ::= { rtpRcvrEntry 2 } 863 rtpRcvrCNAME OBJECT-TYPE 864 SYNTAX Utf8String 865 MAX-ACCESS read-only 866 STATUS current 867 DESCRIPTION 868 "The RTP canonical name of the receiver." 869 ::= { rtpRcvrEntry 3 } 871 rtpRcvrAddr OBJECT-TYPE 872 SYNTAX TAddress 873 MAX-ACCESS read-only 874 STATUS current 875 DESCRIPTION 876 "The unicast transport address on which the receiver is receiving RTP 877 packets. In the case of an RTP Monitor this address is the local 878 address of the receiver on which it is sending RTCP Receiver Report 879 packet is received." 880 ::= { rtpRcvrEntry 4 } 882 rtpRcvrRTT OBJECT-TYPE 883 SYNTAX Gauge32 884 MAX-ACCESS read-only 885 STATUS current 886 DESCRIPTION 887 "The round trip time measurement taken by the source of the 888 RTP stream based on the algorithm described on sec. 6 of 889 RFC 1889, 'RTP: A Transport Protocol for Real-Time 890 Applications.' This algorithm can produce meaningful 891 results when the RTP agent has the same clock as the stream 892 sender (when the RTP monitor is also the sending host for the 893 particular reciever). Otherwise, the entity should return 894 'noSuchInstance' in response to queries against rtpRcvrRTT." 895 ::= { rtpRcvrEntry 5 } 897 rtpRcvrLostPackets OBJECT-TYPE 898 SYNTAX Counter64 899 MAX-ACCESS read-only 900 STATUS current 901 DESCRIPTION 902 "A count of RTP packets lost as observed by this receiver 903 since rtpRcvrStartTime." 904 ::= { rtpRcvrEntry 6 } 906 rtpRcvrJitter OBJECT-TYPE 907 SYNTAX Gauge32 908 MAX-ACCESS read-only 909 STATUS current 910 DESCRIPTION 911 "An estimate of delay variation as observed by this 912 receiver. (see RFC 1889, 'RTP: A Transport Protocol 913 for Real-Time Applications' sec.6.3.1 and A.8)." 914 ::= { rtpRcvrEntry 7 } 916 rtpRcvrTool OBJECT-TYPE 917 SYNTAX Utf8String (SIZE(0..127)) 918 MAX-ACCESS read-only 919 STATUS current 920 DESCRIPTION 921 "Name of the application program source of the stream." 922 ::= { rtpRcvrEntry 8 } 924 rtpRcvrRRs OBJECT-TYPE 925 SYNTAX Counter32 926 MAX-ACCESS read-only 927 STATUS current 928 DESCRIPTION 929 "A count of the number of RTCP Receiver Reports that have 930 been sent from this receiver, or observed if the RTP entity 931 is a monitor, since rtpRcvrStartTime." 932 ::= { rtpRcvrEntry 9 } 934 rtpRcvrRRTime OBJECT-TYPE 935 SYNTAX TimeStamp 936 MAX-ACCESS read-only 937 STATUS current 938 DESCRIPTION 939 "rtpRcvrRRTime is the value of SysUpTime at the time that the 940 last RTCP Receiver Report was received from this receiver, in 941 the case of a monitor or RR receiver (the RTP Sender). It is 942 the value of SysUpTime at the time that the last RR was sent by 943 this receiver in the case of an RTP receiver sending the RR." 944 ::= { rtpRcvrEntry 10 } 946 rtpRcvrPT OBJECT-TYPE 947 SYNTAX INTEGER (0..127) 948 MAX-ACCESS read-only 949 STATUS current 950 DESCRIPTION 951 "Static or dynamic payload type from the RTP header (see 952 RFC 1889, 'RTP: A Transport Protocol for Real-Time 953 Applications' sec. 5)." 954 ::= { rtpRcvrEntry 11 } 956 rtpRcvrPackets OBJECT-TYPE 957 SYNTAX Counter64 958 MAX-ACCESS read-only 959 STATUS current 960 DESCRIPTION 961 "Count of RTP packets received by this RTP host receiver 962 since rtpRcvrStartTime." 963 ::= { rtpRcvrEntry 12 } 965 rtpRcvrOctets OBJECT-TYPE 966 SYNTAX Counter64 967 MAX-ACCESS read-only 968 STATUS current 969 DESCRIPTION 970 "Count of RTP octets received by this receiving RTP host 971 since rtpRcvrStartTime. This value does not include Header Octets." 972 ::= { rtpRcvrEntry 13 } 974 rtpRcvrStartTime OBJECT-TYPE 975 SYNTAX TimeStamp 976 MAX-ACCESS read-only 977 STATUS current 978 DESCRIPTION 979 "The value of SysUpTime at the time that this row was 980 created." 981 ::= { rtpRcvrEntry 14 } 983 -- 984 -- MODULE GROUPS 985 -- 986 rtpGroups OBJECT IDENTIFIER ::= { rtpConformance 1 } 987 rtpSystemGroup OBJECT-GROUP 988 OBJECTS { 989 rtpSessionDomain, 990 rtpSessionRemAddr, 991 rtpSessionIfIndex, 992 rtpSessionSenderJoins, 993 rtpSessionReceiverJoins, 994 rtpSessionStartTime, 995 rtpSessionByes, 996 rtpSessionMonitor, 997 rtpSenderCNAME, 998 rtpSenderAddr, 999 rtpSenderPackets, 1000 rtpSenderOctets, 1001 rtpSenderTool, 1002 rtpSenderSRs, 1003 rtpSenderSRTime, 1004 rtpSenderStartTime, 1005 rtpRcvrCNAME, 1006 rtpRcvrAddr, 1007 rtpRcvrLostPackets, 1008 rtpRcvrJitter, 1009 rtpRcvrTool, 1010 rtpRcvrRRs, 1011 rtpRcvrRRTime, 1012 rtpRcvrStartTime 1013 } 1014 STATUS current 1015 DESCRIPTION 1016 "Objects available to all RTP Systems." 1017 ::= { rtpGroups 1 } 1019 rtpHostGroup OBJECT-GROUP 1020 OBJECTS { 1021 rtpSessionLocAddr, 1022 rtpSenderPT, 1023 rtpRcvrPT, 1024 rtpRcvrRTT, 1025 rtpRcvrOctets, 1026 rtpRcvrPackets 1027 } 1028 STATUS current 1029 DESCRIPTION 1030 "Objects that are available to RTP Host systems, but may not 1031 be available to RTP Monitor systems." 1032 ::= { rtpGroups 2 } 1034 rtpMonitorGroup OBJECT-GROUP 1035 OBJECTS { 1036 rtpSessionNewIndex, 1037 rtpSessionRowStatus 1038 } 1039 STATUS current 1040 DESCRIPTION 1041 "Objects used to create rows in the RTP Session Table. These objects 1042 are not needed if the system does not create rows." 1043 ::= { rtpGroups 3 } 1045 rtpInverseGroup OBJECT-GROUP 1046 OBJECTS { 1047 rtpSessionInverseStartTime, 1048 rtpSenderInverseStartTime, 1049 rtpRcvrInverseStartTime 1050 } 1051 STATUS current 1052 DESCRIPTION 1053 "Objects used in the Inverse Lookup Tables." 1054 ::= { rtpGroups 4 } 1056 -- 1057 -- Compliance 1058 -- 1059 rtpCompliances OBJECT IDENTIFIER ::= { rtpConformance 2 } 1061 rtpHostCompliance MODULE-COMPLIANCE 1062 STATUS current 1063 DESCRIPTION 1064 "Host implementations MUST comply." 1065 MODULE RTP-MIB 1066 MANDATORY-GROUPS { 1067 rtpSystemGroup, 1068 rtpHostGroup 1069 } 1070 GROUP rtpMonitorGroup 1071 DESCRIPTION 1072 "The objects in the rtpHostGroup MUST be implemented 1073 in RTP host systems, i.e., that are the source or the 1074 destination of RTP data packets." 1075 GROUP rtpInverseGroup 1076 DESCRIPTION 1077 "Multicast RTP Systems SHOULD implement the optional 1078 tables." 1079 OBJECT rtpSessionNewIndex 1080 MIN-ACCESS not-accessible 1081 DESCRIPTION 1082 "RTP system implementations support of 1083 row creation and deletion is OPTIONAL so 1084 implementation of this object is OPTIONAL." 1085 OBJECT rtpSessionDomain 1086 MIN-ACCESS read-only 1087 DESCRIPTION 1088 "RTP system implementation support of 1089 row creation and deletion is OPTIONAL. When 1090 it is not supported so write access is 1091 OPTIONAL." 1092 OBJECT rtpSessionRemAddr 1093 MIN-ACCESS read-only 1094 DESCRIPTION 1095 "Row creation and deletion is OPTIONAL so 1096 read-create access to this object is OPTIONAL." 1097 OBJECT rtpSessionIfIndex 1098 MIN-ACCESS read-only 1099 DESCRIPTION 1100 "Row creation and deletion is OPTIONAL so 1101 read-create access to this object is OPTIONAL." 1103 OBJECT rtpSessionRowStatus 1104 MIN-ACCESS not-accessible 1105 DESCRIPTION 1106 "Row creation and deletion is OPTIONAL so 1107 read-create access to this object is OPTIONAL." 1108 OBJECT rtpSessionInverseStartTime 1109 MIN-ACCESS not-accessible 1110 DESCRIPTION 1111 "Multicast RTP Systems SHOULD implement the optional 1112 tables." 1113 OBJECT rtpSenderInverseStartTime 1114 MIN-ACCESS not-accessible 1115 DESCRIPTION 1116 "Multicast RTP Systems SHOULD implement the optional 1117 tables." 1118 OBJECT rtpRcvrInverseStartTime 1119 MIN-ACCESS not-accessible 1120 DESCRIPTION 1121 "Multicast RTP Systems SHOULD implement the optional 1122 tables." 1123 ::= { rtpCompliances 1 } 1125 rtpMonitorCompliance MODULE-COMPLIANCE 1126 STATUS current 1127 DESCRIPTION 1128 "Monitor implementations must comply. RTP Monitors are not 1129 required to support creation or deletion." 1130 MODULE RTP-MIB 1131 MANDATORY-GROUPS { 1132 rtpSystemGroup, 1133 rtpMonitorGroup 1134 } 1135 GROUP rtpHostGroup 1136 DESCRIPTION 1137 "The objects in the rtpMonitorGroup MUST be implemented in RTP 1138 monitors. Monitor implementations may not have access to 1139 values in the rtpHostGroup." 1140 GROUP rtpInverseGroup 1141 DESCRIPTION 1142 "Multicast RTP Systems SHOULD implement the optional 1143 tables." 1144 OBJECT rtpSessionLocAddr 1145 MIN-ACCESS not-accessible 1146 DESCRIPTION 1147 "RTP monitor sourcing of RTP or RTCP data packets 1148 is OPTIONAL and implementation of this object is 1149 OPTIONAL." 1150 OBJECT rtpRcvrPT 1151 MIN-ACCESS not-accessible 1152 DESCRIPTION 1153 "RTP monitor systems may not support 1154 retrieval of the RTP Payload Type from the RTP 1155 header (and may receive RTCP messages only). When 1156 queried for the payload type information" 1157 OBJECT rtpSenderPT 1158 MIN-ACCESS not-accessible 1159 DESCRIPTION 1160 "RTP monitor systems NEED NOT support 1161 retrieval of the RTP Payload Type from the RTP 1162 header (and may receive RTCP messages only). When 1163 queried for the payload type information." 1164 OBJECT rtpRcvrOctets 1165 MIN-ACCESS not-accessible 1166 DESCRIPTION 1167 "RTP monitor systems may receive only the RTCP messages 1168 and not the RTP messages that contain the octet count 1169 of the RTP message. Thus implementation of this 1170 object is OPTIONAL" 1172 OBJECT rtpRcvrPackets 1173 MIN-ACCESS not-accessible 1174 DESCRIPTION 1175 "RTP monitor systems may receive only the RTCP messages 1176 and not the RTP messages that contain the octet count 1177 of the RTP message. Thus implementation of this 1178 object is OPTIONAL." 1179 OBJECT rtpSessionIfIndex 1180 MIN-ACCESS read-only 1181 DESCRIPTION 1182 "Row creation and deletion is OPTIONAL so 1183 read-create access to this object is OPTIONAL." 1184 OBJECT rtpSessionInverseStartTime 1185 MIN-ACCESS not-accessible 1186 DESCRIPTION 1187 "Multicast RTP Systems SHOULD implement the optional 1188 tables." 1189 OBJECT rtpSenderInverseStartTime 1190 MIN-ACCESS not-accessible 1191 DESCRIPTION 1192 "Multicast RTP Systems SHOULD implement the optional 1193 tables." 1194 OBJECT rtpRcvrInverseStartTime 1195 MIN-ACCESS not-accessible 1196 DESCRIPTION 1197 "Multicast RTP Systems SHOULD implement the optional 1198 tables." 1199 ::= { rtpCompliances 2 } 1200 END 1201 4. Security Issues 1203 In most cases, MIBs are not themselves security risks; if SNMP security 1204 is operating as intended, the use of a MIB to view information about a 1205 system, or to change some parameter at the system, is a tool, not a 1206 threat. However, there are a number of management objects defined in this 1207 MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such 1208 objects may be considered sensitive or vulnerable in some network 1209 environments. The support for SET operations in a non-secure 1210 environment without proper protection can have a negative effect on 1211 network operations. 1213 None of the read-only objects in this MIB reports a password, though 1214 some SDES [RFC1889] items such as the CNAME [RFC1889], the canonical name, 1215 may be deemed sensitive depending on the security policies of a particular 1216 enterprise. If access to these objects is not limited by an 1217 appropriate access control policy, these objects can provide an 1218 attacker with information about a system's configuration and the 1219 services that that system is providing. Some enterprises view their 1220 network and system configurations, as well as information about 1221 usage and performance, as corporate assets; such enterprises may 1222 wish to restrict SNMP access to most of the objects in the MIB. 1223 This MIB supports read-write operations against rtpSessionNewIndex 1224 which has the side effect of creating an entry in the rtpSessionTable 1225 when it is written to. Five objects in rtpSessionEntry have 1226 read-create access: rtpSessionDomain, rtpSessionRemAddr, 1227 rtpSessionIfIndex, rtpSessionRowStatus, and rtpSessionIfAddr identify an RTP 1228 session to be monitored on a particular interface. The values of these 1229 objects are not to be changed once created, and initialization of these 1230 objects affects only the monitoring of an RTP session and not the 1231 operation of an RTP session on any host end-system. Since write 1232 operations to rtpSessionNewIndex and the five objects in 1233 rtpSessionEntry affect the operation of the monitor, write access to 1234 these objects should be subject to the appropriate access control 1235 policy. 1237 Confidentiality of RTP and RTCP data packets is defined in section 9 of 1238 the RTP specification [RFC1889]. Encryption may be performed on RTP packets, 1239 RTCP packets, or both. Encryption of RTCP packets may pose a problem 1240 for third-party monitors though "For RTCP, it is allowed to split a 1241 compound RTCP packet into two lower-layer packets, one to be encrypted 1242 and one to be sent in the clear. For example, SDES information might 1243 be encrypted while reception reports were sent in the clear to 1244 accommodate third-party monitors [RFC1889]." 1245 SNMPv1 by itself is not a secure environment. Even if the network 1246 itself is secure (for example by using IPSec), there is no control 1247 as to who on the secure network is allowed to access and GET/SET 1248 (read/change/create/delete) the objects in this MIB. It is 1249 recommended that the implementers consider the security features 1250 as provided by the SNMPv3 framework. Specifically, the use of the 1251 User-based Security Model RFC 2574 [RFC2574] and the View-based 1252 Access Control Model RFC 2575 [RFC2575] is recommended. It is then 1253 a customer/user responsibility to ensure that the SNMP entity 1254 giving access to an instance of this MIB, is properly configured to 1255 give access to the objects only to those principals (users) that 1256 have legitimate rights to indeed GET or SET (change/create/delete) 1257 them. 1259 5. Acknowledgements 1261 The authors wish to thank Bert Wijnen and the participants from the 1262 ITU SG-16 management effort for their helpful comments. Alan Batie 1263 and Bill Lewis from Intel also contributed greatly to the RTP MIB 1264 through their review of various drafts of the MIB and their work 1265 on the implementation of an SNMP RTP Monitor. Stan Naudus from 3Com 1266 and John Du from Intel contributed to the original RTP MIB design and 1267 co-authored the original RTP MIB draft documents; much of their work 1268 remains in the current RTP MIB. 1270 6. Intellectual Property 1272 The IETF takes no position regarding the validity or scope of any 1273 intellectual property or other rights that might be claimed to 1274 pertain to the implementation or use of the technology described in 1275 this document or the extent to which any license under such rights 1276 might or might not be available; neither does it represent that it 1277 has made any effort to identify any such rights. Information on the 1278 IETF's procedures with respect to rights in standards-track and 1279 standards-related documentation can be found in BCP-11. Copies of 1280 claims of rights made available for publication and any assurances of 1281 licenses to be made available, or the result of an attempt made to 1282 obtain a general license or permission for the use of such 1283 proprietary rights by implementors or users of this specification can 1284 be obtained from the IETF Secretariat. 1286 The IETF invites any interested party to bring to its attention any 1287 copyrights, patents or patent applications, or other proprietary 1288 rights which may cover technology that may be required to practice 1289 this standard. Please address the information to the IETF Executive 1290 Director. 1292 7. References 1294 [RFC1889] H. Shulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 1295 A Transport Protocol for real-time applications," RFC 1889. 1297 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 1298 for Describing SNMP Management Frameworks", RFC 2571, April 1299 1999 1301 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification 1302 of Management Information for TCP/IP-based Internets", STD 1303 16, RFC 1155, May 1990 1305 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 1306 16, RFC 1212, March 1991 1308 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the 1309 SNMP", RFC 1215, March 1991 1311 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1312 Rose, M., and S. Waldbusser, "Structure of Management 1313 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999 1315 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1316 Rose, M., and S. Waldbusser, "Textual Conventions for 1317 SMIv2", STD 58, RFC 2579, April 1999 1319 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1320 Rose, M., and S. Waldbusser, "Conformance Statements for 1321 SMIv2", STD 58, RFC 2580, April 1999 1323 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 1324 Network Management Protocol", STD 15, RFC 1157, May 1990. 1326 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1327 "Introduction to Community-based SNMPv2", RFC 1901, January 1328 1996. 1330 [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1331 "Transport Mappings for Version 2 of the Simple Network 1332 Management Protocol (SNMPv2)", RFC 1906, January 1996. 1334 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 1335 Processing and Dispatching for the Simple Network Management 1336 Protocol (SNMP)", RFC 2572, April 1999 1338 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 1339 (USM) for version 3 of the Simple Network Management 1340 Protocol (SNMPv3)", RFC 2574, April 1999 1342 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1343 "Protocol Operations for Version 2 of the Simple Network 1344 Management Protocol (SNMPv2)", RFC 1905, January 1996. 1346 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", 1347 RFC 2573, April 1999 1349 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 1350 Access Control Model (VACM) for the Simple Network 1351 Management Protocol (SNMP)", RFC 2575, April 1999 1353 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 1354 "Introduction to Version 3 of the Internet-standard Network 1355 Management Framework", RFC 2570, April 1999 1357 8. Authors Addresses 1359 Mark Baugher Email: mbaugher@passedge.com 1360 Intel Corporation 1361 2111 N.E.25th Avenue 1362 Hillsboro, Oregon 97124 1363 U.S.A. 1365 Bill Strahm Email: Bill.Strahm@intel.com 1366 Intel Corporation 1367 2111 N.E.25th Avenue 1368 Hillsboro, Oregon 97124 1369 U.S.A. 1371 Irina Suconick Email: isuconick@videoserver.com 1372 Videoserver Corporation 1373 63 Third Street 1374 Burlington, Massachusetts 01803 1375 U.S.A. 1377 9. Full Copyright Statement 1379 Copyright (C) The Internet Society (1999). All Rights Reserved. 1381 This document and translations of it may be copied and furnished to 1382 others, and derivative works that comment on or otherwise explain it 1383 or assist in its implementation may be prepared, copied, published 1384 and distributed, in whole or in part, without restriction of any 1385 kind, provided that the above copyright notice and this paragraph 1386 are included on all such copies and derivative works. However, this 1387 document itself may not be modified in any way, such as by removing 1388 the copyright notice or references to the Internet Society or other 1389 Internet organizations, except as needed for the purpose of 1390 developing Internet standards in which case the procedures for 1391 copyrights defined in the Internet Standards process must be 1392 followed, or as required to translate it into languages other than 1393 English. 1395 The limited permissions granted above are perpetual and will not be 1396 revoked by the Internet Society or its successors or assigns. 1398 This document and the information contained herein is provided on an 1399 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1400 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1401 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1402 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1403 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.