[要約] RFC 3991は、MGCPリダイレクトとリセットパッケージに関する仕様です。このRFCの目的は、MGCPゲートウェイのリダイレクトとリセットの動作を定義し、通信の信頼性と柔軟性を向上させることです。
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).
Copyright（c）The Internet Society（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.
このドキュメントは、コミュニティの情報のために公開されています。現在、多くの製品に展開されている非ITFプロトコルについて説明しています。実装者は、IETF Megaco Working GroupおよびITU-T SG16で開発されたRFC 3015に注意する必要があります。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つ以上のエンドポイントを新しいコールエージェントにリダイレクトできます。これは、通知Requestまたは接続処理コマンドで実行する必要があります。ただし、これらのコマンドはエンドポイントまたは接続状態に影響するため、そのような要求は通常、単一のコマンドを使用してエンドポイントのグループに送信することはできません。これは、新しいコールエージェントが失敗したものを引き継ぐ場合、新しいコールエージェントがエンドポイントを一度に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.
また、新しい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.
このパッケージに含まれる3番目の機能は、エンドポイントの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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [1]に記載されているように解釈される。
Package Name: RED Version: 0
パッケージ名：赤いバージョン：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]の通知パラメーターと同じように機能しますが、複数のドメイン名を指定することができます。
* 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.
* コールエージェントは、「すべての」ワイルドカードによって指定されたエンドポイントのコレクションに、新しいnotifidedentityまたは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]で定義されているコロンと通知値のコンマ分離リストが続きます。
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は、通知パラメーターと同様の方法で機能しますが、複数のドメイン名をリストすることを除きます。したがって、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パラメーターは、通知パラメーターが許可されている任意のコマンドまたは応答でオプションです。再起動に続いて、特にプロビジョニングされない限り、NotifiedEntityListは最初は空です。後続のコマンドでは、明示的に変更されるまで現在の値を保持します。通知パラメーターと非空白の通知リストパラメーターの両方が設定されている場合（必ずしも同時にそうではない）、notifiedentityパラメーター値は、notifiedentityListパラメーターの開始に暗黙的に追加されていると見なされます。したがって、通知パラメーターは、明示的に空に設定されていない限り、常に連絡する最初のドメイン名を定義します。その場合、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再送信手順のように、リスト内の最初のドメイン名で送信が最初に試みられます。このドメイン名の各IPアドレスは、最初に[2]で指定されたとおりに試行する必要があります。これが失敗した場合、通常のMGCPの再送信に続いて、2番目のドメイン名の各IPアドレスを試みる必要があります。プロシージャ、「n」（再送信数）が各ドメイン名でゼロに設定されています（[2]のセクション4.3を参照）。新しいドメイン名への再送信が開始されるたびに、デフォルトの再送信タイマー値（RTO）などを使用する必要があります。前のドメイン名への送信に使用される推定量（T-Delay）と測定（AADおよびADEV）は時代遅れと見なされます。ただし、最大トランザクションの寿命の考慮事項は通常どおりに適用されることに注意してください。したがって、ドメイン名のいずれかのIPアドレスのいずれかへの再送信は、コマンドが最初に送信されてからT-Max秒以上に発生してはなりません。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を介して監査できます。通知パラメーターの値はここには含まれておらず、個別に監査する必要があります。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コマンドの関心のあるエンドポイントを指定するために使用できるいくつかの新しいパラメーターを導入します。これらは、エンドポイントリストとエンドポイントマップ拡張パラメーターです。これらのパラメーターは、ゲートウェイに対応する仮想エンドポイントが、次のようなLocalEndPointNameとして指定されている場合にのみ使用する必要があります。
EPCF 1200 MG@gw1.whatever.net MGCP 1.0
EPCF 1200 mg@gw1.hatever.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)
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（セクションE.5）に記載されている範囲のワイルドカード表記と「すべて」のワイルドカードを含むLocalEndPointNameですが、2つのフォームを単一のコマンドで混合してはなりません。
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)
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 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パラメーターを使用する場合、エンドポイントマップが参照しているエンドポイントを指定するために、EndPointListパラメーターの直前（つまり、前の行で）が必要です（EndPointListには「すべて」ワイルドカードを含めてはなりません）。いくつかのEndPointListおよびEndPointMapパラメーター行を提供できます。エンドポイントマップパラメーターが、前のエンドポイントリストパラメーターで指定されたエンドポイントを超えて拡張されている場合、エラーと見なされます。その場合、返品コード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]に送信され、指定されたエンドポイントのいずれかがサービス外である場合、コマンドはreturn Code 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コマンドに応答できる限り、エンドポイント構成コマンドをエンドポイントリストおよび/またはエンドポイントマップパラメーターによって指定されたエンドポイントに適用できます（これらのエンドポイントがインサービスであるかどうかに関係なく）。もちろん、エンドポイント構成情報はゲートウェイの再起動を介して維持されません（コールエージェントは、再起動メソッド「再起動」を備えた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コマンドで使用する新しい拡張機能パラメーターが定義されています。次のように、「Red/N」パラメーターに新しい通知値を含めることができます。
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.
これにより、エンドポイントの「通知されたエンティティ」が指定された値に変更されます。「すべての」ワイルドカード条約が使用されている場合、通知の値は、これらのエンドポイントのすべての既存の「通知されたエンティティ」を置き換えます。その後の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アドレスに解決するドメイン名である場合、解決されたアドレスの1つを選択する必要があります。これらのIPアドレスのいずれかがリクエストを送信するコールエージェントの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
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
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"）パラメーターは、通知パラメーターが許可される任意のコマンドとともに使用できます。ただし、「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」パラメーターにはデフォルトの値がなく、「通知」を監査するための監査動作は[2]で指定されたものから変更されていません。「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.HATEVER.NET MGCP 1.0 RED/EL：DS/E1-3/[1-30] RED/MP：TFTTTTTTTTTTTTTTTTTFFFFTFFTTTTTTTF/EL：DS/E1-5/[1-30] RED/MP：
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:
次のパッケージ固有の返品コードは、「赤」パッケージ用に定義されています。
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.
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.
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の名前「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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[2] Andreasen、F。およびB. Foster、「Media Gateway Control Protocol（MGCP）バージョン1.0」、RFC 3435、2003年1月。
[3] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[3] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[4] Kent、S。およびR. Atkinson、「IPカプセル化セキュリティペイロード（ESP）」、RFC 2406、1998年11月。
Authors' Addresses
著者のアドレス
Flemming Andreasen Cisco Systems 499 Thornall Street, 8th Floor Edison, NJ 08837
フレミングアンドレアセンシスコシステム499 Thornall Street、8階エジソン、ニュージャージー08837
EMail: fandreas@cisco.com
Bill Foster Cisco Systems
ビル・フォスター・シスコ・システム
EMail: bfoster@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。