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