RFC2959 日本語訳
2959 Real-Time Transport Protocol Management Information Base. M.Baugher, B. Strahm, I. Suconick. October 2000. (Format: TXT=62063 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Baugher
Request for Comments: 2959 B. Strahm
Category: Standards Track Intel Corp.
I. Suconick
VideoServer Corp.
October 2000
Baugherがコメントのために要求するワーキンググループM.をネットワークでつないでください: 2959年のB.Strahmカテゴリ: 標準化過程インテル社I.Suconick VideoServer社の2000年10月
Real-Time Transport Protocol
Management Information Base
リアルタイムのトランスポート・プロトコル管理情報ベース
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(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).
ネットワーク管理プロトコルがインターネットコミュニティにある状態で、このメモは使用のために、Management Information基地の一部(MIB)を定義します。 特に、それは、レアル-時間Transportプロトコル(RTP)システム(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
1. ネットワークマネージメントフレームワーク… 2 2. 概要… 3 2.1のコンポーネント… 3 2.2 RTPシステムの実現へのMIBの適用性… 4 2.3 RTP MIBの構造… 4 3の定義… 5 4. セキュリティ問題… 26 5. 承認… 27 6. 知的所有権… 27 7. 参照… 28 8. 作者のアドレス… 30 9. 完全な著作権宣言文… 31
Baugher, et al. Standards Track [Page 1] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[1ページ]。
1. The SNMP Management Framework
1. SNMP管理フレームワーク
The SNMP Management Framework presently consists of five major components:
SNMP Management Frameworkは現在、5個の主要コンポーネントから成ります:
o An overall architecture, described in RFC 2571 [RFC2571].
o RFC2571[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 オブジェクトを説明して、命名するためのメカニズムと管理の目的のためのイベント。 Management情報(SMI)のこのStructureの最初のバージョンは、STD16、RFC1155[RFC1155]、STD16、RFC1212[RFC1212]、およびRFC1215[RFC1215]でSMIv1と呼ばれて、説明されます。 SMIv2と呼ばれる第2バージョンはSTD58、RFC2578[RFC2578]、RFC2579[RFC2579]、およびRFC2580[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 経営情報を移すためのメッセージプロトコル。 SNMPメッセージプロトコルの最初のバージョンは、STD15、RFC1157[RFC1157]でSNMPv1と呼ばれて、説明されます。 SNMPメッセージプロトコルの第2のバージョンは、RFC1901[RFC1901]とRFC1906[RFC1906]でSNMPv2cと呼ばれて、説明されます。(プロトコルはインターネット標準化過程プロトコルではありません)。 メッセージプロトコルの第3バージョンは、RFC1906[RFC1906]、RFC2572[RFC2572]、およびRFC2574[RFC2574]でSNMPv3と呼ばれて、説明されます。
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 経営情報にアクセスするための操作について議定書の中で述べてください。 プロトコル操作と関連PDU形式の第一セットはSTD15、RFC1157[RFC1157]で説明されます。 2番目のセットのプロトコル操作と関連PDU形式はRFC1905[RFC1905]で説明されます。
o A set of fundamental applications described in RFC 2573
[RFC2573] and the view-based access control mechanism described
in RFC 2575 [RFC2575].
o RFC2573[RFC2573]で説明された1セットの基礎的応用と視点ベースのアクセス管理機構はRFC2575で[RFC2575]について説明しました。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570].
RFC2570[RFC2570]で現在のSNMP Management Frameworkへの、より詳細な紹介を見つけることができます。
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.
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 MIBのオブジェクトは、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
このメモはSMIv2に対応であるMIBモジュールを指定します。 適切な翻訳でSMIv1に従うMIBは生産できます。 どんな翻訳も可能でないので(Counter64の使用)、結果として起こる翻訳されたMIBはオブジェクトかイベントが省略されるところで意味的に同等でなければなりません。 いくつか、マシン読み込み可能
Baugher, et al. Standards Track [Page 2] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[2ページ]。
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.
SMIv2の情報は翻訳プロセスの間、SMIv1の原文の記述に変換されるでしょう。 しかしながら、マシンの読み込み可能な情報のこの損失がMIBの意味論を変えると考えられません。
2. Overview
2. 概要
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.
「RTPシステム」はRTPデータ・パケットを送るか、または受けるアプリケーション・プログラムを実行するホストエンドシステムであるかもしれませんかそれがパケットをRTPに送る中間システムであるかもしれません。 送付者と受信機でRTP Controlプロトコル(RTCP)パケットを送って、RTPパケット伝送とレセプション[RFC1889]に関して情報を伝達します。 RTPモニターは中間システムとRTPホストか中間システムから送付者と受信機のRTCP情報を集めるかもしれません。
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.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
2.1 Components
2.1 コンポーネント
The RTP MIB is structured around "Session," "Receiver" and "Sender" conceptual abstractions.
RTP MIBは「セッション」、「受信機」、および「送付者」概念的な抽象化の周りで構造化されます。
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.1 「RTPセッション」がそうである、」 …RTPとコミュニケートする関係者の協会。 各関係者に関しては、セッションは送付先輸送アドレス(RTPとRTCPのための1つのネットワーク・アドレスとポート組)の特定の組によって定義されます。 「送付先輸送アドレスは、IPマルチキャストに関するケースのようにすべての関係者にとって一般的であるかもしれないか、またはそれぞれにおいて、異なるかもしれません、個々のユニキャストアドレスと一般的なポート組のケースのように」、[RFC1889]のセクション3で定義されるように。
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.2 「送付者」がRTPセッション以内に32ビットの数値によって特定される、「」 同期ソース、"SSRC"が評価する、」 …です。[RFC1889]のセクション3の定義されるとしての「RTPパケットの水源。」 また、送付者は[RFC1889]のセクション6の指定されるとしてのRTCP Sender Reportパケットの源です。
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].
2.1.3 「RTPパケットの流れ」の「受信機」が中で説明されるようにaユニキャストかマルチキャストReceiverであるかもしれない、2.1、.1、上です。 RTP Receiverには、セッションにユニークなSSRC値があります。 RTP Receiverは[RFC1889]のセクション6の指定されるとしてのRTCP Receiver Reportsの源です。
Baugher, et al. Standards Track [Page 3] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[3ページ]。
2.2 Applicability of the MIB to RTP System Implementations
2.2 RTPシステムの実現へのMIBの適用性
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.
RTP MIBは2つのタイプのRTP実装、RTP Host Systems(エンドシステム)、およびRTP Monitorsで使用されるかもしれません、と[RFC1889]のセクション3は見ます。 さらなる研究にはRTP MIBの[RFC1889]のセクション7で定義されるRTP TranslatorsとMixersの使用があります。
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.1 RTPホストSystemsは集まるのにRTP MIBを使用するかもしれないエンドシステムRTPセッションとホストが送るか、または受け取っているストリームデータです。 RTPセッションの生涯「ヘルプデスク」シナリオのように起こる欠点を、これらのデータはネットワークマネージャによって使用されて、検出して、診断するかもしれません。
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.2 マルチキャストRTPセッションのRTP Monitorsは第三者であるかもしれないかRTPホストに位置するかもしれません。 RTP MonitorsはRTPセッションを集めて、統計データを流すのにRTP MIBを使用するかもしれません。 これらのデータはキャパシティプランニングと他のネットワーク管理目的にネットワークマネージャによって使用されるかもしれません。 RTP Monitorは、ネットワークマネージャが、RTPセッションのときに欠点を検出して、診断するか、またはネットワーク飼葉桶が操作を構成することを許可することを許可するためにデータを集めるのにRTP MIBを使用するかもしれません。
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.2.3 多くのホストシステムが彼らが送って、受けているものを超えてストリームの動向をおさえたくなるでしょう。 ホストモニタシステムでは、ホストエージェントは、セッションのときにそれが送って、受けているストリームに関するデータ、およびRTCPデータを他のホストに関する料金先方払いのデータに保守するのにホストからのRTPデータを使用するでしょう。 例えば、ストリームを送るRTPホストのためのエージェントはrtpSenderTableを維持するのにRTPシステムからのデータを使用するでしょうが、それはストリームを受けている終点にrtpRcvrTableを維持したがっているかもしれません。 これをするために、RTPエージェントはrtpRcvrTableを造るストリームの受信機からの料金先方払いのRTCPデータがそうするでしょう。 ホストモニタシステムは'本当の(1)'にrtpSessionMonitorオブジェクトを設定しなければなりませんが、それはrtpSessionTableの行を作成して、破壊する管理操作を受け入れる必要はありません。
2.3 The Structure of the RTP MIB
2.3 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.
6個のテーブルがRTP MIBにあります。 rtpSessionTableはホスト、またはモニターで活発なセッションについて説明するオブジェクトを含んでいます。 rtpSenderTableはRTPセッションまで送付者の情報を含んでいます。 rtpRcvrTableはRTPセッションデータの受信機の情報を含んでいます。 rtpSessionInverseTable、rtpSenderInverseTable、およびrtpRcvrInverseTableは効率的にそれぞれrtpSessionTable、rtpSenderTable、およびrtpRcvrTableにインデックスを見つける情報を含んでいます。
Baugher, et al. Standards Track [Page 4] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[4ページ]。
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.
逆のルックアップ表(rtpSessionInverseTable、rtpSenderInverseTable、およびrtpRcvrInverseTable)は管理アプリケーションが効率的に他のテーブルの概念的な行にアクセスするのを助ける任意のテーブルです。 テーブルインデックス(rtpSessionTableのrtpSessionIndex、rtpSenderTableのrtpSenderSSRC、およびrtpRcvrTableのSSRC組)が他のMIBsから利用可能でないときに、このMIB SHOULDの作成者はマルチキャストRTPセッションのためのこれらのテーブルを実装します。 さもなければ、管理アプリケーションはやむを得ずセッション、送付者、または多くの受信機を通した高価な木の散歩を実行するかもしれません。
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.
どんな特定のRTPセッションのためにも、rtpSessionMonitorオブジェクトは、RTPセッションまでのリモート送付者か受信機がモニターされることになっているかどうかを示します。 rtpSessionMonitorが本当の(1)であるなら、rtpSenderTableとrtpRcvrTableでエントリーでセッションまでの送付者と受信機をモニターしなければなりません。 RTPセッションはリモート送付者かリモート受信機からのRTCPレポートからの情報でそれぞれrtpSenderTableとrtpRcvrTableオブジェクトをアップデートするRTPエージェントによってモニターされます。
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.
rtpSessionNewIndexはネットワーク管理アプリケーションがrtpSessionTableの概念的な行作成としてユニークなインデックスを得るのを可能にするグローバルなオブジェクトです。 このように、SNMP Set操作は、モニターを構成するのに使用されるかもしれません。
3. Definitions
3. 定義
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;
RTP-MIB定義:、:= 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、-、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
rtpMIBモジュールアイデンティティは"200010020000Z"をアップデートしました--2000年10月2日の組織、「IETF AVTワーキンググループメール:」 「Baugherが郵便であるとマークしてください」という" rem-conf@es.net "コンタクトインフォメーション 第25インテル社2111Ne Avenueヒースボロー、または97124
Baugher, et al. Standards Track [Page 5] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[5ページ]。
United States
Tel: +1 503 466 8406
Email: mbaugher@passedge.com
合衆国Tel: +1 8406年の503 466メール: 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
ビルStrahm郵便: インテル社2111Ne第25Avenueヒースボロー、または97124合衆国Tel: +1 4632年の503 264メール: 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"
イリーナSuconick郵便: Ennovateネットワーク60Codmanヒル通り、Boxboro、マ01719Tel: +1 781-505-2155 メールしてください: " 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."
記述、「RTPシステムMIBの管理オブジェクトは情報の3つのタイプの周りで構造化されます」。 1. セッションアドレスなどのRTPおよそセッション一般情報。 2. 特定の送付者によってRTPセッションに送られながら、RTPに関する情報は流れます。 3. RTPストリームに関する情報はRTPセッションのときに特定の受信機のそばで特定の送付者から受信されました。 2つのタイプのRTP Systems、RTPホスト、およびRTPモニターがあります。 以下で説明されるように、あるオブジェクトはRTP Systemの特定のタイプにユニークです。 また、RTPホストはRTPモニターとして機能するかもしれません。 'RTP、RFC1889を参照してください:、' 「'レアル-時間ApplicationsのためのTransportプロトコル'、定義のためのセクション3.0。」 REVISION"200010020000Z"--2000年10月2日の記述は「このMIBのバージョンに頭文字をつけます」。 「RFC2959として、発行されます」。
::= { mib-2 87 }
::= mib-2 87
--
-- OBJECTS
--
rtpMIBObjects OBJECT IDENTIFIER ::= { rtpMIB 1 }
rtpConformance OBJECT IDENTIFIER ::= { rtpMIB 2 }
-- -- オブジェクト--rtpMIBObjectsオブジェクト識別子:、:= rtpMIB1rtpConformanceオブジェクト識別子:、:= rtpMIB2
--
--
Baugher, et al. Standards Track [Page 6] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[6ページ]。
-- 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 NEW INDEX--rtpSessionNewIndex OBJECT-TYPE SYNTAX TestAndIncrマックス-ACCESSは「このオブジェクトは'SMIv2のための原文のConventions'で説明されるように値をrtpSessionIndexに割り当てるのに使用されること」をSTATUSの現在の記述に読書して書きます。 行の作成をサポートするRTPシステムのために、ネットワークマネージャは、rtpSessionEntryの新しいインスタンスを作成するSetにオブジェクトを読んで、次に、値の返事を書くでしょう。 コード'inconsistentValue'に応じてSetが失敗するなら、プロセスを繰り返さなければなりません。 Setが成功するなら、オブジェクトは増加されています、そして、マネージャの方向に従って、新しいインスタンスは作成されます。 「しかしながら、RTPエージェントがモニターとして務めていないなら、RTPエージェントだけがRTPセッションテーブルの概念的な行を作成するかもしれません。」 ::= rtpMIBObjects1
--
-- 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 }
-- -- SESSION INVERSE TABLE--rtpSessionInverseTable OBJECT-TYPEのSYNTAX SEQUENCE OF RtpSessionInverseEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「それぞれrtpSessionTableの行について説明して、rtpSessionDomain、rtpSessionRemAddr、およびrtpSessionLocAddr TAddress組を1つ以上のrtpSessionIndex値に写像します」。 「これで、全体(潜在的に大きい)のテーブルを押して行く必要はなくて与えられたセッションに対応するrtpSessionTableの行を検索するのは可能になります。」 ::= rtpMIBObjects2
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 }
rtpSessionInverseEntry OBJECT-TYPE SYNTAX RtpSessionInverseEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「各エントリーはちょうどrtpSessionTableの1つのエントリーに対応しています--tuple、rtpSessionDomain、rtpSessionRemAddr、rtpSessionLocAddr、およびrtpSessionIndexを含むエントリー。」 rtpSessionDomain、rtpSessionRemAddr、rtpSessionLocAddr、rtpSessionIndexに索引をつけてください:、:= rtpSessionInverseTable1
Baugher, et al. Standards Track [Page 7] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[7ページ]。
RtpSessionInverseEntry ::= SEQUENCE {
rtpSessionInverseStartTime TimeStamp
}
RtpSessionInverseEntry:、:= 系列rtpSessionInverseStartTimeタイムスタンプ
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 }
rtpSessionInverseStartTime OBJECT-TYPE SYNTAX TimeStampのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この行が作成された時間のSysUpTimeの値。」 ::= rtpSessionInverseEntry1
--
-- 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 }
-- -- SESSION TABLE--、rtpSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpSessionEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「1つのエントリーがパケットが送られて、受け取る、そして/または、モニターされる予定であるそれぞれのRTPセッションの間、rtpSessionTableにあります」。 ::= rtpMIBObjects3
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
rtpSessionEntry OBJECT-TYPE SYNTAX RtpSessionEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「rtpSessionTableのデータは唯一RTPセッションを特定します」。 ホストRTPエージェントはパケットを送るか、または受け取っている各セッションのために書き込み禁止行を作成しなければなりません。 1台以上の送付者か受信機が観察されるセッションの始めのRTPエージェントは通りを作成しなければなりません。 セッションが終わっていて、rtpRcvrEntryがなくてrtpSenderEntryが全くこのセッションの間ないとき、RTPエージェントによって作成された通りを削除しなければなりません。 送られるすべてのRTPストリームに関する経営情報を作成するためにモニターされるか、または受け取られたSHOULDが'本当の(1)'のTruthValueを持っているrtpSessionMonitorであるRTPセッション。 RTP Systemが集会経営情報(追加概念的な行はrtpRcvrTableとrtpSenderTableで作成される)の目的のためのマルチキャストセッションに参加することを引き起こす副作用に伴うRTPモニターSHOULD許可証行作成。 その結果、rtpSessionTableはSHOULDを船をこいで運びます。RTPセッションには、目的をモニターしながら、作成されてください。 通り、a管理アプリケーションSHOULDによって作成されて、SNMP操作で削除されてください。
Baugher, et al. Standards Track [Page 8] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[8ページ]。
management applications. Rows created by management operations
are deleted by management operations by setting
rtpSessionRowStatus to 'destroy(6)'."
INDEX { rtpSessionIndex }
::= { rtpSessionTable 1 }
管理アプリケーション。 「rtpSessionRowStatusに'(6)を破壊します'ように設定することによって、管理操作で作成された通りは管理操作で削除されます。」 rtpSessionIndexに索引をつけてください:、:= rtpSessionTable1
RtpSessionEntry ::= SEQUENCE {
rtpSessionIndex Integer32,
rtpSessionDomain TDomain,
rtpSessionRemAddr TAddress,
rtpSessionLocAddr TAddress,
rtpSessionIfIndex InterfaceIndex,
rtpSessionSenderJoins Counter32,
rtpSessionReceiverJoins Counter32,
rtpSessionByes Counter32,
rtpSessionStartTime TimeStamp,
rtpSessionMonitor TruthValue,
rtpSessionRowStatus RowStatus
}
RtpSessionEntry:、:= 系列rtpSessionIndex Integer32、rtpSessionDomain TDomain、rtpSessionRemAddr TAddress、rtpSessionLocAddr TAddress、rtpSessionIfIndex InterfaceIndex、rtpSessionSenderJoins Counter32、rtpSessionReceiverJoins Counter32、rtpSessionByes Counter32、rtpSessionStartTimeタイムスタンプ、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 }
rtpSessionIndex OBJECT-TYPE SYNTAX Integer32(1 .2147483647)のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「SNMP目的だけのためにあって、どんなプロトコル値にも関係がない概念的な行のインデックス。」 「これらの行が連続して作成されるか、または維持されるという要件が全くありません。」 ::= rtpSessionEntry1
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 }
rtpSessionDomain OBJECT-TYPE SYNTAX TDomainマックス-ACCESSは「トランスポート層プロトコルはこのセッションのときにRTPデータ・パケットの流れを送るか、または受けるのに使用した」STATUSの現在の記述を読書して作成します。 「rtpSessionRowStatusが'アクティブである'なら、変えることができません。」 ::= rtpSessionEntry2
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
rtpSessionRemAddr OBJECT-TYPE SYNTAX TAddressマックス-ACCESSはSTATUSの現在の記述を読書して作成します。「RTPパケットがRTPシステムによって送られるアドレス。」 IPマルチキャストRTPセッションのときに、これは使用されるただ一つのアドレスです。
Baugher, et al. Standards Track [Page 9] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[9ページ]。
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 }
RTPセッションデータのすべての送付者と受信機で。 ユニキャストRTPセッションのときに、これはリモートRTPシステムのユニキャストアドレスです。 '目的地アドレス組は、IPマルチキャストに関するケースのようにすべての関係者にとって一般的であるかもしれないか、またはそれぞれにおいて、異なるかもしれません、個々のユニキャストの場合では、ネットワーク・アドレスが. 'See RFC1889を対にするとき、'RTP' 'リアルタイムのアプリケーションのためのトランスポート・プロトコル'、秒 3. 輸送サービスはrtpSessionDomainによって特定されます。 snmpUDPDomainに関しては、これは、IPアドレスと隣の、より高い変に番号付のポートにRTCPを送る偶数のUDP Portです、とRFC1889は見ます、秒 5." ::= rtpSessionEntry3
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 }
「ローカルアドレスはRTPシステムで使用した」rtpSessionLocAddr OBJECT-TYPE SYNTAX TAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 IPマルチキャストRTPセッションのときに、rtpSessionRemAddrはrtpSessionLocAddrと同じIPマルチキャストアドレスになるでしょう。 ユニキャストRTPセッションのときに、rtpSessionRemAddrとrtpSessionLocAddrには、異なったユニキャストアドレスがあるでしょう。 'RTP、RFC1889を見てください:、' 'リアルタイムのアプリケーションのためのトランスポート・プロトコル'、秒 3. 輸送サービスはrtpSessionDomainによって特定されます。 snmpUDPDomainに関しては、これは、IPアドレスと隣の、より高い変に番号付のポートにRTCPを送る偶数のUDP Portです、とRFC1889は見ます、秒 5." ::= rtpSessionEntry4
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 }
'RFC2233を見てください、Interfaces Group MIB使用SMIv2。rtpSessionIfIndex OBJECT-TYPE SYNTAX InterfaceIndexマックス-ACCESSがSTATUSの現在の記述を読書して作成する、「ifIndex値が換算値に設定される、-、MIB、(')」。 これは、場合かRTP Monitorの場合でRTP小川が送られるインタフェースである、またはRTCPパケットが受け取られるインタフェースを受けました。 「rtpSessionRowStatusが'アクティブである'なら、変えることができません。」 ::= rtpSessionEntry5
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
rtpSessionSenderJoins OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「この概念的な行が作成されて以来のセッションのときに接合したのが観察された送付者の数」です。
Baugher, et al. Standards Track [Page 10] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[10ページ]。
(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 }
(rtpSessionStartTime。) 送付者は、それに発信することによって、RTPセッションを'接合します'。 いなくなって、次にRTCP BYEに続いて、再加わる送付者('RTP、RFC1889を見てください:、' 'リアルタイムのアプリケーションのためのトランスポート・プロトコル'、秒 6.6) または、セッションタイムアウトは二度数えられるかもしれません。 「新しいRTP送付者がRTPかRTCPを使用するのが検出されるときはいつも、このカウンタは増加されています。」 ::= rtpSessionEntry6
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 }
rtpSessionReceiverJoins OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「それが受信機の数、この概念的な行が作成されて以来(rtpSessionStartTime)このセッションのときに接合しているのが観測される、」 受信機は、RTCP Receiver Reportsをセッションに送ることによって、RTPセッションを'接合します'。 いなくなって、次にRTCP BYEに続いて、再接合する受信機('RTP、RFC1889を見てください:、' 'リアルタイムのアプリケーションのためのトランスポート・プロトコル'、秒 6.6) 「または、セッションタイムアウトは二度数えられるかもしれません。」 ::= rtpSessionEntry7
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 }
rtpSessionByes OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「RTCP BYEのカウント」です。('RTP、RFC1889を見てください:、' 'リアルタイムのアプリケーションのためのトランスポート・プロトコル'、秒 6.6) 「メッセージはこの実体によって受信されました。」 ::= rtpSessionEntry8
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 }
rtpSessionStartTime OBJECT-TYPE SYNTAX TimeStampのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この行が作成された時間のSysUpTimeの値。」 ::= rtpSessionEntry9
rtpSessionMonitor OBJECT-TYPE
SYNTAX TruthValue
MAX-ACCESS read-only
STATUS current
DESCRIPTION
rtpSessionMonitor OBJECT-TYPE SYNTAX TruthValueのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述
Baugher, et al. Standards Track [Page 11] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[11ページ]。
"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 }
「論理演算子、'本当の(1)'へのSetは地方のRTP Systemに加えたリモート送付者か受信機であるならRTCPを使用することでモニターされることになっています。」 RTP Monitorsは'本当の(1)'に初期設定しなければなりません、そして、RTP Hosts SHOULDはこの'誤った(2)'を初期化します。 「'ホストモニター'システムが彼らのリモート関係者からRTCPを受けているので彼らが'本当の(1)'にこの値を設定しなければならないことに注意してください。」 ::= rtpSessionEntry10
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 }
rtpSessionRowStatus OBJECT-TYPE SYNTAX RowStatusマックス-ACCESSは現在の記述が「'アクティブ'をRTPかRTCPメッセージを送ると評価するか、またはRTP Systemは受けた」STATUSを読書して作成します。 新たに作成された概念的な列が持たなければならない、すべてが'アクティブに'なる前に初期化された物を読書して作成します。 「5分後に'notReady'か'notInService'状態にある概念的な列を取り除くかもしれません。」 ::= rtpSessionEntry11
--
-- 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 }
-- -- SENDER INVERSE TABLE--rtpSenderInverseTable OBJECT-TYPEのSYNTAX SEQUENCE OF RtpSenderInverseEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「rtpSenderTableのrtpSenderSSRCインデックスにrtpSenderAddr、rtpSessionIndexを写像します」。 このテーブルで、管理アプリケーションはrtpSessionIndexによって分類されるよりrtpSenderAddrによってむしろ分類されたエントリーを見つけることができます。 rtpSessionDomainとrtpSenderAddrを考えて、木の散歩から1セットのrtpSessionIndexとrtpSenderSSRC値を返すことができます。 「次のSNMP Get操作でrtpSessionIndexを指定するとき、1つ以上のrtpSenderSSRC値を返すかもしれません。」 ::= rtpMIBObjects4
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,
rtpSenderInverseEntry OBJECT-TYPE SYNTAX RtpSenderInverseEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述「各エントリーはちょうどrtpSenderTableの1つのエントリーに対応しています--インデックスを含むエントリーは対にされます、rtpSessionIndex、rtpSenderSSRC。」 インデックス、rtpSessionDomain、rtpSenderAddr、rtpSessionIndex
Baugher, et al. Standards Track [Page 12] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[12ページ]。
rtpSenderSSRC }
::= { rtpSenderInverseTable 1 }
rtpSenderSSRC ::= rtpSenderInverseTable1
RtpSenderInverseEntry ::= SEQUENCE {
rtpSenderInverseStartTime TimeStamp
}
RtpSenderInverseEntry:、:= 系列rtpSenderInverseStartTimeタイムスタンプ
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 }
rtpSenderInverseStartTime OBJECT-TYPE SYNTAX TimeStampのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この列が作成された時間のSysUpTimeの値。」 ::= rtpSenderInverseEntry1
--
-- 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 }
-- -- SENDERS TABLE--アクセスしやすくないSTATUS現在の記述が「送付者の情報かRTP Sessionへの送付者にテーブルの上に置く」rtpSenderTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpSenderEntryマックス-ACCESS。 RTP送付ホストは送られる各流れのためのこのテーブルにエントリーを持たなければなりません。 このホストによって受け取られて、RTP受信ホストはそれぞれの送付の流れのためのこのテーブルにエントリーを持っているかもしれません。 「rtpSessionTableの概念的な列がマネージャによって'アクティブに'されるとき、RTPモニターはそれぞれの観測された送付者のために副作用としてマルチキャストRTP Sessionにエントリーを作成しなければなりません。」 ::= rtpMIBObjects5
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 }
rtpSenderEntry OBJECT-TYPE SYNTAX RtpSenderEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「各エントリーは独身のRTP Sender Synchronization Sourceからの情報を含SSRC、(RFC1889'RTP: レアル-時間ApplicationsのためのTransportプロトコル'sec.6を見てください)であっています」。 セッションはrtpSessionIndexによってSNMP実体に特定されます。 送付者か送付者回であるときに、BYEが外で受け取られているとき、通りはRTPエージェントによって取り除かれます。(Sec、RFC1889を見てください。 6.2.1) 「rtpSessionEntryは削除されます」 rtpSessionIndex、rtpSenderSSRCに索引をつけてください:、:= rtpSenderTable1
Baugher, et al. Standards Track [Page 13] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[13ページ]。
RtpSenderEntry ::= SEQUENCE {
rtpSenderSSRC Unsigned32,
rtpSenderCNAME Utf8String,
rtpSenderAddr TAddress,
rtpSenderPackets Counter64,
rtpSenderOctets Counter64,
rtpSenderTool Utf8String,
rtpSenderSRs Counter32,
rtpSenderSRTime TimeStamp,
rtpSenderPT INTEGER,
rtpSenderStartTime TimeStamp
}
RtpSenderEntry:、:= 系列rtpSenderSSRC Unsigned32、rtpSenderCNAME Utf8String、rtpSenderAddr TAddress、rtpSenderPackets Counter64、rtpSenderOctets Counter64、rtpSenderTool Utf8String、rtpSenderSRs Counter32、rtpSenderSRTimeタイムスタンプ、rtpSenderPT整数、rtpSenderStartTimeタイムスタンプ
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 }
rtpSenderSSRC OBJECT-TYPE SYNTAX Unsigned32のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「RTP SSRC、または送付者の同期ソース識別子。」 「RTPセッションアドレスとSSRCはRTPセッションまで唯一送付者を特定します(RFC1889を見てください、'RTP: レアル-時間ApplicationsのためのTransportプロトコル'sec.3)。」 ::= rtpSenderEntry1
rtpSenderCNAME OBJECT-TYPE
SYNTAX Utf8String
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The RTP canonical name of the sender."
::= { rtpSenderEntry 2 }
rtpSenderCNAME OBJECT-TYPE SYNTAX Utf8Stringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「送付者のRTPの正準な名。」 ::= rtpSenderEntry2
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 }
「ユニキャスト輸送ソースは送付者に記述する」rtpSenderAddr OBJECT-TYPE SYNTAX TAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 「RTP Monitorの場合では、このアドレスは送付者がRTCP Sender Reportsを送るのに使用しているアドレスです。」 ::= rtpSenderEntry3
rtpSenderPackets OBJECT-TYPE
SYNTAX Counter64
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Count of RTP packets sent by this sender, or observed by
「RTPパケットのカウントは、この送付者で送ったか、または見た」rtpSenderPackets OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述
Baugher, et al. Standards Track [Page 14] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[14ページ]。
an RTP monitor, since rtpSenderStartTime."
::= { rtpSenderEntry 4 }
「rtpSenderStartTime以来のRTPモニター。」 ::= rtpSenderEntry4
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 }
「rtpSenderStartTime以来、非ヘッダーRTP八重奏のカウントは、この送付者で送ったか、またはRTPモニターで観測した」rtpSenderOctets OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= rtpSenderEntry5
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 }
書き込み禁止のSTATUSの現在の記述が「流れのアプリケーション・プログラム源について命名する」rtpSenderTool OBJECT-TYPE SYNTAX Utf8String(SIZE(0 .127))マックス-ACCESS。 ::= rtpSenderEntry6
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 }
「Aは、この送付者から送られたRTCP Sender Reportsの数を数えたか、またはRTP実体がモニターである、rtpSenderStartTime以来観測した」rtpSenderSRs OBJECT-TYPE SYNTAX Counter32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= rtpSenderEntry7
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 }
rtpSenderSRTime OBJECT-TYPE SYNTAX TimeStampのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「rtpSenderSRTimeはこの送付者から最後のSRを受け取った時間のSysUpTimeの値です、モニターか受信ホストの場合で」。 「送付ホストの場合でこの送付者によって送られます」。 ::= rtpSenderEntry8
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
大部分のRTPヘッダーからの有効搭載量タイプは最近、RTP Packetを受け取りました。rtpSenderPT OBJECT-TYPE SYNTAX INTEGER(0 .127)のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「(RFC1889を見てください、'RTP:、Transportプロトコル、'、」
Baugher, et al. Standards Track [Page 15] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[15ページ]。
Real-Time Applications' sec. 5)."
::= { rtpSenderEntry 9 }
リアルタイムのアプリケーションの秒 5)." ::= rtpSenderEntry9
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 }
rtpSenderStartTime OBJECT-TYPE SYNTAX TimeStampのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この列が作成された時間のSysUpTimeの値。」 ::= rtpSenderEntry10
--
-- 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 }
-- -- RECEIVER INVERSE TABLE--rtpRcvrInverseTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpRcvrInverseEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述は「rtpRcvrTableのrtpRcvrSRCSSRCとrtpRcvrSSRCインデックスにrtpRcvrAddrとrtpSessionIndexを写像します」。 このテーブルで、管理アプリケーションはrtpSessionIndexでというよりむしろrtpRcvrAddrによって分類されたエントリーを見つけることができます。 rtpSessionDomainとrtpRcvrAddrを考えて、木の散歩から1セットのrtpSessionIndex、rtpRcvrSRCSSRC、およびrtpRcvrSSRC値を返すことができます。 「次のSNMP Get操作でrtpSessionIndexを指定するとき、1rtpRcvrSRCSSRCとrtpRcvrSSRC組を返すかもしれません。」 ::= rtpMIBObjects6
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 OBJECT-TYPE SYNTAX RtpRcvrInverseEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述「各エントリーはちょうどrtpRcvrTableの1つのエントリーに対応しています--インデックスを含むエントリーは対にされます、rtpSessionIndex、rtpRcvrSSRC。」 rtpSessionDomain、rtpRcvrAddr、rtpSessionIndex、rtpRcvrSRCSSRC、rtpRcvrSSRCに索引をつけてください:、:= rtpRcvrInverseTable1
RtpRcvrInverseEntry ::= SEQUENCE {
rtpRcvrInverseStartTime TimeStamp
}
RtpRcvrInverseEntry:、:= 系列rtpRcvrInverseStartTimeタイムスタンプ
rtpRcvrInverseStartTime OBJECT-TYPE
SYNTAX TimeStamp
rtpRcvrInverseStartTimeオブジェクト・タイプ構文タイムスタンプ
Baugher, et al. Standards Track [Page 16] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[16ページ]。
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value of SysUpTime at the time that this row was
created."
::= { rtpRcvrInverseEntry 1 }
マックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この列が作成された時間のSysUpTimeの値。」 ::= rtpRcvrInverseEntry1
--
-- 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 }
-- -- RECEIVERS TABLE--、rtpRcvrTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpRcvrEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「受信機の情報のテーブルかRTPセッションデータの受信機。」 RTPセッションパケットを受けるRTPホストはその受信機/送付者組のためにこのテーブルでエントリーを作成しなければなりません。 セッションパケットをRTPに送るRTPホストは、各受信機のためにこのテーブルでRTPグループからRTCPフィードバックを使用することで彼らの流れにエントリーを作成するかもしれません。 「rtpSessionTableの概念的な列がマネージャによって'アクティブに'されるとき、RTPモニターは副作用としてそれぞれの観測されたRTPセッション受信機のためのエントリーを作成します。」 ::= rtpMIBObjects7
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 OBJECT-TYPE SYNTAX RtpRcvrEntryのマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「各エントリーはrtpRcvrSRCSSRCによって特定された送付者からパケットを受けている独身のRTP Synchronization Sourceからの情報を含SSRC、RFC1889を見てください、('RTP: レアル-時間ApplicationsのためのTransportプロトコル'sec.6)であっています」。 セッションはrtpSessionIndexによってRTPエージェント実体に特定されます。 送付者か送付者回であるときに、BYEが外で受け取られているとき、通りはRTPエージェントによって取り除かれます。(Sec、RFC1889を見てください。 6.2.1) 「rtpSessionEntryは削除されます」 rtpSessionIndex、rtpRcvrSRCSSRC、rtpRcvrSSRCに索引をつけてください:、:= rtpRcvrTable1
RtpRcvrEntry ::= SEQUENCE {
rtpRcvrSRCSSRC Unsigned32,
rtpRcvrSSRC Unsigned32,
rtpRcvrCNAME Utf8String,
rtpRcvrAddr TAddress,
RtpRcvrEntry:、:= 系列、rtpRcvrSRCSSRC Unsigned32、rtpRcvrSSRC Unsigned32、rtpRcvrCNAME Utf8String、rtpRcvrAddr TAddress
Baugher, et al. Standards Track [Page 17] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[17ページ]。
rtpRcvrRTT Gauge32,
rtpRcvrLostPackets Counter64,
rtpRcvrJitter Gauge32,
rtpRcvrTool Utf8String,
rtpRcvrRRs Counter32,
rtpRcvrRRTime TimeStamp,
rtpRcvrPT INTEGER,
rtpRcvrPackets Counter64,
rtpRcvrOctets Counter64,
rtpRcvrStartTime TimeStamp
}
rtpRcvrRTT Gauge32、rtpRcvrLostPackets Counter64、rtpRcvrJitter Gauge32、rtpRcvrTool Utf8String、rtpRcvrRRs Counter32、rtpRcvrRRTimeタイムスタンプ、rtpRcvrPT整数、rtpRcvrPackets Counter64、rtpRcvrOctets Counter64、rtpRcvrStartTimeタイムスタンプ
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 }
rtpRcvrSRCSSRC OBJECT-TYPE SYNTAX Unsigned32のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「RTP SSRC、または送付者の同期ソース識別子。」 「RTPセッションアドレスとSSRCは唯一RTPの流れの送付者か受信機を特定します(RFC1889を見てください、'RTP: レアル-時間ApplicationsのためのTransportプロトコル'sec.3)。」 ::= rtpRcvrEntry1
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 }
rtpRcvrSSRC OBJECT-TYPE SYNTAX Unsigned32のマックス-ACCESSのアクセスしやすくないSTATUS現在の記述、「RTP SSRC. RTPセッションが記述する受信機に関する同期ソース識別子とSSRCが唯一RTPの流れの受信機を特定する、(RFC1889を見てください、'RTP: レアル-時間ApplicationsのためのTransportプロトコル'sec.3)」 ::= rtpRcvrEntry2
rtpRcvrCNAME OBJECT-TYPE
SYNTAX Utf8String
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The RTP canonical name of the receiver."
::= { rtpRcvrEntry 3 }
rtpRcvrCNAME OBJECT-TYPE SYNTAX Utf8Stringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「受信機のRTPの正準な名」、:、:= rtpRcvrEntry3
rtpRcvrAddr OBJECT-TYPE
SYNTAX TAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
rtpRcvrAddr OBJECT-TYPE SYNTAX TAddressのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述
Baugher, et al. Standards Track [Page 18] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[18ページ]。
"The unicast transport address on which the receiver is
receiving RTP packets and/or RTCP Receiver Reports."
::= { rtpRcvrEntry 4 }
「受信機がRTPパケットを受けているユニキャスト輸送アドレス、そして/または、RTCP Receiver Reports。」 ::= rtpRcvrEntry4
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 }
rtpRcvrRTT OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述は「秒のときに説明されたアルゴリズムに基づくRTPの流れの源によって取られた周遊旅行時間測定」です。 '6RFC1889、RTP:、' 'RTPエージェントであるときに. 'Thisアルゴリズムが生産できるレアル-時間Applicationsの重要な結果のためのTransportプロトコルには、流れの送付者と同じ時計があります(また、RTPモニターが特定の受信機のための送付ホストであるときに)。 「さもなければ、実体はrtpRcvrRTTに対する質問に対応して'noSuchInstance'を返すべきです。」 ::= rtpRcvrEntry5
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 }
「RTPパケットのカウントはrtpRcvrStartTime以来この受信機によって観測されるように失った」rtpRcvrLostPackets OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= rtpRcvrEntry6
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 }
rtpRcvrJitter OBJECT-TYPE SYNTAX Gauge32のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「観測されるとしてのこの受信機による遅れ変化の見積り、(RFC1889、'RTP: レアル-時間ApplicationsのためのTransportプロトコル'sec.6.3.1、およびA.8を見ます)、」 ::= rtpRcvrEntry7
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 }
書き込み禁止のSTATUSの現在の記述が「流れのアプリケーション・プログラム源について命名する」rtpRcvrTool OBJECT-TYPE SYNTAX Utf8String(SIZE(0 .127))マックス-ACCESS。 ::= rtpRcvrEntry8
rtpRcvrRRs OBJECT-TYPE
SYNTAX Counter32
rtpRcvrRRsオブジェクト・タイプ構文Counter32
Baugher, et al. Standards Track [Page 19] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[19ページ]。
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 }
「Aは、この受信機から送られたRTCP Receiver Reportsの数を数えたか、またはRTP実体がモニターである、rtpRcvrStartTime以来観測した」マックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= rtpRcvrEntry9
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 }
rtpRcvrRRTime OBJECT-TYPE SYNTAX TimeStampのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「rtpRcvrRRTimeはこの受信機から最後のRTCP Receiver Reportを受け取った時間のSysUpTimeの値です、モニターかRR受信機(RTP Sender)の場合で」。 「それはこの受信機でRRを送るRTP受信機の場合で最後のRRを送った時間のSysUpTimeの値です。」 ::= rtpRcvrEntry10
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 }
「静的であるかダイナミックなペイロードはRTPヘッダーからタイプする」rtpRcvrPT OBJECT-TYPE SYNTAX INTEGER(0 .127)のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述('RTP、RFC1889を見てください:、' リアルタイムのアプリケーションの秒のためのトランスポート・プロトコル 5)." ::= rtpRcvrEntry11
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 }
「rtpRcvrStartTime以来RTPパケットのカウントはこのRTPホスト受信機で受けた」rtpRcvrPackets OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= rtpRcvrEntry12
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 }
「非ヘッダーRTP八重奏のカウントはrtpRcvrStartTime以来RTPが接待するこの受信で受けた」rtpRcvrOctets OBJECT-TYPE SYNTAX Counter64のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 ::= rtpRcvrEntry13
Baugher, et al. Standards Track [Page 20] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[20ページ]。
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 }
rtpRcvrStartTime OBJECT-TYPE SYNTAX TimeStampのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「この列が作成された時間のSysUpTimeの値。」 ::= rtpRcvrEntry14
-- -- 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
-- -- MODULE GROUPS------RTP Systemsの2つのタイプ、RTPホスト、およびRTP Monitorsがあります。 -- したがって、3種類の物があります: 1) 両方に共通の物--システム、2の)種類 RTP Hostsと3に)ユニークな物 物--RTP Monitorsに、ユニークです。 4番目のグループ、4が)あります。 物、それ--、SHOULD、Multicastホストと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
rtpGroups物の識別子:、:= rtpConformance1rtpSystemGroup 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海流
Baugher, et al. Standards Track [Page 21] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[21ページ]。
DESCRIPTION
"Objects available to all RTP Systems."
::= { rtpGroups 1 }
記述が「すべてのRTP Systemsに利用可能な状態で、反対する」、:、:= rtpGroups1
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 }
rtpHostGroup OBJECT-GROUP OBJECTS、rtpSessionLocAddr、rtpSenderPT、rtpRcvrPT、rtpRcvrRTT、rtpRcvrOctets、rtpRcvrPackets、STATUSの現在の記述、「RTP Monitorシステムに利用可能でないかもしれないのを除いて、RTP Hostシステムに利用可能な物」、:、:= rtpGroups2
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 }
rtpMonitorGroup OBJECT-GROUP OBJECTS、rtpSessionNewIndex、STATUSの現在の記述が「列を作成するのに使用されて、RTP Session Tableで反対させる」rtpSessionRowStatus。 「システムが列を作成しないなら、これらの物は必要ではありません。」 ::= rtpGroups3
rtpInverseGroup OBJECT-GROUP
OBJECTS {
rtpSessionInverseStartTime,
rtpSenderInverseStartTime,
rtpRcvrInverseStartTime
}
STATUS current
DESCRIPTION
"Objects used in the Inverse Lookup Tables."
::= { rtpGroups 4 }
rtpInverseGroup OBJECT-GROUP OBJECTS、rtpSessionInverseStartTime、rtpSenderInverseStartTime、rtpRcvrInverseStartTime、「物はInverse Lookup Tablesで使用した」STATUSの現在の記述。 ::= rtpGroups4
--
-- Compliance
--
rtpCompliances OBJECT IDENTIFIER ::= { rtpConformance 2 }
-- -- 承諾--rtpCompliances物の識別子:、:= rtpConformance2
rtpHostCompliance MODULE-COMPLIANCE
STATUS current
rtpHostCompliance MODULE-COMPLIANCE STATUS海流
Baugher, et al. Standards Track [Page 22] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[22ページ]。
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."
記述、「ホスト導入は応じなければなりません」。 MODULE RTP-MIB MANDATORY-GROUPS、rtpSystemGroup、rtpHostGroup、GROUP rtpMonitorGroup記述、「システムをホスティングしてください、私、任意に列の創造と削除を支持してください、」 「これで、RTP HostシステムはRTP Monitorとして作動するでしょう。」 GROUP rtpInverseGroup記述、「マルチキャストRTP Systems SHOULDは任意のテーブルを実行します」。 「列の創造と削除のRTPシステムの実現サポートがOPTIONALであるので、この物の実現はOPTIONAL OBJECT rtpSessionNewIndex MIN-ACCESSのアクセスしやすくない記述です」。 「列の創造と削除のRTPシステムの実現サポートはOPTIONAL OBJECT rtpSessionDomain MIN-ACCESS書き込み禁止記述です」。 「それがいつ支持されないかは、そうが、アクセスを書くOPTIONALです。」 OBJECT rtpSessionRemAddr MIN-ACCESS書き込み禁止記述、「創造をこいでくださいといって、削除がOPTIONALであるのでアクセスを読書して作成してください、この物には、OPTIONALがある、」 OBJECT rtpSessionIfIndex MIN-ACCESS書き込み禁止記述、「創造をこいでくださいといって、削除がOPTIONALであるのでアクセスを読書して作成してください、この物には、OPTIONALがある、」 OBJECT rtpSessionRowStatus MIN-ACCESSのアクセスしやすくない記述、「創造をこいでくださいといって、削除がOPTIONALであるのでアクセスを読書して作成してください、この物には、OPTIONALがある、」 OBJECT rtpSessionInverseStartTime MIN-ACCESSのアクセスしやすくない記述、「マルチキャストRTP Systems SHOULDは任意のテーブルを実行します」。
Baugher, et al. Standards Track [Page 23] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[23ページ]。
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 }
OBJECT rtpSenderInverseStartTime MIN-ACCESSのアクセスしやすくない記述、「マルチキャストRTP Systems SHOULDは任意のテーブルを実行します」。 OBJECT rtpRcvrInverseStartTime MIN-ACCESSのアクセスしやすくない記述、「マルチキャストRTP Systems SHOULDは任意のテーブルを実行します」。 ::= rtpCompliances1
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
rtpMonitorCompliance MODULE-COMPLIANCE STATUSの現在の記述、「モニター実現は応じなければなりません」。 「RTP Monitorsは創造か削除を支持する必要はありません。」 MODULE RTP-MIB MANDATORY-GROUPS、rtpSystemGroup、rtpMonitorGroup、「モニター実現で中の値にrtpHostGroupにアクセスしないかもしれない」GROUP rtpHostGroup記述。 GROUP rtpInverseGroup記述、「マルチキャストRTP Systems SHOULDは任意のテーブルを実行します」。 「RTPかRTCPデータ・パケットのRTPモニターソーシングはOPTIONALです、そして、この物の実現はOPTIONAL OBJECT rtpSessionLocAddr MIN-ACCESSのアクセスしやすくない記述です」。 OBJECT rtpRcvrPT MIN-ACCESSのアクセスしやすくない記述、「RTPモニタシステムはRTPヘッダー(そして、RTCPメッセージだけを受け取るかもしれない)からRTP有効搭載量Typeの検索を支持しないかもしれません」。 「質問された」 ペイロードタイプ情報OBJECT rtpSenderPT MIN-ACCESSには、アクセスしやすくない記述であるときに、「RTPモニタシステムはRTPからRTP有効搭載量Typeの検索を支持しないかもしれません」。
Baugher, et al. Standards Track [Page 24] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[24ページ]。
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
ヘッダー(そして、RTCPメッセージだけを受け取るかもしれません)。 「ペイロードのために質問されたら、情報をタイプしてください。」 OBJECT rtpRcvrOctets MIN-ACCESSのアクセスしやすくない記述、「RTPモニタシステムはRTPメッセージではなく、RTPメッセージの八重奏カウントを含むRTCPメッセージだけを受け取るかもしれません」。 」 OPTIONALはOBJECT rtpRcvrPackets MIN-ACCESSのアクセスしやすくない記述です。「その結果、このオブジェクトの実装、「RTPモニタシステムはRTPメッセージではなく、RTPメッセージの八重奏カウントを含むRTCPメッセージだけを受け取るかもしれません」。 「その結果、このオブジェクトの実装はOPTIONALです。」 OBJECT rtpSessionIfIndex MIN-ACCESS書き込み禁止記述、「作成をこいでくださいといって、削除がOPTIONALであるのでアクセスを読書して作成してください、このオブジェクトには、OPTIONALがある、」 「マルチキャストRTP Systems SHOULDは任意のテーブルを実装する」OBJECT rtpSessionInverseStartTime MIN-ACCESSのアクセスしやすくない記述。 「マルチキャストRTP Systems SHOULDは任意のテーブルを実装する」OBJECT rtpSenderInverseStartTime MIN-ACCESSのアクセスしやすくない記述。 「マルチキャストRTP Systems SHOULDは任意のテーブルを実装する」OBJECT rtpRcvrInverseStartTime MIN-ACCESSのアクセスしやすくない記述。 ::= rtpCompliances2は終わります。
Baugher, et al. Standards Track [Page 25] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[25ページ]。
4. Security Considerations
4. セキュリティ問題
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.
多くの場合、MIBsは自分たちでセキュリティリスクではありません。 SNMPセキュリティがそうであるなら、意図されるとしての作動(システムの情報を見るか、またはシステムの何らかのパラメタを変えるMIBの使用)はツールです、脅威でない。 aがあります。読書して書くことのマックス-ACCESS節を持っているこのMIBで定義された管理オブジェクトに付番する、そして/または、読書して作成します。 そのようなオブジェクトはいくつかのネットワーク環境で敏感であるか、または被害を受け易いと考えられるかもしれません。 適切な保護のない非安全な環境におけるSET操作のサポートはネットワーク操作のときにマイナスの影響がある場合があります。
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.
このMIBの書き込み禁止オブジェクトのいずれもパスワードを報告しません、特定の企業の安全保障政策によって、CNAME[RFC1889]などのいくつかのSDES[RFC1889]の品目(正準な名前)が敏感であると考えられるかもしれませんが。 これらのオブジェクトへのアクセスが適切なアクセス制御方針で制限されないなら、これらのオブジェクトはそのシステムが提供であるというシステムの構成とサービスの情報を攻撃者に提供できます。 いくつかの企業が企業資産として用法と性能に関してそれらのネットワーク、システム構成、および情報を見なします。 そのような企業はMIBでSNMPアクセスをオブジェクトの大部分に制限したがっているかもしれません。 このMIBはそれに書かれているrtpSessionTableでエントリーを作成する副作用を持っているrtpSessionNewIndexに対して読書して書いている操作をサポートします。 rtpSessionEntryの5個のオブジェクトで、アクセスを読書して作成します: rtpSessionDomain、rtpSessionRemAddr、rtpSessionIfIndex、rtpSessionRowStatus、およびrtpSessionIfAddrは、特定のインタフェースでモニターされるためにRTPセッションを特定します。 これらのオブジェクトの値がいったん作成されると変えられないことであり、これらのオブジェクトの初期化はどんなホストエンドシステムにおけるRTPセッションの操作ではなく、RTPセッションのモニターだけに影響します。 rtpSessionNewIndexに操作を書いてください。そうすれば、rtpSessionEntryの5個のオブジェクトがモニターの操作に影響するので、適切なアクセス制御への対象が方針であったならこれらのオブジェクトへのアクセスを書いてください。
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]."
RTPとRTCPデータ・パケットの秘密性はRTP仕様[RFC1889]のセクション9で定義されます。 暗号化はRTPパケット、RTCPパケット、または両方に実行されるかもしれません。 「RTCPに関して、合成RTCPパケットを2つの下層パケット、暗号化されるべき1、および明確で送られる1つに分けることができます」が、RTCPパケットの暗号化は第三者モニターのために問題を設定するかもしれません。 「例えば、第三者モニター[RFC1889]を収容するために明確でレセプションレポートを送った間、SDES情報を暗号化するかもしれません。」
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
それ自体でSNMPv1は安全な環境ではありません。 ネットワーク自体が安全であっても(例えば、IPSecを使用するのによる)、だれが安全なネットワークにアクセスとGET/SETに許容されているかに関してコントロールが全くありません。
Baugher, et al. Standards Track [Page 26] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[26ページ]。
(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.
(読むか、変える、作成する、または削除します) このMIBのオブジェクト。 implementersがSNMPv3フレームワークで提供するようにセキュリティ機能を考えるのは、お勧めです。 明確に、UserベースのSecurity Model RFC2574[RFC2574]とViewベースのAccess Control Model RFC2575[RFC2575]の使用はお勧めです。 そして、本当にGETに正当な権利を持っている校長(ユーザ)をそれらだけへのオブジェクトへのアクセスに与えるか、または(変えるか、作成する、または削除します)それらをSETに与えるために構成されて、それはこのMIBのインスタンスへのアクセスを与えるSNMP実体が適切にそうであることを保証する顧客/ユーザ責任です。
5. Acknowledgements
5. 承認
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.
作者は彼らの役に立つコメントについてITU SG-16経営努力からバートWijnenと関係者に感謝したがっています。 また、インテルからのアランBatieとビル・ルイスはRTP MIBに彼らのMIBの様々な草稿のレビューとSNMP RTP Monitorの実装に対する彼らの仕事で大いに貢献しました。 3ComからのスタンNaudusとインテルからのジョンDuはオリジナルのRTP MIBデザインに貢献して、オリジナルのRTP MIB草稿ドキュメントについて共同執筆しました。 彼らの仕事の多くが現在のRTP MIBに残っています。 ビル・フェナーは最終合意文書の品質を改良したしっかりしたフィードバックを提供しました。
6. Intellectual Property
6. 知的所有権
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.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
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.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
Baugher, et al. Standards Track [Page 27] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[27ページ]。
7. References
7. 参照
[RFC1889] Shulzrinne, H., Casner, S., Frederick, R. and V.
Jacobson, "RTP: A Transport Protocol for real-time
applications," RFC 1889, January 1996.
[RFC1889] Shulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのTransportプロトコル」、RFC1889、1996年1月。
[RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks",
RFC 2571, April 1999.
[RFC2571] ハリントンとD.とPresuhnとR.とB.Wijnen、「SNMP管理フレームワークについて説明するためのアーキテクチャ」、RFC2571、1999年4月。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based Internets",
STD 16, RFC 1155, May 1990.
M.とK.McCloghrie、[RFC1155]は上昇して、「TCP/IPベースのインターネットのための経営情報の構造と識別」(STD16、RFC1155)は1990がそうするかもしれません。
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions",
STD 16, RFC 1212, March 1991.
[RFC1212] ローズとM.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with
the SNMP", RFC 1215, March 1991.
[RFC1215]ローズ、1991年3月のM.、「SNMPとの使用のためのDefining TrapsのためのConvention」RFC1215。
[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.
[RFC2578]McCloghrieとK.、パーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(1999年4月)。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrieとK.とパーキンスとD.とSchoenwaelderとJ.とケースとJ.とローズとM.とS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin,
"Simple Network Management Protocol", STD 15, RFC 1157,
May 1990.
[RFC1157] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン(「簡単なネットワーク管理プロトコル」、STD15、RFC1157)は1990がそうするかもしれません。
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901,
January 1996.
[RFC1901] ケースとJ.とMcCloghrieとK.とローズとM.とS.Waldbusser、「地域密着型のSNMPv2"への紹介、RFC1901、1996年1月。」
[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.
[RFC1906]ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のためのマッピングを輸送します」、RFC1906、1996年1月。
Baugher, et al. Standards Track [Page 28] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[28ページ]。
[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.
[RFC2572] ケース、J.、ハリントンD.、Presuhn R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、RFC2572、1999年4月。
[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.
[RFC2574]ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC2574、1999年4月。
[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.
[RFC1905]ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3
Applications", RFC 2573, April 1999.
[RFC2573] レビとD.とマイヤーとP.とB.スチュワート、「SNMPv3アプリケーション」、RFC2573、1999年4月。
[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.
[RFC2575] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、RFC2575、1999年4月。
[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.
[RFC2570]ケースとJ.とマンディとR.、パーテインとD.とB.スチュワート、「インターネット標準ネットワークマネージメントフレームワークのバージョン3への序論」RFC2570(1999年4月)。
Baugher, et al. Standards Track [Page 29] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[29ページ]。
8. Authors' Addresses
8. 作者のアドレス
Mark Baugher Intel Corporation 2111 N.E.25th Avenue Hillsboro, Oregon 97124 U.S.A.
第25マークBaugherインテル社2111東北Avenueオレゴン97124ヒルズバロ(米国)
EMail: mbaugher@passedge.com
メール: mbaugher@passedge.com
Bill Strahm Intel Corporation 2111 N.E.25th Avenue Hillsboro, Oregon 97124 U.S.A.
第25ビルStrahmインテル社2111東北Avenueオレゴン97124ヒルズバロ(米国)
EMail: Bill.Strahm@intel.com
メール: Bill.Strahm@intel.com
Irina Suconick Ennovate Networks 60 Codman Hill Rd., Boxboro, Ma 01719 U.S.A.
イリーナSuconick Ennovateは60Codmanヒル通り、Boxboro、マ01719米国をネットワークでつなぎます。
EMail: irina@ennovatenetworks.com
メール: irina@ennovatenetworks.com
Baugher, et al. Standards Track [Page 30] RFC 2959 RTP MIB October 2000
Baugher、他 規格はRTP MIB2000年10月にRFC2959を追跡します[30ページ]。
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Baugher, et al. Standards Track [Page 31]
Baugher、他 標準化過程[31ページ]
一覧
スポンサーリンク
