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