RFC3624 日本語訳
3624 The Media Gateway Control Protocol (MGCP) Bulk Audit Package. B.Foster, D. Auerbach, F. Andreasen. November 2003. (Format: TXT=34391 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Foster
Request for Comments: 3624 D. Auerbach
Category: Informational F. Andreasen
Cisco Systems
November 2003
コメントを求めるワーキンググループB.フォスターの要求をネットワークでつないでください: 3624年のD.アウアーバックカテゴリ: 情報のF.Andreasenシスコシステムズ2003年11月
The Media Gateway Control Protocol (MGCP) Bulk Audit Package
メディアゲートウェイ制御プロトコル(MGCP)の大量の監査パッケージ
Status of this Memo
この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)インターネット協会(2003)。 All rights reserved。
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.
このドキュメントは共同体の情報のために発表されています。 それは現在多くの製品の中に配備されている非IETFプロトコルについて説明します。 ImplementersはMGCPがアドレスに設計されたのをRFC3015を意識しているべきです。(RFCはIETF Megaco作業部会とITU-T SG16で開発されて、IETFとITU-Tによって需要を満たす規格ベース(包含はセキュリティ問題を見直した)の方法であると考えられます)。
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.
ベースメディアゲートウェイControlプロトコル(MGCP)はCallエージェントが一度に1つの終点に終点、そして/または、接続状態を監査できるだけである監査コマンドを含んでいます。 このドキュメントはゲートウェイ終点のグループの大量の監査のための新しいMGCPパッケージについて説明します。 それで、Callエージェントは終点のグループのために健康な接続と終点州として終点命名規則、例示された終点のリストを決定できます。
Foster, et al. Informational [Page 1] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[1ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
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
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 監査パッケージを膨らませてください。 . . . . . . . . . . . . . . . . . . . . . 2 2.1. 定義をパッケージしてください。 . . . . . . . . . . . . . . . . . . 2 2.1.1. パラメタ. . . . . . . . . . . . . . . 3 2.1.2をパッケージしてください。 非しつこい仮想の終点の監査を膨らませてください。 . . . . . . . . . . . . . . . . . . . 11 2.1.3. 特定の復帰コードをパッケージしてください。 . . . . . . . . . 12 2.2. パッケージに関する例は.1に.132.2を使用します。 終点リスト。 . . . . . . . . . . . . . . . . . 13 2.2.2. 接続カウントリスト。 . . . . . . . . . . . . . 13 2.2.3. 接続モードリスト. . . . . . . . . . . . . . 15 2.2.4。 終点州. . . . . . . . . . . . . . . . . 15 3。 IANA問題. . . . . . . . . . . . . . . . . . . . . 17 4。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 17 5。 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . 18 7. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 19
1. Introduction
1. 序論
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.
ベースメディアゲートウェイControlプロトコル(MGCP)[3]はCallエージェントが終点を監査できるだけである監査コマンド、そして/または、接続状態(一度に1つの終点)を含んでいます。 このドキュメントはゲートウェイ終点のグループの大量の監査のための新しいMGCPパッケージについて説明します。 それで、Callエージェントは、終点命名規則を決定して、例示された終点のリストを決定して、終点のグループのために接続と終点州を決心しています。 これは多くの終点を持っているゲートウェイがあるフェイルオーバー状況で特に重要です。
Conventions Used in this Document
このDocumentのコンベンションUsed
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].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[2]で説明されるように本書では解釈されることであるべきですか?
2. Bulk Audit Package
2. 大量の監査パッケージ
2.1. Package Definition
2.1. パッケージ定義
Package Name: BA
名前をパッケージしてください: Ba
Package Version: 0
バージョンをパッケージしてください: 0
Foster, et al. Informational [Page 2] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[2ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
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.
記述をパッケージしてください: このパッケージは終点と接続状態のハイレベルの眺めをゲートウェイの終点のグループに監査して、得る能力をCallエージェントに提供します。
2.1.1. Package Parameters
2.1.1. パッケージパラメタ
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:
新しいBulkRequestedInfoパラメタはAuditEndpointコマンドにおける使用のために定義されます。 EndpointIdsのコンパクトなリストを要求するか、または終点のグループのために以下で定義されるように終点か接続状態の高い平らな視点を要求するのにパラメタを使用できます:
ReturnCode,
[EndPointNameList,]
[InstantiatedEndpointList,]
[ConnectionCountList,]
[ConnectionModeList,]
[EndpointStateList,]
[NextEndpointName,]
[ReportedEndpointList]
<-- AuditEndPoint(EndpointId,
[StartEndpointName,]
[MaxNumEndpoints,]
[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仕様、Bulk Auditsパッケージに関連しているパラメタを使用できるBulkRequestedInfoの正常なRequestedInfoパラメタ、「オール、」 終点の収集を監査するためのワイルドカード。 しかしながら、それはワイルドカードなしで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.
以下の小区分は詳細にBulk Audit Commandに関連しているパラメタについて説明します。 そして、セクション2.1 .1 .1、2.1 .1 .2はa要求とセクション2.1.1で.3〜2.1に含まれていて、.8が説明する.1がパラメタを返すということであるかもしれないパラメタについて説明します。
2.1.1.1. StartEndpointName and MaxNumEndpoints Parameters
2.1.1.1. StartEndpointNameとMaxNumEndpointsパラメタ
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]):
ワイルドな梳綿機が興味がある終点に資格を与えるために十分でないかもしれないので、StartEndpointName(興味がある最初の終点)とMaxNumEndPoints(興味がある終点の最大数)を含んでいることによって、さらなる資格を提供できます。 以下のAugmented BNF(ABNF)構文に従って、これらのパラメタは説明されます。(ABNF構文定義[1])についてRFC2234を参照してください:
"BA/SE" ":" 0*WSP LocalEndpointName
「「Ba/SE」」:、」 0*WSP LocalEndpointName
"BA/NU" ":" 0*WSP MaxNumEndpoints
「「Ba/ν」」:」 0*WSP MaxNumEndpoints
Foster, et al. Informational [Page 3] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[3ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
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に値が範囲にある終点の10進数であるところ。 MaxNumEndpointsパラメタSHOULD、EndpointStateList、そして/または、ConnectionCountListのために監査を要求するときには単に含められてください。 EndPointNameListかInstantiatedEndpointListを求める要求に含まれているなら、それは無視されるかもしれません。
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文法が完全なEndpointNameよりむしろこのパッケージのために要求と応答パラメタ行に提供されるのを確実にしてください。 コンパクト性のためにこれをします、すなわち、それが与えられた要求のコマンドライン部分で既に利用可能であるので、ドメイン名部分を省きます。
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によって定義された終点のリストがあると、レポートを終点にワイルドカード範囲の中で指定されたものまで返すだけでしょう。
2.1.1.2. BulkRequestedInfo Parameter
2.1.1.2. BulkRequestedInfoパラメタ
The BulkRequestedInfo parameter line is described according to the following ABNF syntax definitions:
以下のABNF構文定義に従って、BulkRequestedInfoパラメタ行は説明されます:
BulkRequestedInfo = "BA/F:" 0*WSP
*( EndpointOrInstantList *("," EndpointOrInstantList))
/ *( EndpointOrConnState *("," EndpointOrConnState))
BulkRequestedInfoが等しい、「Ba/F:」 0*WSP*、(EndpointOrInstantList*、(「」、EndpointOrInstantList) /*(EndpointOrConnState*、(「」、EndpointOrConnState)
EndpointOrConnState = "BA/C" / "BA/M" / EndpointStateParam
EndpointOrConnStateは「Ba/C」/「Ba/M」/EndpointStateParamと等しいです。
EndpointOrInstantList = "BA/Z" / "BA/X"
EndpointOrInstantListは「Ba/Z」/「Ba/X」と等しいです。
EndpointStateParam = "BA/S" "(" StateType
0*("," 0*(WSP) StateType)")"
EndpointStateParamが「Ba/S」と等しい、「(「StateType0*、(「」、0*(WSP) StateType)、」、)、」
StateType = "I" / "D" / "N" / "S" / "H"
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」を返すという要求がInstantiatedEndpointList*「Ba/C」を返すという要求がConnectionCountList*「Ba/M」を返すという要求がConnectionModeList*「Ba/S」を返すという要求がEndpointStateListを返すという要求であるということであるということであるということであるということです。
Each of the parameters can be provided at most once in the BulkRequestedInfo.
高々一度それぞれのパラメタをBulkRequestedInfoに提供できます。
Foster, et al. Informational [Page 4] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[4ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
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にみられるように、EndpointStateParamパラメタは終点に評価されるべき状態を定義する1つ以上のStateTypeパラメタでparameterizedされます:
* "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.
* 「私」--終点による*稼働中です、「D」--外された(外された終点についての議論のための[3]についてセクション4.3と4.4.7を見ます)終点、*「N」--終点が通知状態にあります、*「L」--終点が堅苦しい州(堅苦しいモードで、すなわち、NTFYへの応答が起こった後にRQNTを待っている)の*「S」にあるということです--アクティブなオンにオフな(OO)かタイムアウト(TO)信号が終点にあります、*「H」--終点が「怠けてください」を除いた何らかの状態にあります。 この最後のパラメタの意味を終点のタイプに頼っています: * パラメタには、サービス(終点が意識している状態のない)を運搬人に提供するだけである終点への意味がありません。 この場合、状態はいつも誤り(「空費する」ために対応する)に評価されます。 * それら(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").
StateTypesのリストは将来、広げられるかもしれません。 未知のStateTypeが遭遇するなら、エラーコード803(すなわち、「サポートされないStateType」)でコマンドを拒絶しなければなりません。
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.
この要求の結果、提供されたレポートは「本当であっ」て、「誤る」か各終点において「使われなくなること」のしるしをもたらします。 そして、終点がそうである、稼働中である、評価基準のどれかは有効です、終点のためのレポートが「本当に」評価するその時。 「誤った」指示は終点がサービスとすべての評価基準が偽に評価するコネである場合にだけ報告されるでしょう。 その結果、レポートが監査された状態の上の論理的な「OR」機能を提供する、終点は中で修理します。 監査される状態において関係ありません、終点が使われなくなっていると考えられると、「使われなくなる」指示はいつも報告されるでしょう。
Foster, et al. Informational [Page 5] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[5ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
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".
終点が外されるかどうかに関するレポートか通知状態で要求を示します。 与えられた終点が「外す」か「通知」状態にあるなら、レポートが「本当に」その終点に示すその時です。 終点によるどちらも外された州か通知状態にありますが、稼働中です、次に、その終点のためのレポートが「誤ること」を示すということであるなら。 終点が使われなくなっていると、その終点のためのレポートは「使われなくなること」を示すでしょう。
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.
終点がサービスで稼働中であるか、または出かけているかを決定するだけであるために、Callエージェントは「I」StateTypeパラメタだけで要求をするべきです。
2.1.1.3. EndPointNameList and InstantiatedEndpointList Parameters
2.1.1.3. EndPointNameListとInstantiatedEndpointListパラメタ
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)
「Ba/Z:」 0*WSP RangedLocalName0*(「」、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がLocalEndpointNameであるところでは、それはすなわち[3]のAppendix E(セクションE.5)で説明された及んだワイルドカード記法を含むかもしれません:
RangeWildcard = "[" NumericalRange *( "," NumericalRange ) "]"
NumericalRange = 1*(DIGIT) [ "-" 1*(DIGIT) ].
RangeWildcardが等しい、「[「NumericalRange*、(「」、NumericalRange)、」、]、」 NumericalRangeは1*(ケタ)[「-」1*(ケタ)]と等しいです。
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]
Foster, et al. Informational [Page 6] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[6ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
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.
それに注意してください、範囲ワイルドカードがキャラクタを使用するので「[「1つの範囲の始まりを示すために「[「範囲ワイルドカードを使用する終点名にキャラクタを使用してはいけません」。
Note that the ranged wildcard notation (RangeWildcard above) also allows commas between ranges like:
また、及んだワイルドカード記法(上のRangeWildcard)が以下のように範囲の間のコンマを許容することに注意してください。
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.
* InstantiatedEndpointListは「本当」(または、例示される)の終点を返すという要求です。
InstantiatedEndpointList Parameter:
InstantiatedEndpointListパラメタ:
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:
InstantiatedEndpointList価値の構文がEndPointNameList値がEndPointNameListとともに帰ったのと同じである、すなわち、以下の構文で多くの線を返すかもしれません:
"BA/X:" 0*WSP RangedLocalName 0*("," 0*WSP RangedLocalName)
「Ba/X:」 0*WSP RangedLocalName0*(「」、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などの)か他のしつこい終点の場合では、通常、InstantiatedEndpointListは要求されていないでしょう。 しかしながら、それが要求されると、InstantiatedEndpointListと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:
しつこくない仮想の終点に「」 ワイルドカード(「*」)のすべてを名前の一番左用語に返します。(名前は、終点が任意の名前が適用されて、仮想であって非しつこいのを示すためにEndPointNameListでダイナミックに割り当てられます)。 しかしながら、しつこい終点にEndPointNameListを返すとき、」 ワイルドカード記法のすべてを使用してはいけません。「以下の例はこれを例証します:
ba/z: announcement/* ba/z: foo/bar/* ba/z: foo/foo/*
Ba/z: 発表/*Ba/z: foo/bar/*Ba/z: foo/foo/*
Foster, et al. Informational [Page 7] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[7ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
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.
「」 ワイルドカードのすべてが私たちに言って、その「発表」は単にダイナミックなセットの非しつこい仮想の終点のための一番左用語です。 これらの終点の1つを例示するために、私たちが含んでいるだろう、「いくらか、」 要求(例えば、NotificationRequestかCreateConnection)のEndpointIdのLocalEndpointNameとしてのワイルドカード(例えば、「発表/$」)について。 そして、応答は例示された終点を示すSpecificEndpointIdを含んでいるでしょう。 また、上記の例で"foo"が2つの異なったレベルの非しつこい仮想の終点を定義することに注意してください。
2.1.1.4. ConnectionCountList
2.1.1.4. ConnectionCountList
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)
「Ba/C:」 0*WSP NumConnections0*(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」。
2.1.1.5. ConnectionModeList
2.1.1.5. ConnectionModeList
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)
「Ba/M:」 0*WSP ModeOrCount0*(ModOrCount)
ModeOrCount = ConnCount / ConnMode
ModeOrCountはConnCount / ConnModeと等しいです。
ConnMode = "I" / "S" / "R" / "B" / "C" / "L" / "T" / "N" / "U"
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がどちらのまた16進でもあるところで、終点か値「Z」で0-15 接続との文通を評価してください、15以上の接続が出席しているのを示して。
Foster, et al. Informational [Page 8] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[8ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
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
* 「私」は、「不活発な」接続モード*「S」が、"sendonly"接続モード*「R」が、"recvonly"接続モード*「B」が、"sendrecv"接続モード*「C」が、"confrnce"接続モード*「L」が、「ループバック」接続モード*「T」が、接続モード*「N」が、"netwloop"接続モード*「U」がある他の接続モードを示すのを示すのを「最もconttestに」示すのを示すのを示すのを示すのを示すのを示すのを示します。
For a definition of MGCP connection modes, refer to section 3.2.2.6 of [3].
MGCP接続モードの定義について、セクション3.2を参照してください。.2 .6 [3]について。
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.
終点に接続が全くそれにないなら、値「0インチ」をModeOrCountに与えます。 終点に関連している1つの接続があれば、接続モード(ConnMode)のシンボルを提供します。 2〜15まで接続が他方ではあれば、(ConnCount)が提供されるポートの数を表すシンボルは各接続のための接続モード(ConnMode)を示すシンボルのリストで従いました。 15以上の接続があれば、ConnCountのために「Z」を示します、そして、その終点における接続に接続モードを全く提供しません。
2.1.1.6. EndpointStateList Parameter
2.1.1.6. EndpointStateListパラメタ
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)
「Ba/S:」 0*WSP EndPointState0*(EndPointState)
EndPointState = "T" / "F" / "O"
EndPointStateは「T」/「F」/「O」と等しいです。
where:
どこ:
* "T" indicates "True"
* "F" indicates "False"
* "O" indicates "Out of Service"
* 「T」は、「本当」の*「F」が「使われなくなっていた」状態で「O」が示す「誤った」*を示すのを示します。
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.
EndPointStateインディケータが終点の接続状態に関して何も言わないことに注意してください。
Foster, et al. Informational [Page 9] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[9ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
2.1.1.7. NextEndpointName Parameter
2.1.1.7. NextEndpointNameパラメタ
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パラメタはリターンに含まれるでしょう、報告されるために追加終点が報告されませんでしたが、情報が利用可能であったワイルドなcarded終点名で覆われたこのゲートウェイにあれば。
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
「「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).
次のセットの終点における監査を続けるために、Callエージェントは出発点(例えば、次の要求におけるStartEndpointNameとしての)としてNextEndpointNameを使用することによって、さらなる要求をすることができます。
2.1.1.8. ReportedEndpointList Parameter
2.1.1.8. ReportedEndpointListパラメタ
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のリストの前の応答線にReportedEndpointListを提供しなければなりません。 ABNF構文は以下の通りです:
"BA/EL:" 0*WSP LimitedRangedName 0*("," 0*WSP LimitRangedName)
「Ba/高架鉄道:」 0*WSP LimitedRangedName0*(「」、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構文)を含むかもしれません。 しかしながら、範囲ワイルドカード記法が同時にLimitedRangedNameが許容するだけである地方名に関する複数の諸条件に使用されるのを許容するRangedLocalNameと異なって、すなわち、最後の学期、以下に使用されるべき範囲記法は有効です:
ba/el: ds/ds1-1/[1,3-5,8-24]
Ba/高架鉄道: 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/高架鉄道: ds/ds1-1/[1-24]、ds/ds1-2/[1-24]、ds/ds1-3/[1-24]
Foster, et al. Informational [Page 10] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[10ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
However, the following is not valid:
しかしながら、以下は有効ではありません:
ba/el: ds/ds1-[1-3]/[1-24]
Ba/高架鉄道: 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とInstantiatedEndpointListの両方を返すという要求を含むかもしれません。 しかしながら、EndPointNameList、そして/または、InstantiatedEndpointListを求める要求はConnectionCountListかEndpointStateListのどちらかを求める要求を含んではいけません。
2.1.2. Bulk Auditing of Non-persistent Virtual Endpoints
2.1.2. 非しつこい仮想の終点の大量の監査
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のReportedEndpointListは、どの終点が報告されているかをまさに説明します。
Example:
例:
A Call Agent requests to know about the EndPointNameList for the
endpoints on a conference bridge:
Callエージェントは、EndPointNameListに関してカンフェレンス・ブリッジの終点に知るよう要求します:
AUEP 1200 *@gw1.x.net MGCP 1.0
BA/F: BA/Z
AUEP1200 *@gw1.x.net MGCP1.0Ba/F: Ba/Z
Response:
応答:
200 1200 OK
ba/z: cnf/*
200 1200は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.,:
これは命名規則を示しますが、しかし、事実上、これらの終点のすべてが例示されるというわけではありません。 すなわち、Aは例示されることのリストのために終点を要求します:
AUEP 1201 cnf/*@gw1.x.net MGCP 1.0
BA/F: BA/X
AUEP1201 cnf/*@gw1.x.net MGCP1.0Ba/F: Ba/X
might yield:
もたらすかもしれません:
200 1201 OK
ba/x: cnf/[1-3]
ba/x: cnf/[6-12]
200 1201はBa/xを承認します: cnf/[1-3]Ba/x: cnf/[6-12]
Foster, et al. Informational [Page 11] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[11ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
indicating that only these particular endpoints are instantiated.
これらの特定の終点だけが例示されるのを示します。
Suppose the Call Agent now asks for the ConnectionCountList i.e.,:
すなわち、Callエージェントが現在ConnectionCountListを求めると仮定してください:
AUEP 1202 cnf/*@gw1.x.net MGCP 1.0
BA/F: BA/C
AUEP1202 cnf/*@gw1.x.net MGCP1.0Ba/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の正面でReportedEndpointListによって示されるでしょう):
200 1202 OK
ba/el: cnf/[1-3]
ba/c: 035
ba/el: cnf/[6-12]
ba/c: 3450333
200 1202OK Ba/高架鉄道: cnf/[1-3]Ba/c: 035Ba/高架鉄道: 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 1202OK Ba/高架鉄道: cnf/[1-3]、Ba/高架鉄道: cnf/[6-12]Ba/c: 035Ba/c: 3450333
or
または
200 1202 OK
ba/el: cnf/[1-3], ba/el: cnf/[6-12]
ba/c: 0353450333
200 1202OK Ba/高架鉄道: cnf/[1-3]、Ba/高架鉄道: cnf/[6-12]Ba/c: 0353450333
2.1.3. Package Specific Return Codes
2.1.3. 特定の復帰コードをパッケージしてください。
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 支持された805Incorrectlyではなく、無効のNextEndpointName801Invalid StartEndpointName802Invalid、サポートされないBulkRequestInfo Parameter803InvalidまたはサポートされないStateType804Bulk Audit Typeが未知の、または、入手できない終点の範囲806Requested StartEndpointを指定しました。
Foster, et al. Informational [Page 12] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[12ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
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:
エラーコードに従って、特定の誤りがコード化するパッケージがパッケージ名を含んでいることに注意してください。 例えば、エラーコード801が1001年の取引IDとの要求に対応して起こるなら、以下としてそれを送るでしょう。
801 1001 /BA
801 1001/Ba
2.2. Examples of Package Use
2.2. パッケージ使用に関する例
2.2.1. Endpoint List
2.2.1. 終点リスト
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
AUEP1200 *@gw1.x.net MGCP1.0Ba/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は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はBa/zを承認します: aaln/[1-10]Ba/z: ds/ds1-1/[1-24]
2.2.2. Connection Count List
2.2.2. 接続カウントリスト
Example1: Audit the number of connections on endpoints of a single E1:
Example1: シングルの終点のポートの数を1E監査してください:
AUEP 2111 ds/e1-3/*@gw1.net
BA/F: BA/C
AUEP2111 ds/e1-3/*@gw1.net Ba/F: Ba/C
Response:
応答:
200 2111 OK
BA/EL: ds/e1-3/[1-30]
BA/C: 012111210001000001000001000010
200 2111OK Ba/高架鉄道: ds/e1-3/[1-30]BA/C: 012111210001000001000001000010
Foster, et al. Informational [Page 13] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[13ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
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
AUEP1144 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
200 1144OK Ba/高架鉄道: ds/ds3-1/[1-192]BA/C: 010000010001000001000001Ba/C: 001000000101000000001001 : Ba/C: 011000100010000010000010Ba/C: 011111010001000001000001Ba/C: 011000001100000001000001Ba/Ne: ds/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/高架鉄道」と「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
200 1144OK Ba/高架鉄道: ds/ds3-1/ds1-1/[1-24]BA/C: 010000010001000001000001Ba/高架鉄道: ds/ds3-1/ds1-2/[1-24]BA/C: 001000000101000000001001 : Ba/高架鉄道: ds/ds3-1/ds1-6/[1-24]BA/C: 011000100010000010000010Ba/高架鉄道: ds/ds3-1/ds1-7/[1-24]BA/C: 011111010001000001000001Ba/高架鉄道: ds/ds3-1/ds1-8/[1-24]BA/C: 011000001100000001000001Ba/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:
Callエージェントは、返上「/Neになってください」を使用することですなわちそれが単にやめられた始めの終点を示すのによる終点が次の要求のために「Ba/SE」として値を評価するよう要求し続けることができました:
AUEP 1145 ds/ds3-3/*@gw1.net
BA/F: BA/C
BA/SE: ds/ds3-1/ds1-9/1
AUEP1145 ds/ds3-3/*@gw1.net Ba/F: Ba/C Ba/SE: ds/ds3-1/ds1-9/1
Foster, et al. Informational [Page 14] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[14ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
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: この場合、Callエージェントは、DS0が始まる12人の接続状態に関して、LocalEndpointNameがある終点が「以下を/ds3-1/ds1-6/4インチdsすること」を知りたがっています。
AUEP 1146 ds/ds3-1/*@gw1.net
BA/F: BA/C
BA/SE: ds/ds3-1/ds1-6/4
BA/NU: 12
AUEP1146 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 1144OK Ba/高架鉄道: ds/ds3-1/ds1-6/[4-15]BA/C: 011000010001Ba/Ne: ds/ds3-1/ds1-6/16
2.2.3. Connection Mode List
2.2.3. 接続モードリスト
Example: Audit the connection modes for connections on the endpoints of a single E1:
例: シングルの終点で接続のための接続モードを1E監査してください:
AUEP 2111 ds/e1-3/*@gw1.net
BA/F: BA/M
AUEP2111 ds/e1-3/*@gw1.net Ba/F: Ba/M
Response:
応答:
200 2111 OK
BA/EL: ds/e1-3/[1-30]
BA/M: 0R2BRBBB2RRB000B00000B00000B0000B0
200 2111OK Ba/高架鉄道: 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がds/e1-3/6には"sendrecv"と"recvonly"モード*終点ds/e1-3/4にある2つの接続にすべてのケース*終点ds/e1-3/7のモードが持っている"sendrecv"2つの接続、"recvonly"モード*などにおける両方の、1つの接続をあります。
2.2.4. Endpoint State
2.2.4. 終点州
Endpoint state requests and responses are similar. An example of requesting endpoint state similar to example 3 in the previous section:
終点州の要求と応答は同様です。 前項の例3と同様の終点州を要求する例:
Foster, et al. Informational [Page 15] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[15ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
AUEP 1150 ds/ds3-1/*@gw1.net
BA/F: BA/S(I)
BA/SE: ds/ds3-1/ds1-6/4
BA/NU: 12
AUEP1150 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 1150OK Ba/高架鉄道: 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:
同様の要求にもかかわらず、追加パラメタがあるAは以下の通りです。
AUEP 1151 ds/ds3-1/*@gw1.net
BA/F: BA/S(H,N)
BA/SE: ds/ds3-1/ds1-6/4
BA/NU: 12
AUEP1151 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 1151OK Ba/高架鉄道: 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.
これは、少なくとも「H」(オフフック)と「N」(通知状態)が「T」を持っている終点に本当に評価したStateTypeパラメタの1つが次に、(ds/ds3 1/ds1-6/4から始められた要求以来のすなわち、ds/ds3-1/ds1 6/7とds/ds3-1/ds1-6/16)と交際したのを示します。 他のすべての終点は、オフフックでなくてまた「通知状態」ではありません。 終点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
AUEP1151 ds/ds3-1/*@gw1.net Ba/F: Ba/S(H、N)、Ba/C Ba/SE: ds/ds3-1/ds1-6/4 BA/NU: 12
Foster, et al. Informational [Page 16] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[16ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
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 1151OK Ba/高架鉄道: ds/ds3-1/ds1-6/[4-15]BA/S: FFFTFFFFFFFO Ba/C: 011000010001Ba/Ne: ds/ds3-1/ds1-6/16
3. IANA Considerations
3. IANA問題
The MGCP package title, "Bulk Audit", with the name, "BA", has been registered with IANA as indicated in Appendix C.1 in [3].
MGCPパッケージタイトル、[3]の付録C.1にみられるように「Ba」という名前がある「大量の監査」をIANAに登録してあります。
4. Security Considerations
4. セキュリティ問題
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]などのセキュリティプロトコルと保全サービスの使用が、認証されたソースから要求と応答を得て、メッセージを変更していないのを確実にするのに必要です。 そのようなサービスがなければ、ゲートウェイとCallエージェントは攻撃にオープンです。
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.
例えば、権限のないソースからの監査要求はメディアゲートウェイ状態を変更しないでしょうが、活動していない終点の場所を見つけるのに提供された情報は使用できました。(次に、終点は権限のない電話をかけるのに通じることができました)。 同様に、Callエージェントに返された監査への応答を変更する攻撃は誤伝が終点州に関して提供されるCallエージェントが使われなくなっていた状態で有効な判定を取ることなどの不正確な何らかの行動を取ることができたサービス不能攻撃につながるかもしれません。
Foster, et al. Informational [Page 17] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[17ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
5. References
5. 参照
[1] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[1] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[3] Andreasen, F. and B. Foster, "Media Gateway Control Protocol
(MGCP) Version 1.0", RFC 3435, January 2003.
[3] Andreasen、F.、およびB.フォスター、「メディアゲートウェイコントロールは2003年1月にバージョン1インチ、(MGCP)RFC3435について議定書の中で述べます」。
[4] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[4] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[5] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload
(ESP)", RFC 2406, November 1998.
[5] ケントとS.とR.アトキンソン、「セキュリティ有効搭載量(超能力)を要約するIP」、RFC2406、1998年11月。
6. Authors' Addresses
6. 作者のアドレス
Flemming Andreasen Cisco Systems 499 Thornall Street, 8th Floor Edison, NJ 08837
ニュージャージー フレミングAndreasenシスコシステムズ499Thornall通り、第8Floorエディソン、08837
EMail: fandreas@cisco.com
メール: fandreas@cisco.com
David Auerbach Cisco Systems Inc. 170 W. Tasman Drive San Jose, CA, 95134
Driveサンノゼ、デヴィッドアウアーバックシスコシステムズ株式会社170W.タスマン・カリフォルニア 95134
EMail: dea@cisco.com
メール: dea@cisco.com
Bill Foster Cisco Systems
ビルフォスターシスコシステムズ
EMail: bfoster@cisco.com
メール: bfoster@cisco.com
Foster, et al. Informational [Page 18] RFC 3624 MGCP Bulk Audit Package November 2003
フォスター、他 情報[18ページ]のRFC3624MGCPは監査パッケージ2003年11月に膨れます。
7. Full Copyright Statement
7. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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 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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Foster, et al. Informational [Page 19]
フォスター、他 情報[19ページ]
一覧
スポンサーリンク
