File: rfc2959.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1739 lines) | stat: -rw-r--r-- 62,063 bytes parent folder | download | duplicates (8)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739






Network Working Group                                        M. Baugher
Request for Comments: 2959                                    B. Strahm
Category: Standards Track                                   Intel Corp.
                                                            I. Suconick
                                                      VideoServer Corp.
                                                           October 2000


                      Real-Time Transport Protocol
                      Management Information Base

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it defines objects for managing Real-Time Transport
   Protocol (RTP) systems (RFC1889).

Table of Contents

   1. The Network Management Framework .............................  2
   2. Overview .....................................................  3
   2.1 Components ..................................................  3
   2.2 Applicability of the MIB to RTP System Implementations ......  4
   2.3 The Structure of the RTP MIB ................................  4
   3 Definitions ...................................................  5
   4. Security Considerations ...................................... 26
   5. Acknowledgements ............................................. 27
   6. Intellectual Property ........................................ 27
   7. References ................................................... 28
   8. Authors' Addresses ........................................... 30
   9. Full Copyright Statement ..................................... 31







Baugher, et al.             Standards Track                     [Page 1]

RFC 2959                        RTP MIB                     October 2000


1.  The SNMP Management Framework

   The SNMP Management Framework presently consists of five major
   components:

      o  An overall architecture, described in RFC 2571 [RFC2571].

      o  Mechanisms for describing and naming objects and events for the
         purpose of management.  The first version of this Structure of
         Management Information (SMI) is called SMIv1 and described in
         STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
         1215 [RFC1215].  The second version, called SMIv2, is described
         in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580
         [RFC2580].

      o  Message protocols for transferring management information.  The
         first version of the SNMP message protocol is called SNMPv1 and
         described in STD 15, RFC 1157 [RFC1157].  A second version of
         the SNMP message protocol, which is not an Internet standards
         track protocol, is called SNMPv2c and described in RFC 1901
         [RFC1901] and RFC 1906 [RFC1906].  The third version of the
         message protocol is called SNMPv3 and described in RFC 1906
         [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].

      o  Protocol operations for accessing management information.  The
         first set of protocol operations and associated PDU formats is
         described in STD 15, RFC 1157 [RFC1157].  A second set of
         protocol operations and associated PDU formats is described in
         RFC 1905 [RFC1905].

      o  A set of fundamental applications described in RFC 2573
         [RFC2573] and the view-based access control mechanism described
         in RFC 2575 [RFC2575].

   A more detailed introduction to the current SNMP Management Framework
   can be found in RFC 2570 [RFC2570].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  Objects in the MIB are
   defined using the mechanisms defined in the SMI.

   This memo specifies a MIB module that is compliant to the SMIv2.  A
   MIB conforming to the SMIv1 can be produced through the appropriate
   translations.  The resulting translated MIB must be semantically
   equivalent, except where objects or events are omitted because no
   translation is possible (use of Counter64).  Some machine readable





Baugher, et al.             Standards Track                     [Page 2]

RFC 2959                        RTP MIB                     October 2000


   information in SMIv2 will be converted into textual descriptions in
   SMIv1 during the translation process.  However, this loss of machine
   readable information is not considered to change the semantics of the
   MIB.

2. Overview

   An "RTP System" may be a host end-system that runs an application
   program that sends or receives RTP data packets, or it may be an
   intermediate-system that forwards RTP packets.  RTP Control Protocol
   (RTCP) packets are sent by senders and receivers to convey
   information about RTP packet transmission and reception [RFC1889].
   RTP monitors may collect RTCP information on senders and receivers to
   and from an RTP host or intermediate-system.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.

2.1 Components

   The RTP MIB is structured around "Session," "Receiver" and "Sender"
   conceptual abstractions.

   2.1.1  An "RTP Session" is the "...association of participants
   communicating with RTP.  For each participant, the session is defined
   by a particular pair of destination transport addresses (one network
   address plus a port pair for RTP and RTCP).  The destination
   transport addresses may be common for all participants, as in the
   case of IP multicast, or may be different for each, as in the case of
   individual unicast addresses plus a common port pair," as defined in
   section 3 of [RFC1889].

   2.1.2 A "Sender" is identified within an RTP session by a 32-bit
   numeric "Synchronization Source," or "SSRC", value and is "...the
   source of a stream of RTP packets" as defined in section 3 of
   [RFC1889].  The sender is also a source of RTCP Sender Report packets
   as specified in section 6 of [RFC1889].

   2.1.3 A "Receiver" of a "stream of RTP packets" can be a unicast or
   multicast Receiver as described in 2.1.1, above.  An RTP Receiver has
   an SSRC value that is unique to the session.  An RTP Receiver is a
   source of RTCP Receiver Reports as specified in section 6 of
   [RFC1889].







Baugher, et al.             Standards Track                     [Page 3]

RFC 2959                        RTP MIB                     October 2000


2.2 Applicability of the MIB to RTP System Implementations

   The RTP MIB may be used in two types of RTP implementations, RTP Host
   Systems (end systems) and RTP Monitors, see section 3 of [RFC1889].
   Use of the RTP MIB for RTP Translators and Mixers, as defined in
   section 7 of [RFC1889], is for further study.

   2.2.1 RTP host Systems are end-systems that may use the RTP MIB to
   collect RTP session and stream data that the host is sending or
   receiving; these data may be used by a network manager to detect and
   diagnose faults that occur over the lifetime of an RTP session as in
   a "help-desk" scenario.

   2.2.2 RTP Monitors of multicast RTP sessions may be third-party or
   may be located in the RTP host.  RTP Monitors may use the RTP MIB to
   collect RTP session and stream statistical data; these data may be
   used by a network manager for capacity planning and other network-
   management purposes.  An RTP Monitor may use the RTP MIB to collect
   data to permit a network manager to detect and diagnose faults in RTP
   sessions or to permit a network manger to configure its operation.

   2.2.3 Many host systems will want to keep track of streams beyond
   what they are sending and receiving.  In a host monitor system, a
   host agent would use RTP data from the host to maintain data about
   streams it is sending and receiving, and RTCP data to collect data
   about other hosts in the session.  For example, an agent for an RTP
   host that is sending a stream would use data from its RTP system to
   maintain the rtpSenderTable, but it may want to maintain a
   rtpRcvrTable for endpoints that are receiving its stream.  To do this
   the RTP agent will collect RTCP data from the receivers of its stream
   to build the rtpRcvrTable.  A host monitor system MUST set the
   rtpSessionMonitor object to 'true(1)', but it does not have to accept
   management operations that create and destroy rows in its
   rtpSessionTable.

