idnits 2.17.1 draft-ietf-avt-rtp-mib-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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 an Authors' Addresses Section. ** There are 9 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 3 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 96 has weird spacing: '...red for rtpIS...' == Line 429 has weird spacing: '...ndexing purpo...' == Line 622 has weird spacing: '...urposes only ...' == Line 881 has weird spacing: '... "This objec...' == Line 882 has weird spacing: '...onIndex as de...' == (6 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 (November 18, 1997) is 9654 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) -- Missing reference section? '1' on line 1371 looks like a reference -- Missing reference section? '2' on line 1374 looks like a reference -- Missing reference section? '3' on line 1379 looks like a reference -- Missing reference section? '4' on line 1385 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 7 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft RTP MIB November 18, 1997 4 Real-Time Transport Protocol 5 Management Information Base 6 8 November 18, 1997 10 Mark Baugher 11 Intel Corporation 12 2111 N.E.25th Avenue 13 Hillsboro, Oregon 97124 15 mbaugher@intel.com 17 John Du 18 Intel Corporation 19 2111 N.E.25th Avenue 20 Hillsboro, Oregon 97124 22 John_Du@ccm.jf.intel.com 24 Stan Naudus 25 3Com Corporation 26 2070 Chain Bridge Road 27 Vienna, Virginia 22182 29 snaudus@usrva.com 31 Status of this Memo 33 This document is an Internet-Draft. Internet-Drafts are 34 working documents of the Internet Engineering Task Force 35 (IETF), its areas, and its working groups. Note that other 36 groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months. Internet-Drafts may be updated, replaced, or made 41 obsolete by other documents at any time. It is not 42 appropriate to use Internet-Drafts as reference material or to 43 cite them other than as a ``working draft'' or ``work in 44 progress.'' 46 To learn the current status of any Internet-Draft, please 47 check the 1id-abstracts.txt listing contained in the Internet- 48 Drafts Shadow Directories on ds.internic.net, nic.nordu.net, 49 venera.isi.edu, or munnari.oz.au. 51 1. Changes from Previous Draft 53 (1) The DESCRIPTION clauses are changed for those rtpEgEntry and 54 rtpInEntry objects that also appear in RTCP messages. The 55 current values are always to be used rather than the values 56 from the last RTCP message for MIB objects that are also defined 57 in RTCP. 59 (2) Interfaces in rtpEgEntry, rtpInEntry and rtpSessionEntry are now 60 defined by a pair of InterfaceIndex and IpAddress object 61 instances. InterfaceIndex is a Textual Convention that is 62 introduced in this MIB to be zero when the interface has an 63 IP Address; otherwise it is the IfIndex from the IF-MIB. 65 (3) rtpEgIndex and rtpInIndex are added to serve as the sole indexes 66 to rtpEgEntry and rtpInEntry respectively. This change is needed 67 to support multi-homed RTP hosts. 69 (4) rtpEgStartTime, rtpInStartTime and rtpSessionStartTime are added 70 for the purpose of recording the SysUpTime value at the time of 71 conceptual row creation as required by RFC 1902 for conceptual 72 rows that contain counters that do not become active at the 73 start of the epoch. 75 (5) rtpEgTool DEFVAL comment no longer refers to RTCP SDES. 77 (6) The interarrival jitter estimator was added to the rtpInEntry 78 and the rtpRREntry. 80 (7) rtpInPackets added to count the total number of RTP data packets 81 that are received. 83 (8) rtpSessionIfIndex changed to 'read-create.' 85 (9) A potential problem of the duplicate counting of rtpSessionSenders 86 and rtpSessionReceivers is mentioned in their DESCRIPTION clauses. 88 (10) rtpRREntry's last two indexes are reversed with rtpSRSSRC appear- 89 ing before rtpRRSSRC to permit tree walks organized by sender. 91 (11) DisplayString is used in place of OCTET STRING for CNAME's and 92 Tool names. 94 (12) Unsigned32 used for SSRC's in place of INTEGER. 96 (13) OID values are renumbered for rtpIS, rtpISGlobals, rtpSRTable, 97 rtpRRTable, rtpRRFracLost and subsequent columns of rtpRREntry. 99 2. Abstract 101 This memo defines an experimental Management Information Base 102 (MIB) for use with network management protocols in 103 TCP/IP-based internets. In particular, it defines objects for 104 managing Real-Time Transport Protocol systems [1]. Comments 105 should be made to the IETF Audio/Video Transport Working Group 106 at rem-conf@es.net. 108 This memo does not specify a standard for the Internet 109 community. 111 3. The Network Management Framework 113 The SNMPv2 Network Management Framework consists of the 114 following major components: 116 RFC 1902 which defines the SMI, the mechanisms used for 117 describing and naming objects for the purpose of management. 119 RFC 1903 Textual Conventions for Version 2 of the Simple 120 Network Management Protocol (SNMPv2). 122 RFC 1904 Conformance Statements for Version 2 of the 123 Simple Network Management Protocol (SNMPv2). 125 RFC 1905 Protocol Operations for Version 2 of the 126 Simple Network Management Protocol (SNMPv2). 128 RFC 1906 Transport Mappings for Version 2 of the 129 Simple Network Management Protocol (SNMPv2). 131 RFC 1907 Management Information Base for Version 2 of 132 the Simple Network Management Protocol (SNMPv2). 134 RFC 1908 Coexistence between Version 1 and Version 2 of 135 the Internet-standard Network Management Framework. 137 The Framework permits new objects to be defined for the 138 purpose of experimentation and evaluation. 140 Managed objects are accessed via a virtual information store, 141 termed the Management Information Base or MIB. Within a given 142 MIB module, objects are defined using the SMI's OBJECT-TYPE 143 macro[2]. At a minimum, each object has a name, a syntax, an 144 access-level, and an implementation-status. 146 The name is an object identifier, an administratively assigned 147 name, which specifies an object type. The object type 148 together with an object instance serves to uniquely identify a 149 specific instantiation of the object. For human convenience, 150 we often use a textual string, termed the object descriptor, 151 to also refer to the object type. 153 The syntax of an object type defines the abstract data 154 structure corresponding to that object type. The ASN.1[3] 155 language is used for this purpose. However, RFC 1902 156 purposely restricts the ASN.1 constructs which may be used. 157 These restrictions are made for simplicity. 159 The access-level of an object type defines whether it makes 160 "protocol sense" to read and/or write the value of an instance 161 of the object type. (This access-level is independent of any 162 administrative authorization policy.) 164 The implementation-status of an object type indicates whether 165 the object is mandatory, optional, obsolete, or deprecated. 167 4. Overview 169 An "RTP System" may be a host end-system that runs an application 170 program that sends or receives RTP data packets, or it may be an 171 intermediate-system that forwards RTP packets. RTP Control 172 Protocol (RTCP) packets are sent by senders and receivers to 173 convey information about RTP packet transmission and reception [1]. 175 4.1 Textual Conventions 177 A new data type, InterfaceIndex, is introduced as a textual convention in 178 this MIB document. Textual conventions enhance the readability of 179 the specification and can ease comparison with other specifications 180 if appropriate. It should be noted that the introduction of the 181 textual conventions has no effect on either the syntax nor the 182 semantics of any managed objects. The use of these is merely an 183 artifact of the explanatory method used. Objects defined in terms of 184 one of these methods are always encoded by means of the rules that 185 define the primitive type. Hence, no changes to the SMI or the SNMP 186 are necessary to accommodate these textual conventions which are 187 adopted merely for the convenience of readers and writers. 189 4.2 Components 191 The RTP MIB is structured around "Session," "Receiver" and "Sender" 192 conceptual abstractions. 194 4.2.1 An "RTP Session" is the "...association of participants 195 communicating with RTP. For each participant, the session is 196 defined by a particular pair of destination transport addresses 197 (one network address plus a port pair for RTP and RTCP). The 198 destination transport addresses may be common for all participants, 199 as in the case of IP multicast, or may be different for each, as in 200 the case of individual unicast addresses plus a common port pair," 201 as defined in section 3 of [1]. 203 4.2.2 A "Sender" is identified by a 32-bit numeric "Synchronization 204 Source," or "SSRC", value and is "...the source of a stream of RTP 205 packets" as defined in section 3 of [1]. The Sender is also a source 206 of RTCP Sender Report packets as specified in section 6 of [1]. 208 4.2.3 A "Receiver" of a "stream of RTP packets" can be a unicast or 209 multicast Receiver as described in 4.2.1, above. An RTP Receiver has 210 an SSRC value that is unique to the session. An RTP Receiver is a 211 source of RTCP Receiver Reports as specified in section 6 of [1]. 213 4.3 Applicability of the MIB to RTP System Implementations 215 The RTP MIB may be used in two types of RTP implementations, RTP Host 216 Systems (end systems) and RTP Monitors, see section 3 of [1]. 217 Use of the RTP MIB for RTP Translators and Mixers, as defined in 218 section 7 of [1], is for further study. 220 4.3.1 RTP Host Systems are end-systems that may use the RTP MIB 221 to collect RTP Session and Stream data; these data may be used 222 by a network manager to diagnose faults that occur over the life time 223 of an RTP Session as in a "help-desk" scenario. 225 4.3.2 RTP Monitors of multicast RTP sessions may be located in an RTP 226 intermediate-system or in the host. RTP Monitors may use the RTP 227 MIB to collect RTP Session and Stream statistical data; these data may 228 be used by a network manager for capacity planning and other 229 network-management purposes. An RTP Monitor may also use the RTP MIB 230 to collect data to permit a network manager to diagnose faults in RTP 231 sessions, or to permit a network manger to configure the Monitor. 233 4.4 The Structure of the RTP MIB 235 There are two modules in the RTP MIB: The RTP-SYSTEM module 236 is used for RTP Host Systems, and the RTP-IS module is designed 237 for RTP Monitors. There are two tables in RTP-SYSTEM and three 238 tables in RTP-IS. 240 RTP-SYSTEM Tables: 241 rtpInTable 242 rtpEgTable 244 These tables contain information about RTP Streams that an RTP 245 end system is sending (rtpEgTable) or receiving (rtpInTable). 247 These tables are not intended for use by RTP Monitors. rtpInTable 248 and rtpEgTable do not contain objects which are creatable nor 249 writable by a network manager. The rtpSessionTable in RTP-IS 250 permits conceptual rows to be created by a network manager for the 251 purpose of identifying RTP sessions to be monitored. 253 RTP-IS Tables: 254 rtpSessionTable 255 rtpSRTable 256 rtpRRTable 258 rtpSessionNewIndex is a global object that permits a network-management 259 application to obtain a unique index for conceptual row creation 260 in the rtpSessionTable. In this way the SNMP Set operation may 261 be used to configure a monitor which implements RTP-IS. 263 4.5 SNMP Implementations 265 An RTP System that runs either a single application or multiple 266 applications with a single management-entity may be a practical 267 configuration for monitoring, translating or mixing. Host end- 268 -systems are the vast majority of RTP implementations, however, 269 and a "monolithic" solution may be inadequate if management of 270 RTP end-systems proves to be truly useful. The RTP-SYSTEM module 271 described in 4.4 contains tables that may be shared among RTP 272 application programs that run concurrently on the same device - as 273 many or most do. Sharing occurs on a table basis, and this may 274 be complicated on some host systems. Rows in the RTP MIB tables, 275 however, are uniquely identified by RTP Session and SSRC pairs 276 (or a pair of SSRCs for RTP Receivers). If the RTP Session and 277 SSRC values are unique to the RTP application program, then 278 conceptual rows do not need to be shared. 280 Table sharing may be a problem for SNMP management entities on some 281 host operting systems: All SNMP management requests are sent to UDP 282 Port 161, and an Application Programming Interface (API) is needed to 283 facilitate this sharing. The API is specific to the host operating 284 system, and there are solutions provided by host operating system 285 vendors and by independent software vendors. There is also a 286 standardization effort within the IETF to at least define a standard 287 system-interface protocol that may be implemented in an API to permit 288 multiple management entities to share the object name space[4]. Whether 289 or not independent RTP application programs can cooperatively and 290 concurrently support the RTP MIB is outside the scope of this draft 291 document and will differ depending on the operating system in question. 293 5. Definitions 295 RTP-SYSTEM DEFINITIONS ::= BEGIN 296 IMPORTS 297 Counter32, Gauge32, experimental, Integer32, 298 IpAddress, MODULE-IDENTITY, OBJECT-IDENTITY, 299 OBJECT-TYPE, TimeTicks, Unsigned32 FROM SNMPv2-SMI 300 DisplayString, TAddress, TDomain, 301 TEXTUAL-CONVENTION, TimeStamp FROM SNMPv2-TC 302 OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF; 304 rtpSystem MODULE-IDENTITY 305 LAST-UPDATED "9711112000Z" 306 ORGANIZATION "IETF AVT Working Group" 307 CONTACT-INFO 308 "Mark Baugher 309 Postal: Intel Corporation 310 2111 NE 25th Avenue 311 Hillsboro, OR 97124 312 United States 313 Tel: +1 503 264 3849 314 Email: mbaugher@intel.com 316 John Du 317 Postal: Intel Corporation 318 2111 NE 25th Avenue 319 Hillsboro, OR 97124 320 United States 321 Tel: +1 503 264 0636 322 Email: John_Du@ccm.jf.intel.com 324 Stan Naudus 325 Postal: 3Com Corporation 326 2070 Chain Bridge Road 327 Vienna, VA 328 United States 329 Tel: +1 703 848 7710 330 Email: snaudus@usrva.com" 331 DESCRIPTION 332 "The MIB module that describes managed objects of 333 general use by RTP Host Systems. The MIB is 334 structured around two types of information. 335 1. Information about RTP streams being sent to 336 an RTP Session by a particular source. 337 2. Information about RTP streams received on an 338 RTP Session by a particular receiver. 339 Refer to 'RTP: A Transport Protocol for Real-Time 340 Applications,' section 3.0, for definitions." 341 ::= { experimental 77 1 } 342 rtp OBJECT-IDENTITY 343 STATUS current 344 DESCRIPTION 345 "The root of RTP Object-identifiers." 346 ::= { experimental 77 } 348 InterfaceIndex ::= TEXTUAL-CONVENTION 349 STATUS current 350 DESCRIPTION 351 "The range of ifIndex." 352 SYNTAX Integer32 353 -- 354 -- OBJECTS 355 -- 356 rtpGlobals OBJECT IDENTIFIER ::= { rtp 2 } 358 rtpDomains OBJECT IDENTIFIER ::= { rtpGlobals 1 } 360 rtpUDPDomain OBJECT-IDENTITY 361 STATUS current 362 DESCRIPTION 363 "RTP over UDP transport domain over IPv4. This definition 364 uses the transport address type, snmpUDPAddress, which is 365 defined in SNMPv2-TM, 'Transport Mappings for Version 2 of 366 the Simple Network Management Protocol (SNMPv2)'." 367 REFERENCE "RFC 1906, p. 3" 368 ::= { rtpDomains 1 } 370 -- Stream Tables: 371 -- Egress Streams are sent by an RTP System to an RTP Session. 372 -- Ingress Streams are received on a session by some RTP System. 373 -- 374 -- 375 -- EGRESS STREAMS TABLE 376 -- 377 rtpEgTable OBJECT-TYPE 378 SYNTAX SEQUENCE OF RtpEgEntry 379 MAX-ACCESS not-accessible 380 STATUS current 381 DESCRIPTION 382 "The rtpEgTable contains state, statistics, and attribute 383 information about a stream being sent by an RTP sender that 384 is local to the RTP System and which is uniquely identified 385 in the RTP Session by a synchronization source (SSRC) value 386 ('RTP: A Transport Protocol for Real-Time Applications, 3'). 387 There is a conceptual row for each stream being sent by the 388 local RTP System." 389 ::= { rtpSystem 1 } 391 rtpEgEntry OBJECT-TYPE 392 SYNTAX RtpEgEntry 393 MAX-ACCESS not-accessible 394 STATUS current 395 DESCRIPTION 396 "An rtpEgEntry contains information about one stream 397 that's being sent by a sender on the local RTP Host 398 System. Although some object definitions in rtpEgEntry also 399 appear in certain RTCP messages, the values retrieved by the 400 SNMP entity are current values and not values taken from the 401 last RTCP message that was sent. Table rows cannot be created 402 nor deleted via SNMP operations." 403 INDEX { rtpEgIndex } 404 ::= { rtpEgTable 1 } 406 RtpEgEntry ::= SEQUENCE { 407 rtpEgIndex Integer32, 408 rtpEgDstAddr TAddress, 409 rtpEgSSRC Unsigned32, 410 rtpEgCNAME DisplayString, 411 rtpEgPT INTEGER, 412 rtpEgSentPackets Counter32, 413 rtpEgSentOctets Counter32, 414 rtpEgTool DisplayString, 415 rtpEgLastSR TimeTicks, 416 rtpEgDomain TDomain, 417 rtpEgSrcAddr TAddress, 418 rtpEgStartTime TimeStamp, 419 rtpEgIfIndex InterfaceIndex, 420 rtpEgIfAddr IpAddress 421 } 423 rtpEgIndex OBJECT-TYPE 424 SYNTAX Integer32 (1..65535) 425 MAX-ACCESS not-accessible 426 STATUS current 427 DESCRIPTION 428 "The number of this stream. This is for SNMP 429 Indexing purposes only and has no relation to 430 any protocol value." 431 ::= { rtpEgEntry 1 } 433 rtpEgDstAddr OBJECT-TYPE 434 SYNTAX TAddress 435 MAX-ACCESS read-only 436 STATUS current 437 DESCRIPTION 438 "The destination transport service address to which 439 the stream of RTP data packets is being sent. The 440 trasport-service is identified by rtpEgDomain. For 441 rtpUDPDomain, this is an IP address and a even-numbered 442 UDP Port with RTCP packets being sent on the next higher 443 odd-numbered port, according to 'RTP: A Transport 444 Protocol for Real-Time Application' section 10." 445 ::= { rtpEgEntry 2 } 447 rtpEgSSRC OBJECT-TYPE 448 SYNTAX Unsigned32 449 MAX-ACCESS read-only 450 STATUS current 451 DESCRIPTION 452 "The RTP SSRC, or synchronization source identifier, of the 453 sender. The RTP Session Address plus an SSRC uniquely 454 identify a sender or receiver of an RTP stream (see 'RTP: 455 A Transport Protocol for Real-Time Applications' sec.3)." 456 ::= { rtpEgEntry 3 } 458 rtpEgCNAME OBJECT-TYPE 459 SYNTAX DisplayString 460 MAX-ACCESS read-only 461 STATUS current 462 DESCRIPTION 463 "The RTP canonical name of the sender." 464 ::= { rtpEgEntry 4 } 466 rtpEgPT OBJECT-TYPE 467 SYNTAX INTEGER (0..127) 468 MAX-ACCESS read-only 469 STATUS current 470 DESCRIPTION 471 "Static or dynamic Payload Type from the RTP header." 472 ::= { rtpEgEntry 5 } 474 rtpEgSentPackets OBJECT-TYPE 475 SYNTAX Counter32 476 MAX-ACCESS read-only 477 STATUS current 478 DESCRIPTION 479 "Count of RTP packets sent by this sender since the start 480 of the stream at rtpEgStartTime." 481 ::= { rtpEgEntry 6 } 483 rtpEgSentOctets OBJECT-TYPE 484 SYNTAX Counter32 485 MAX-ACCESS read-only 486 STATUS current 487 DESCRIPTION 488 "Count of octets sent by this sender since the start of 489 the stream at rtpEgStartTime." 490 ::= { rtpEgEntry 7 } 492 rtpEgTool OBJECT-TYPE 493 SYNTAX DisplayString (SIZE(0..127)) 494 MAX-ACCESS read-only 495 STATUS current 496 DESCRIPTION 497 "Name of the application program source of the stream." 498 DEFVAL { ''H } -- Null if not identified to mgt entity 499 ::= { rtpEgEntry 8 } 501 rtpEgLastSR OBJECT-TYPE 502 SYNTAX TimeTicks 503 MAX-ACCESS read-only 504 STATUS current 505 DESCRIPTION 506 "The elapsed time since the most recent RTCP Sender 507 Report was sent for this stream in 0.01 seconds." 508 ::= { rtpEgEntry 9 } 510 rtpEgDomain OBJECT-TYPE 511 SYNTAX TDomain 512 MAX-ACCESS read-only 513 STATUS current 514 DESCRIPTION 515 "The transport-layer protocol used for sending 516 the stream of RTP data packets from this source." 517 DEFVAL { rtpUDPDomain } 518 ::= { rtpEgEntry 10 } 520 rtpEgSrcAddr OBJECT-TYPE 521 SYNTAX TAddress 522 MAX-ACCESS read-only 523 STATUS current 524 DESCRIPTION 525 "The transport service address from which the stream 526 of RTP data packets is being sent. For 527 rtpUDPDomain, this is an IP address and an even- 528 numbered UDP port, see 'RTP: A Transport Protocol 529 for Real-Time Applications,' section 10." 530 ::= { rtpEgEntry 11 } 532 rtpEgStartTime OBJECT-TYPE 533 SYNTAX TimeStamp 534 MAX-ACCESS read-only 535 STATUS current 536 DESCRIPTION 537 "The value of SysUpTime when this row was created." 538 ::= { rtpEgEntry 12 } 540 rtpEgIfIndex OBJECT-TYPE 541 SYNTAX InterfaceIndex 542 MAX-ACCESS read-only 543 STATUS current 544 DESCRIPTION 545 "The ifIndex value is zero for interfaces that have an IP 546 address defined for the interface on which RTP data packets 547 are being sent for this stream. Otherwise this object is set 548 to the corresponding value from the Internet Standard MIB." 549 ::= { rtpEgEntry 13 } 551 rtpEgIfAddr OBJECT-TYPE 552 SYNTAX IpAddress 553 MAX-ACCESS read-only 554 STATUS current 555 DESCRIPTION 556 "The IP Address of the interface on which the stream of 557 RTP data packets is being sent for interfaces that have an 558 IP Address and set to 0.0.0.0 when rtpEgIfIndex is non zero." 559 ::= { rtpEgEntry 14 } 561 -- 562 -- INGRESS STREAMS TABLE 563 -- 565 rtpInTable OBJECT-TYPE 566 SYNTAX SEQUENCE OF RtpInEntry 567 MAX-ACCESS not-accessible 568 STATUS current 569 DESCRIPTION 570 "Data in the rtpInTable identify the stream and session, 571 state and statistics, and include information needed by 572 an RTP receiver to detect loops. This table will at 573 least contain a row for each stream being received 574 (ingress stream) by some SSRC on the local RTP System. 575 (see 'RTP: A Transport Protocol for Real-Time Applications' 576 sec. 3 and 8)." 577 ::= { rtpSystem 2 } 579 rtpInEntry OBJECT-TYPE 580 SYNTAX RtpInEntry 581 MAX-ACCESS not-accessible 582 STATUS current 583 DESCRIPTION 584 "An rtpInTable entry uniquely identifies an RTP Data Stream 585 received by the rtpInDstAddr, rtpInReceiverSSRC and 586 rtpInSenderSSRC. There is an rtpInEntry for each stream 587 received by the local RTP System. Although some 588 object definitions also appear in RTCP messages, the values 589 retrieved by the management entity are the current values rather 590 than the values used in the previous RTCP messages that was sent. 591 Table rows cannot be created nor deleted via SNMP operations." 592 INDEX { rtpInIndex } 593 ::= { rtpInTable 1 } 595 RtpInEntry ::= SEQUENCE { 596 rtpInIndex Integer32, 597 rtpInDstAddr TAddress, 598 rtpInReceiverSSRC Unsigned32, 599 rtpInSenderSSRC Unsigned32, 600 rtpInSenderCNAME DisplayString, 601 rtpInPT INTEGER, 602 rtpInSenderAddr TAddress, 603 rtpInPackets Counter32, 604 rtpInLostPackets Counter32, 605 rtpInOctets Counter32, 606 rtpInJitter Gauge32, 607 rtpInTool DisplayString, 608 rtpInLastRR TimeTicks, 609 rtpInDomain TDomain, 610 rtpInSrcAddr TAddress, 611 rtpInStartTime TimeStamp, 612 rtpInIfIndex InterfaceIndex, 613 rtpInIfAddr IpAddress 614 } 616 rtpInIndex OBJECT-TYPE 617 SYNTAX Integer32 (1..65535) 618 MAX-ACCESS not-accessible 619 STATUS current 620 DESCRIPTION 621 "The number of this stream. This is for SNMP indexing 622 purposes only and has no relation to any protocol value." 623 ::= { rtpInEntry 1 } 625 rtpInDstAddr OBJECT-TYPE 626 SYNTAX TAddress 627 MAX-ACCESS read-only 628 STATUS current 629 DESCRIPTION 630 "The destination transport service address on which 631 the stream of RTP data packets is being received. 632 For rtpUDPDomain, this is an IP address and a even-numbered 633 UDP Port with the RTCP being sent and received on the next 634 higher odd-numbered port, see 'RTP: A Transport Protocol 635 for Real-Time Application', 10.0." 636 ::= { rtpInEntry 2 } 638 rtpInReceiverSSRC OBJECT-TYPE 639 SYNTAX Unsigned32 640 MAX-ACCESS read-only 641 STATUS current 642 DESCRIPTION 643 "The RTP SSRC, or synchronization source identifier, of the 644 receiver. The RTP Session Address plus an SSRC uniquely 645 identify a sender or receiver of an RTP stream (see 'RTP: 646 A Transport Protocol for Real-Time Applications' sec.3)." 647 ::= { rtpInEntry 3 } 649 rtpInSenderSSRC OBJECT-TYPE 650 SYNTAX Unsigned32 651 MAX-ACCESS read-only 652 STATUS current 653 DESCRIPTION 654 "The RTP SSRC, or synchronization source identifier, of the 655 sender. The RTP Session Address plus an SSRC uniquely 656 identify a sender or receiver of an RTP stream (see 'RTP: 657 A Transport Protocol for Real-Time Applications' sec.3)." 658 ::= { rtpInEntry 4 } 660 rtpInPT OBJECT-TYPE 661 SYNTAX INTEGER(0..127) 662 MAX-ACCESS read-only 663 STATUS current 664 DESCRIPTION 665 "The RTP Payload Type of the RTP data stream." 666 ::= { rtpInEntry 5 } 668 rtpInSenderCNAME OBJECT-TYPE 669 SYNTAX DisplayString 670 MAX-ACCESS read-only 671 STATUS current 672 DESCRIPTION 673 "The RTP canonical name of the sender." 674 ::= { rtpInEntry 6 } 676 rtpInSenderAddr OBJECT-TYPE 677 SYNTAX TAddress 678 MAX-ACCESS read-only 679 STATUS current 680 DESCRIPTION 681 "The sender's transport address of the RTP data." 682 ::= { rtpInEntry 7 } 684 rtpInPackets OBJECT-TYPE 685 SYNTAX Counter32 686 MAX-ACCESS read-only 687 STATUS current 688 DESCRIPTION 689 "A count of total packets sent since the start of the stream 690 at rtpInStartTime. See 'RTP: A Transport Protocol for Real- 691 Time Applications', sec. 6.3." 692 ::= { rtpInEntry 8 } 694 rtpInLostPackets OBJECT-TYPE 695 SYNTAX Counter32 696 MAX-ACCESS read-only 697 STATUS current 698 DESCRIPTION 699 "A count from the RTCP RR of lost packets since the 700 start of the stream at rtpInStartTime." 701 ::= { rtpInEntry 9 } 703 rtpInOctets OBJECT-TYPE 704 SYNTAX Counter32 705 MAX-ACCESS read-only 706 STATUS current 707 DESCRIPTION 708 "A count by the SNMP entity of bytes received from the 709 ingress stream since the start of stream at rtpInStartTime." 710 ::= { rtpInEntry 10 } 712 rtpInJitter OBJECT-TYPE 713 SYNTAX Gauge32 714 MAX-ACCESS read-only 715 STATUS current 716 DESCRIPTION 717 "An estimate by the SNMP entity of current delay variation 718 of packets from the ingress stream (see 'RTP: A Transport 719 Protocol for Real-Time Applications,' sec. 6.3.1)." 720 ::= { rtpInEntry 11 } 722 rtpInTool OBJECT-TYPE 723 SYNTAX DisplayString (SIZE(0..127)) 724 MAX-ACCESS read-only 725 STATUS current 726 DESCRIPTION 727 "The RTCP SDES item identifying the tool used 728 to receive the ingress stream." 729 DEFVAL { ''H } -- Null if not identified to mgt entity 730 ::= { rtpInEntry 12 } 732 rtpInLastRR OBJECT-TYPE 733 SYNTAX TimeTicks 734 MAX-ACCESS read-only 735 STATUS current 736 DESCRIPTION 737 "The elapsed time since the most recent RTCP Receiver 738 Report was sent for the ingress stream in 0.01 seconds." 739 ::= { rtpInEntry 13 } 741 rtpInDomain OBJECT-TYPE 742 SYNTAX TDomain 743 MAX-ACCESS read-only 744 STATUS current 745 DESCRIPTION 746 "The transport-layer protocol used for receiving 747 the stream of RTP data packets from this source." 748 DEFVAL { rtpUDPDomain } 749 ::= { rtpInEntry 14 } 751 rtpInSrcAddr OBJECT-TYPE 752 SYNTAX TAddress 753 MAX-ACCESS read-only 754 STATUS current 755 DESCRIPTION 756 "The transport service address from which the stream 757 of RTCP data packets is being sent. For 758 rtpUDPDomain, this is an IP address and a UDP 759 port." 760 ::= { rtpInEntry 15 } 762 rtpInStartTime OBJECT-TYPE 763 SYNTAX TimeStamp 764 MAX-ACCESS read-only 765 STATUS current 766 DESCRIPTION 767 "The value of SysUpTime when this row was created." 768 ::= { rtpInEntry 16 } 770 rtpInIfIndex OBJECT-TYPE 771 SYNTAX InterfaceIndex 772 MAX-ACCESS read-only 773 STATUS current 774 DESCRIPTION 775 "The ifIndex value is zero for interfaces that have an IP 776 address defined for the interface on which RTP data packets 777 are being received for this stream. Otherwise this object is 778 set to the corresponding value from the Internet Standard 779 MIB." 780 ::= { rtpInEntry 17 } 782 rtpInIfAddr OBJECT-TYPE 783 SYNTAX IpAddress 784 MAX-ACCESS read-only 785 STATUS current 786 DESCRIPTION 787 "The IP Address of the interface on which the RTP data packets 788 are being received for interfaces that have an IP Address. 789 The value is 0.0.0.0 when rtpInIfIndex is non zero." 790 ::= { rtpInEntry 18 } 792 -- 793 -- GROUPS 794 -- 795 rtpSystemGroup OBJECT-GROUP 796 OBJECTS { 797 rtpEgDstAddr, 798 rtpEgSSRC, 799 rtpEgCNAME, 800 rtpEgPT, 801 rtpEgSentPackets, 802 rtpEgSentOctets, 803 rtpEgTool, 804 rtpEgLastSR, 805 rtpEgDomain, 806 rtpEgSrcAddr, 807 rtpEgStartTime, 808 rtpEgIfIndex, 809 rtpEgIfAddr, 810 rtpInDstAddr, 811 rtpInSenderSSRC, 812 rtpInReceiverSSRC, 813 rtpInSenderCNAME, 814 rtpInPT, 815 rtpInSenderAddr, 816 rtpInPackets, 817 rtpInLostPackets, 818 rtpInOctets, 819 rtpInJitter, 820 rtpInTool, 821 rtpInLastRR, 822 rtpInDomain, 823 rtpInSrcAddr, 824 rtpInStartTime, 825 rtpInIfIndex, 826 rtpInIfAddr 827 } 828 STATUS current 829 DESCRIPTION 830 "Accessible objects used to define RTP Streams that are being 831 sent or received by an RTP Host System." 832 ::= { rtpSystem 9 } 833 rtpSystemCompliance MODULE-COMPLIANCE 834 STATUS current 835 DESCRIPTION "The compliance statement for SNMP entities that 836 implement RTP. All accessible objects are 837 read only." 838 MODULE RTP-SYSTEM 839 MANDATORY-GROUPS { rtpSystemGroup } 840 ::= { rtpSystem 10 } 841 END 843 -- ****** 844 -- RTP-IS 845 -- ****** 847 RTP-IS DEFINITIONS ::= BEGIN 848 IMPORTS 849 Counter32, Gauge32, IpAddress, Integer32, 850 MODULE-IDENTITY, OBJECT-TYPE, TimeTicks, 851 Unsigned32 FROM SNMPv2-SMI 852 RowStatus, TAddress, TDomain, 853 DisplayString, TestAndIncr, TimeStamp FROM SNMPv2-TC 854 OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF 855 InterfaceIndex, rtp, rtpUDPDomain FROM RTP-SYSTEM; 857 rtpIS MODULE-IDENTITY 858 LAST-UPDATED "9711111800Z" 859 ORGANIZATION "IETF AVT Working Group." 860 CONTACT-INFO 861 " Mark Baugher 862 Postal: Intel Corporation 863 2111 NE 25th Avenue 864 Hillsboro, OR 97124 865 Tel: +1 503 264 3849 866 Email: mbaugher@intel.com" 867 DESCRIPTION 868 "The MIB module for use by Real-Time Transport Protocol 869 multicast monitors." 870 ::= { rtp 3 } 872 rtpISGlobals OBJECT IDENTIFIER ::= { rtp 4 } 873 -- 874 -- SESSION TABLE 875 -- 876 rtpSessionNewIndex OBJECT-TYPE 877 SYNTAX TestAndIncr 878 MAX-ACCESS read-write 879 STATUS current 880 DESCRIPTION 881 "This object is used to assign values to 882 rtpSessionIndex as described in 'Textual Con- 883 ventions for SNMPv2'. The network manager 884 reads the object, and then writes the value 885 back in the SET that creates a new instance of 886 rtpSessionEntry. If the SET fails with the 887 code inconsistentValue, then the process must 888 be repeated; If the SET succeeds, then the ob- 889 ject is incremented, and the new instance is 890 created according to the managers directions." 891 ::= { rtpISGlobals 1 } 893 rtpSessionTable OBJECT-TYPE 894 SYNTAX SEQUENCE OF RtpSessionEntry 895 MAX-ACCESS not-accessible 896 STATUS current 897 DESCRIPTION 898 "There's one entry in the SessionTable for each Session that 899 is being monitored. Row creation has the side effect of 900 causing the RTP System to join the session for the purposes 901 of gathering management information." 902 ::= { rtpIS 1 } 904 rtpSessionEntry OBJECT-TYPE 905 SYNTAX RtpSessionEntry 906 MAX-ACCESS not-accessible 907 STATUS current 908 DESCRIPTION 909 "Data in rtpSessionTable uniquely identify an RTP 910 Session. Rows of the rtpSessionTable can be created 911 and deleted via SNMP operations." 912 INDEX { rtpSessionIndex } 913 ::= { rtpSessionTable 1 } 915 RtpSessionEntry ::= SEQUENCE { 916 rtpSessionIndex Integer32, 917 rtpSessionDomain TDomain, 918 rtpSessionAddr TAddress, 919 rtpSessionIfIndex InterfaceIndex, 920 rtpSessionIfAddr IpAddress, 921 rtpSessionSenders Counter32, 922 rtpSessionReceivers Counter32, 923 rtpSessionStartTime TimeStamp, 924 rtpSessionRowStatus RowStatus 925 } 927 rtpSessionIndex OBJECT-TYPE 928 SYNTAX Integer32 (1..65535) 929 MAX-ACCESS not-accessible 930 STATUS current 931 DESCRIPTION 932 "The index of the conceptual row which is for 933 SNMP purposes only and has no relation to any 934 protocol value." 935 ::= { rtpSessionEntry 1} 937 rtpSessionDomain OBJECT-TYPE 938 SYNTAX TDomain 939 MAX-ACCESS read-create 940 STATUS current 941 DESCRIPTION 942 "The transport-layer protocol used for sending 943 the stream of RTP data packets from this source. 944 Cannot be changed after rtpSessionRowStatus is 'active'." 945 DEFVAL { rtpUDPDomain } 946 ::= { rtpSessionEntry 2 } 948 rtpSessionAddr OBJECT-TYPE 949 SYNTAX TAddress 950 MAX-ACCESS read-create 951 STATUS current 952 DESCRIPTION 953 "The destination transport service address to which the stream 954 of RTP data packets is being sent and received. The 955 transport-service is identified by rtpSessionDomain. For 956 rtpUDPDomain, this is an IP address and an even-numbered UDP 957 Port with the RTCP being sent on the next higher odd-numbered 958 port, see 'RTP: A Transport Protocol for Real-Time 959 Application,' 10. Cannot be changed after rtpSessionRowStatus 960 is 'active'." 961 ::= { rtpSessionEntry 3 } 963 rtpSessionIfIndex OBJECT-TYPE 964 SYNTAX InterfaceIndex 965 MAX-ACCESS read-create 966 STATUS current 967 DESCRIPTION 968 "The ifIndex value is zero for interfaces that have an IP 969 address defined for the interface on which RTP data packets 970 are received for this session. Otherwise this object is set 971 to the corresponding value from the Internet Standard MIB. 972 Cannot be changed after rtpSessionRowStatus is 'active'." 973 ::= { rtpSessionEntry 4 } 975 rtpSessionIfAddr OBJECT-TYPE 976 SYNTAX IpAddress 977 MAX-ACCESS read-create 978 STATUS current 979 DESCRIPTION 980 "The IP Address of the interface on which the monitored stream 981 of RTP data packets is being received for interfaces that have 982 an IP Address. If rtpSessionIfIndex is non-zero, then this 983 object should have the value 0.0.0.0. Cannot be changed after 984 rtpSessionRowStatus has become 'active'." 985 ::= { rtpSessionEntry 5 } 987 rtpSessionSenders OBJECT-TYPE 988 SYNTAX Counter32 989 MAX-ACCESS read-only 990 STATUS current 991 DESCRIPTION 992 "The high-water mark of the number of senders observed by 993 the monitor since this conceptual row was created 994 (rtpSessionStartTime). Senders that leave and then 995 re-join following an RTCP BYE or session timeout may be 996 counted multiple times." 997 ::= { rtpSessionEntry 6 } 999 rtpSessionReceivers OBJECT-TYPE 1000 SYNTAX Counter32 1001 MAX-ACCESS read-only 1002 STATUS current 1003 DESCRIPTION 1004 "The high-water mark of the number of receivers that are 1005 observed by the monitor since this conceptual row was 1006 created (rtpSessionStartTime). Receivers that leave and 1007 then re-join following an RTCP BYE or session timeout may be 1008 counted multiple times." 1009 ::= { rtpSessionEntry 7 } 1011 rtpSessionStartTime OBJECT-TYPE 1012 SYNTAX TimeStamp 1013 MAX-ACCESS read-only 1014 STATUS current 1015 DESCRIPTION 1016 "The value of SysUpTime at the time that this row was 1017 created." 1018 ::= { rtpSessionEntry 8 } 1020 rtpSessionRowStatus OBJECT-TYPE 1021 SYNTAX RowStatus 1022 MAX-ACCESS read-create 1023 STATUS current 1024 DESCRIPTION 1025 "Value of 'active' when when RTCP messages are being 1026 received by a local RTP Monitor System. A manager-created 1027 conceptual row must have the rtpSessionAddr initialized by 1028 the manager before becoming 'active', and it must have the 1029 rtpSessionIf or the rtpSessionIfAddr initialized by the 1030 manager before becoming active. A conceptual row that is 1031 in the 'notReady' or 'notInService' state may be removed 1032 after 5 minutes." 1033 ::= { rtpSessionEntry 9 } 1035 -- 1036 -- SENDERS TABLE 1037 -- 1038 rtpSRTable OBJECT-TYPE 1039 SYNTAX SEQUENCE OF RtpSREntry 1040 MAX-ACCESS not-accessible 1041 STATUS current 1042 DESCRIPTION 1043 "Table of RTP Monitor information about senders to an RTP 1044 Session. Entries are created as a side-effect by the SNMP 1045 entity when a conceptual row in the rtpSessionTable 1046 becomes 'active'." 1047 ::= { rtpIS 2 } 1049 rtpSREntry OBJECT-TYPE 1050 SYNTAX RtpSREntry 1051 MAX-ACCESS not-accessible 1052 STATUS current 1053 DESCRIPTION 1054 "Each entry contains monitoring information from a single RTP 1055 Synchronization Source (SSRC) taken from RTCP Sender Report 1056 (SR) messages sent by the senders to an RTP Session (see 'RTP: 1057 A Transport Protocol for Real-Time Applications' sec.6). The 1058 session is identified to the the SNMP entity by 1059 rtpSessionIndex." 1060 INDEX { rtpSessionIndex, rtpSRSSRC } 1061 ::= { rtpSRTable 1 } 1063 RtpSREntry ::= SEQUENCE { 1064 rtpSRSSRC Unsigned32, 1065 rtpSRCNAME DisplayString, 1066 rtpSRSentPackets Counter32, 1067 rtpSRSentOctets Counter32, 1068 rtpSRTool DisplayString, 1069 rtpSRs Counter32, 1070 rtpSRLastSR TimeTicks 1071 } 1073 rtpSRSSRC OBJECT-TYPE 1074 SYNTAX Unsigned32 1075 MAX-ACCESS not-accessible 1076 STATUS current 1077 DESCRIPTION 1078 "The RTP SSRC, or synchronization source identifier, of the 1079 sender. The RTP Session Address plus an SSRC uniquely 1080 identify a sender or receiver of an RTP stream (see 'RTP: 1081 A Transport Protocol for Real-Time Applications' sec.3)." 1082 ::= { rtpSREntry 1 } 1084 rtpSRCNAME OBJECT-TYPE 1085 SYNTAX DisplayString 1086 MAX-ACCESS read-only 1087 STATUS current 1088 DESCRIPTION 1089 "The RTP canonical name of the sender." 1090 ::= { rtpSREntry 2 } 1092 rtpSRSentPackets OBJECT-TYPE 1093 SYNTAX Counter32 1094 MAX-ACCESS read-only 1095 STATUS current 1096 DESCRIPTION 1097 "Count of RTP packets sent by this sender since row creation 1098 as recorded in rtpSessionStartTime." 1099 ::= { rtpSREntry 3 } 1101 rtpSRSentOctets OBJECT-TYPE 1102 SYNTAX Counter32 1103 MAX-ACCESS read-only 1104 STATUS current 1105 DESCRIPTION 1106 "Count of octets sent by this sender since row creation 1107 as recorded in rtpSessionStartTime." 1108 ::= { rtpSREntry 4 } 1110 rtpSRTool OBJECT-TYPE 1111 SYNTAX DisplayString (SIZE(0..127)) 1112 MAX-ACCESS read-only 1113 STATUS current 1114 DESCRIPTION 1115 "Name of the application program source of the stream." 1116 DEFVAL { ''H } -- Null if not received in RTCP SDES 1117 ::= { rtpSREntry 5 } 1119 rtpSRs OBJECT-TYPE 1120 SYNTAX Counter32 1121 MAX-ACCESS read-only 1122 STATUS current 1123 DESCRIPTION 1124 "A count of the number of RTCP Sender Reports that have 1125 been received from this source since row creation as recorded 1126 in rtpSessionStartTime." 1127 ::= { rtpSREntry 6 } 1129 rtpSRLastSR OBJECT-TYPE 1130 SYNTAX TimeTicks 1131 MAX-ACCESS read-only 1132 STATUS current 1133 DESCRIPTION 1134 "The elapsed time, in units of hundredths of a second, 1135 since the last RTCP Sender Report was received from 1136 this sender." 1137 ::= { rtpSREntry 7 } 1139 -- 1140 -- RECEIVERS TABLE 1141 -- 1142 rtpRRTable OBJECT-TYPE 1143 SYNTAX SEQUENCE OF RtpRREntry 1144 MAX-ACCESS not-accessible 1145 STATUS current 1146 DESCRIPTION 1147 "Table of RTP Monitor information. Entries are created 1148 as a side-effect by the SNMP entity when a conceptual row in 1149 the rtpSessionTable becomes 'active'." 1150 ::= { rtpIS 3 } 1152 rtpRREntry OBJECT-TYPE 1153 SYNTAX RtpRREntry 1154 MAX-ACCESS not-accessible 1155 STATUS current 1156 DESCRIPTION 1157 "Each entry contains monitoring information from a single RTP 1158 Synchronization Source (SSRC) taken from RTCP Receiver Report 1159 (RR) messages sent by the receivers of an RTP Session (see 1160 'RTP: A Transport Protocol for Real-Time Applications', 3.0) 1161 The session is identified to the the SNMP entity by 1162 rtpSessionIndex." 1163 INDEX { rtpSessionIndex, rtpSRSSRC, rtpRRSSRC } 1164 ::= { rtpRRTable 1 } 1166 RtpRREntry ::= SEQUENCE { 1167 rtpRRSSRC Unsigned32, 1168 rtpRRCNAME DisplayString, 1169 rtpRRAddr TAddress, 1170 rtpRRFracLost Gauge32, 1171 rtpRRRTT Gauge32, 1172 rtpRRLostPackets Counter32, 1173 rtpRRJitter Gauge32, 1174 rtpRRs Counter32, 1175 rtpRRTool DisplayString, 1176 rtpRRLastRR TimeTicks 1177 } 1179 rtpRRSSRC OBJECT-TYPE 1180 SYNTAX Unsigned32 1181 MAX-ACCESS not-accessible 1182 STATUS current 1183 DESCRIPTION 1184 "The RTP SSRC, or synchronization source identifier, of the 1185 receiver. The RTP Session Address plus an SSRC uniquely 1186 identify a sender or receiver of an RTP stream (see 'RTP: 1187 A Transport Protocol for Real-Time Applications' sec.3)." 1188 ::= { rtpRREntry 1 } 1190 rtpRRCNAME OBJECT-TYPE 1191 SYNTAX DisplayString 1192 MAX-ACCESS read-only 1193 STATUS current 1194 DESCRIPTION 1195 "The RTP canonical name of the source of the RR." 1196 ::= { rtpRREntry 2 } 1198 rtpRRAddr OBJECT-TYPE 1199 SYNTAX TAddress 1200 MAX-ACCESS read-only 1201 STATUS current 1202 DESCRIPTION 1203 "The unicast transport-service address of the 1204 source of the RR." 1205 ::= { rtpRREntry 3 } 1207 rtpRRFracLost OBJECT-TYPE 1208 SYNTAX Gauge32 1209 MAX-ACCESS read-only 1210 STATUS current 1211 DESCRIPTION 1212 "The fraction of packets lost over the time as 1213 reported by the most recent RTCP RR." 1214 ::= { rtpRREntry 4 } 1216 rtpRRRTT OBJECT-TYPE 1217 SYNTAX Gauge32 1218 MAX-ACCESS read-only 1219 STATUS current 1220 DESCRIPTION 1221 "The round trip time measurement taken by the source of the 1222 RTP stream based on the algorithm described in sec. 6.3.1 of 1223 'RTP: A Transport Protocol for Real-Time Applications.' 1224 This algorithm can produce meaningful results when the 1225 monitor has the same clock as the stream sender. In all 1226 other cases the entity should return 'noSuchInstance' in 1227 response to queries against rtpRRRTT." 1228 ::= { rtpRREntry 5 } 1230 rtpRRLostPackets OBJECT-TYPE 1231 SYNTAX Counter32 1232 MAX-ACCESS read-only 1233 STATUS current 1234 DESCRIPTION 1235 "A count from the most recent RTCP Receiver Report of lost 1236 packets." 1237 ::= { rtpRREntry 6 } 1239 rtpRRJitter OBJECT-TYPE 1240 SYNTAX Gauge32 1241 MAX-ACCESS read-only 1242 STATUS current 1243 DESCRIPTION 1244 "An estimate by the SNMP entity of current delay variation 1245 of packets from the ingress stream (see 'RTP: A Transport 1246 Protocol for Real-Time Applications,' sec. 6.3.1)." 1247 ::= { rtpRREntry 7 } 1249 rtpRRTool OBJECT-TYPE 1250 SYNTAX DisplayString (SIZE(0..127)) 1251 MAX-ACCESS read-only 1252 STATUS current 1253 DESCRIPTION 1254 "Name of the application program source of the stream." 1255 DEFVAL { ''H } -- Null if not received in RTCP SDES 1256 ::= { rtpRREntry 8 } 1258 rtpRRs OBJECT-TYPE 1259 SYNTAX Counter32 1260 MAX-ACCESS read-only 1261 STATUS current 1262 DESCRIPTION 1263 "A count of Receiver Reports that have been received from 1264 this particular receiver since row creation 1265 (rtpSessionStartTime)." 1266 ::= { rtpRREntry 9 } 1268 rtpRRLastRR OBJECT-TYPE 1269 SYNTAX TimeTicks 1270 MAX-ACCESS read-only 1271 STATUS current 1272 DESCRIPTION 1273 "The elapsed time since the most recent RTCP Receiver 1274 Report was received from this receiver, expressed in 1275 units of hundredths of a second." 1276 ::= { rtpRREntry 10 } 1278 -- 1279 -- MODULE GROUPS 1280 -- 1281 rtpISGroup OBJECT-GROUP 1282 OBJECTS { 1283 rtpSessionNewIndex, 1284 rtpSessionAddr, 1285 rtpSessionDomain, 1286 rtpSessionIfAddr, 1287 rtpSessionIfIndex, 1288 rtpSessionSenders, 1289 rtpSessionReceivers, 1290 rtpSessionStartTime, 1291 rtpSessionRowStatus, 1292 rtpRRCNAME, 1293 rtpRRAddr, 1294 rtpRRFracLost, 1295 rtpRRRTT, 1296 rtpRRLostPackets, 1297 rtpRRJitter, 1298 rtpRRTool, 1299 rtpRRs, 1300 rtpRRLastRR, 1301 rtpSRCNAME, 1302 rtpSRSentPackets, 1303 rtpSRSentOctets, 1304 rtpSRTool, 1305 rtpSRs, 1306 rtpSRLastSR 1307 } 1308 STATUS current 1309 DESCRIPTION 1310 "Accessible objects used to define RTP sessions." 1311 ::= { rtpIS 9 } 1313 rtpISCompliance MODULE-COMPLIANCE 1314 STATUS current 1315 DESCRIPTION 1316 "The compliance statement for SNMP entities that implement 1317 an RTP monitor." 1318 MODULE RTP-IS 1319 MANDATORY-GROUPS { rtpISGroup } 1320 ::= { rtpIS 10 } 1321 END 1322 6. Security Issues 1324 In most cases, MIBs are not themselves security risks; if SNMP security 1325 is operating as intended, the use of a MIB to view information about a 1326 system, or to change some parameter at the system, is a tool, not a 1327 threat. 1329 None of the read-only objects in this MIB reports a password, though 1330 some SDES items such as the CNAME, the canonical name, may be deemed 1331 sensitive depending on the particular security policies of a particular 1332 enterprise. If access to these objects is not limited by an 1333 appropriate access control policy, these objects can provide an attacker 1334 with information about a system's configuration and the services that 1335 that system is providing. Some enterprises view their network and 1336 system configurations themselves, as well as information about usage and 1337 performance, as corporate assets; such enterprises may wish to restrict 1338 SNMP access to most of the objects in the MIB. 1340 This MIB supports read-write operations against rtpSessionNewIndex which 1341 has the side effect of creating an entry in the rtpSessionTable when it 1342 is written to. Three objects in rtpSessionEntry have read-create access: 1343 rtpSessionAddr, rtpSessionIfIndex and rtpSessionIfAddr identify an RTP 1344 Session to be monitored on a particular monitor interface. The values 1345 of these objects are not to be changed once created, and initialization 1346 of these objects affects only the monitoring of an RTP Session and 1347 not the operation of an RTP Session on any host end-system. Since 1348 write operations to rtpSessionNewIndex and the three objects in 1349 rtpSessionEntry affect the operation of the monitor, write access 1350 to these objects should be subject to the appropriate access control 1351 policy. 1353 Confidentiality of RTP and RTCP data packets is defined in section 9 of 1354 the RTP specification [1]. Encryption may be performed on RTP packets, 1355 RTCP packets, or both. Encryption of RTCP packets may pose a problem 1356 for third-party monitors though "For RTCP, it is allowed to split a 1357 compound RTCP packet into two lower-layer packets, one to be encrypted 1358 and one to be sent in the clear. For example, SDES information might 1359 be encrypted while reception reports were sent in the clear to 1360 accommodate third-party monitors [1]." 1362 7. Acknowledgements 1364 Alan Batie, Bill Strahm and Lenitra Clay developed RTP monitors 1365 having SNMP interfaces on FreeBSD and Windows NT. Bill Strahm 1366 developed the SNMP interface to Intel's RTP implementation. Bill 1367 Lewis developed an RTP management application. 1369 9. References 1371 [1] H. Shulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 1372 A Transport Protocol for real-time applications," RFC 1889. 1374 [2] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, 1375 "Structure of Management Information for Version 2 1376 of the Simple Network Management Protocol (SNMPv2)", 1377 RFC 1902, January, 1996. 1379 [3] Information processing systems -- Open Systems 1380 Interconnection -- Specification of Basic Encoding Rules 1381 for Abstract Notation One (ASN.1), International 1382 Organization for Standardization. International Standard 1383 8825, (December, 1987). 1385 [4] M.Daniele, B. Wijnen, D. Francisco, "Agent Extensibility 1386 (AgentX) Protocol, Version 1", work in progress, 1387 , November, 1996.