idnits 2.17.1 draft-ietf-avt-rtp-mib-02.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-27) 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 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** There is 1 instance 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 551: '... MUST initialize this to 'fal...' RFC 2119 keyword, line 552: '...1)' and RTP Hosts MUST initialize this...' RFC 2119 keyword, line 565: '...tReady' or 'notInService' state MAY be...' RFC 2119 keyword, line 578: '...s for RTP sending hosts MUST create an...' RFC 2119 keyword, line 978: '...he objects in the rtpHostGroup MUST be...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 349 has weird spacing: '... "This objec...' == Line 350 has weird spacing: '...onIndex as de...' == Line 351 has weird spacing: '...entions for ...' == Line 352 has weird spacing: '...em, the netwo...' == Line 353 has weird spacing: '... the objec...' == (3 more instances...) -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: rtpCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The management information of the objects in the rtpISGroup is taken from the IP, UDP, RTP headers and the required RTCP messages that are specified in RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications', 6.4. rtpRcvrTool and rtpSenderTool are not required fields in the RTCP SDES message so a DEFVAL is provided for these objects." MODULE RTP MANDATORY-GROUPS { rtpSystemGroup } GROUP rtpHostGroup DESCRIPTION "The objects in the rtpHostGroup MUST be implemented in RTP Host systems that are the source or the destination of RTP data packets." GROUP rtpMonitorGroup DESCRIPTION "The objects in the rtpMonitorGroup MUST be implemented in RTP monitors." OBJECT rtpSessionNewIndex MIN-ACCESS not-accessible DESCRIPTION "RTP host system implementations MAY NOT support row creation and deletion." OBJECT rtpSessionDomain MIN-ACCESS read-only DESCRIPTION "RTP host system implementations MAY NOT support row creation and deletion." OBJECT rtpSessionRemAddr MIN-ACCESS read-only DESCRIPTION "RTP host system implementations MAY NOT support row creation and deletion." == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: OBJECT rtpSessionIfIndex MIN-ACCESS read-only DESCRIPTION "RTP host system implementations MAY NOT support row creation and deletion." OBJECT rtpSessionIfAddr MIN-ACCESS read-only DESCRIPTION "RTP host system implementations MAY NOT support row creation and deletion." OBJECT rtpSessionRowStatus MIN-ACCESS not-accessible DESCRIPTION "RTP host system implementations MAY NOT support row creation and deletion." OBJECT rtpSessionLocAddr MIN-ACCESS not-accessible DESCRIPTION "RTP monitor system implementations MAY NOT source RTP or RTCP data packets." OBJECT rtpRcvrPT MIN-ACCESS not-accessible DESCRIPTION "RTP monitor system implementations MAY NOT support retrieval of the RTP Payload Type from the RTP header (and may receive RTCP messages only). When queried for the payload type information, the sub-agent MAY return 'noSuchObject'." OBJECT rtpSenderPT MIN-ACCESS not-accessible DESCRIPTION "RTP monitor system implementations MAY NOT support retrieval of the RTP Payload Type from the RTP header (and may receive RTCP messages only). When queried for the payload type information, the sub-agent MAY return 'noSuchObject'." OBJECT rtpRcvrRTT MIN-ACCESS not-accessible DESCRIPTION "The round-trip time calculation presented on sec. 6 of RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications', may be accurately computed by a monitor that uses the same clock as a particular sender. In other cases, the monitor SHOULD return 'noSuchObject' in response to a Get that references rtpRcvrRTT." == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: OBJECT rtpRcvrLostOctets MIN-ACCESS not-accessible DESCRIPTION "RTP monitor system implementations MAY NOT support monitoring of this object when rtpSessionMonitor is 'true' since it is not obtainable from RTCP reports." OBJECT rtpRcvrOctets MIN-ACCESS not-accessible DESCRIPTION "RTP monitor system implementations MAY NOT support monitoring of this object when rtpSessionMonitor is 'true' since it is not obtainable from RTCP reports." OBJECT rtpRcvrPackets MIN-ACCESS not-accessible DESCRIPTION "RTP monitor system implementations MAY NOT support monitoring of this object when rtpSessionMonitor is 'true' since it is not obtainable from RTCP reports." ::= { rtp 8 } END -- 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 (August 7, 1998) is 9395 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 1122 looks like a reference -- Missing reference section? '2' on line 1125 looks like a reference -- Missing reference section? '3' on line 1130 looks like a reference -- Missing reference section? '4' on line 1136 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft RTP MIB August 7, 1998 4 Real-Time Transport Protocol 5 Management Information Base 6 8 August 7, 1998 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@intel.com 24 Stan Naudus 25 3Com Corporation 26 2070 Chain Bridge Road 27 Vienna, Virginia 22182 29 Stan_Naudus@3Com.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 There is a large change introduced in this draft from the 54 previous draft: The tables for the RTP host and the 55 RTP monitor have been merged. The rtpInTable and rtpEgTable 56 have been removed and their objects are subsumed by the 57 rtpRcvrTable and rtpSenderTable, respectively. The rtpRRTable 58 and the rtpSRTable for RTP monitors are removed and their 59 objects are subsumed by the rtpRcvrTable and rtpSenderTable 60 respectively. rtpSessionMonitor has been added to the 61 rtpSessionTable to distinguish between sessions that are 62 being sourced or received by the local RTP System and sessions 63 that are being monitored by a third-party monitor or by a 64 local RTP System that may also be sending or receiving 65 RTP Session data. 67 For clarity an explicit address pair, rtpSessionLocAddr 68 and rtpSessionRemAddr have been added to the rtpSessionTable 69 to identify an RTP Session and replace the rtpEgDstAddr and 70 rtpInDstAddr objects. rtpSessionRemAddr replaces (renames) 71 rtpSessionAddr. Finally, rtpRRFracLost has been removed as an 72 object used by RTP monitors in favor of polling and computing 73 loss statistics in the network management application. 75 2. Abstract 77 This memo defines an experimental Management Information Base 78 (MIB) for use with network management protocols in 79 TCP/IP-based internets. In particular, it defines objects for 80 managing Real-Time Transport Protocol systems [1]. Comments 81 should be made to the IETF Audio/Video Transport Working Group 82 at rem-conf@es.net. 84 This memo does not specify a standard for the Internet 85 community. 87 3. The Network Management Framework 89 The SNMPv2 Network Management Framework consists of the 90 following major components: 92 RFC 1902 which defines the SMI, the mechanisms used for 93 describing and naming objects for the purpose of management. 95 RFC 1903 Textual Conventions for Version 2 of the Simple 96 Network Management Protocol (SNMPv2). 98 RFC 1904 Conformance Statements for Version 2 of the 99 Simple Network Management Protocol (SNMPv2). 101 RFC 1905 Protocol Operations for Version 2 of the 102 Simple Network Management Protocol (SNMPv2). 104 RFC 1906 Transport Mappings for Version 2 of the 105 Simple Network Management Protocol (SNMPv2). 107 RFC 1907 Management Information Base for Version 2 of 108 the Simple Network Management Protocol (SNMPv2). 110 RFC 1908 Coexistence between Version 1 and Version 2 of 111 the Internet-standard Network Management Framework. 113 The Framework permits new objects to be defined for the 114 purpose of experimentation and evaluation. 116 Managed objects are accessed via a virtual information store, 117 termed the Management Information Base or MIB. Within a given 118 MIB module, objects are defined using the SMI's OBJECT-TYPE 119 macro[2]. At a minimum, each object has a name, a syntax, an 120 access-level, and an implementation-status. 122 The name is an object identifier, an administratively assigned 123 name, which specifies an object type. The object type 124 together with an object instance serves to uniquely identify a 125 specific instantiation of the object. For human convenience, 126 we often use a textual string, termed the object descriptor, 127 to also refer to the object type. 129 The syntax of an object type defines the abstract data 130 structure corresponding to that object type. The ASN.1[3] 131 language is used for this purpose. However, RFC 1902 132 purposely restricts the ASN.1 constructs which may be used. 133 These restrictions are made for simplicity. 135 The access-level of an object type defines whether it makes 136 "protocol sense" to read and/or write the value of an instance 137 of the object type. (This access-level is independent of any 138 administrative authorization policy.) 140 The implementation-status of an object type indicates whether 141 the object is mandatory, optional, obsolete, or deprecated. 143 4. Overview 145 An "RTP System" may be a host end-system that runs an application 146 program that sends or receives RTP data packets, or it may be an 147 intermediate-system that forwards RTP packets. RTP Control 148 Protocol (RTCP) packets are sent by senders and receivers to 149 convey information about RTP packet transmission and reception [1]. 150 RTP monitors may collect RTCP information on senders and receivers 151 to and from an RTP host or intermediate-system. 153 4.1 Components 155 The RTP MIB is structured around "Session," "Receiver" and "Sender" 156 conceptual abstractions. 158 4.1.1 An "RTP Session" is the "...association of participants 159 communicating with RTP. For each participant, the session is 160 defined by a particular pair of destination transport addresses 161 (one network address plus a port pair for RTP and RTCP). The 162 destination transport addresses may be common for all participants, 163 as in the case of IP multicast, or may be different for each, as in 164 the case of individual unicast addresses plus a common port pair," 165 as defined in section 3 of [1]. 167 4.1.2 A "Sender" is identified within an RTP Session by a 32-bit numeric 168 "Synchronization Source," or "SSRC", value and is "...the source of a 169 stream of RTP packets" as defined in section 3 of [1]. The Sender is 170 also a source of RTCP Sender Report packets as specified in section 6 171 of [1]. 173 4.1.3 A "Receiver" of a "stream of RTP packets" can be a unicast or 174 multicast Receiver as described in 4.2.1, above. An RTP Receiver has 175 an SSRC value that is unique to the session. An RTP Receiver is a 176 source of RTCP Receiver Reports as specified in section 6 of [1]. 178 4.2 Textual Conventions 180 A new data type, InterfaceIndex, is introduced as a textual convention 181 in this MIB document. Textual conventions enhance the readability of 182 the specification and can ease comparison with other specifications 183 if appropriate. It should be noted that the introduction of the 184 textual conventions has no effect on either the syntax nor the 185 semantics of any managed objects. The use of these is merely an 186 artifact of the explanatory method used. Objects defined in terms of 187 one of these methods are always encoded by means of the rules that 188 define the primitive type. Hence, no changes to the SMI or the SNMP 189 are necessary to accommodate these textual conventions which are 190 adopted merely for the convenience of readers and writers. 192 4.3 Applicability of the MIB to RTP System Implementations 194 The RTP MIB may be used in two types of RTP implementations, RTP Host 195 Systems (end systems) and RTP Monitors, see section 3 of [1]. 196 Use of the RTP MIB for RTP Translators and Mixers, as defined in 197 section 7 of [1], is for further study. 199 4.3.1 RTP Host Systems are end-systems that may use the RTP MIB 200 to collect RTP Session and Stream data that the host is sending or 201 receiving; these data may be used by a network manager to detect and 202 diagnose faults that occur over the life time of an RTP Session as 203 in a "help-desk" scenario. 205 4.3.2 RTP Monitors of multicast RTP sessions may be third-party, or 206 may be located in an RTP intermediate-system or in the host. RTP 207 Monitors may use the RTP MIB to collect RTP Session and Stream 208 statistical data; these data may be used by a network manager for 209 capacity planning and other network-management purposes. An RTP 210 Monitor may use the RTP MIB to collect data to permit a network 211 manager to detect and diagnose faults in RTP sessions, or to permit 212 a network manger to configure its operation. 214 4.4 The Structure of the RTP MIB 216 There are three tables in the RTP MIB. The rtpSessionTable contains 217 objects that describe active sessions at the host, intermediate system, 218 or monitor. The rtpSenderTable contains information about senders 219 to the RTP Session. The rtpRcvrTable contains information about 220 receivers of RTP Session data. 222 For any particular RTP Session, the rtpSessionMonitor object indicates 223 whether information about remote senders or receivers to the RTP 224 Session are to be monitored. RTP Sessions are monitored by the 225 sub-agent that updates rtpSenderTable and rtpRcvrTable objects with 226 information from RTCP reports from remote senders or remote receivers 227 respectively. 229 rtpSessionNewIndex is a global object that permits a network-management 230 application to obtain a unique index for conceptual row creation 231 in the rtpSessionTable. In this way the SNMP Set operation may 232 be used to configure a monitor. 234 4.5 SNMP Implementations 236 An RTP System that runs either a single application or multiple 237 applications with a single management-entity may be a practical 238 configuration for monitoring, translating or mixing. Host end- 239 -systems are the vast majority of RTP implementations, however, 240 a "monolithic" solution may be inadequate if management of 241 RTP end-systems proves to be truly useful. The RTP MIB contains 242 tables that may be shared among RTP application programs that run 243 concurrently on the same device - as many or most do. Sharing 244 occurs on a table basis. 246 Table sharing may be a problem for SNMP management entities on some 247 host operting systems: All SNMP management requests are sent to UDP 248 Port 161, and an Application Programming Interface (API) is needed to 249 facilitate this sharing. The API is specific to the host operating 250 system, and there are solutions provided by host operating system 251 vendors and by independent software vendors. There is also a 252 standardization effort within the IETF to at least define a standard 253 system-interface protocol that may be implemented in an API to permit 254 multiple management entities to share the object name space[4]. Whether 255 or not independent RTP application programs can cooperatively and 256 concurrently support the RTP MIB is outside the scope of this draft 257 document and will depend upon the operating system in question. 259 5. Definitions 261 RTP DEFINITIONS ::= BEGIN 262 IMPORTS 263 Counter32, Gauge32, experimental, Integer32, 264 IpAddress, MODULE-IDENTITY, OBJECT-IDENTITY, 265 OBJECT-TYPE, Unsigned32 FROM SNMPv2-SMI 266 DisplayString, RowStatus, TAddress, 267 TDomain, TestAndIncr, TEXTUAL-CONVENTION, 268 TimeStamp, TruthValue FROM SNMPv2-TC 269 OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF; 271 rtp MODULE-IDENTITY 272 LAST-UPDATED "9807212000Z" 273 ORGANIZATION "IETF AVT Working Group" 274 CONTACT-INFO 275 "Mark Baugher 276 Postal: Intel Corporation 277 2111 NE 25th Avenue 278 Hillsboro, OR 97124 279 United States 280 Tel: +1 503 264 3849 281 Email: mbaugher@intel.com 283 John Du 284 Postal: Intel Corporation 285 2111 NE 25th Avenue 286 Hillsboro, OR 97124 287 United States 288 Tel: +1 503 264 0636 289 Email: John.Du@intel.com 291 Stan Naudus 292 Postal: 3Com Corporation 293 2070 Chain Bridge Road 294 Vienna, VA 295 United States 296 Tel: +1 703 848 7710 297 Email: Stan_Naudus@3Com.com" 298 DESCRIPTION 299 "The managed objects of RTP systems. The MIB is 300 structured around three types of information. 301 1. General information about RTP Sessions such 302 as the Session Address. 303 2. Information about RTP streams being sent to 304 an RTP Session by a particular source. 305 3. Information about RTP streams received on an 306 RTP Session by a particular receiver from a 307 particular sender. 309 There are two types of RTP Systems, RTP hosts and 310 RTP monitors. As described below, certain objects 311 are unique to a particular type of RTP System. An 312 RTP host may also function as an RTP monitor. 313 Refer to RFC 1889, 'RTP: A Transport Protocol for 314 Real-Time Applications,' section 3.0, for definitions." 315 ::= { experimental 77 } 317 InterfaceIndex ::= TEXTUAL-CONVENTION 318 STATUS current 319 DESCRIPTION 320 "The range of ifIndex. This is defined here since zero 321 is used to define an unnumbered interface." 322 SYNTAX Integer32 324 -- 325 -- OBJECTS 326 -- 327 rtpGlobals OBJECT IDENTIFIER ::= { rtp 1 } 329 rtpDomains OBJECT IDENTIFIER ::= { rtpGlobals 1 } 331 rtpUDPDomain OBJECT-IDENTITY 332 STATUS current 333 DESCRIPTION 334 "RTP over UDP transport domain over IPv4. This definition 335 uses the transport address type, snmpUDPAddress, which is 336 defined in SNMPv2-TM, 'Transport Mappings for Version 2 of 337 the Simple Network Management Protocol (SNMPv2)'." 338 REFERENCE "RFC 1906, sec. 2 " 339 ::= { rtpDomains 1 } 341 -- 342 -- SESSION TABLE 343 -- 344 rtpSessionNewIndex OBJECT-TYPE 345 SYNTAX TestAndIncr 346 MAX-ACCESS read-write 347 STATUS current 348 DESCRIPTION 349 "This object is used to assign values to 350 rtpSessionIndex as described in 'Textual 351 Conventions for SNMPv2'. For an RTP monitor 352 system, the network manager would read 353 the object, and then write the value back in 354 the Set that creates a new instance of 355 rtpSessionEntry. If the Set fails with the code 356 'inconsistentValue,' then the process must be 357 repeated; If the Set succeeds, then the object 358 is incremented, and the new instance is 359 created according to the manager's directions. 360 However, if the RTP system is not a monitor, only 361 the RTP sub-agent may create conceptual rows in the 362 RTP session table." 363 ::= { rtpGlobals 2 } 365 rtpSessionTable OBJECT-TYPE 366 SYNTAX SEQUENCE OF RtpSessionEntry 367 MAX-ACCESS not-accessible 368 STATUS current 369 DESCRIPTION 370 "There's one entry in the SessionTable for each RTP Session 371 on which packets are being sent, received, and/or 372 monitored." 373 ::= { rtp 2 } 375 rtpSessionEntry OBJECT-TYPE 376 SYNTAX RtpSessionEntry 377 MAX-ACCESS not-accessible 378 STATUS current 379 DESCRIPTION 380 "Data in rtpSessionTable uniquely identify an RTP 381 Session. A host sub-agent will create a read-only row for 382 each session to which packets are being sent or received. 383 An RTP Session can be monitored to create management 384 information on all RTP streams being sent or received when 385 the rtpSessionMonitor has the TruthValue of 'true(1)'. A 386 monitor sub-agent may permit row creation with the side 387 effect of causing the RTP System to join the session for 388 the purposes of gathering management information (thus 389 additional conceptual rows are created in the rtpRcvrTable 390 and rtpSenderTable). rtpSessionTable rows can be created for 391 RTP Session monitoring purposes. Rows created by a 392 management application may be deleted via SNMP operations." 393 INDEX { rtpSessionIndex } 394 ::= { rtpSessionTable 1 } 396 RtpSessionEntry ::= SEQUENCE { 397 rtpSessionIndex Integer32, 398 rtpSessionDomain TDomain, 399 rtpSessionRemAddr TAddress, 400 rtpSessionLocAddr TAddress, 401 rtpSessionIfIndex InterfaceIndex, 402 rtpSessionIfAddr IpAddress, 403 rtpSessionSenders Counter32, 404 rtpSessionReceivers Counter32, 405 rtpSessionByes Counter32, 406 rtpSessionStartTime TimeStamp, 407 rtpSessionMonitor TruthValue, 408 rtpSessionRowStatus RowStatus 409 } 411 rtpSessionIndex OBJECT-TYPE 412 SYNTAX Integer32 (1..65535) 413 MAX-ACCESS not-accessible 414 STATUS current 415 DESCRIPTION 416 "The index of the conceptual row which is for SNMP purposes 417 only and has no relation to any protocol value." 418 ::= { rtpSessionEntry 1} 420 rtpSessionDomain OBJECT-TYPE 421 SYNTAX TDomain 422 MAX-ACCESS read-create 423 STATUS current 424 DESCRIPTION 425 "The transport-layer protocol used for sending or receiving 426 the stream of RTP data packets on this session. 427 Cannot be changed after rtpSessionRowStatus is 'active'." 428 DEFVAL { rtpUDPDomain } 429 ::= { rtpSessionEntry 2 } 431 rtpSessionRemAddr OBJECT-TYPE 432 SYNTAX TAddress 433 MAX-ACCESS read-create 434 STATUS current 435 DESCRIPTION 436 "The remote destination transport address on which the stream 437 of RTP data packets is being sent and/or received. An RTP 438 Session is defined by a pair of destination transport 439 addresses. 'The destination address pair may be common for 440 all participants, as in the case of IP multicast, or may be 441 different for each, as in the case of individual unicast 442 network address pairs.' See RFC 1889, 'RTP: A Transport 443 Protocol for Real-Time Applications, sec. 3. The transport 444 service is identified by rtpSessionDomain. For rtpUDPDomain, 445 this is an IP address and an even-numbered UDP Port with the 446 RTCP being sent on the next higher odd-numbered port, see 447 RFC 1889, sec. 5. Cannot be changed after rtpSessionRowStatus 448 is 'active'." 449 ::= { rtpSessionEntry 3 } 451 rtpSessionLocAddr OBJECT-TYPE 452 SYNTAX TAddress 453 MAX-ACCESS read-only 454 STATUS current 455 DESCRIPTION 456 "The local destination transport address on which the stream 457 of data packets is being sent and/or received. For unicast 458 RTP Sessions, this is the local address of the 459 RTP Session. For IP multicast RTP Sessions, this object should 460 have the same value as rtpSessionRemoteAddr. See RFC 1889, 461 'RTP: A Transport Protocol for Real-Time Applications, sec. 462 3. The transport service is identified by rtpSessionDomain. 463 For rtpUDPDomain, this is an IP address and an even-numbered 464 UDP Port with the RTCP being sent on the next higher 465 odd-numbered port, see RFC 1889, sec. 5." 466 ::= { rtpSessionEntry 4 } 468 rtpSessionIfIndex OBJECT-TYPE 469 SYNTAX InterfaceIndex 470 MAX-ACCESS read-create 471 STATUS current 472 DESCRIPTION 473 "The ifIndex value is zero for interfaces that have an IP 474 address defined for the interface on which RTP data packets 475 are sent or received for this session. Otherwise this object 476 is set to the corresponding value from the Internet Standard 477 MIB. Cannot be changed after rtpSessionRowStatus is 478 'active'. A zero value for both rtpSessionIfIndex and 479 rtpSessionIfAddr indicates that the default interface be 480 used." 481 DEFVAL { 0 } 482 ::= { rtpSessionEntry 5 } 484 rtpSessionIfAddr OBJECT-TYPE 485 SYNTAX IpAddress 486 MAX-ACCESS read-create 487 STATUS current 488 DESCRIPTION 489 "The IP Address of the interface on which the stream of RTP 490 data packets is being sent and/or received for interfaces that 491 have an IP Address. If rtpSessionIfIndex is non-zero, this 492 object should have the value 0.0.0.0. Cannot be changed after 493 rtpSessionRowStatus has become 'active'. A zero 494 value for both rtpSessionIfIndex and rtpSessionIfAddr 495 indicates that the default interface be used." 496 DEFVAL { 0 } 497 ::= { rtpSessionEntry 6 } 499 rtpSessionSenders OBJECT-TYPE 500 SYNTAX Counter32 501 MAX-ACCESS read-only 502 STATUS current 503 DESCRIPTION 504 "The maximum number of senders observed by 505 the monitor since this conceptual row was created 506 (rtpSessionStartTime). Senders that leave and then 507 re-join following an RTCP BYE (See RFC 1889, 'RTP: A 508 Transport Protocol for Real-Time Applications,' sec. 6.6) 509 or session timeout may be counted twice." 510 ::= { rtpSessionEntry 7 } 512 rtpSessionReceivers OBJECT-TYPE 513 SYNTAX Counter32 514 MAX-ACCESS read-only 515 STATUS current 516 DESCRIPTION 517 "The maximum number of receivers that are 518 observed since this conceptual row was created 519 (rtpSessionStartTime). Receivers that leave and then re-join 520 following an RTCP BYE (See RFC 1889, 'RTP: A Transport 521 Protocol for Real-Time Applications,' sec. 6.6)or session 522 timeout may be counted twice." 523 ::= { rtpSessionEntry 8 } 525 rtpSessionByes OBJECT-TYPE 526 SYNTAX Counter32 527 MAX-ACCESS read-only 528 STATUS current 529 DESCRIPTION 530 "A count of RTCP BYE (See RFC 1889, 'RTP: A Transport 531 Protocol for Real-Time Applications,' sec. 6.6) messages 532 received by this entity." 533 ::= { rtpSessionEntry 9 } 535 rtpSessionStartTime OBJECT-TYPE 536 SYNTAX TimeStamp 537 MAX-ACCESS read-only 538 STATUS current 539 DESCRIPTION 540 "The value of SysUpTime at the time that this row was 541 created." 542 ::= { rtpSessionEntry 10 } 544 rtpSessionMonitor OBJECT-TYPE 545 SYNTAX TruthValue 546 MAX-ACCESS read-only 547 STATUS current 548 DESCRIPTION 549 "Boolean, Set to 'true(1)' if senders or receivers in addition 550 to the local RTP System are to be monitored. RTP Host Systems 551 MUST initialize this to 'false(2)'. RTP Monitors MUST 552 initialize to 'true(1)' and RTP Hosts MUST initialize this 553 'false(2)'." 554 ::= { rtpSessionEntry 11 } 556 rtpSessionRowStatus OBJECT-TYPE 557 SYNTAX RowStatus 558 MAX-ACCESS read-create 559 STATUS current 560 DESCRIPTION 561 "Value of 'active' when RTP or RTCP messages being sent or 562 received by an RTP System are being monitored. A manager- 563 created conceptual row must have the rtpSessionAddr initialized 564 by the manager before becoming 'active' A conceptual row that 565 is in the 'notReady' or 'notInService' state MAY be 566 removed after 5 minutes." 567 ::= { rtpSessionEntry 12 } 569 -- 570 -- SENDERS TABLE 571 -- 572 rtpSenderTable OBJECT-TYPE 573 SYNTAX SEQUENCE OF RtpSenderEntry 574 MAX-ACCESS not-accessible 575 STATUS current 576 DESCRIPTION 577 "Table of information about a sender or senders to an RTP 578 Session. Sub-agents for RTP sending hosts MUST create an 579 entry in this table for each stream being sent. Sub-agents 580 for RTP monitors create an entry for each observed RTP Session 581 sender as a side-effect when a conceptual row in the 582 rtpSessionTable is made 'active' by a manager." 583 ::= { rtp 3 } 585 rtpSenderEntry OBJECT-TYPE 586 SYNTAX RtpSenderEntry 587 MAX-ACCESS not-accessible 588 STATUS current 589 DESCRIPTION 590 "Each entry contains monitoring information from a single RTP 591 Synchronization Source (SSRC, see RFC 1889 'RTP: A Transport 592 Protocol for Real-Time Applications' sec.6). The session is 593 identified to the the SNMP entity by rtpSessionIndex." 594 INDEX { rtpSessionIndex, rtpSenderSSRC } 595 ::= { rtpSenderTable 1 } 597 RtpSenderEntry ::= SEQUENCE { 598 rtpSenderSSRC Unsigned32, 599 rtpSenderCNAME DisplayString, 600 rtpSenderAddr TAddress, 601 rtpSenderPackets Counter32, 602 rtpSenderOctets Counter32, 603 rtpSenderTool DisplayString, 604 rtpSenderSRs Counter32, 605 rtpSenderSRTime TimeStamp, 606 rtpSenderPT INTEGER, 607 rtpSenderStartTime TimeStamp 608 } 610 rtpSenderSSRC OBJECT-TYPE 611 SYNTAX Unsigned32 612 MAX-ACCESS not-accessible 613 STATUS current 614 DESCRIPTION 615 "The RTP SSRC, or synchronization source identifier of the 616 sender. The RTP Session Address plus an SSRC uniquely 617 identify a sender or receiver of an RTP stream (see RFC 1889, 618 'RTP: A Transport Protocol for Real-Time Applications' 619 sec.3)." 620 ::= { rtpSenderEntry 1 } 622 rtpSenderCNAME OBJECT-TYPE 623 SYNTAX DisplayString (SIZE(0..255)) 624 MAX-ACCESS read-only 625 STATUS current 626 DESCRIPTION 627 "The RTP canonical name of the sender." 628 ::= { rtpSenderEntry 2 } 630 rtpSenderAddr OBJECT-TYPE 631 SYNTAX TAddress 632 MAX-ACCESS read-only 633 STATUS current 634 DESCRIPTION 635 "The unicast transport source address of the sender." 636 ::= { rtpSenderEntry 3 } 638 rtpSenderPackets OBJECT-TYPE 639 SYNTAX Counter32 640 MAX-ACCESS read-only 641 STATUS current 642 DESCRIPTION 643 "Count of RTP packets sent by this sender, or observed by 644 an RTP monitor from RTCP Reports, since rtpSenderStartTime." 645 ::= { rtpSenderEntry 4 } 647 rtpSenderOctets OBJECT-TYPE 648 SYNTAX Counter32 649 MAX-ACCESS read-only 650 STATUS current 651 DESCRIPTION 652 "Count of RTP octets sent by this sender, or observed by 653 an RTP monitor from RTCP Reports, since rtpSenderStartTime." 654 ::= { rtpSenderEntry 5 } 656 rtpSenderTool OBJECT-TYPE 657 SYNTAX DisplayString (SIZE(0..127)) 658 MAX-ACCESS read-only 659 STATUS current 660 DESCRIPTION 661 "Name of the application program that's the stream source." 662 DEFVAL { ''H } -- Null if not available 663 ::= { rtpSenderEntry 6 } 665 rtpSenderSRs OBJECT-TYPE 666 SYNTAX Counter32 667 MAX-ACCESS read-only 668 STATUS current 669 DESCRIPTION 670 "A count of the number of RTCP Sender Reports that have 671 been sent from this sender, or observed if the RTP entity 672 is a monitor, since rtpSenderStartTime." 673 ::= { rtpSenderEntry 7 } 675 rtpSenderSRTime OBJECT-TYPE 676 SYNTAX TimeStamp 677 MAX-ACCESS read-only 678 STATUS current 679 DESCRIPTION 680 "The value is always zero if the source of the RTP Stream is 681 the local RTP System. Otherwise, rtpSenderSRTime is the 682 value of SysUpTime at the time that the last SR was received 683 from this sender, in the case of a monitor." 684 ::= { rtpSenderEntry 8 } 686 rtpSenderPT OBJECT-TYPE 687 SYNTAX INTEGER (0..127) 688 MAX-ACCESS read-only 689 STATUS current 690 DESCRIPTION 691 "Static or dynamic payload type from the RTP header (see RFC 692 1889, 'RTP: A Transport Protocol for Real-Time Applications' 693 sec. 5)." 694 ::= { rtpSenderEntry 9 } 696 rtpSenderStartTime OBJECT-TYPE 697 SYNTAX TimeStamp 698 MAX-ACCESS read-only 699 STATUS current 700 DESCRIPTION 701 "The value of SysUpTime at the time that this row was 702 created." 703 ::= { rtpSenderEntry 10 } 705 -- 706 -- RECEIVERS TABLE 707 -- 708 rtpRcvrTable OBJECT-TYPE 709 SYNTAX SEQUENCE OF RtpRcvrEntry 710 MAX-ACCESS not-accessible 711 STATUS current 712 DESCRIPTION 713 "Table of information about a receiver or receivers of RTP 714 Session data. Sub-agents for RTP hosts that receive RTP 715 Session packets create an entry in this table for that 716 receiver/sender pair Sub-agents for RTP monitors create an 717 entry for each observed RTP Session receiver as a side- 718 effect when a conceptual row in the rtpSessionTable is made 719 'active' by a manager." 720 ::= { rtp 4 } 722 rtpRcvrEntry OBJECT-TYPE 723 SYNTAX RtpRcvrEntry 724 MAX-ACCESS not-accessible 725 STATUS current 726 DESCRIPTION 727 "Each entry contains monitoring information from a single RTP 728 Synchronization Source (SSRC, see RFC 1889, 'RTP: A Transport 729 Protocol for Real-Time Applications' sec.6). The session is 730 identified to the the SNMP entity by rtpSessionIndex." 731 INDEX { rtpSessionIndex, rtpRcvrRemSSRC, rtpRcvrLocSSRC } 732 ::= { rtpRcvrTable 1 } 734 RtpRcvrEntry ::= SEQUENCE { 735 rtpRcvrRemSSRC Unsigned32, 736 rtpRcvrLocSSRC Unsigned32, 737 rtpRcvrCNAME DisplayString, 738 rtpRcvrAddr TAddress, 739 rtpRcvrRTT Gauge32, 740 rtpRcvrLostPackets Counter32, 741 rtpRcvrLostOctets Counter32, 742 rtpRcvrJitter Gauge32, 743 rtpRcvrTool DisplayString, 744 rtpRcvrRRs Counter32, 745 rtpRcvrRRTime TimeStamp, 746 rtpRcvrPT INTEGER, 747 rtpRcvrPackets Counter32, 748 rtpRcvrOctets Counter32, 749 rtpRcvrStartTime TimeStamp 750 } 752 rtpRcvrRemSSRC OBJECT-TYPE 753 SYNTAX Unsigned32 754 MAX-ACCESS not-accessible 755 STATUS current 756 DESCRIPTION 757 "The RTP SSRC, or synchronization source identifier of the 758 sender. The RTP Session Address plus an SSRC uniquely 759 identify a sender or receiver of an RTP stream (see RFC 760 1889, 'RTP: A Transport Protocol for Real-Time 761 Applications' sec.3)." 762 ::= { rtpRcvrEntry 1 } 764 rtpRcvrLocSSRC OBJECT-TYPE 765 SYNTAX Unsigned32 766 MAX-ACCESS not-accessible 767 STATUS current 768 DESCRIPTION 769 "The RTP SSRC, or synchronization source identifier of the. 770 receiver. The RTP Session Address plus an SSRC uniquely 771 identify a sender or receiver of an RTP stream (see RFC 772 1889, 'RTP: A Transport Protocol for Real-Time 773 Applications' sec.3)." 774 ::= { rtpRcvrEntry 2 } 776 rtpRcvrCNAME OBJECT-TYPE 777 SYNTAX DisplayString (SIZE(0..255)) 778 MAX-ACCESS read-only 779 STATUS current 780 DESCRIPTION 781 "The RTP canonical name of the receiver." 782 ::= { rtpRcvrEntry 3 } 784 rtpRcvrAddr OBJECT-TYPE 785 SYNTAX TAddress 786 MAX-ACCESS read-only 787 STATUS current 788 DESCRIPTION 789 "The unicast transport address of the receiver." 790 ::= { rtpRcvrEntry 4 } 792 rtpRcvrRTT OBJECT-TYPE 793 SYNTAX Gauge32 794 MAX-ACCESS read-only 795 STATUS current 796 DESCRIPTION 797 "The round trip time measurement taken by the source of the 798 RTP stream based on the algorithm described on sec. 6 of 799 RFC 1889, 'RTP: A Transport Protocol for Real-Time 800 Applications.' This algorithm can produce meaningful 801 results when the sub-agent has the same clock as the stream 802 sender (when the RTP monitor is also a sending host for the 803 particular reciever). Otherwise, the entity should return 804 'noSuchObject' in response to queries against rtpRcvrRTT." 805 ::= { rtpRcvrEntry 5 } 807 rtpRcvrLostPackets OBJECT-TYPE 808 SYNTAX Counter32 809 MAX-ACCESS read-only 810 STATUS current 811 DESCRIPTION 812 "A count of RTP packets lost as observed by this receiver 813 since rtpRcvrStartTime." 814 ::= { rtpRcvrEntry 6 } 816 rtpRcvrLostOctets OBJECT-TYPE 817 SYNTAX Counter32 818 MAX-ACCESS read-only 819 STATUS current 820 DESCRIPTION 821 "A count of RTP octets lost as observed by this receiver 822 since rtpRcvrStartTime." 823 ::= { rtpRcvrEntry 7 } 825 rtpRcvrJitter OBJECT-TYPE 826 SYNTAX Gauge32 827 MAX-ACCESS read-only 828 STATUS current 829 DESCRIPTION 830 "An estimate of delay variation as observed by this receiver." 831 ::= { rtpRcvrEntry 8 } 833 rtpRcvrTool OBJECT-TYPE 834 SYNTAX DisplayString (SIZE(0..127)) 835 MAX-ACCESS read-only 836 STATUS current 837 DESCRIPTION 838 "Name of the application program that's receiving the stream." 839 DEFVAL { ''H } -- Null if not available 840 ::= { rtpRcvrEntry 9 } 842 rtpRcvrRRs OBJECT-TYPE 843 SYNTAX Counter32 844 MAX-ACCESS read-only 845 STATUS current 846 DESCRIPTION 847 "A count of Receiver Reports as observed by this receiver 848 since rtpSessionStartTime." 849 ::= { rtpRcvrEntry 10 } 851 rtpRcvrRRTime OBJECT-TYPE 852 SYNTAX TimeStamp 853 MAX-ACCESS read-only 854 STATUS current 855 DESCRIPTION 856 "The value is always zero if the receiver of the RTP Stream 857 is the local RTP System. Otherwise, rtpRcvrRRTime is the 858 value of SysUpTime at the time that the last RTCP Receiver 859 Report was received from this receiver, in the case of a 860 monitor, or sent by this receiver, in the case of a receiving 861 host." 862 ::= { rtpRcvrEntry 11 } 864 rtpRcvrPT OBJECT-TYPE 865 SYNTAX INTEGER (0..127) 866 MAX-ACCESS read-only 867 STATUS current 868 DESCRIPTION 869 "Static or dynamic payload type from the RTP header (see RFC 870 1889, 'RTP: A Transport Protocol for Real-Time Applications' 871 sec. 5)." 872 ::= { rtpRcvrEntry 12 } 874 rtpRcvrPackets OBJECT-TYPE 875 SYNTAX Counter32 876 MAX-ACCESS read-only 877 STATUS current 878 DESCRIPTION 879 "Count of RTP packets received by this RTP host receiver since 880 rtpRcvrStartTime. RTP Sessions being monitored ('true(1)' 881 value for rtpSessionMonitor) may not have this information." 882 ::= { rtpRcvrEntry 13 } 884 rtpRcvrOctets OBJECT-TYPE 885 SYNTAX Counter32 886 MAX-ACCESS read-only 887 STATUS current 888 DESCRIPTION 889 "Count of RTP octets received by this receiving RTP host 890 since rtpRcvrStartTime. Monitored sessions (rtpSessionMonitor 891 is 'false') may not have this information." 892 ::= { rtpRcvrEntry 14 } 894 rtpRcvrStartTime OBJECT-TYPE 895 SYNTAX TimeStamp 896 MAX-ACCESS read-only 897 STATUS current 898 DESCRIPTION 899 "The value of SysUpTime at the time that this row was 900 created." 901 ::= { rtpRcvrEntry 15 } 903 -- 904 -- MODULE GROUPS 905 -- 906 rtpSystemGroup OBJECT-GROUP 907 OBJECTS { 908 rtpSessionDomain, 909 rtpSessionRemAddr, 910 rtpSessionIfIndex, 911 rtpSessionIfAddr, 912 rtpSessionSenders, 913 rtpSessionReceivers, 914 rtpSessionStartTime, 915 rtpSessionRowStatus, 916 rtpSessionByes, 917 rtpSessionMonitor, 918 rtpSenderCNAME, 919 rtpSenderAddr, 920 rtpSenderPackets, 921 rtpSenderOctets, 922 rtpSenderTool, 923 rtpSenderSRs, 924 rtpSenderSRTime, 925 rtpSenderStartTime, 926 rtpRcvrCNAME, 927 rtpRcvrAddr, 928 rtpRcvrLostPackets, 929 rtpRcvrJitter, 930 rtpRcvrTool, 931 rtpRcvrRRs, 932 rtpRcvrRRTime, 933 rtpRcvrStartTime 934 } 935 STATUS current 936 DESCRIPTION 937 "Objects used by all RTP systems." 938 ::= { rtp 5 } 940 rtpHostGroup OBJECT-GROUP 941 OBJECTS { 942 rtpSessionLocAddr, 943 rtpSenderPT, 944 rtpRcvrPT, 945 rtpRcvrRTT, 946 rtpRcvrLostOctets, 947 rtpRcvrOctets, 948 rtpRcvrPackets 949 } 950 STATUS current 951 DESCRIPTION 952 "Objects used by RTP host systems." 953 ::= { rtp 6 } 955 rtpMonitorGroup OBJECT-GROUP 956 OBJECTS { 957 rtpSessionNewIndex 958 } 959 STATUS current 960 DESCRIPTION 961 "Objects used by RTP monitor systems." 962 ::= { rtp 7 } 964 rtpCompliance MODULE-COMPLIANCE 965 STATUS current 966 DESCRIPTION 967 "The management information of the objects in the 968 rtpISGroup is taken from the IP, UDP, RTP headers 969 and the required RTCP messages that are specified 970 in RFC 1889, 'RTP: A Transport Protocol for Real-Time 971 Applications', 6.4. rtpRcvrTool and rtpSenderTool are 972 not required fields in the RTCP SDES message so 973 a DEFVAL is provided for these objects." 974 MODULE RTP 975 MANDATORY-GROUPS { rtpSystemGroup } 976 GROUP rtpHostGroup 977 DESCRIPTION 978 "The objects in the rtpHostGroup MUST be 979 implemented in RTP Host systems that are the source 980 or the destination of RTP data packets." 981 GROUP rtpMonitorGroup 982 DESCRIPTION 983 "The objects in the rtpMonitorGroup MUST be 984 implemented in RTP monitors." 985 OBJECT rtpSessionNewIndex 986 MIN-ACCESS not-accessible 987 DESCRIPTION 988 "RTP host system implementations MAY NOT support 989 row creation and deletion." 990 OBJECT rtpSessionDomain 991 MIN-ACCESS read-only 992 DESCRIPTION 993 "RTP host system implementations MAY NOT support 994 row creation and deletion." 995 OBJECT rtpSessionRemAddr 996 MIN-ACCESS read-only 997 DESCRIPTION 998 "RTP host system implementations MAY NOT support 999 row creation and deletion." 1001 OBJECT rtpSessionIfIndex 1002 MIN-ACCESS read-only 1003 DESCRIPTION 1004 "RTP host system implementations MAY NOT support 1005 row creation and deletion." 1006 OBJECT rtpSessionIfAddr 1007 MIN-ACCESS read-only 1008 DESCRIPTION 1009 "RTP host system implementations MAY NOT support 1010 row creation and deletion." 1011 OBJECT rtpSessionRowStatus 1012 MIN-ACCESS not-accessible 1013 DESCRIPTION 1014 "RTP host system implementations MAY NOT support 1015 row creation and deletion." 1016 OBJECT rtpSessionLocAddr 1017 MIN-ACCESS not-accessible 1018 DESCRIPTION 1019 "RTP monitor system implementations MAY NOT source 1020 RTP or RTCP data packets." 1021 OBJECT rtpRcvrPT 1022 MIN-ACCESS not-accessible 1023 DESCRIPTION 1024 "RTP monitor system implementations MAY NOT support 1025 retrieval of the RTP Payload Type from the RTP 1026 header (and may receive RTCP messages only). When 1027 queried for the payload type information, the 1028 sub-agent MAY return 'noSuchObject'." 1029 OBJECT rtpSenderPT 1030 MIN-ACCESS not-accessible 1031 DESCRIPTION 1032 "RTP monitor system implementations MAY NOT support 1033 retrieval of the RTP Payload Type from the RTP 1034 header (and may receive RTCP messages only). When 1035 queried for the payload type information, the 1036 sub-agent MAY return 'noSuchObject'." 1037 OBJECT rtpRcvrRTT 1038 MIN-ACCESS not-accessible 1039 DESCRIPTION 1040 "The round-trip time calculation presented 1041 on sec. 6 of RFC 1889, 'RTP: A Transport 1042 Protocol for Real-Time Applications', may 1043 be accurately computed by a monitor that uses 1044 the same clock as a particular sender. In other 1045 cases, the monitor SHOULD return 'noSuchObject' 1046 in response to a Get that references rtpRcvrRTT." 1048 OBJECT rtpRcvrLostOctets 1049 MIN-ACCESS not-accessible 1050 DESCRIPTION 1051 "RTP monitor system implementations MAY NOT support 1052 monitoring of this object when rtpSessionMonitor is 1053 'true' since it is not obtainable from RTCP reports." 1054 OBJECT rtpRcvrOctets 1055 MIN-ACCESS not-accessible 1056 DESCRIPTION 1057 "RTP monitor system implementations MAY NOT support 1058 monitoring of this object when rtpSessionMonitor is 1059 'true' since it is not obtainable from RTCP reports." 1060 OBJECT rtpRcvrPackets 1061 MIN-ACCESS not-accessible 1062 DESCRIPTION 1063 "RTP monitor system implementations MAY NOT support 1064 monitoring of this object when rtpSessionMonitor is 1065 'true' since it is not obtainable from RTCP reports." 1066 ::= { rtp 8 } 1067 END 1069 6. Security Issues 1071 In most cases, MIBs are not themselves security risks; if SNMP security 1072 is operating as intended, the use of a MIB to view information about a 1073 system, or to change some parameter at the system, is a tool, not a 1074 threat. 1076 None of the read-only objects in this MIB reports a password, though 1077 some SDES items such as the CNAME, the canonical name, may be deemed 1078 sensitive depending on the security policies of a particular 1079 enterprise. If access to these objects is not limited by an 1080 appropriate access control policy, these objects can provide an 1081 attacker with information about a system's configuration and the 1082 services that that system is providing. Some enterprises view their 1083 network and system configurations themselves, as well as information 1084 about usage and performance, as corporate assets; such enterprises may 1085 wish to restrict SNMP access to most of the objects in the MIB. 1087 This MIB supports read-write operations against rtpSessionNewIndex which 1088 has the side effect of creating an entry in the rtpSessionTable when it 1089 is written to. Five objects in rtpSessionEntry have read-create access: 1090 rtpSessionDomain, rtpSessionRemAddr, rtpSessionIfIndex, 1091 rtpSessionRowStatus rtpSessionIfAddr identify an RTP Session to be 1092 monitored on a particular interface. The values of these objects are 1093 not to be changed once created, and initialization of these objects 1094 affects only the monitoring of an RTP Session and not the operation of 1095 an RTP Session on any host end-system. Since write operations to 1096 rtpSessionNewIndex and the five objects in rtpSessionEntry affect the 1097 operation of the monitor, write access to these objects should be 1098 subject to the appropriate access control policy. 1100 Confidentiality of RTP and RTCP data packets is defined in section 9 of 1101 the RTP specification [1]. Encryption may be performed on RTP packets, 1102 RTCP packets, or both. Encryption of RTCP packets may pose a problem 1103 for third-party monitors though "For RTCP, it is allowed to split a 1104 compound RTCP packet into two lower-layer packets, one to be encrypted 1105 and one to be sent in the clear. For example, SDES information might 1106 be encrypted while reception reports were sent in the clear to 1107 accommodate third-party monitors [1]." 1108 7. Acknowledgements 1110 George Kajos and Irina Suconick from Videoserver recommended some 1111 changes in the structure and organization of the RTP MIB that are 1112 contained in this draft. Boris Bekkerman from 3Com identified 1113 some problems in clarity and consistency of RTP MIB definitions. 1114 Alan Batie and Bill Strahm from Intel have prototyped SNMP RTP 1115 Monitors on FreeBSD and Windows NT, respectively. The Windows 1116 implementation is being used at Intel. Bill Lewis from Intel 1117 has written an RTP management application that is available in 1118 binary form with the FreeBSD version of the SNMP RTP Monitor. 1120 9. References 1122 [1] H. Shulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 1123 A Transport Protocol for real-time applications," RFC 1889. 1125 [2] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, 1126 "Structure of Management Information for Version 2 1127 of the Simple Network Management Protocol (SNMPv2)", 1128 RFC 1902, January, 1996. 1130 [3] Information processing systems -- Open Systems 1131 Interconnection -- Specification of Basic Encoding Rules 1132 for Abstract Notation One (ASN.1), International 1133 Organization for Standardization. International Standard 1134 8825, (December, 1987). 1136 [4] M.Daniele, B. Wijnen, D. Francisco, "Agent Extensibility 1137 (AgentX) Protocol, Version 1," RFC 2257, January 1998.