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