[要約] RFC 3624は、MGCPのバルク監査パッケージに関する規格であり、MGCPベースのメディアゲートウェイの監査機能を提供する。目的は、ネットワーク管理者がメディアゲートウェイの状態を効率的に監視し、トラブルシューティングを行うこと。
Network Working Group B. Foster
Request for Comments: 3624 D. Auerbach
Category: Informational F. Andreasen
Cisco Systems
November 2003
The Media Gateway Control Protocol (MGCP) Bulk Audit Package
メディアゲートウェイ制御プロトコル（MGCP）バルク監査パッケージ
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
IESG Note
IESGノート
This document is being published for the information of the community. It describes a non-IETF protocol that is currently being deployed in a number of products. Implementers should be aware of RFC 3015, which was developed in the IETF Megaco Working Group and the ITU-T SG16, and which is considered by the IETF and the ITU-T to be the standards-based (including reviewed security considerations) way to meet the needs that MGCP was designed to address.
このドキュメントは、コミュニティの情報のために公開されています。現在、多くの製品に展開されている非ITFプロトコルについて説明しています。実装者は、IETF Megaco Working GroupおよびITU-T SG16で開発されたRFC 3015を認識する必要があり、IETFとITU-Tによって標準ベースの（レビューされたセキュリティに関する考慮事項を含む）と見なされます。MGCPが対処するように設計されたニーズを満たします。
Abstract
概要
The base Media Gateway Control Protocol (MGCP) includes audit commands that only allow a Call Agent to audit endpoint and/or connection state one endpoint at a time. This document describes a new MGCP package for bulk auditing of a group of gateway endpoints. It allows a Call Agent to determine the endpoint naming convention, the list of instantiated endpoints as well connection and endpoint state for the group of endpoints.
ベースメディアゲートウェイコントロールプロトコル（MGCP）には、コールエージェントがエンドポイントおよび/または接続状態の1つのエンドポイントのみを一度に監査できるようにする監査コマンドが含まれています。このドキュメントでは、ゲートウェイエンドポイントのグループのバルク監査のための新しいMGCPパッケージについて説明します。コールエージェントがエンドポイントの命名規則、エンドポイントのグループの接続とエンドポイント状態のインスタンス化エンドポイントのリスト、エンドポイントの命名規則を決定できます。
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Bulk Audit Package. . . . . . . . . . . . . . . . . . . . . . 2
2.1. Package Definition. . . . . . . . . . . . . . . . . . . 2
2.1.1. Package Parameters . . . . . . . . . . . . . . . 3
2.1.2. Bulk Auditing of Non-persistent Virtual
Endpoints. . . . . . . . . . . . . . . . . . . . 11
2.1.3. Package Specific Return Codes. . . . . . . . . . 12
2.2. Examples of Package Use . . . . . . . . . . . . . . . . 13
2.2.1. Endpoint List. . . . . . . . . . . . . . . . . . 13
2.2.2. Connection Count List. . . . . . . . . . . . . . 13
2.2.3. Connection Mode List . . . . . . . . . . . . . . 15
2.2.4. Endpoint State . . . . . . . . . . . . . . . . . 15
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5. References. . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 18
7. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 19
The reader is assumed to be familiar with the base MGCP protocol [3].
読者は、ベースMGCPプロトコル[3]に精通していると想定されています。
The base Media Gateway Control Protocol (MGCP) [3] includes audit commands that only allow a Call Agent to audit an endpoint and/or a connection state, one endpoint at a time. This document describes a new MGCP package for bulk auditing of a group of gateway endpoints. It allows a Call Agent to determine the endpoint naming convention, to determine the list of instantiated endpoints, and to determine the connection and endpoint state for the group of endpoints. This is particularly important in fail-over situations in which there are gateways that have large numbers of endpoints.
ベースメディアゲートウェイコントロールプロトコル（MGCP）[3]には、コールエージェントがエンドポイントおよび/または接続状態のみを監査できるようにする監査コマンドが含まれています。このドキュメントでは、ゲートウェイエンドポイントのグループのバルク監査のための新しいMGCPパッケージについて説明します。コールエージェントは、エンドポイントの命名規則を決定し、インスタンス化されたエンドポイントのリストを決定し、エンドポイントのグループの接続とエンドポイントの状態を決定できます。これは、多くのエンドポイントを備えたゲートウェイがあるフェイルオーバー状況で特に重要です。
Conventions Used in this Document
このドキュメントで使用されている規則
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [2]に記載されているように解釈される。
Package Name: BA
パッケージ名：BA
Package Version: 0 Package Description: This package provides the Call Agent the ability to audit and obtain high-level view of endpoint and connection state for a group of endpoints in a gateway.
パッケージバージョン：0パッケージ説明：このパッケージは、コールエージェントに、ゲートウェイ内のエンドポイントのグループのエンドポイントと接続状態の高レベルビューを監査および取得する機能を提供します。
A new BulkRequestedInfo parameter is defined for use in the AuditEndpoint command. The parameter can be used to request a compact list of EndpointIds or to request a high level view of endpoint or connection state for a group of endpoints as defined below:
auditendpointコマンドで使用するために、新しいbulkrequestedinfoパラメーターが定義されています。パラメーターを使用して、エンドポイントイドのコンパクトリストを要求するか、以下に定義するエンドポイントのグループのエンドポイントまたは接続状態の高レベルビューを要求することができます。
ReturnCode,
[EndPointNameList,]
[InstantiatedEndpointList,]
[ConnectionCountList,]
[ConnectionModeList,]
[EndpointStateList,]
[NextEndpointName,]
[ReportedEndpointList]
<-- AuditEndPoint(EndpointId,
[StartEndpointName,]
[MaxNumEndpoints,]
[BulkRequestedInfo])
Unlike the normal RequestedInfo parameter in the base MGCP specification, the BulkRequestedInfo parameter associated with the Bulk Audits package can be used with "all-of" wildcards for auditing a collection of endpoints. However, it is not an error to specify an EndpointId without wildcards.
ベースMGCP仕様の通常のRequestEdInfoパラメーターとは異なり、バルク監査パッケージに関連付けられているBulkRequestedInfoパラメーターは、エンドポイントのコレクションを監査するための「Oll-of」ワイルドカードで使用できます。ただし、ワイルドカードなしでendpointIDを指定することはエラーではありません。
The following sub-sections describe the parameters associated with the Bulk Audit Command in detail. Sections 2.1.1.1 and 2.1.1.2 describe the parameters that can be included with a request and sections 2.1.1.3 to 2.1.1.8 describe return parameters.
次のサブセクションでは、バルク監査コマンドに関連するパラメーターを詳細に説明しています。セクション2.1.1.1および2.1.1.2は、リクエストに含めることができるパラメーターとセクション2.1.1.3から2.1.1.8について説明します。
Because wild-carding may not be sufficient to qualify the endpoints of interest, further qualification can be provided by including a StartEndpointName (the first endpoint of interest) and MaxNumEndPoints (the maximum number of endpoints of interest). These parameters are described according to the following Augmented BNF (ABNF) Syntax (refer to RFC 2234 for ABNF syntax definitions [1]):
Wild Cardingは関心のあるエンドポイントを適格にするのに十分ではないかもしれないため、StartEndPointName（関心のある最初のエンドポイント）とMaxNumendPoints（最大エンドポイントの対象点の最大数）を含めることにより、さらなる資格を提供できます。これらのパラメーターは、以下の拡張BNF（ABNF）構文に従って説明されています（ABNF構文定義についてはRFC 2234を参照[1]）：
"BA/SE" ":" 0*WSP LocalEndpointName
"BA/NU" ":" 0*WSP MaxNumEndpoints
where MaxNumEndpoints is the decimal number of endpoints with a value in the range 1 to 65535. The MaxNumEndpoints parameter SHOULD only be included when requesting an audit for an EndpointStateList and/or ConnectionCountList. If included in a request for the EndPointNameList or InstantiatedEndpointList, it MAY be ignored.
MaxNumendPointsは、範囲1〜65535の値を持つエンドポイントの小数点数です。MaxNumendPointsパラメーターは、EndPointStateListおよび/またはConnectionCountListの監査を要求する場合にのみ含める必要があります。EndPointNameListまたはInstantimedEndPointListのリクエストに含まれている場合、無視される場合があります。
Note that only the LocalEndpointName (see ABNF grammar in [3]) is provided in request and response parameter lines for this package rather than the full EndpointName. This is done for the sake of compactness, i.e., the domain name portion is left out since it is already available in the command line portion of a given request.
LocalEndPointName（[3]のABNF文法を参照）のみが、フルエンドポイント名ではなく、このパッケージのリクエストおよび応答パラメーター行で提供されていることに注意してください。これは、コンパクトさのために行われます。つまり、特定のリクエストのコマンドライン部分ですでに利用可能であるため、ドメイン名の部分は除外されます。
If the list of endpoints defined by the StartEndpointName and MaxNumEndPoints is outside the range designated by the wild-carding, a report will only be returned for endpoints up to those specified within the wild-card range.
StartEndPointNameおよびMaxNumendPointsによって定義されたエンドポイントのリストがワイルドカードによって指定された範囲の外側にある場合、レポートは、エンドポイントに対してワイルドカード範囲内で指定されたものにのみ返されます。
The BulkRequestedInfo parameter line is described according to the following ABNF syntax definitions:
BulkRequestedInfoパラメーター行は、次のABNF構文定義に従って説明されています。
BulkRequestedInfo = "BA/F:" 0*WSP
*( EndpointOrInstantList *("," EndpointOrInstantList))
/ *( EndpointOrConnState *("," EndpointOrConnState))
EndpointOrConnState = "BA/C" / "BA/M" / EndpointStateParam
EndpointOrInstantList = "BA/Z" / "BA/X"
EndpointStateParam = "BA/S" "(" StateType
0*("," 0*(WSP) StateType)")"
StateType = "I" / "D" / "N" / "S" / "H"
where the BulkRequestedInfo parameters have the following meaning:
BulkRequestedInfoパラメーターには次の意味があります。
* "BA/Z" is a request to return EndPointNameList * "BA/X" is a request to return InstantiatedEndpointList * "BA/C" is a request to return the ConnectionCountList * "BA/M" is a request to return the ConnectionModeList * "BA/S" is a request to return the EndpointStateList
* "ba/z"はendpointnameList * "ba/x"を返すリクエストです。「ba/s」は、endpointStateListを返すリクエストです
Each of the parameters can be provided at most once in the BulkRequestedInfo.
各パラメーターは、BulkRequestedInfoでせいぜい1回提供できます。
EndpointStateParam Parameter:
EndPointStateParamパラメーター：
As indicated in the above ABNF, the EndpointStateParam parameter is itself parameterized with one or more StateType parameters that define the conditions to be evaluated for the endpoint:
上記のABNFに示されているように、エンドポイントStateParamパラメーターは、エンドポイントの評価される条件を定義する1つ以上のStateTypeパラメーターでパラメーター化されています。
* "I" - the endpoint is in-service, * "D" - the endpoint is disconnected (see sections 4.3 and 4.4.7 of [3] for a discussion on disconnected endpoints), * "N" - the endpoint is in the notification state, * "L" - the endpoint is in lockstep state (i.e., waiting for an RQNT after a response to a NTFY has occurred while in lockstep mode) * "S" - there is an active on-off (OO) or timeout (TO) signal on the endpoint, * "H" - the endpoint is in some state other than "idle". The meaning of this last parameter depends on the type of endpoint: * The parameter has no meaning for endpoints that only provide bearer services (with no state that the endpoint is aware of). In this case, the condition is always evaluated to false (corresponding to "idle"). * For endpoints that have a state machine associated with them (such as a CAS endpoint), the endpoint MUST be in some state other than the "idle" state in order for the condition to be evaluated as true. * In the case where the endpoint has hook-state associated with it, the hook-state MUST be off-hook. In the case of digital channel associated signaling (CAS) connections, hook-state may be provided in either direction. If the hook-state in either direction is off-hook, the endpoint is considered non-idle, i.e., the condition is satisfied.
* "i" - エンドポイントはインサービスです * "d" - エンドポイントは切断されます（切断されたエンドポイントに関する議論については[3]のセクション4.3および4.4.7を参照）、 * "n" - エンドポイントは通知状態 * "l" - エンドポイントはロックステップ状態にあります（つまり、ntfyへの応答がロックステップモード中に発生した後、RQNTを待つ） *「S」 - アクティブなオンオフ（OO）またはエンドポイントでのタイムアウト（to）信号、 * "h" - エンドポイントは「アイドル」以外の一部の状態にあります。この最後のパラメーターの意味は、エンドポイントのタイプに依存します。 *パラメーターは、ベアラーサービスのみを提供するエンドポイントに対して意味がありません（エンドポイントが認識している状態はありません）。この場合、条件は常にfalseに評価されます（「アイドル」に対応）。*状態マシン（CASエンドポイントなど）を持つエンドポイントの場合、エンドポイントは、条件を真であると評価するためには、「アイドル」状態以外の状態になければなりません。*エンドポイントにフックステートが関連付けられている場合、フックステートはオフフックでなければなりません。デジタルチャネル関連シグナル伝達（CAS）接続の場合、フックステートはどちらの方向にも提供される場合があります。いずれかの方向のフック状態がオフフックである場合、エンドポイントは非アイドルと見なされます。つまり、条件は満たされます。
The list of StateTypes may be extended in the future. If an unknown StateType is encountered, the command MUST be rejected with error code 803 (i.e., "unsupported StateType").
統計タイプのリストは将来拡張される可能性があります。不明なステートタイプに遭遇した場合、コマンドはエラーコード803（つまり、「サポートされていないステートタイプ」）で拒否されなければなりません。
The report, provided as a result of this request, yields an indication of either "True", "False", or "Out of Service" for each endpoint. If the endpoint is in-service and any one of the criteria holds true, then the report for the endpoint will evaluate to "True". A "False" indication will only be reported if the endpoint is in-service and all criteria evaluate to false. The report thus provides the logical "OR" function over the conditions audited for endpoints in-service. Irrespective of the state being audited, an "Out of Service" indication will always be reported if the endpoint is considered out-of-service.
この要求の結果として提供されたレポートは、各エンドポイントの「真」、「偽」、または「サービスを受けていない」のいずれかを示しています。エンドポイントがインサービスであり、基準のいずれかが真である場合、エンドポイントのレポートは「真」と評価されます。エンドポイントがインサービスであり、すべての基準がfalseと評価されている場合にのみ、「偽」の表示が報告されます。したがって、このレポートは、エンドポイントのインサービスで監査された条件に対する論理的な「または「関数」を提供します。州が監査されていることに関係なく、エンドポイントがサービス外であると見なされる場合、「サービスを受けていない」兆候は常に報告されます。
Note that the criteria "D", "N", "L", "S" and "H" can only be true if the endpoint is in-service, so that requesting "I" at the same time (although allowed) would be unnecessary (i.e., redundant).
基準「d」、「n」、「l」、「s」、および「h」は、エンドポイントがインサービスである場合にのみ真であることに注意してください。不必要に（つまり、冗長）。
Example: If the request for EndpointStateList for one or more endpoints includes the parameter line:
例：1つ以上のエンドポイントのEndPointStateListのリクエストにパラメーター行が含まれている場合：
BA/F: BA/S(D,N)
Ba/f：ba/s（d、n）
indicating a request for a report on whether endpoints are disconnected or in the notification state. If a given endpoint is in either a "disconnected" or "notification" state, then the report will indicate "True" for that endpoint. If the endpoint is neither in a disconnected state nor in a notification state, but is in-service, then the report for that endpoint will indicate "False". If the endpoint is out-of-service, then the report for that endpoint will indicate "Out of Service".
エンドポイントが切断されているか、通知状態でエンドポイントが切断されているかについてのレポートのリクエストを示します。特定のエンドポイントが「切断された」または「通知」状態のいずれかにある場合、レポートはそのエンドポイントの「真」を示します。エンドポイントが切断された状態でも通知状態でもないが、インサービスである場合、そのエンドポイントのレポートは「false」を示します。エンドポイントがサービス外である場合、そのエンドポイントのレポートは「サービスを停止していない」ことを示します。
In order to only determine whether an endpoint is in-service or out-of service, the Call Agent should make a request with only the "I" StateType parameter.
エンドポイントがサービス内であるかサービス外かを判断するために、コールエージェントは「i」StateTypeパラメーターのみでリクエストを行う必要があります。
EndPointNameList Parameter:
EndPointNameListパラメーター：
The EndPointNameList is a list of the endpoint names (i.e., the endpoint naming convention for the endpoints configured for service) supported by the gateway as qualified by the wildcarded EndPointId, and possibly StartEndPointName and MaxNumEndpoints parameters. This list can include one or more lines in the following ABNF format:
EndPointNameListは、WildCarded EndPointID、およびおそらくStartEndPointNameおよびMaxNumendPointsパラメーターによって資格があるゲートウェイでサポートされているエンドポイント名（つまり、サービス用に構成されたエンドポイントのエンドポイント命名規則）のリストです。このリストには、次のABNF形式に1つ以上の行を含めることができます。
"BA/Z:" 0*WSP RangedLocalName 0*("," 0*WSP RangedLocalName)
where RangedLocalName is a LocalEndpointName that may include the ranged wildcard notation described in Appendix E (section E.5) of [3], i.e.,:
RangedLocalNameは、[3]の付録E（セクションE.5）に記載されている範囲のワイルドカード表記を含むLocalEndPointNameです。
RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]" NumericalRange = 1*(DIGIT) [ "-" 1*(DIGIT) ].
rangewildcard = "[" numericalrange*（ "、" numericalrange） "]" numericalrange = 1*（digit）[" - " 1*（digit）]。
Example:
例：
ba/z: ds/ds1-1/[1-24], ds/ds1-2/[1-24], ds/ds1-3/[1-24]
BA/Z：DS/DS1-1/[1-24]、DS/DS1-2/[1-24]、DS/DS1-3/[1-24]
or simply:
または単に：
ba/z: ds/ds1-[1-3]/[1-24]
BA/Z：DS/DS1- [1-3]/[1-24]
Note that, since range wildcards use the character "[" to indicate the start of a range, the "[" character MUST NOT be used in endpoint names that use range wildcards.
範囲のワイルドカードは文字「」を使用して範囲の開始を示すため、「」文字は範囲のワイルドカードを使用するエンドポイント名で使用してはならないことに注意してください。
Note that the ranged wildcard notation (RangeWildcard above) also allows commas between ranges like:
上記の距離にあるワイルドカード表記（上記のレンジワイルドカード）は、次のような範囲間のコンマも可能であることに注意してください。
ba/z: ds/ds1-1/[1,3-5,8-24]
BA/Z：DS/DS1-1/[1,3-5,8-24]
For virtual endpoints, that are automatically created and deleted on the fly by the gateway, there is a difference between reporting the endpoint names (i.e., the "naming convention") used in describing the endpoints and reporting the actual endpoints that are instantiated at the time the request is made. For this case:
ゲートウェイによって自動的に作成および削除された仮想エンドポイントの場合、エンドポイントの記述に使用されるエンドポイント名（つまり、「命名条約」）の報告と、インスタンス化された実際のエンドポイントの報告には違いがあります。リクエストが作成されます。この場合：
* EndPointNameList is a request to return the naming convention and
* EndPointNameListは、命名規則を返すリクエストであり、
* InstantiatedEndpointList is a request to return the "real" (or instantiated) endpoints.
* InstantiMedEndPointListは、「実際の」（またはインスタンス化された）エンドポイントを返すリクエストです。
InstantiatedEndpointList Parameter:
instantimedendpointlistパラメーター：
The syntax of the InstantiatedEndpointList value is the same as the EndPointNameList value returned with EndPointNameList, i.e., a number of lines may be returned with the following syntax:
InstantiedEndPointList値の構文は、EndPointNameLISTで返されたEndPointNameList値と同じです。つまり、次の構文で多くの行が返される場合があります。
"BA/X:" 0*WSP RangedLocalName 0*("," 0*WSP RangedLocalName)
In the case of hard-wired/physical endpoints (such as DSO's) or other persistent endpoints, the InstantiatedEndpointList would normally not be requested. However, if it is requested, the InstantiatedEndpointList and the EndPointNameList will be the same.
ハードワイヤード/物理エンドポイント（DSOなど）またはその他の永続的なエンドポイントの場合、通常は要求されません。ただし、要求されている場合、InstantiedEndPointListとEndPointNameListは同じになります。
For virtual endpoints that are not persistent, an "all of" wild card ("*") is returned for the leftmost term of the name, which is dynamically assigned in the EndPointNameList to indicate that arbitrary names apply, and that the endpoints are virtual and non-persistent. The "all of" wild card notation MUST NOT be used when returning the EndPointNameList for persistent endpoints however. The following example illustrates this:
永続的ではない仮想エンドポイントの場合、「すべての」ワイルドカード（ "*"）のすべての名前が名前の左端に返されます。これは、任意の名前が適用され、エンドポイントが仮想であることを示すためにエンドポイントズメリストに動的に割り当てられます。と非存在。ただし、「すべて」のワイルドカード表記は、永続的なエンドポイントのためにエンドポイントノーメリストを返す際に使用してはなりません。次の例はこれを示しています：
ba/z: announcement/* ba/z: foo/bar/* ba/z: foo/foo/* The "all of" wildcard tells us, that "announcement" is simply the leftmost term for a dynamic set of non-persistent virtual endpoints. To instantiate one of these endpoints, we would include the "any of" wildcard (e.g., "announcement/$") as the LocalEndpointName in the EndpointId of a request (e.g., NotificationRequest or CreateConnection). The response would then include the SpecificEndpointId indicating the instantiated endpoint. Also, note in the above example that "foo" defines two different levels of non-persistent virtual endpoints.
ba/z：naunnal/* ba/z：foo/bar/* ba/z：foo/foo/* "all" wildcardが私たちに伝えている、「アナウンス」は単に非ダイナミックなセットの左端の用語であると言うこと永続的な仮想エンドポイント。これらのエンドポイントのいずれかをインスタンス化するために、「WildCard（例： "Annutant/$"）のいずれかを要求のendpointid（たとえば、NotificationRequestまたはCreateConnection）のLocalEndPointNameとして含めます。その後、応答には、インスタンス化されたエンドポイントを示すrepatedPointIDが含まれます。また、上記の例では、「foo」は2つの異なるレベルの非密接な仮想エンドポイントを定義していることに注意してください。
The ConnectionCountList indicates the number of connections on a series of endpoints. It consists of a number of lines with the following ABNF syntax:
ConnectionCountListは、一連のエンドポイントの接続数を示します。これは、次のABNF構文を持つ多くの線で構成されています。
"BA/C:" 0*WSP NumConnections 0*(NumConnections)
where NumConnections is either:
numConnectionsは次のとおりです。
* a hexadecimal digit indicating the number of connections on the endpoint corresponding to the position on the list, or
* リストの位置に対応するエンドポイント上の接続の数を示す16進数、または
* the letter "Z" indicating that there are more than 15 connections on this endpoint.
* このエンドポイントに15を超える接続があることを示す文字「z」。
The ConnectionModeList indicates the connection modes for all the connections on a series of endpoints. It consists of a number of lines with the following ABNF syntax:
ConnectionModelistは、一連のエンドポイントのすべての接続の接続モードを示します。これは、次のABNF構文を持つ多くの線で構成されています。
"BA/M:" 0*WSP ModeOrCount 0*(ModOrCount)
ModeOrCount = ConnCount / ConnMode
ConnMode = "I" / "S" / "R" / "B" / "C" / "L" / "T" / "N" / "U"
where ConnCount is either hexadecimal value corresponding to 0-15 connections on an endpoint or the value "Z", indicating that more than 15 connections are present.
ここで、conncountはエンドポイント上の0〜15接続または値「z」に対応する16進数のいずれかで、15を超える接続が存在することを示しています。
ConnMode indicates the connection mode where:
connmodeは接続モードを示します。
* "I" indicates "inactive" connection mode * "S" indicates "sendonly" connection mode * "R" indicates "recvonly" connection mode * "B" indicates "sendrecv" connection mode * "C" indicates "confrnce" connection mode * "L" indicates "loopback" connection mode * "T" indicates "conttest" connection mode * "N" indicates "netwloop" connection mode * "U" indicates some other connection mode
* 「I」は「非アクティブ」接続モード *を示します * "s"は "sendonly"接続モード *を示します * "r"は "recvonly"接続モードを示します * "b"は "sendrecv"接続モード * "c"を示します。「l」は「ループバック "接続モード *「t」が「conttest」接続モードを示す「t」を示す *" n "は「ネットループ」接続モードを示します *" u "は他の接続モードを示します
For a definition of MGCP connection modes, refer to section 3.2.2.6 of [3].
MGCP接続モードの定義については、[3]のセクション3.2.2.6を参照してください。
If an endpoint has no connections on it, ModeOrCount is given the value "0". If there is one connection associated with the endpoint, the symbol for the connection mode (ConnMode) is provided. If, on the other hand, there are from 2 to 15 connections, a symbol representing the number of connections (ConnCount) is provided followed by a list of symbols indicating the connection mode (ConnMode) for each connection. If there are more than 15 connections, "Z" is indicated for ConnCount and no connection modes are provided for the connections on that endpoint.
エンドポイントに接続がない場合、ModeorCountに値「0」が与えられます。エンドポイントに関連付けられた1つの接続がある場合、接続モードのシンボル（connmode）が提供されます。一方、2〜15の接続がある場合、接続の数（conncount）を表すシンボルが提供され、その後、各接続の接続モード（connmode）を示すシンボルのリストが提供されます。15を超える接続がある場合、conncountに「z」が示されており、そのエンドポイントの接続に接続モードは提供されていません。
The EndpointStateList gives an overview of the endpoint state for a series of endpoints. It consists of a number of lines with the following ABNF syntax:
EndPointStateListは、一連のエンドポイントのエンドポイント状態の概要を示します。これは、次のABNF構文を持つ多くの線で構成されています。
"BA/S:" 0*WSP EndPointState 0*(EndPointState)
EndPointState = "T" / "F" / "O"
where:
ただし：
* "T" indicates "True" * "F" indicates "False" * "O" indicates "Out of Service"
* 「t」は「true」 *「f」が「false」 *「o」を示す「false」を示します。
The "True" or "False" determination is based on the criteria supplied in StateType parameters when the request is made.
「真」または「偽」の決定は、リクエストが行われたときにStatetypeパラメーターで提供される基準に基づいています。
Note that the EndPointState indicator does not say anything about the connection state of the endpoint.
エンドポイントステートインジケーターは、エンドポイントの接続状態について何も言わないことに注意してください。
The NextEndpointName parameter will be included in the return, if there are additional endpoints in this gateway covered by the wild-carded endpoint name that were not reported, but for which information was available to be reported.
次のゲートウェイには、報告されていないが報告できるワイルドカードエンドポイント名で覆われたこのゲートウェイに追加のエンドポイントがある場合、nextEndpointNameパラメーターが返品に含まれます。
Note that the NextEndpointName is the LocalEndpointName (as opposed to EndpointName) of the next endpoint after the last endpoint reported. The syntax is as follows:
次のエンドポイントが報告された後、NextEndPointNameは次のエンドポイントのLocalEndPointName（EndPointNameとは対照的に）であることに注意してください。構文は次のとおりです。
"BA/NE" ":" 0*WSP LocalEndpointName
A gateway may supply a report that is shorter than the request if the resulting report would have resulted in a message that would be too large (i.e., such that the report is larger than the maximum datagram size). In the case where the gateway supplied a response for less endpoints than requested, the gateway MUST supply NextEndpointName in the response.
ゲートウェイは、結果のレポートが大きすぎるメッセージが得られる場合（つまり、レポートが最大データグラムのサイズよりも大きくなるように）、リクエストよりも短いレポートを提供する場合があります。ゲートウェイが要求よりも少ないエンドポイントの応答を提供した場合、ゲートウェイは応答でNextEndPointNameを提供する必要があります。
In order to continue the audit on a following set of endpoints, the Call Agent can make a further request by using the NextEndpointName as the starting point (e.g., as the StartEndpointName in a following request).
次の一連のエンドポイントで監査を継続するために、コールエージェントは、nextEndpointNameを開始点として使用してさらにリクエストを行うことができます（たとえば、以下のリクエストのStartEndPointNameとして）。
A ReportedEndpointList MUST be provided in a response line before list(s) of EndpointStateList and/or ConnectionCountList in order to clearly specify the list of endpoints that are being reported. The ABNF syntax is as follows:
報告されているエンドポイントのリストを明確に指定するために、報告されたEndpointStateListおよび/またはConnectionCountListのリストの前の応答行で提供する必要があります。ABNF構文は次のとおりです。
"BA/EL:" 0*WSP LimitedRangedName 0*("," 0*WSP LimitRangedName)
where LimitedRangedName is a LocalEndpointName that may include a ranged wildcard notation (RangeWildcard syntax indicated earlier). However, unlike the RangedLocalName that allows the range wildcard notation to be used on multiple terms of the local name at the same time, LimitedRangedName only allows the range notation to be used for the last term, i.e., the following is valid:
LimitedRangedNameは、遠隔のワイルドカード表記を含むLocalEndPointNameです（以前に示すRangeWildCard構文）。ただし、範囲のワイルドカード表記をローカル名の複数の項で同時に使用できるようにするRangedLocalNameとは異なり、LimitedRangedNameでは、範囲表記を最後の用語でのみ使用できます。つまり、以下は有効です。
ba/el: ds/ds1-1/[1,3-5,8-24]
BA/EL：DS/DS1-1/[1,3-5,8-24]
or
または又はそれとも若しくは乃至或るいは
ba/el: ds/ds1-1/[1-24], ds/ds1-2/[1-24], ds/ds1-3/[1-24]
BA/EL：DS/DS1-1/[1-24]、DS/DS1-2/[1-24]、DS/DS1-3/[1-24]
However, the following is not valid:
ただし、以下は無効です。
ba/el: ds/ds1-[1-3]/[1-24]
BA/EL：DS/DS1- [1-3]/[1-24]
Note that a single bulk audit request may include a request to return both ConnectionCountList and EndpointStateList. However, the resulting report that includes both MUST cover the same endpoints.
単一のバルク監査リクエストには、ConnectionCountListとEndPointStateListの両方を返すリクエストが含まれる場合があることに注意してください。ただし、両方を含む結果のレポートは、同じエンドポイントをカバーする必要があります。
A single bulk audit request may also include a request to return both EndPointNameList and InstantiatedEndpointList. However, requests for either an EndPointNameList and/or an InstantiatedEndpointList MUST NOT include a request for either ConnectionCountList or EndpointStateList.
単一のバルク監査リクエストには、EndPointNameListとInstantiedEndPointListの両方を返すリクエストも含まれます。ただし、EndPointNameListおよび/またはInstantimedEndPointListのいずれかのリクエストには、ConnectionCountListまたはEndPointStateListのいずれかのリクエストを含めてはなりません。
Note that gateways that have non-persistent virtual endpoints may have instantiated endpoints that are disjoint with respect to the name space. The ReportedEndpointList in front of a ConnectionCountList and/or EndpointStateList describes exactly which endpoints are being reported.
非密接な仮想エンドポイントを持つゲートウェイには、名前空間に関してはばらばらであるエンドポイントがインスタンス化されている可能性があることに注意してください。ConnectionCountListおよび/またはEndPointStateListの前にあるReportEndPointListは、どのエンドポイントが報告されているかを正確に説明しています。
Example:
例：
A Call Agent requests to know about the EndPointNameList for the endpoints on a conference bridge:
コールエージェントは、カンファレンスブリッジのエンドポイントのエンドポイントズマナリストについて知るように要求します。
AUEP 1200 *@gw1.x.net MGCP 1.0 BA/F: BA/Z
auep 1200 *@gw1.x.net mgcp 1.0 ba/f：ba/z
Response:
応答：
200 1200 OK ba/z: cnf/*
200 1200 OK BA/Z：CNF/*
This indicates the naming convention but in fact not all of these endpoints are instantiated. A request for the list of instantiated endpoints, i.e.,:
これは命名規則を示していますが、実際にはこれらのエンドポイントのすべてがインスタンス化されているわけではありません。インスタンス化されたエンドポイントのリストのリクエスト、すなわち、：
AUEP 1201 cnf/*@gw1.x.net MGCP 1.0 BA/F: BA/X
auep 1201 cnf/*@gw1.x.net mgcp 1.0 ba/f：ba/x
might yield:
収益を得るかもしれません：
200 1201 OK ba/x: cnf/[1-3] ba/x: cnf/[6-12]
200 1201 OK BA/X：CNF/[1-3] BA/X：CNF/[6-12]
indicating that only these particular endpoints are instantiated.
これらの特定のエンドポイントのみがインスタンス化されていることを示します。
Suppose the Call Agent now asks for the ConnectionCountList i.e.,:
コールエージェントがConnectionCountListを要求すると仮定します。
AUEP 1202 cnf/*@gw1.x.net MGCP 1.0 BA/F: BA/C
auep 1202 cnf/*@gw1.x.net mgcp 1.0 ba/f：ba/c
The resulting instantiated virtual endpoints may be disjoint, which would be indicated by the ReportedEndpointList in front of the ConnectionCountList, e.g.,:
結果として生じるインスタンス化された仮想エンドポイントは、connectionCountListの前にあるREPORTENDPOINTLISTによって示される可能性があります。
200 1202 OK ba/el: cnf/[1-3] ba/c: 035 ba/el: cnf/[6-12] ba/c: 3450333
200 1202 OK BA/EL：CNF/[1-3] BA/C：035 BA/EL：CNF/[6-12] BA/C：3450333
or alternatively:
または、または：
200 1202 OK ba/el: cnf/[1-3], ba/el: cnf/[6-12] ba/c: 035 ba/c: 3450333
200 1202 OK BA/EL：CNF/[1-3]、BA/EL：CNF/[6-12] BA/C：035 BA/C：3450333
or
または又はそれとも若しくは乃至或るいは
200 1202 OK ba/el: cnf/[1-3], ba/el: cnf/[6-12] ba/c: 0353450333
200 1202 OK BA/EL：CNF/[1-3]、BA/EL：CNF/[6-12] BA/C：0353450333
The following return codes are specific to this package:
次の返品コードは、このパッケージに固有です。
800 Invalid NextEndpointName 801 Invalid StartEndpointName 802 Invalid or unsupported BulkRequestInfo Parameter 803 Invalid or unsupported StateType 804 Bulk Audit Type not supported 805 Incorrectly specified endpoint range 806 Requested StartEndpoint unknown or unavailable
800 Invalid NextEndPointName 801 Invalid startEndPointName 802無効またはサポートされていないBulkRequestinfoパラメーター803無効またはサポートされていないStateType 804バルク監査タイプはサポートされていません
Note that package specific error codes includes the package name following the error code. For example, if error code 801 occurs in response to a request with a transaction ID of 1001 it would be sent as:
パッケージ固有のエラーコードには、エラーコードに続くパッケージ名が含まれていることに注意してください。たとえば、1001のトランザクションIDでリクエストに応じてエラーコード801が発生した場合、次のように送信されます。
801 1001 /BA
801 1001 /ba
This section contains examples of how to obtain a list of endpoints.
このセクションには、エンドポイントのリストを取得する方法の例が含まれています。
Example 1: This is an example of a gateway that contains a single OC3 that contains a single level of hierarchy at the T1 level.
例1：これは、T1レベルで単一のレベルの階層を含む単一のOC3を含むゲートウェイの例です。
The request is made:
リクエストが行われます：
AUEP 1200 *@gw1.x.net MGCP 1.0 BA/F: BA/Z
auep 1200 *@gw1.x.net mgcp 1.0 ba/f：ba/z
This may result in a single "BA/Z" term with ranges specifying all of the endpoints.
これにより、すべてのエンドポイントを指定する範囲を備えた単一の「Ba/z」用語が生じる場合があります。
200 1200 OK ba/z: ds/ds1-[1-84]/[1-24]
200 1200 OK BA/Z：DS/DS1- [1-84]/[1-24]
Example 2: In this example the gateway has 10 analog lines and a single T1. The same request is made as in example 1, but now the response is:
例2：この例では、ゲートウェイには10個のアナログラインと単一のT1があります。同じ要求は例1と同じですが、今では応答は次のとおりです。
200 1200 OK ba/z: aaln/[1-10] ba/z: ds/ds1-1/[1-24]
200 1200 OK BA/Z：Aaln/[1-10] BA/Z：DS/DS1-1/[1-24]
Example1: Audit the number of connections on endpoints of a single E1:
例1：単一のE1のエンドポイントでの接続の数を監査します：
AUEP 2111 ds/e1-3/*@gw1.net BA/F: BA/C
AUEP 2111 DS/E1-3/*@gw1.net Ba/f：Ba/c
Response:
応答：
200 2111 OK BA/EL: ds/e1-3/[1-30] BA/C: 012111210001000001000001000010
200 2111 OK BA/EL：DS/E1-3/[1-30] BA/C：012111210001000001000001000010
Example 2: Audit the number of connections on endpoints of a DS3:
例2：DS3のエンドポイントでの接続数を監査します：
AUEP 1144 ds/ds3-1/*@gateway.net BA/F: BA/C
auep 1144 ds/ds3-1/*@gateway.net ba/f：ba/c
Response:
応答：
200 1144 OK BA/EL: ds/ds3-1/[1-192] BA/C: 010000010001000001000001 BA/C: 001000000101000000001001 : BA/C: 011000100010000010000010 BA/C: 011111010001000001000001 BA/C: 011000001100000001000001 BA/NE: ds/ds3-1/193
DS3-1/193
In this case, the response provided by the gateway contained information about the first 192 endpoints. If the ds-3 contained a T1 hierarchy, the "BA/EL" and "BA/NE" values would indicate that hierarchy e.g.,:
この場合、ゲートウェイによって提供される応答には、最初の192エンドポイントに関する情報が含まれていました。DS-3にT1階層が含まれている場合、「Ba/EL」と「Ba/NE」の値は、階層、例えば、次のことを示します。
200 1144 OK
BA/EL: ds/ds3-1/ds1-1/[1-24]
BA/C: 010000010001000001000001
BA/EL: ds/ds3-1/ds1-2/[1-24]
BA/C: 001000000101000000001001
:
BA/EL: ds/ds3-1/ds1-6/[1-24]
BA/C: 011000100010000010000010
BA/EL: ds/ds3-1/ds1-7/[1-24]
BA/C: 011111010001000001000001
BA/EL: ds/ds3-1/ds1-8/[1-24]
BA/C: 011000001100000001000001
BA/NE: ds/ds3-1/ds1-9/1
The Call Agent could continue to request endpoints by indicating the starting endpoint where it left off, i.e., simply using the returned "BE/NE" value as the "BA/SE" value for the next request:
コールエージェントは、中断した開始エンドポイントを示すことでエンドポイントを要求し続けることができます。つまり、次のリクエストの「ba/se」値として返された「be/ne」値を単に使用するだけです。
AUEP 1145 ds/ds3-3/*@gw1.net BA/F: BA/C BA/SE: ds/ds3-1/ds1-9/1
auep 1145 ds/ds3-3/*@gw1.net ba/f：ba/c ba/se：ds/ds3-1/ds1-9/1
Example 3: In this case, the Call Agent wants to know about the connection state of 12 DS0's starting with the endpoint with the LocalEndpointName "ds/ds3-1/ds1-6/4":
例3：この場合、コールエージェントは、ローカルエンドポイント名「DS/DS3-1/DS1-6/4」を使用してエンドポイントから始まる12のDS0の接続状態について知りたいと考えています。
AUEP 1146 ds/ds3-1/*@gw1.net BA/F: BA/C BA/SE: ds/ds3-1/ds1-6/4 BA/NU: 12
AUEP 1146 DS/DS3-1/*@GW1.NET BA/F：BA/C BA/SE：DS/DS3-1/DS1-6/4 BA/NU：12
Response:
応答：
200 1144 OK BA/EL: ds/ds3-1/ds1-6/[4-15] BA/C: 011000010001 BA/NE: ds/ds3-1/ds1-6/16
200 1144 OK BA/EL：DS/DS3-1/DS1-6/[4-15] BA/C：011000010001 BA/NE：DS/DS3-1/DS1-6/16
Example: Audit the connection modes for connections on the endpoints of a single E1:
例：単一のE1のエンドポイント上の接続の接続モードを監査します：
AUEP 2111 ds/e1-3/*@gw1.net BA/F: BA/M
AUEP 2111 DS/E1-3/*@gw1.net Ba/f：ba/m
Response:
応答：
200 2111 OK
BA/EL: ds/e1-3/[1-30]
BA/M: 0R2BRBBB2RRB000B00000B00000B0000B0
This shows that:
これは次のことを示しています。
* Endpoint ds/e1-3/1 has no connections * Endpoint ds/e1-3/2 has one connection and it is in "recvonly" mode. * Endpoint ds/e1-3/3 has two connections which are in "sendrecv" and "recvonly" mode * Endpoints ds/e1-3/4 to ds/e1-3/6 each have one connection - in "sendrecv" mode in all cases * Endpoints ds/e1-3/7 has two connections, both in "recvonly" mode * etc.
* エンドポイントDS/E1-3/1には接続がありません *エンドポイントDS/E1-3/2には1つの接続があり、「Recvonly」モードです。*エンドポイントDS/E1-3/3には、「sendrecv」および「recvonly」モードにある2つの接続があります *エンドポイントDS/E1-3/4からDS/E1-3/6はそれぞれ1つの接続を持っています - 「SendRecv」モードですべての場合において *エンドポイントDS/E1-3/7には、「recvonly」モード *などの2つの接続があります。
Endpoint state requests and responses are similar. An example of requesting endpoint state similar to example 3 in the previous section:
エンドポイントの状態のリクエストと応答は似ています。前のセクションの例3と同様のエンドポイント状態を要求する例：
AUEP 1150 ds/ds3-1/*@gw1.net
BA/F: BA/S(I)
BA/SE: ds/ds3-1/ds1-6/4
BA/NU: 12
Response:
応答：
200 1150 OK BA/EL: ds/ds3-1/ds1-6/[4-15] BA/S: TOOTTOOTTOOT BA/NE: ds/ds3-1/ds1-6/16
200 1150 OK BA/EL：DS/DS3-1/DS1-6/[4-15] BA/S：Toottoottoot BA/NE：DS/DS3-1/DS1-6/16
The request for in-service endpoints returns "True" for all endpoints in-service, and "O" for all endpoints "Out of Service".
インサービスのエンドポイントの要求は、すべてのエンドポイントのインサービスの「真」、およびすべてのエンドポイントの「O」を「サービスを停止している」と返します。
A similar request but with additional parameters might be:
同様のリクエストですが、追加のパラメーターがある場合があります：
AUEP 1151 ds/ds3-1/*@gw1.net
BA/F: BA/S(H,N)
BA/SE: ds/ds3-1/ds1-6/4
BA/NU: 12
Response:
応答：
200 1151 OK BA/EL: ds/ds3-1/ds1-6/[4-15] BA/S: FFFTFFFFFFFO BA/NE: ds/ds3-1/ds1-6/16
200 1151 OK BA/EL：DS/DS3-1/DS1-6/[4-15] BA/S：FFFTFFFFFFFO BA/NE：DS/DS3-1/DS1-6/16
This indicates that at least one of the StateType parameters "H" (off-hook) and "N" (notification state) evaluated to true for the endpoints that have a "T" associated with then (i.e., ds/ds3-1/ds1- 6/7 and ds/ds3-1/ds1-6/16 since the request started from ds/ds3- 1/ds1-6/4). All other endpoints are neither off-hook nor in the "notification state". Note that endpoint ds/ds3-1/ds1-6/15 is marked as being out-of-service.
これは、StateTypeパラメーターの少なくとも1つが「H」（オフフック）および「N」（通知状態）で、「t」がthenに関連付けられているエンドポイント（すなわち、DS/DS3-1///DS1- 6/7およびDS/DS3-1/DS1-6/16リクエストがDS/DS3- 1/DS1-6/4から始まったため。他のすべてのエンドポイントは、オフフックでも「通知状態」でもありません。エンドポイントDS/DS3-1/DS1-6/15は、サービス外であるとマークされていることに注意してください。
It is possible to request both connection state and endpoint state in the same request such as:
次のような同じ要求で、接続状態とエンドポイントの両方の状態を要求することができます。
AUEP 1151 ds/ds3-1/*@gw1.net
BA/F: BA/S(H,N), BA/C
BA/SE: ds/ds3-1/ds1-6/4
BA/NU: 12
In this case, the response might be:
この場合、応答は次のとおりです。
200 1151 OK BA/EL: ds/ds3-1/ds1-6/[4-15] BA/S: FFFTFFFFFFFO BA/C: 011000010001 BA/NE: ds/ds3-1/ds1-6/16
200 1151 OK BA/EL：DS/DS3-1/DS1-6/[4-15] BA/S：FFFTFFFFFFFO BA/C：011000010001 BA/NE：DS/DS3-1/DS1-6/16
The MGCP package title, "Bulk Audit", with the name, "BA", has been registered with IANA as indicated in Appendix C.1 in [3].
[3]の付録C.1に示されているように、「BA」という名前の「バルク監査」というMGCPパッケージのタイトル「バルク監査」は、IANAに登録されています。
Section 5 of the base MGCP specification [3] discusses security requirements for the base protocol, which apply equally to the package defined in this document. Use of a security Protocol such as IPsec [4, 5] that provides per message authentication and integrity services is required in order to ensure that requests and responses are obtained from authenticated sources and that messages have not been modified. Without such services, gateways and Call Agents are open to attacks.
ベースMGCP仕様[3]のセクション5では、このドキュメントで定義されているパッケージに等しく適用されるベースプロトコルのセキュリティ要件について説明します。リクエストと応答が認証されたソースから取得され、メッセージが変更されていないことを確認するために、メッセージごとの認証と整合性サービスを提供するIPSEC [4、5]などのセキュリティプロトコルの使用が必要です。このようなサービスがなければ、ゲートウェイとコールエージェントは攻撃に対して開かれています。
For example, although audit requests from unauthorized sources will not modify media gateway state, the information provided could be used to locate idle endpoints, which could then lead to making unauthorized calls. Similarly, an attack that modifies a response to an audit returned to a Call Agent could lead to a denial of service attack in which a Call Agent that is provided misinformation as to endpoint state could take some incorrect action such as taking valid calls out of service.
たとえば、許可されていないソースからの監査リクエストはメディアゲートウェイ状態を変更しませんが、提供される情報を使用してアイドルエンドポイントを見つけることができます。同様に、コールエージェントに返された監査への応答を変更する攻撃は、エンドポイント状態に関して誤った情報を提供するコールエージェントが、有効なコールをサービスから削除するなどの誤ったアクションを実行できる可能性があるサービス拒否攻撃につながる可能性があります。。
[1] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[1] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[3] Andreasen、F。およびB. Foster、「Media Gateway Control Protocol（MGCP）バージョン1.0」、RFC 3435、2003年1月。
[4] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[4] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[5] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[5] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
Flemming Andreasen Cisco Systems 499 Thornall Street, 8th Floor Edison, NJ 08837
フレミングアンドレアセンシスコシステム499 Thornall Street、8階エジソン、ニュージャージー08837
EMail: fandreas@cisco.com
David Auerbach Cisco Systems Inc. 170 W. Tasman Drive San Jose, CA, 95134
David Auerbach Cisco Systems Inc. 170 W. Tasman Drive San Jose、CA、95134
EMail: dea@cisco.com
Bill Foster Cisco Systems
ビル・フォスター・シスコ・システム
EMail: bfoster@cisco.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
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 assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
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エディター機能の資金は現在、インターネット協会によって提供されています。