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