2.3  The Structure of the RTP MIB

   There are six tables in the RTP MIB.  The rtpSessionTable contains
   objects that describe active sessions at the host, or monitor.  The
   rtpSenderTable contains information about senders to the RTP session.
   The rtpRcvrTable contains information about receivers of RTP session
   data.  The rtpSessionInverseTable, rtpSenderInverseTable, and
   rtpRcvrInverseTable contain information to efficiently find indexes
   into the rtpSessionTable, rtpSenderTable, and rtpRcvrTable,
   respectively.






Baugher, et al.             Standards Track                     [Page 4]

RFC 2959                        RTP MIB                     October 2000


   The reverse lookup tables (rtpSessionInverseTable,
   rtpSenderInverseTable, and rtpRcvrInverseTable) are optional tables
   to help management applications efficiently access conceptual rows in
   other tables.  Implementors of this MIB SHOULD implement these tables
   for multicast RTP sessions when table indexes (rtpSessionIndex of
   rtpSessionTable, rtpSenderSSRC of rtpSenderTable, and the SSRC pair
   in the rtpRcvrTable) are not available from other MIBs.  Otherwise,
   the management application may be forced to perform expensive tree
   walks through large numbers of sessions, senders, or receivers.

   For any particular RTP session, the rtpSessionMonitor object
   indicates whether remote senders or receivers to the RTP session are
   to be monitored.  If rtpSessionMonitor is true(1) then senders and
   receivers to the session MUST be monitored with entries in the
   rtpSenderTable and rtpRcvrTable.  RTP sessions are monitored by the
   RTP agent that updates rtpSenderTable and rtpRcvrTable objects with
   information from RTCP reports from remote senders or remote receivers
   respectively.

   rtpSessionNewIndex is a global object that permits a network-
   management application to obtain a unique index for conceptual row
   creation in the rtpSessionTable.  In this way the SNMP Set operation
   MAY be used to configure a monitor.

3. Definitions

RTP-MIB DEFINITIONS ::= BEGIN
IMPORTS
       Counter32, Counter64, Gauge32, mib-2, Integer32,
       MODULE-IDENTITY,
       OBJECT-TYPE, Unsigned32                     FROM SNMPv2-SMI
       RowStatus, TAddress,
       TDomain, TestAndIncr,
       TimeStamp, TruthValue                       FROM SNMPv2-TC
       OBJECT-GROUP, MODULE-COMPLIANCE             FROM SNMPv2-CONF
       Utf8String                                  FROM SYSAPPL-MIB
       InterfaceIndex                              FROM IF-MIB;

rtpMIB MODULE-IDENTITY
    LAST-UPDATED "200010020000Z"  -- 2 October 2000
    ORGANIZATION
                 "IETF AVT Working Group
    Email:   rem-conf@es.net"
    CONTACT-INFO
            "Mark Baugher
    Postal: Intel Corporation
            2111 NE 25th Avenue
            Hillsboro, OR   97124



Baugher, et al.             Standards Track                     [Page 5]

RFC 2959                        RTP MIB                     October 2000


            United States
    Tel:    +1 503 466 8406
    Email:  mbaugher@passedge.com

            Bill Strahm
    Postal: Intel Corporation
            2111 NE 25th Avenue
            Hillsboro, OR   97124
            United States
    Tel:    +1 503 264 4632
    Email:  bill.strahm@intel.com

            Irina Suconick
    Postal: Ennovate Networks
            60 Codman Hill Rd.,
            Boxboro, Ma 01719
    Tel:    +1 781-505-2155
    Email:  irina@ennovatenetworks.com"

        DESCRIPTION
        "The managed objects of RTP systems.  The MIB is
        structured around three types of information.
        1. General information about RTP sessions such
           as the session address.
        2. Information about RTP streams being sent to
           an RTP session by a particular sender.
        3. Information about RTP streams received on an
           RTP session by a particular receiver from a
           particular sender.
         There are two types of RTP Systems, RTP hosts and
         RTP monitors.  As described below, certain objects
         are unique to a particular type of RTP System.   An
         RTP host may also function as an RTP monitor.
         Refer to RFC 1889, 'RTP: A Transport Protocol for
         Real-Time Applications,' section 3.0, for definitions."
   REVISION     "200010020000Z"  -- 2 October 2000
   DESCRIPTION  "Initial version of this MIB.
                 Published as RFC 2959."

::= { mib-2 87 }

--
-- OBJECTS
--
rtpMIBObjects OBJECT IDENTIFIER ::= { rtpMIB 1 }
rtpConformance OBJECT IDENTIFIER ::= { rtpMIB 2 }

--



Baugher, et al.             Standards Track                     [Page 6]

RFC 2959                        RTP MIB                     October 2000


-- SESSION NEW INDEX
--
rtpSessionNewIndex OBJECT-TYPE
    SYNTAX          TestAndIncr
    MAX-ACCESS      read-write
    STATUS          current
    DESCRIPTION
      "This  object  is  used  to  assign  values  to rtpSessionIndex
       as described in 'Textual Conventions  for  SMIv2'.  For an RTP
       system that supports the creation of rows, the  network manager
       would read the  object,  and  then write the value back in
       the Set that creates a new instance  of rtpSessionEntry.   If
       the  Set  fails with the code 'inconsistentValue,' then the
       process must be repeated; If the Set succeeds, then the object
       is incremented, and the  new  instance  is created according to
       the manager's directions.  However, if the RTP agent is not
       acting as a monitor, only the RTP agent may create conceptual
       rows in the RTP session table."
    ::= { rtpMIBObjects 1 }

--
-- SESSION INVERSE TABLE
--
rtpSessionInverseTable OBJECT-TYPE
    SYNTAX          SEQUENCE OF RtpSessionInverseEntry
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
      "Maps rtpSessionDomain, rtpSessionRemAddr, and rtpSessionLocAddr
       TAddress pairs to one or more rtpSessionIndex values, each
       describing a row in the rtpSessionTable.  This makes it possible
       to retrieve the row(s) in the rtpSessionTable corresponding to a
       given session without having to walk the entire (potentially
       large) table."
    ::= { rtpMIBObjects 2 }

rtpSessionInverseEntry OBJECT-TYPE
    SYNTAX          RtpSessionInverseEntry
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
      "Each entry corresponds to exactly one entry in the
       rtpSessionTable - the entry containing the tuple,
       rtpSessionDomain, rtpSessionRemAddr, rtpSessionLocAddr
       and rtpSessionIndex."
    INDEX { rtpSessionDomain, rtpSessionRemAddr, rtpSessionLocAddr,
            rtpSessionIndex }
    ::= { rtpSessionInverseTable 1 }



