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