Network Working Group B. Foster
Request for Comments: 3991 F. Andreasen
Category: Informational Cisco Systems
February 2005
Media Gateway Control Protocol (MGCP) Redirect and Reset 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 (2005).
著作権（C）インターネット協会（2005）。
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 the standards-based (including reviewed security considerations) way to meet the needs that MGCP was designed to address by the IETF and the ITU-T.
この文書は、コミュニティの情報については公表されています。これは、現在の製品の数に展開されている非IETFプロトコルを記述しています。実装者は、IETFのMegaco作業部会とITU-T SG16で開発されたRFC 3015、を知っておく必要があり、そしてそれはMGCPがで対処するように設計されたことのニーズを満たすために、標準ベース（見直しのセキュリティの考慮事項を含む）方法を考えられていますIETFおよびITU-T。
Abstract
抽象
The base Media Gateway Control Protocol (MGCP) specification (RFC 3435) allows endpoints to be redirected one endpoint at a time. This document provides extensions in the form of a new MGCP package that provides mechanisms for redirecting and resetting a group of endpoints. It also includes the ability to more accurately redirect endpoints by allowing a list of Call Agents to be specified in a preferred order.
ベースメディアゲートウェイ制御プロトコル（MGCP）仕様（RFC 3435）のエンドポイントは、一度に1つのエンドポイントをリダイレクトすることを可能にします。この文書では、リダイレクトすると、エンドポイントのグループをリセットするためのメカニズムを提供する新しいMGCPパッケージの形で拡張機能を提供します。また、より正確にコールエージェントのリストは、優先順に指定することを可能にすることによって、エンドポイントをリダイレクトする機能が含まれています。
Table of Contents
目次
1. Introduction.................................................. 2
1.1. Conventions Used in This Document....................... 3
2. Redirect and Reset Package.................................... 3
2.1. NotifiedEntityList Extension Parameter.................. 3
2.2. Endpoint Specifier...................................... 4
2.2.1. EndpointList and EndpointMap Extension
Parameters...................................... 4
2.2.2. Application to Out-of-Service Endpoints......... 6
2.3. Redirect................................................ 6
2.4. Reset Extension Parameter............................... 7
2.5. Return Codes............................................ 8
3. IANA Considerations........................................... 9
4. Security Considerations....................................... 9
5. Normative References.......................................... 9
Authors' Addresses................................................ 10
Full Copyright Statement.......................................... 11
The base Media Gateway Control Protocol (MGCP) specification [2] allows a Call Agent to specify a new NotifiedEntity parameter in order to redirect one or more endpoints to a new Call Agent. This must be done in a NotificationRequest or a connection handling command. However, because these commands affect endpoint or connection state, such a request cannot typically be sent to a group of endpoints with a single command. This means that if a new Call Agent takes over for a failed one, the new Call Agent must redirect endpoints one at a time. If there is a large number of endpoints (e.g., within a large trunking gateway), this could take considerable time.
ベースメディアゲートウェイ制御プロトコル（MGCP）仕様[2]コール・エージェントは新しいコールエージェントに1つ以上のエンドポイントをリダイレクトするために、新たなNotifiedEntityパラメータを指定することを可能にします。これはNotificationRequestまたは接続処理コマンドで行う必要があります。これらのコマンドは、エンドポイントまたは接続状態に影響を与えるので、しかし、そのような要求は、一般的に1つのコマンドで、エンドポイントのグループに送信することはできません。これは、新しいコールエージェントが失敗した1を引き継ぐ場合、新しいコールエージェントが一度にエンドポイントを1つずつリダイレクトする必要があることを意味します。 （例えば、大トランキングゲートウェイ内の）エンドポイントの数が多い場合、これはかなりの時間がかかる可能性があります。
This document defines a new redirect and reset package for MGCP that allows the Call Agent to redirect a group of endpoints without affecting endpoint or connection state.
この文書は、新しいリダイレクトを定義し、コールエージェントがエンドポイントまたは接続状態に影響を与えることなく、エンドポイントのグループをリダイレクトすることができますMGCPのためのパッケージをリセットします。
Also included is a new NotifiedEntityList parameter, which is similar to the NotifiedEntity parameter but allows for multiple domain names to be provided. This allows the Call Agent to more accurately direct endpoints to a preferred ordered list of alternate Call Agents.
また、NotifiedEntityパラメータに似ていますが、複数のドメイン名が提供されるのを可能にする新しいNotifiedEntityListパラメータが、含まれています。これは、別のコールエージェントの優先順序付きリストへより正確に直接エンドポイントにコールエージェントを可能にします。
A third capability contained in this package is the ability to reset and re-initialize one or more groups of endpoints efficiently. This capability is useful in Call Agent failover situations.
このパッケージに含まれている第三の能力を効率的にエンドポイントの1つ以上のグループをリセットして再初期化する能力です。この機能は、コールエージェントのフェイルオーバーの状況で有用です。
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 BCP 14, RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。
Package Name: RED Version: 0
パッケージ名：REDバージョン：0
This package does the following:
このパッケージには、次のことを行います。
* Defines a new NotifiedEntityList extension parameter. This works the same as the NotifiedEntity parameter in [2] but allows more than one domain name to be specified.
*新しいNotifiedEntityList拡張パラメータを定義します。これは、[2]でNotifiedEntityパラメータと同じように動作しますが、複数のドメイン名を指定することができます。
* Allows a Call Agent to pass a new NotifiedEntity or NotifiedEntityList to a collection of endpoints specified by an "all of" wildcard. This is useful if a new Call Agent takes over from a previous one and wants to redirect endpoint(s) to send messages to it from now on.
*コールエージェントがワイルドカード「のすべて」で指定されたエンドポイントのコレクションに新しいNotifiedEntityまたはNotifiedEntityListを渡すことができます。新しいコール・エージェントは、以前のものから引き継ぎ、今からそれにメッセージを送信するエンドポイント（複数可）をリダイレクトしたい場合に便利です。
* Allows a Call Agent to request one or more groups of endpoints to do a reset, which can be useful following certain types of failures.
*コールエージェントは、障害の特定の種類以下役立ちリセットを行うには、エンドポイントの1つまたは複数のグループを要求することができます。
The NotifiedEntityList parameter is encoded as "NL" and is followed by a colon and a comma-separated list of NotifiedEntity values as defined in the MGCP specification [2], as follows:
次のようにNotifiedEntityListパラメータは、「NL」として符号化され、MGCP仕様[2]で定義されるように、結腸とNotifiedEntity値のカンマ区切りのリストが続きます。
RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net
RED / NL：ca1@myca.whatever.net、ca2@mybackupca.whatever.net
The NotifiedEntityList works in a way similar to the NotifiedEntity parameter, except that it allows multiple domain names to be listed. The NotifiedEntityList thus specifies a new "notified entity" for the endpoint.
NotifiedEntityListは、それが複数のドメイン名が記載されていることを可能にすることを除いて、NotifiedEntityパラメータと同様に動作します。 NotifiedEntityListは、このようにエンドポイントに対する新しい「通知実体」を指定します。
The NotifiedEntityList parameter is optional in any command or response where the NotifiedEntity parameter is allowed. Following a restart, the NotifiedEntityList is initially empty, unless provisioned otherwise. In subsequent commands, it retains its current value until explicitly changed. If both a NotifiedEntity parameter and a non-empty NotifiedEntityList parameter have been set (not necessarily at the same time), the NotifiedEntity parameter value will be viewed as being implicitly added to the beginning of the NotifiedEntityList parameter. The NotifiedEntity parameter thus always defines the first domain name to contact unless it has explicitly been set to empty. In that case, the NotifiedEntityList defines the "notified entity". If the NotifiedEntityList is also empty, then the normal MGCP handling of an empty "notified entity" applies. We will refer to the list of domain names that result from the above rules as the "notified entity list".
NotifiedEntityListパラメータはNotifiedEntityパラメータが許可されている任意のコマンドまたは応答に任意です。そうでない場合は、プロビジョニングしない限り、再起動後、NotifiedEntityListは、最初は空です。明示的に変更されるまで、後続のコマンドでは、現在の値を保持します。 NotifiedEntityパラメータと非空NotifiedEntityListパラメータの両方が（必ずしも同時に）設定されている場合は、NotifiedEntityパラメータ値は、暗黙的NotifiedEntityListパラメータの先頭に追加されるとみなすことになります。 NotifiedEntityパラメータは、このように、常に明示的に空に設定されていない限り連絡する最初のドメイン名を定義します。その場合には、NotifiedEntityListは、「通知の実体」を定義します。 NotifiedEntityListも空である場合は、空の「通知実体」の通常のMGCP処理が適用されます。私たちは、「通知のエンティティリスト」として上記のルールに起因するドメイン名のリストを参照します。
When the "notified entity list" is non-empty, transmission is first attempted with the first domain name in the list, as in the normal MGCP retransmission procedures described in [2]. Each of the IP addresses for this domain name MUST first be tried as specified in [2], and if this is unsuccessful, each of the IP-addresses for the second domain name MUST then be attempted, etc., following the normal MGCP retransmission procedures, with "N" (the number of retransmissions) set to zero for each domain name (see Section 4.3 in [2]). Whenever retransmission to a new domain name is initiated, the default retransmission timer value (RTO), etc., SHOULD be used. The estimator (T-DELAY) and measurements (AAD and ADEV) used for the transmission to the previous domain name are considered obsolete. Note, however, that the maximum transaction lifetime considerations apply as usual; therefore, retransmission to any of the IP addresses for any of the domain names MUST NOT occur more than T-Max seconds after the command is initially sent, irrespective of where it was sent. The Max1 DNS query MAY be performed for each of the domain names, or it MAY simply be performed for the first domain name. The Max2 DNS query however MUST NOT be performed for any but the last domain name. Also note that only the last IP-address for the last domain name can reach Max2 retransmissions; therefore, retransmission to all IP addresses other than the last IP address of the last domain name in the list MUST end after Max1 retransmissions.
「通知されたエンティティのリスト」が空でない場合、送信は、最初の[2]に記載の通常のMGCP再送手順と同様に、リスト内の最初のドメイン名で試みられます。 [2]で指定されるように、このドメイン名のIPアドレスの各々は、最初に試さなければならない、これが失敗した場合、第二のドメイン名のIP-アドレスの各々は、通常のMGCP再送以下など、試みなければなりません「N」（再送回数）との手順は、（[2]のセクション4.3を参照）は、各ドメイン名に対してゼロに設定しました。新しいドメイン名への再送信が開始されるたびに、デフォルトの再送タイマ値（RTO）などは、使用されるべきです。以前のドメイン名への送信のために使用される推定器（T-DELAY）と測定値（AADとADEV）は時代遅れであると考えられます。最大トランザクション存続考慮事項がいつものように適用されること、しかし、注意してください。そのため、ドメイン名のいずれかのアドレスは、コマンドの後にT-マックス秒以上発生はならない（MUST NOT）IPのいずれかへの再送信は、最初にかかわらず、それが送信されたところの、送信されます。 Max1ののDNSクエリがドメイン名ごとに実行することができる、またはそれは単に最初のドメイン名のために実行することができます。 Max2ののDNSクエリは、しかし最後のドメイン名が、任意のために行ってはなりません。また、最後のドメイン名の最後のIPアドレスがMax2の再送信に達することができることに注意してください。そのため、すべてのIPへの再送信は、リストの最後のドメイン名の最後のIPアドレスがMax1の再送信の後に終了する必要があります以外のアドレス。
The current value of the NotifiedEntityList parameter can be audited via AuditEndpoint; the value of the NotifiedEntity parameter will not be included here and must be audited separately. Support for the NotifiedEntityList in AuditConnection is permissible, but it is neither required nor recommended.
NotifiedEntityListパラメータの現在の値はAuditEndpointを経由して監査することができます。 NotifiedEntityパラメータの値は、ここには含まれず、別途監査を受けなければなりません。 AuditConnectionでNotifiedEntityListのサポートは許されるが、それは必要としないでも推奨もされていません。
A simple "all-of" wildcard, as defined in [2], may not be sufficient to accurately specify endpoints of interest. An example of this is a case where a Call Agent fails over, resulting in a state mismatch for endpoints involved with transient calls. To re-synchronize, the Call Agent can use the reset extension parameter described in section 2.4 of this document, to ensure that idle endpoints are in fact idle.
簡単には、「すべての」で定義されるように、ワイルドカード、[2]、正確に関心のあるエンドポイントを指定するのに十分ではないかもしれません。この例は、コールエージェントが一時通話に関わるエンドポイントの状態の不一致が生じ、フェイルオーバーした場合です。再同期のために、コールエージェントはアイドルのエンドポイントは、実際のアイドルであることを保証するために、このドキュメントのセクション2.4で説明したリセット拡張パラメータを使用することができます。
However, these endpoints may be randomly distributed across the available endpoints in a large trunk gateway.
しかしながら、これらのエンドポイントは、ランダムに大きなトランクゲートウェイで利用可能なエンドポイントに分散されてもよいです。
To satisfy this requirement, the RED package introduces some new parameters that may be used to specify the endpoints of interest for the EndpointConfiguration Command. These are the EndpointList and the EndpointMap extension parameters. These parameters MUST only be used when a virtual endpoint corresponding to the gateway is specified as the LocalEndpointName, such as:
この要件を満たすために、REDパッケージはEndpointConfigurationコマンドの関心のエンドポイントを指定するために使用することができるいくつかの新しいパラメータを導入しています。これらはEndpointListとEndpointMap拡張パラメータです。ゲートウェイに対応する仮想エンドポイントはLocalEndpointNameとして指定されている場合、これらのパラメータのみなど、使用する必要があります。
EPCF 1200 MG@gw1.whatever.net MGCP 1.0
EPCF 1200 MG@gw1.whatever.net MGCP 1.0
where "MG" is the virtual endpoint name associated with the gateway.
ここで、「MGは、」ゲートウェイに関連付けられた仮想エンドポイント名です。
The EndPointList parameters is a list of endpoint names that can include one or more lines in the following format:
EndPointListパラメータは、次の形式で1つ以上の行を含むことができ、エンドポイント名のリストです：
"RED/EL:" 0*WSP RangedLocalName 0*("," 0*WSP RangedLocalName)
"RED / EL：" 0 * 0 * WSP RangedLocalName（ "" 0 * WSP RangedLocalName）
RangedLocalName is a LocalEndpointName that may include the range wildcard notation described in Appendix E (section E.5) of [2] as well as an "all" wildcard, but the two forms MUST NOT be mixed in a single command:
RangedLocalName [2]の付録Eに記載の範囲ワイルドカード表記を含んでもよいLocalEndpointName（セクションE.5）であるだけでなく、「全て」のワイルドカードが、2つの形式が単一のコマンド中で混合してはいけません。
RangeWildcard = "*" / "[" NumericalRange *("," NumericalRange)"]" NumericalRange = 1*(DIGIT) [ "-" 1*(DIGIT) ]
RangeWildcard = "*" / "[" NumericalRange *（ "" NumericalRange） "]" NumericalRange = 1 *（DIGIT）[ " - " 1 *（DIGIT）]
Example:
例：
RED/EL: ds/ds1-1/[1-24], ds/ds1-2/[1-24], ds/ds1-3/[1-24]
RED / EL：DS / ds1-1 / [1-24]、DS / ds1-2 / [1-24]、DS / ds1-3 / [1-24]
Including an EndpointMap parameter with the following format can further specify the endpoints:
次の形式でEndpointMapパラメータを含めると、さらにエンドポイントを指定することができます。
"RED/MP:" 0*WSP TrueOrFalse 0*(TrueOrFalse)
"RED / MP" 0 * 0 * WSP TrueOrFalse（TrueOrFalse）
TrueOrFalse = "T" / "F"
TrueOrFalse = "T" / "F"
"T" indicates that the command should be applied to the corresponding endpoint, and "F" indicates that it should not. This parameter can be used in conjunction with the reset extension parameter described in section 2.4 of this document to force arbitrarily distributed endpoints into an idle state.
「T」は、コマンドが、対応するエンドポイントに適用されるべきであることを示し、「F」は、それがないことを示しています。このパラメータは、アイドル状態に任意に分散エンドポイントを強制するために、この文書のセクション2.4に記載されたリセット拡張パラメータと共に使用することができます。
If the EndpointMap parameter is used, it MUST be immediately preceded (i.e., on the previous line) by an EndPointList parameter to specify the endpoints the EndpointMap is referring to (the EndPointList MUST NOT contain the "all" wildcard). Several EndpointList and
EndpointMapパラメータが使用される場合、直ちにEndpointMapは（EndPointListが「全て」のワイルドカードを含めることはできません）を参照しているエンドポイントを指定するEndPointListパラメータによって（すなわち、前の行に）先行しなければなりません。いくつかのEndpointListと
EndpointMap parameter lines can be provided. It is considered an error if an EndpointMap parameter extends beyond the endpoints specified in the preceding EndPointList parameter. In that case, return code 800 MUST be used (see section 2.5).
EndpointMapパラメータラインを提供することができます。 EndpointMapパラメータが先行EndPointListパラメータで指定されたエンドポイントを越えて延在する場合には、エラーであると考えられます。その場合には、リターンコード800は（セクション2.5を参照）を使用しなければなりません。
The EndpointList and EndpointMap parameters MUST only be used with the EndpointConfiguration command. The EndpointList parameter MAY be provided without an EndpointMap parameter. However, as indicated earlier, an EndpointMap parameter MUST be immediately preceded by an EndpointList parameter. Neither of these parameters is auditable.
EndpointListとEndpointMapパラメータは唯一EndpointConfigurationコマンドで使用しなければなりません。 EndpointListパラメータはEndpointMapパラメータなしで提供されてもよいです。先に示したようしかし、EndpointMapパラメータは直ちにEndpointListパラメータが先行されなければなりません。これらのパラメータのどちらも監査可能です。
For an example of EndpointMap parameter usage, see Section 2.4.
EndpointMapパラメータの使用方法の例については、2.4節を参照してください。
Note that the EndpointConfiguration command is normally only valid for in-service endpoints. If an EndpointConfiguration request is sent to a wildcarded LocalEndpointName [2] and any of the endpoints specified are out-of-service, the command will fail with return code 501 (endpoint not ready).
EndpointConfigurationコマンドは、インサービスのエンドポイントのために、通常のみ有効であることに注意してください。 EndpointConfiguration要求は、ワイルドカードLocalEndpointNameに送信される場合、[2]と指定されたエンドポイントのいずれかがアウトオブサービスであり、コマンドがリターンコード501（エンドポイントの準備ができていない）で失敗します。
However, as long as the gateway is in service and able to respond to MGCP commands, it can apply the endpoint configuration command to endpoints specified by the EndpointList and/or EndpointMap parameters (regardless of whether those endpoints are in-service). Of course, the endpoint configuration information will not be maintained over gateway restarts (as the Call Agent would have to reapply the endpoint configuration after it receives an RSIP with the restart method "restart"). For example, if a new "notified entity" was provided, it would have no effect since the provisioned value would be used upon restart.
しかし、限り、ゲートウェイは、サービスおよびMGCPコマンドに応答することができるように、それは（かかわらず、これらのエンドポイントがサービス中であるかどうかの）EndpointList及び/又はEndpointMapパラメータで指定されたエンドポイントにエンドポイントコンフィギュレーションコマンドを適用することができます。 （それが再起動方法「再起動」でRSIPを受けた後、コールエージェントがエンドポイントの設定を再適用しなければならないであろうと）もちろん、エンドポイントの設定情報は、ゲートウェイの再起動に渡って維持されることはありません。新しい「通知エンティティは、」提供された場合、それはプロビジョニング値は再起動時に使用されるので、効果がないだろう。
EndpointList and/or EndpointMap parameters MUST only be used with a virtual endpoint name corresponding to the gateway (as indicated above). If it is used with any other endpoint name (whether wild-carded or not), then error code 801 (section 2.5) MUST be returned.
EndpointList及び/又はEndpointMapパラメータは、（上述したように）ゲートウェイに対応する仮想エンドポイント名を使用する必要があります。それは（野生カーディングするか否かにかかわらず）、他のエンドポイントの名前で使用される場合、エラーコード801（セクション2.5）が返されなければなりません。
A new extension parameter for use with the EndpointConfiguration command is defined. A new NotifiedEntity value can be included with a "RED/N" parameter as follows:
EndpointConfigurationコマンドで使用する新しい拡張パラメータが定義されています。次のように新しいNotifiedEntity値が「RED / N」パラメータに含めることができます。
EPCF 1200 *@gw1.whatever.net MGCP 1.0 RED/N: ca1@ca1234.whatever.net
EPCF 1200 *@gw1.whatever.net MGCP 1.0 RED / N：ca1@ca1234.whatever.net
This changes the "notified entity" for the endpoint(s) to the value specified. If the "all of" wildcard convention is used, the NotifiedEntity value replaces all of the existing "notified entities" for those endpoints. If NotifiedEntity is omitted in a subsequent EndpointConfiguration command, the "notified entity" remains unchanged.
これは、指定した値にエンドポイントの「通知実体」（複数可）を変更します。 「すべての」ワイルドカードの規則を使用する場合は、NotifiedEntity値は、これらのエンドポイントのために既存の「通知の実体」のすべてを置き換えます。 NotifiedEntityが、その後のEndpointConfigurationコマンドでは省略されている場合は、「通知の実体は」変わらず。
If the "notified entity" is a domain name that resolves to multiple IP addresses, one of the resolved addresses MUST be selected. If one of those IP addresses is the IP address of the Call Agent sending the request, that IP address SHOULD be selected first.
「通知エンティティが」複数のIPアドレスに解決されるドメイン名である場合は、解決のアドレスのいずれかを選択する必要があります。これらのIPアドレスの1つが要求を送信するコールエージェントのIPアドレスである場合は、そのIPアドレスを最初に選択する必要があります。
The NotifiedEntityList parameter can also be specified in an endpoint configuration command, such as follows:
NotifiedEntityListパラメータはまた、以下のように、エンドポイントコンフィギュレーションコマンドで指定することができます。
EPCF 1200 *@gw1.whatever.net MGCP 1.0 RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net
EPCF 1200 *@gw1.whatever.net MGCP 1.0 RED / NL：ca1@myca.whatever.net、ca2@mybackupca.whatever.net
Note that this command will only succeed if all the endpoints on the gateway are in-service.
ゲートウェイ上のすべてのエンドポイントがサービス中である場合に、このコマンドは、成功することに注意してください。
As indicated in section 2.2, it can also apply this to the gateway virtual endpoint:
セクション2.2に示されているように、それはまた、ゲートウェイ、仮想エンドポイントにこれを適用することができます。
EPCF 1200 MG@gw1.whatever.net MGCP 1.0 RED/EL: * RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net
EPCF 1200 MG@gw1.whatever.net MGCP 1.0 RED / EL：* RED / NL：ca1@myca.whatever.net、ca2@mybackupca.whatever.net
Note that the outcome of this command is not affected by the service state of the endpoints on the gateway.
このコマンドの結果は、ゲートウェイ上のエンドポイントのサービス状態に影響されないことに留意されたいです。
As indicated in section 2.1, the NotifiedEntityList ("RED/NL") parameter may be used with any command for which a NotifiedEntity parameter is allowed. However, the "RED/N" parameter SHOULD only be used with the endpoint configuration command.
セクション2.1に示されているように、NotifiedEntityList（「RED / NL」）パラメータは、NotifiedEntityパラメータが許容される任意のコマンドと共に使用することができます。しかし、「RED / N」パラメータは、エンドポイントコンフィギュレーションコマンドで使用されるべきです。
The "RED/N" parameter does not have a default value, and the auditing behavior for auditing the "NotifiedEntity" is unchanged from that specified in [2], regardless of how the "NotifiedEntity" was set (i.e., there is no specific audit associated with the "RED/N" parameter, and therefore the "RED/N" parameter cannot be audited).
「RED / N」パラメータがデフォルト値を持っていない、と「NotifiedEntity」を監査する監査動作がで指定されたものから変更されていない[2]にかかわらず、「NotifiedEntity」が設定されたかの（すなわち、具体的なありません監査）「RED / N」パラメータに関連付けられ、したがって「RED / N」パラメータを監査することはできません。
Another EndpointConfiguration parameter ("RED/R") allows the Call Agent to reset one or more endpoints. The ABNF syntax for the parameter line is as follows:
別のEndpointConfigurationパラメータ（「RED / R」）はコールエージェントが1つ以上のエンドポイントをリセットすることができます。次のようにパラメータ行のためのABNFの構文は次のとおりです。
"RED/R:" 0*WSP "reset"
"RED / R：" 0 * WSP "リセット"
This has the effect of resetting and re-initializing the specified endpoints (i.e., any connections on the endpoint will be deleted, and the endpoint will be returned to its clean default state without any active signals).
これは、指定されたエンドポイント（すなわち、エンドポイント上のすべての接続が削除され、エンドポイントがアクティブな信号なしにクリーンなデフォルトの状態に戻される）リセットして再初期化する効果を有します。
Example:
例：
EPCF 1200 mg@gw1.whatever.net MGCP 1.0 RED/EL: ds/e1-3/[1-30] RED/MP: TFTTTTTFFFTTTTTFFFFTFFTTFTTTFF RED/EL: ds/e1-5/[1-30] RED/MP: TFFFFFTFFFTTFTTFFFFTFFFTFTTTTT RED/R: reset
EPCF 1200 mg@gw1.whatever.net MGCP 1.0 RED / EL：DS / E1-3 / [1-30] RED / MP：TFTTTTTFFFTTTTTFFFFTFFTTFTTTFF RED / EL：DS / e1-5 / [1-30] RED / MP： TFFFFFTFFFTTFTTFFFFTFFFTFTTTTT RED / R：リセット
In this case, the particular endpoints specified by "T" by the EndpointMap parameter in the E1 spans ds/e1-3 and ds/e1-5 are reset.
この場合には、E1にEndpointMapパラメータによって「T」によって指定された特定のエンドポイントは、DS / E1-3にまたがり、DSが/ e1-5がリセットされます。
The "RED/R" parameter MUST NOT be used with any command other than the endpoint configuration command. There is no default value for the parameter, and therefore it is unaffected when omitted. There is no specific audit behavior associated with this parameter, i.e., it cannot be audited.
「RED / R」のパラメータは、エンドポイントコンフィギュレーションコマンド以外のコマンドで使用してはいけません。そこパラメータにはデフォルト値はなく、省略された場合ので、それは影響を受けません。このパラメータに関連付けられた特定の監査行動、すなわち、それを監査することはできませんがありません。
The following package-specific return codes are defined for the "RED" package:
次のパッケージ固有の戻りコードは「RED」のパッケージ用に定義されています。
Code Text Explanation
コードテキスト説明
800 EndpointMap Either the EndpointMap parameters Out of Range are outside the range specified by the EndpointList parameter, or the EndpointList Parameter was not included when an EndpointMap parameter was included.
800 EndpointMapいずれかが範囲外EndpointMapパラメータはEndpointMapパラメータが含まれていた場合に含まれていなかったEndpointListパラメータ、またはEndpointListパラメータで指定された範囲外です。
801 Incorrect Usage Incorrect usage of parameters, Of Parameters such as EndpointList parameter, used where the endpoint name was not the virtual endpoint name corresponding to the gateway.
そのようなEndpointListパラメータとしてパラメータのパラメータ801不正使用不正使用、エンドポイント名がゲートウェイに対応する仮想エンドポイント名がなかった場合に使用されます。
The MGCP package title "Redirect and Reset" with the name "RED" and version number 0 has been registered with IANA, as indicated in Appendix C.1 in [2].
[2]の付録C.1に示すように名前「RED」とバージョン番号0のMGCPパッケージタイトル「リダイレクトするとリセット」は、IANAに登録されています。
Section 5 of the base MGCP specification [2] discusses security requirements for the base protocol that apply equally to the package defined in this document. Use of a security protocol that provides per message authentication and integrity services, such as IPsec (RFC 2401 [3], RFC 2406 [4]), is required in order to ensure that requests and responses are obtained from authenticated sources and that messages have not been modified. Without these services, gateways and Call Agents are open to attacks.
ベースMGCP仕様[2]のセクション5は、本文書で定義されたパッケージにも同様に適用ベースプロトコルのためのセキュリティ要件を論じています。 IPsecなどのメッセージ認証及び完全性サービスごとに提供するセキュリティプロトコルの使用、（RFC 2401 [3]は、RFC 2406 [4]）、メッセージが持っている要求と応答が認証ソースから得られることを保証するために、その要求されます変更されていません。これらのサービスがなければ、ゲートウェイやコールエージェントは、攻撃に開放されています。
For example, an attacker could masquerade as a Call Agent and initiate a denial of service attack by resetting endpoints that were involved in valid calls. Another attack using the package described in this document could involve redirecting endpoints to the attacker so that it acts as the Call Agent for those endpoints.
例えば、攻撃者がコール・エージェントとして装うことができ、有効な通話に関与していたエンドポイントをリセットすることにより、サービス拒否攻撃を開始します。それは、これらのエンドポイントのコール・エージェントとして動作するように、この文書で説明したパッケージを使用して別の攻撃は、攻撃者にエンドポイントをリダイレクト関与し得ます。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[2]アンドレア、F.およびB.フォスター、 "メディアゲートウェイコントロールプロトコル（MGCP）バージョン1.0"、RFC 3435、2003年1月。
[3] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[3]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[4]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
Authors' Addresses
著者のアドレス
Flemming Andreasen Cisco Systems 499 Thornall Street, 8th Floor Edison, NJ 08837
フレミングAndreasenのシスコシステムズ499 Thornallストリート、8階エジソン、NJ 08837
EMail: fandreas@cisco.com
メールアドレス：fandreas@cisco.com
Bill Foster Cisco Systems
ビル・フォスターシスコシステムズ
EMail: bfoster@cisco.com
メールアドレス：bfoster@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、www.rfc-editor.orgで、そこに記載される場合を除き、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 ISOC文書の権利に関するISOCの手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。