Baugher, et al.             Standards Track                     [Page 7]

RFC 2959                        RTP MIB                     October 2000


RtpSessionInverseEntry ::= SEQUENCE {
        rtpSessionInverseStartTime     TimeStamp
        }

rtpSessionInverseStartTime OBJECT-TYPE
    SYNTAX          TimeStamp
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "The value of SysUpTime at the time that this row was
       created."
    ::= { rtpSessionInverseEntry 1 }

--
--      SESSION TABLE
--
rtpSessionTable OBJECT-TYPE
    SYNTAX          SEQUENCE OF RtpSessionEntry
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
          "There's one entry in rtpSessionTable for each RTP session
          on which packets are being sent, received, and/or
          monitored."
    ::= { rtpMIBObjects 3 }

rtpSessionEntry OBJECT-TYPE
    SYNTAX          RtpSessionEntry
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
      "Data in rtpSessionTable uniquely identify an RTP session.  A
       host RTP agent MUST create a read-only row for each session to
       which packets are being sent or received.  Rows MUST be created
       by the RTP Agent at the start of a session when one or more
       senders or receivers are observed.  Rows created by an RTP agent
       MUST be deleted when the session is over and there are no
       rtpRcvrEntry and no rtpSenderEntry for this session.  An RTP
       session SHOULD be monitored to create management information on
       all RTP streams being sent or received when the
       rtpSessionMonitor has the TruthValue of 'true(1)'.  An RTP
       monitor SHOULD permit row creation with the side effect of
       causing the RTP System to join the multicast session for the
       purposes of gathering management information  (additional
       conceptual rows are created in the rtpRcvrTable and
       rtpSenderTable).  Thus, rtpSessionTable rows SHOULD be created
       for RTP session monitoring purposes.  Rows created by a
       management application SHOULD be deleted via SNMP operations by



Baugher, et al.             Standards Track                     [Page 8]

RFC 2959                        RTP MIB                     October 2000


       management applications.  Rows created by management operations
       are deleted by management operations by setting
       rtpSessionRowStatus to 'destroy(6)'."
    INDEX { rtpSessionIndex }
    ::= { rtpSessionTable 1 }

RtpSessionEntry ::= SEQUENCE {
        rtpSessionIndex         Integer32,
        rtpSessionDomain        TDomain,
        rtpSessionRemAddr       TAddress,
        rtpSessionLocAddr       TAddress,
        rtpSessionIfIndex       InterfaceIndex,
        rtpSessionSenderJoins   Counter32,
        rtpSessionReceiverJoins Counter32,
        rtpSessionByes          Counter32,
        rtpSessionStartTime     TimeStamp,
        rtpSessionMonitor       TruthValue,
        rtpSessionRowStatus     RowStatus
        }

rtpSessionIndex OBJECT-TYPE
    SYNTAX          Integer32 (1..2147483647)
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
      "The index of the conceptual row which is for SNMP purposes
       only and has no relation to any protocol value.  There is
       no requirement that these rows are created or maintained
       sequentially."
    ::= { rtpSessionEntry 1 }

rtpSessionDomain OBJECT-TYPE
    SYNTAX          TDomain
    MAX-ACCESS      read-create
    STATUS          current
    DESCRIPTION
      "The transport-layer protocol used for sending or receiving
       the stream of RTP data packets on this session.
       Cannot be changed if rtpSessionRowStatus is 'active'."
    ::= { rtpSessionEntry 2 }

rtpSessionRemAddr OBJECT-TYPE
    SYNTAX          TAddress
    MAX-ACCESS      read-create
    STATUS          current
    DESCRIPTION
      "The address to which RTP packets are sent by the RTP system.
      In an IP multicast RTP session, this is the single address used



Baugher, et al.             Standards Track                     [Page 9]

RFC 2959                        RTP MIB                     October 2000


      by all senders and receivers of RTP session data.  In a unicast
      RTP session this is the unicast address of the remote RTP system.
      'The destination address pair may be common for all participants,
      as in the case of IP multicast, or may be different for each, as
      in the case of individual unicast network address pairs.'  See
      RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,'
      sec. 3.  The transport service is identified by rtpSessionDomain.
      For snmpUDPDomain, this is an IP address and even-numbered UDP
      Port with the RTCP being sent on the next higher odd-numbered
      port, see RFC 1889, sec. 5."
    ::= { rtpSessionEntry 3 }

rtpSessionLocAddr OBJECT-TYPE
    SYNTAX          TAddress
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "The local address used by the RTP system.  In an IP multicast
       RTP session, rtpSessionRemAddr will be the same IP multicast
       address as rtpSessionLocAddr.  In a unicast RTP session,
       rtpSessionRemAddr and rtpSessionLocAddr will have different
       unicast addresses.  See RFC 1889, 'RTP: A Transport Protocol for
       Real-Time Applications,' sec. 3.  The transport service is
       identified by rtpSessionDomain.  For snmpUDPDomain, this is an IP
       address and even-numbered UDP Port with the RTCP being sent on
       the next higher odd-numbered port, see RFC 1889, sec. 5."
    ::= { rtpSessionEntry 4 }

