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