rtpSessionIfIndex OBJECT-TYPE
    SYNTAX          InterfaceIndex
    MAX-ACCESS      read-create
    STATUS          current
    DESCRIPTION
     "The ifIndex value is set to the corresponding value
      from IF-MIB (See RFC 2233, 'The Interfaces Group MIB using
      SMIv2').  This is the interface that the RTP stream is being sent
      to or received from, or in the case of an RTP Monitor the
      interface that RTCP packets will be received on.  Cannot be
      changed if rtpSessionRowStatus is 'active'."
    ::= { rtpSessionEntry 5 }

rtpSessionSenderJoins OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "The number of senders that have been observed to have
       joined the session since this conceptual row was created



Baugher, et al.             Standards Track                    [Page 10]

RFC 2959                        RTP MIB                     October 2000


       (rtpSessionStartTime).  A sender 'joins' an RTP
       session by sending to it.  Senders that leave and then
       re-join following an RTCP BYE (see RFC 1889, 'RTP: A
       Transport Protocol for Real-Time Applications,' sec. 6.6)
       or session timeout may be counted twice.  Every time a new
       RTP sender is detected either using RTP or RTCP, this counter
       is incremented."
    ::= { rtpSessionEntry 6 }

rtpSessionReceiverJoins OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "The number of receivers that have been been observed to
       have joined this session since this conceptual row was
       created (rtpSessionStartTime).  A receiver 'joins' an RTP
       session by sending RTCP Receiver Reports to the session.
       Receivers that leave and then re-join following an RTCP BYE
       (see RFC 1889, 'RTP: A Transport Protocol for Real-Time
       Applications,' sec. 6.6) or session timeout may be counted
       twice."
    ::= { rtpSessionEntry 7 }

rtpSessionByes OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "A count of RTCP BYE (see RFC 1889, 'RTP: A Transport
       Protocol for Real-Time Applications,' sec. 6.6) messages
       received by this entity."
    ::= { rtpSessionEntry 8 }

rtpSessionStartTime OBJECT-TYPE
    SYNTAX          TimeStamp
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "The value of SysUpTime at the time that this row was
       created."
    ::= { rtpSessionEntry 9 }

rtpSessionMonitor OBJECT-TYPE
    SYNTAX          TruthValue
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION



Baugher, et al.             Standards Track                    [Page 11]

RFC 2959                        RTP MIB                     October 2000


      "Boolean, Set to 'true(1)' if remote senders or receivers in
       addition to the local RTP System are to be monitored using RTCP.
       RTP Monitors MUST initialize to 'true(1)' and RTP Hosts SHOULD
       initialize this 'false(2)'.  Note that because 'host monitor'
       systems are receiving RTCP from their remote participants they
       MUST set this value to 'true(1)'."
    ::= { rtpSessionEntry 10 }

rtpSessionRowStatus OBJECT-TYPE
    SYNTAX          RowStatus
    MAX-ACCESS      read-create
    STATUS          current
    DESCRIPTION
      "Value of 'active' when RTP or RTCP messages are being
       sent or received by an RTP System.  A newly-created
       conceptual row must have the all read-create objects
       initialized before becoming 'active'.
       A conceptual row that is in the 'notReady' or 'notInService'
       state MAY be removed after 5  minutes."
    ::= { rtpSessionEntry 11 }

--
-- SENDER INVERSE TABLE
--
rtpSenderInverseTable OBJECT-TYPE
    SYNTAX          SEQUENCE OF RtpSenderInverseEntry
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
      "Maps rtpSenderAddr, rtpSessionIndex, to the rtpSenderSSRC
       index of the rtpSenderTable.  This table allows management
       applications to find entries sorted by rtpSenderAddr rather than
       sorted by rtpSessionIndex.  Given the rtpSessionDomain and
       rtpSenderAddr, a set of rtpSessionIndex and rtpSenderSSRC values
       can be returned from a tree walk.  When rtpSessionIndex is
       specified in the SNMP Get-Next operations, one or more
       rtpSenderSSRC values may be returned."
    ::= { rtpMIBObjects 4 }

rtpSenderInverseEntry OBJECT-TYPE
    SYNTAX          RtpSenderInverseEntry
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
      "Each entry corresponds to exactly one entry in the
       rtpSenderTable - the entry containing the index pair,
       rtpSessionIndex, rtpSenderSSRC."
    INDEX { rtpSessionDomain, rtpSenderAddr, rtpSessionIndex,



Baugher, et al.             Standards Track                    [Page 12]

RFC 2959                        RTP MIB                     October 2000


            rtpSenderSSRC }
    ::= { rtpSenderInverseTable 1 }

RtpSenderInverseEntry ::= SEQUENCE {
        rtpSenderInverseStartTime     TimeStamp
        }

rtpSenderInverseStartTime OBJECT-TYPE
    SYNTAX          TimeStamp
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "The value of SysUpTime at the time that this row was
       created."
    ::= { rtpSenderInverseEntry 1 }

--
--  SENDERS TABLE
--
rtpSenderTable OBJECT-TYPE
    SYNTAX          SEQUENCE OF RtpSenderEntry
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
      "Table of information about a sender or senders to an RTP
       Session. RTP sending hosts MUST have an entry in this table
       for each stream being sent.  RTP receiving hosts MAY have an
       entry in this table for each sending stream being received by
       this host.  RTP monitors MUST create an entry for each observed
       sender to a multicast RTP Session as a side-effect when a
       conceptual row in the rtpSessionTable is made 'active' by a
       manager."
    ::= { rtpMIBObjects 5 }

rtpSenderEntry OBJECT-TYPE
    SYNTAX          RtpSenderEntry
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
      "Each entry contains information from a single RTP Sender
       Synchronization Source (SSRC, see RFC 1889 'RTP: A Transport
       Protocol for Real-Time Applications' sec.6).  The session is
       identified to the the SNMP entity by rtpSessionIndex.
       Rows are removed by the RTP agent when a BYE is received
       from the sender or when the sender times out (see RFC
       1889, Sec. 6.2.1) or when the rtpSessionEntry is deleted."
    INDEX { rtpSessionIndex, rtpSenderSSRC }
    ::= { rtpSenderTable 1 }



Baugher, et al.             Standards Track                    [Page 13]

RFC 2959                        RTP MIB                     October 2000


RtpSenderEntry ::= SEQUENCE {
        rtpSenderSSRC           Unsigned32,
        rtpSenderCNAME          Utf8String,
        rtpSenderAddr           TAddress,
        rtpSenderPackets        Counter64,
        rtpSenderOctets         Counter64,
        rtpSenderTool           Utf8String,
        rtpSenderSRs            Counter32,
        rtpSenderSRTime         TimeStamp,
        rtpSenderPT             INTEGER,
        rtpSenderStartTime      TimeStamp
        }

rtpSenderSSRC OBJECT-TYPE
    SYNTAX          Unsigned32
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
      "The RTP SSRC, or synchronization source identifier of the
       sender.  The RTP session address plus an SSRC uniquely
       identify a sender to an RTP session (see RFC 1889, 'RTP: A
       Transport Protocol for Real-Time Applications' sec.3)."
    ::= { rtpSenderEntry 1 }

rtpSenderCNAME OBJECT-TYPE
    SYNTAX          Utf8String
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "The RTP canonical name of the sender."
    ::= { rtpSenderEntry 2 }

rtpSenderAddr OBJECT-TYPE
    SYNTAX          TAddress
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "The unicast transport source address of the sender.  In the
       case of an RTP Monitor this address is the address that the
       sender is using to send its RTCP Sender Reports."
    ::= { rtpSenderEntry 3 }

rtpSenderPackets OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "Count of RTP packets sent by this sender, or observed by



Baugher, et al.             Standards Track                    [Page 14]

RFC 2959                        RTP MIB                     October 2000


       an RTP monitor, since rtpSenderStartTime."
    ::= { rtpSenderEntry 4 }

rtpSenderOctets OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "Count of non-header RTP octets sent by this sender, or observed
       by an RTP monitor, since rtpSenderStartTime."
    ::= { rtpSenderEntry 5 }

rtpSenderTool OBJECT-TYPE
    SYNTAX          Utf8String (SIZE(0..127))
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "Name of the application program source of the stream."
    ::= { rtpSenderEntry 6 }

rtpSenderSRs OBJECT-TYPE
    SYNTAX          Counter32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "A count of the number of RTCP Sender Reports that have
       been sent from this sender, or observed if the RTP entity
       is a monitor, since rtpSenderStartTime."
    ::= { rtpSenderEntry 7 }

rtpSenderSRTime OBJECT-TYPE
    SYNTAX          TimeStamp
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "rtpSenderSRTime is the value of SysUpTime at the time that
       the last SR was received from this sender, in the case of a
       monitor or receiving host.  Or sent by this sender, in the
       case of a sending host."
    ::= { rtpSenderEntry 8 }

rtpSenderPT OBJECT-TYPE
    SYNTAX          INTEGER (0..127)
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "Payload type from the RTP header of the most recently received
       RTP Packet (see RFC 1889, 'RTP: A Transport Protocol for



Baugher, et al.             Standards Track                    [Page 15]

RFC 2959                        RTP MIB                     October 2000


       Real-Time Applications' sec. 5)."
    ::= { rtpSenderEntry 9 }

rtpSenderStartTime OBJECT-TYPE
    SYNTAX          TimeStamp
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "The value of SysUpTime at the time that this row was
       created."
    ::= { rtpSenderEntry 10 }

--
-- RECEIVER INVERSE TABLE
--
rtpRcvrInverseTable OBJECT-TYPE
    SYNTAX          SEQUENCE OF RtpRcvrInverseEntry
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
      "Maps rtpRcvrAddr and rtpSessionIndex to the rtpRcvrSRCSSRC and
       rtpRcvrSSRC indexes of the rtpRcvrTable.  This table allows
       management applications to find entries sorted by rtpRcvrAddr
       rather than by rtpSessionIndex. Given rtpSessionDomain and
       rtpRcvrAddr, a set of rtpSessionIndex, rtpRcvrSRCSSRC, and
       rtpRcvrSSRC values can be returned from a tree walk.  When
       rtpSessionIndex is specified in SNMP Get-Next operations, one or
       more rtpRcvrSRCSSRC and rtpRcvrSSRC pairs may be returned."
    ::= { rtpMIBObjects 6 }

rtpRcvrInverseEntry OBJECT-TYPE
    SYNTAX          RtpRcvrInverseEntry
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
      "Each entry corresponds to exactly one entry in the
       rtpRcvrTable - the entry containing the index pair,
       rtpSessionIndex, rtpRcvrSSRC."
    INDEX { rtpSessionDomain, rtpRcvrAddr,  rtpSessionIndex,
            rtpRcvrSRCSSRC, rtpRcvrSSRC }
    ::= { rtpRcvrInverseTable 1 }

RtpRcvrInverseEntry ::= SEQUENCE {
        rtpRcvrInverseStartTime     TimeStamp
        }

rtpRcvrInverseStartTime OBJECT-TYPE
    SYNTAX          TimeStamp



Baugher, et al.             Standards Track                    [Page 16]

RFC 2959                        RTP MIB                     October 2000


    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "The value of SysUpTime at the time that this row was
       created."
    ::= { rtpRcvrInverseEntry 1 }

--
--  RECEIVERS TABLE
--
rtpRcvrTable OBJECT-TYPE
    SYNTAX          SEQUENCE OF RtpRcvrEntry
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
      "Table of information about a receiver or receivers of RTP
       session data. RTP hosts that receive RTP session packets
       MUST create an entry in this table for that receiver/sender
       pair.  RTP hosts that send RTP session packets MAY create
       an entry in this table for each receiver to their stream
       using RTCP feedback from the RTP group.  RTP monitors
       create an entry for each observed RTP session receiver as
       a side effect when a conceptual row in the rtpSessionTable
       is made 'active' by a manager."
    ::= { rtpMIBObjects 7 }

rtpRcvrEntry OBJECT-TYPE
    SYNTAX          RtpRcvrEntry
    MAX-ACCESS      not-accessible
    STATUS          current
    DESCRIPTION
      "Each entry contains information from a single RTP
       Synchronization Source that is receiving packets from the
       sender identified by rtpRcvrSRCSSRC (SSRC, see RFC 1889,
       'RTP: A Transport Protocol for Real-Time Applications'
       sec.6).  The session is identified to the the RTP Agent entity
       by rtpSessionIndex.  Rows are removed by the RTP agent when
       a BYE is received from the sender or when the sender times
       out (see RFC 1889, Sec. 6.2.1) or when the rtpSessionEntry is
       deleted."
    INDEX { rtpSessionIndex, rtpRcvrSRCSSRC, rtpRcvrSSRC }
    ::= { rtpRcvrTable 1 }

RtpRcvrEntry ::= SEQUENCE {
        rtpRcvrSRCSSRC        Unsigned32,
        rtpRcvrSSRC           Unsigned32,
        rtpRcvrCNAME          Utf8String,
        rtpRcvrAddr           TAddress,



Baugher, et al.             Standards Track                    [Page 17]

RFC 2959                        RTP MIB                     October 2000


        rtpRcvrRTT            Gauge32,
        rtpRcvrLostPackets    Counter64,
        rtpRcvrJitter         Gauge32,
        rtpRcvrTool           Utf8String,
        rtpRcvrRRs            Counter32,
        rtpRcvrRRTime         TimeStamp,
        rtpRcvrPT             INTEGER,
        rtpRcvrPackets        Counter64,
        rtpRcvrOctets         Counter64,
        rtpRcvrStartTime      TimeStamp
        }

rtpRcvrSRCSSRC OBJECT-TYPE
    SYNTAX       Unsigned32
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION
      "The RTP SSRC, or synchronization source identifier of the
       sender.  The RTP session address plus an SSRC uniquely
       identify a sender or receiver of an RTP stream (see RFC
       1889, 'RTP:  A Transport Protocol for Real-Time
       Applications' sec.3)."
    ::= { rtpRcvrEntry 1 }

rtpRcvrSSRC OBJECT-TYPE
    SYNTAX       Unsigned32
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION
      "The RTP SSRC, or synchronization source identifier of the
       receiver.  The RTP session address plus an SSRC uniquely
       identify a receiver of an RTP stream (see RFC 1889, 'RTP:
       A Transport Protocol for Real-Time Applications' sec.3)."
    ::= { rtpRcvrEntry 2 }

rtpRcvrCNAME OBJECT-TYPE
    SYNTAX       Utf8String
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION
      "The RTP canonical name of the receiver."
    ::= { rtpRcvrEntry 3 }

rtpRcvrAddr OBJECT-TYPE
    SYNTAX       TAddress
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION



Baugher, et al.             Standards Track                    [Page 18]

RFC 2959                        RTP MIB                     October 2000


      "The unicast transport address on which the receiver is
       receiving RTP packets and/or RTCP Receiver Reports."
    ::= { rtpRcvrEntry 4 }

rtpRcvrRTT OBJECT-TYPE
    SYNTAX       Gauge32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION
      "The round trip time measurement taken by the source of the
       RTP stream based on the algorithm described on sec. 6 of
       RFC 1889, 'RTP: A Transport Protocol for Real-Time
       Applications.'  This algorithm can produce meaningful
       results when the RTP agent has the same clock as the stream
       sender (when the RTP monitor is also the sending host for the
       particular receiver).  Otherwise, the entity should return
       'noSuchInstance' in response to queries against rtpRcvrRTT."
    ::= { rtpRcvrEntry 5 }

rtpRcvrLostPackets OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "A count of RTP  packets lost as observed by this receiver
       since rtpRcvrStartTime."
    ::= { rtpRcvrEntry 6 }

rtpRcvrJitter OBJECT-TYPE
    SYNTAX          Gauge32
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "An estimate of delay variation as observed by this
       receiver.  (see RFC 1889, 'RTP: A Transport Protocol
       for Real-Time Applications' sec.6.3.1 and A.8)."
    ::= { rtpRcvrEntry 7 }

rtpRcvrTool OBJECT-TYPE
    SYNTAX          Utf8String (SIZE(0..127))
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "Name of the application program source of the stream."
    ::= { rtpRcvrEntry 8 }

rtpRcvrRRs OBJECT-TYPE
    SYNTAX          Counter32



Baugher, et al.             Standards Track                    [Page 19]

RFC 2959                        RTP MIB                     October 2000


    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "A count of the number of RTCP Receiver Reports that have
       been sent from this receiver, or observed if the RTP entity
       is a monitor, since rtpRcvrStartTime."
    ::= { rtpRcvrEntry 9 }

rtpRcvrRRTime OBJECT-TYPE
    SYNTAX         TimeStamp
    MAX-ACCESS     read-only
    STATUS         current
    DESCRIPTION
      "rtpRcvrRRTime is the value of SysUpTime at the time that the
       last RTCP Receiver Report was received from this receiver, in
       the case of a monitor or RR receiver (the RTP Sender).  It is
       the  value of SysUpTime at the time that the last RR was sent by
       this receiver in the case of an RTP receiver sending the RR."
    ::= { rtpRcvrEntry 10 }

rtpRcvrPT OBJECT-TYPE
    SYNTAX          INTEGER (0..127)
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "Static or dynamic payload type from the RTP header (see
       RFC 1889, 'RTP: A Transport Protocol for Real-Time
       Applications' sec. 5)."
    ::= { rtpRcvrEntry 11 }

rtpRcvrPackets OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "Count of RTP packets received by this RTP host receiver
       since rtpRcvrStartTime."
    ::= { rtpRcvrEntry 12 }

rtpRcvrOctets OBJECT-TYPE
    SYNTAX          Counter64
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "Count of non-header RTP octets received by this receiving RTP
       host since rtpRcvrStartTime."
    ::= { rtpRcvrEntry 13 }




Baugher, et al.             Standards Track                    [Page 20]

RFC 2959                        RTP MIB                     October 2000


rtpRcvrStartTime OBJECT-TYPE
    SYNTAX          TimeStamp
    MAX-ACCESS      read-only
    STATUS          current
    DESCRIPTION
      "The value of SysUpTime at the time that this row was
       created."
    ::= { rtpRcvrEntry 14 }

--
--  MODULE GROUPS
--
--
-- There are two types of RTP Systems, RTP hosts and RTP Monitors.
-- Thus there are three kinds of objects: 1) Objects common to both
-- kinds of systems, 2) Objects unique to RTP Hosts and 3) Objects
-- unique to RTP Monitors.  There is a fourth group, 4) Objects that
-- SHOULD be implemented by Multicast hosts and RTP Monitors

rtpGroups OBJECT IDENTIFIER ::= { rtpConformance 1 }
rtpSystemGroup      OBJECT-GROUP
    OBJECTS         {
                    rtpSessionDomain,
                    rtpSessionRemAddr,
                    rtpSessionIfIndex,
                    rtpSessionSenderJoins,
                    rtpSessionReceiverJoins,
                    rtpSessionStartTime,
                    rtpSessionByes,
                    rtpSessionMonitor,
                    rtpSenderCNAME,
                    rtpSenderAddr,
                    rtpSenderPackets,
                    rtpSenderOctets,
                    rtpSenderTool,
                    rtpSenderSRs,
                    rtpSenderSRTime,
                    rtpSenderStartTime,
                    rtpRcvrCNAME,
                    rtpRcvrAddr,
                    rtpRcvrLostPackets,
                    rtpRcvrJitter,
                    rtpRcvrTool,
                    rtpRcvrRRs,
                    rtpRcvrRRTime,
                    rtpRcvrStartTime
                    }
    STATUS          current



Baugher, et al.             Standards Track                    [Page 21]

RFC 2959                        RTP MIB                     October 2000


    DESCRIPTION
        "Objects available to all RTP Systems."
    ::= { rtpGroups 1 }

rtpHostGroup    OBJECT-GROUP
    OBJECTS     {
                rtpSessionLocAddr,
                rtpSenderPT,
                rtpRcvrPT,
                rtpRcvrRTT,
                rtpRcvrOctets,
                rtpRcvrPackets
                }
    STATUS      current
    DESCRIPTION
           "Objects that are available to RTP Host systems, but may not
            be available to RTP Monitor systems."
    ::= { rtpGroups 2 }

rtpMonitorGroup OBJECT-GROUP
    OBJECTS     {
                rtpSessionNewIndex,
                rtpSessionRowStatus
                }
    STATUS      current
    DESCRIPTION
        "Objects used to create rows in the RTP Session Table.  These
        objects are not needed if the system does not create rows."
    ::= { rtpGroups 3 }

rtpInverseGroup OBJECT-GROUP
    OBJECTS     {
                rtpSessionInverseStartTime,
                rtpSenderInverseStartTime,
                rtpRcvrInverseStartTime
                }
    STATUS      current
    DESCRIPTION
            "Objects used in the Inverse Lookup Tables."
    ::= { rtpGroups 4 }

--
--  Compliance
--
rtpCompliances OBJECT IDENTIFIER ::= { rtpConformance 2 }

rtpHostCompliance MODULE-COMPLIANCE
    STATUS          current



Baugher, et al.             Standards Track                    [Page 22]

RFC 2959                        RTP MIB                     October 2000


    DESCRIPTION
            "Host implementations MUST comply."
    MODULE           RTP-MIB
    MANDATORY-GROUPS {
                     rtpSystemGroup,
                     rtpHostGroup
                     }
    GROUP            rtpMonitorGroup
    DESCRIPTION
        "Host systems my optionally support row creation and deletion.
         This would allow an RTP Host system to act as an RTP Monitor."
    GROUP            rtpInverseGroup
    DESCRIPTION
        "Multicast RTP Systems SHOULD implement the optional
         tables."
        OBJECT  rtpSessionNewIndex
            MIN-ACCESS not-accessible
                DESCRIPTION
                 "RTP system implementations support of
                  row creation and deletion is OPTIONAL so
                  implementation of this object is OPTIONAL."
        OBJECT  rtpSessionDomain
           MIN-ACCESS read-only
                DESCRIPTION
                 "RTP system implementation support of
                  row creation and deletion is OPTIONAL.  When
                  it is not supported so write access is
                  OPTIONAL."
        OBJECT  rtpSessionRemAddr
            MIN-ACCESS read-only
              DESCRIPTION
               "Row creation and deletion is OPTIONAL so
                read-create access to this object is OPTIONAL."
        OBJECT  rtpSessionIfIndex
            MIN-ACCESS read-only
              DESCRIPTION
               "Row creation and deletion is OPTIONAL so
                read-create access to this object is OPTIONAL."
        OBJECT  rtpSessionRowStatus
            MIN-ACCESS not-accessible
              DESCRIPTION
               "Row creation and deletion is OPTIONAL so
                read-create access to this object is OPTIONAL."
        OBJECT  rtpSessionInverseStartTime
            MIN-ACCESS not-accessible
              DESCRIPTION
               "Multicast RTP Systems SHOULD implement the optional
                tables."



Baugher, et al.             Standards Track                    [Page 23]

RFC 2959                        RTP MIB                     October 2000


        OBJECT  rtpSenderInverseStartTime
            MIN-ACCESS not-accessible
              DESCRIPTION
               "Multicast RTP Systems SHOULD implement the optional
                tables."
        OBJECT  rtpRcvrInverseStartTime
            MIN-ACCESS not-accessible
              DESCRIPTION
               "Multicast RTP Systems SHOULD implement the optional
                tables."
    ::= { rtpCompliances 1 }

rtpMonitorCompliance MODULE-COMPLIANCE
    STATUS          current
    DESCRIPTION
          "Monitor implementations must comply.  RTP Monitors are not
          required to support creation or deletion."
    MODULE           RTP-MIB
    MANDATORY-GROUPS     {
                         rtpSystemGroup,
                         rtpMonitorGroup
                         }
    GROUP                rtpHostGroup
    DESCRIPTION
        "Monitor implementations may not have access to values in the
         rtpHostGroup."
    GROUP                rtpInverseGroup
    DESCRIPTION
        "Multicast RTP Systems SHOULD implement the optional
         tables."
        OBJECT  rtpSessionLocAddr
            MIN-ACCESS not-accessible
              DESCRIPTION
               "RTP monitor sourcing of RTP or RTCP data packets
                is OPTIONAL and implementation of this object is
                OPTIONAL."
        OBJECT  rtpRcvrPT
            MIN-ACCESS not-accessible
              DESCRIPTION
               "RTP monitor systems 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"
        OBJECT  rtpSenderPT
            MIN-ACCESS not-accessible
              DESCRIPTION
               "RTP monitor systems may not support
                retrieval of the RTP Payload Type from the RTP



Baugher, et al.             Standards Track                    [Page 24]

RFC 2959                        RTP MIB                     October 2000


                header (and may receive RTCP messages only).  When
                queried for the payload type information."
        OBJECT  rtpRcvrOctets
            MIN-ACCESS not-accessible
              DESCRIPTION
               "RTP monitor systems may receive only the RTCP messages
                and not the RTP messages that contain the octet count
                of the RTP message.  Thus implementation of this
                object is OPTIONAL"
        OBJECT  rtpRcvrPackets
            MIN-ACCESS not-accessible
              DESCRIPTION
               "RTP monitor systems may receive only the RTCP messages
                and not the RTP messages that contain the octet count
                of the RTP message.  Thus implementation of this
                object is OPTIONAL."
        OBJECT  rtpSessionIfIndex
            MIN-ACCESS read-only
              DESCRIPTION
               "Row creation and deletion is OPTIONAL so
                read-create access to this object is OPTIONAL."
        OBJECT  rtpSessionInverseStartTime
            MIN-ACCESS not-accessible
              DESCRIPTION
               "Multicast RTP Systems SHOULD implement the optional
                tables."
        OBJECT  rtpSenderInverseStartTime
            MIN-ACCESS not-accessible
              DESCRIPTION
               "Multicast RTP Systems SHOULD implement the optional
                tables."
        OBJECT  rtpRcvrInverseStartTime
            MIN-ACCESS not-accessible
              DESCRIPTION
               "Multicast RTP Systems SHOULD implement the optional
                tables."
    ::= { rtpCompliances 2 }
END













Baugher, et al.             Standards Track                    [Page 25]

RFC 2959                        RTP MIB                     October 2000


4.  Security Considerations

   In most cases, MIBs are not themselves security risks; if SNMP
   security is operating as intended, the use of a MIB to view
   information about a system, or to change some parameter at the
   system, is a tool, not a threat.  However, there are a number of
   management objects defined in this MIB that have a MAX-ACCESS clause
   of read-write and/or read-create.  Such objects may be considered
   sensitive or vulnerable in some network environments.  The support
   for SET operations in a non-secure environment without proper
   protection can have a negative effect on network operations.

   None of the read-only objects in this MIB reports a password, though
   some SDES [RFC1889] items such as the CNAME [RFC1889], the canonical
   name, may be deemed sensitive depending on the security policies of a
   particular enterprise.  If access to these objects is not limited by
   an appropriate access control policy, these objects can provide an
   attacker with information about a system's configuration and the
   services that that system is providing.  Some enterprises view their
   network and system configurations, as well as information about usage
   and performance, as corporate assets; such enterprises may wish to
   restrict SNMP access to most of the objects in the MIB.  This MIB
   supports read-write operations against rtpSessionNewIndex which has
   the side effect of creating an entry in the rtpSessionTable when it
   is written to.  Five objects in rtpSessionEntry have read-create
   access: rtpSessionDomain, rtpSessionRemAddr, rtpSessionIfIndex,
   rtpSessionRowStatus, and rtpSessionIfAddr identify an RTP session to
   be monitored on a particular interface.  The values of these objects
   are not to be changed once created, and initialization of these
   objects affects only the monitoring of an RTP session and not the
   operation of an RTP session on any host end-system.  Since write
   operations to rtpSessionNewIndex and the five objects in
   rtpSessionEntry affect the operation of the monitor, write access to
   these objects should be subject to the appropriate access control
   policy.

   Confidentiality of RTP and RTCP data packets is defined in section 9
   of the RTP specification [RFC1889].  Encryption may be performed on
   RTP packets, RTCP packets, or both.  Encryption of RTCP packets may
   pose a problem for third-party monitors though "For RTCP, it is
   allowed to split a compound RTCP packet into two lower-layer packets,
   one to be encrypted and one to be sent in the clear.  For example,
   SDES information might be encrypted while reception reports were sent
   in the clear to accommodate third-party monitors [RFC1889]."

   SNMPv1 by itself is not a secure environment.  Even if the network
   itself is secure (for example by using IPSec), there is no control as
   to who on the secure network is allowed to access and GET/SET



Baugher, et al.             Standards Track                    [Page 26]

RFC 2959                        RTP MIB                     October 2000


   (read/change/create/delete) the objects in this MIB.  It is
   recommended that the implementers consider the security features as
   provided by the SNMPv3 framework.  Specifically, the use of the
   User-based Security Model RFC 2574 [RFC2574] and the View-based
   Access Control Model RFC 2575 [RFC2575] is recommended.  It is then a
   customer/user responsibility to ensure that the SNMP entity giving
   access to an instance of this MIB, is properly configured to give
   access to the objects only to those principals (users) that have
   legitimate rights to indeed GET or SET (change/create/delete) them.

5.  Acknowledgements

   The authors wish to thank Bert Wijnen and the participants from the
   ITU SG-16 management effort for their helpful comments.  Alan Batie
   and Bill Lewis from Intel also contributed greatly to the RTP MIB
   through their review of various drafts of the MIB and their work on
   the implementation of an SNMP RTP Monitor.  Stan Naudus from 3Com and
   John Du from Intel contributed to the original RTP MIB design and
   co-authored the original RTP MIB draft documents; much of their work
   remains in the current RTP MIB.  Bill Fenner provided solid feedback
   that improved the quality of the final document.

6.  Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.








Baugher, et al.             Standards Track                    [Page 27]

RFC 2959                        RTP MIB                     October 2000


7.  References

   [RFC1889]   Shulzrinne, H., Casner, S., Frederick, R. and V.
               Jacobson, "RTP: A Transport Protocol for real-time
               applications," RFC 1889, January 1996.

   [RFC2571]   Harrington, D., Presuhn, R. and B. Wijnen, "An
               Architecture for Describing SNMP Management Frameworks",
               RFC 2571, April 1999.

   [RFC1155]   Rose, M. and K. McCloghrie, "Structure and Identification
               of Management Information for TCP/IP-based Internets",
               STD 16, RFC 1155, May 1990.

   [RFC1212]   Rose, M. and K. McCloghrie, "Concise MIB Definitions",
               STD 16, RFC 1212, March 1991.

   [RFC1215]   Rose, M., "A Convention for Defining Traps for use with
               the SNMP", RFC 1215, March 1991.

   [RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Structure of Management
               Information Version 2 (SMIv2)", STD 58, RFC 2578, April
               1999.

   [RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Textual Conventions for
               SMIv2", STD 58, RFC 2579, April 1999.

   [RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
               Rose, M. and S. Waldbusser, "Conformance Statements for
               SMIv2", STD 58, RFC 2580, April 1999.

   [RFC1157]   Case, J., Fedor, M., Schoffstall, M. and J. Davin,
               "Simple Network Management Protocol", STD 15, RFC 1157,
               May 1990.

   [RFC1901]   Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
               "Introduction to Community-based SNMPv2", RFC 1901,
               January 1996.

   [RFC1906]   Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
               "Transport Mappings for Version 2 of the Simple Network
               Management Protocol (SNMPv2)", RFC 1906, January 1996.







Baugher, et al.             Standards Track                    [Page 28]

RFC 2959                        RTP MIB                     October 2000


   [RFC2572]   Case, J., Harrington D., Presuhn R. and B. Wijnen,
               "Message Processing and Dispatching for the Simple
               Network Management Protocol (SNMP)", RFC 2572, April
               1999.

   [RFC2574]   Blumenthal, U. and B. Wijnen, "User-based Security Model
               (USM) for version 3 of the Simple Network Management
               Protocol (SNMPv3)", RFC 2574, April 1999.

   [RFC1905]   Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
               "Protocol Operations for Version 2 of the Simple Network
               Management Protocol (SNMPv2)", RFC 1905, January 1996.

   [RFC2573]   Levi, D., Meyer, P. and B. Stewart, "SNMPv3
               Applications", RFC 2573, April 1999.

   [RFC2575]   Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
               Access Control Model (VACM) for the Simple Network
               Management Protocol (SNMP)", RFC 2575, April 1999.

   [RFC2570]   Case, J., Mundy, R., Partain, D. and B. Stewart,
               "Introduction to Version 3 of the Internet-standard
               Network
                Management Framework", RFC 2570, April 1999.



























Baugher, et al.             Standards Track                    [Page 29]

RFC 2959                        RTP MIB                     October 2000


8. Authors' Addresses

   Mark Baugher
   Intel Corporation
   2111 N.E.25th Avenue
   Hillsboro, Oregon  97124
   U.S.A.

   EMail: mbaugher@passedge.com


   Bill Strahm
   Intel Corporation
   2111 N.E.25th Avenue
   Hillsboro, Oregon  97124
   U.S.A.

   EMail: Bill.Strahm@intel.com


   Irina Suconick
   Ennovate Networks
   60 Codman Hill Rd.,
   Boxboro, Ma 01719
   U.S.A.

   EMail: irina@ennovatenetworks.com
























Baugher, et al.             Standards Track                    [Page 30]

RFC 2959                        RTP MIB                     October 2000


9. Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Baugher, et al.             Standards Track                    [Page 31]