RFC3991 日本語訳
3991 Media Gateway Control Protocol (MGCP) Redirect and Reset Package.B. Foster, F. Andreasen. February 2005. (Format: TXT=22951 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Foster Request for Comments: 3991 F. Andreasen Category: Informational Cisco Systems February 2005
コメントを求めるワーキンググループB.フォスターの要求をネットワークでつないでください: 3991年のF.Andreasenカテゴリ: 情報のシスコシステムズ2005年2月
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)インターネット協会(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プロトコルについて説明します。 ImplementersはMGCPがIETFとITU-Tによってアドレスに設計されたのをRFC3015を意識しているべきです。(RFCはIETF Megaco作業部会とITU-T SG16で開発されて、需要を満たす規格ベース(包含はセキュリティ問題を見直した)の方法であると考えられます)。
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.
ベースメディアゲートウェイControlプロトコル(MGCP)仕様(RFC3435)は、終点が一度に1つの終点に向け直されるのを許容します。 このドキュメントは終点のグループを転送して、リセットするのにメカニズムを提供する新しいMGCPパッケージの形に拡大を供給します。 また、それはCallエージェントのリストが都合のよいオーダーで指定されるのを許容することによって、より正確に終点を向け直す能力を含んでいます。
Foster & Andreasen Informational [Page 1] RFC 3991 MGCP Redirect and Reset Package February 2005
フォスターとAndreasenの情報[1ページ]のRFC3991MGCPはパッケージ2005年2月を向け直して、リセットします。
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
1. 序論… 2 1.1. このドキュメントで中古のコンベンション… 3 2. パッケージを向け直して、リセットしてください… 3 2.1. NotifiedEntityList拡大パラメタ… 3 2.2. 終点特許説明書の作成書… 4 2.2.1. EndpointListとEndpointMap拡大パラメタ… 4 2.2.2. 使われなくなっている終点へのアプリケーション… 6 2.3. 向け直します。 6 2.4. 拡大パラメタをリセットしてください… 7 2.5. 復帰コード… 8 3. IANA問題… 9 4. セキュリティ問題… 9 5. 標準の参照… 9人の作者のアドレス… 10 完全な著作権宣言文… 11
1. Introduction
1. 序論
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.
ベースメディアゲートウェイControlプロトコル(MGCP)仕様[2]で、Callエージェントは、新しいCallエージェントに1つ以上の終点を向け直すために新しいNotifiedEntityパラメタを指定できます。 NotificationRequestか接続取り扱い命令でこれをしなければなりません。 しかしながら、これらのコマンドが終点か接続状態に影響するので、ただ一つのコマンドと共にそのような要求を終点のグループに通常送ることができません。 これは、新しいCallエージェントが失敗したもののために引き継ぐなら、新しいCallエージェントが一度に一つ終点を向け直さなければならないことを意味します。 多くの終点(例えば、大きい中継方式ゲートウェイの中の)があれば、これはかなりの時間がかかるかもしれません。
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.
このドキュメントはCallエージェントに終点か接続状態に影響しないで終点のグループを転送させる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パラメタ(NotifiedEntityパラメタと同様ですが複数のドメイン名が提供されるのを許容する)です。 これで、Callエージェントは、より正確に代替のCallエージェントの都合のよい規則正しいリストに終点を向けることができます。
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つ以上のグループをリセットして、再初期化する能力です。 この能力はCallエージェントフェイルオーバー状況で役に立ちます。
Foster & Andreasen Informational [Page 2] RFC 3991 MGCP Redirect and Reset Package February 2005
フォスターとAndreasenの情報[2ページ]のRFC3991MGCPはパッケージ2005年2月を向け直して、リセットします。
1.1. Conventions Used in This Document
1.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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。
2. Redirect and Reset Package
2. パッケージを向け直して、リセットしてください。
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拡大パラメタを定義します。 これは、NotifiedEntityパラメタとして[2]で同じように働いていますが、1つ以上のドメイン名が指定されるのを許容します。
* 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が指定された終点の収集にCallエージェントを通過させる、「」 ワイルドカードのすべて。 新しいCallエージェントが前の1つから引き継いで、これから先メッセージをそれに送るために終点を向け直したいなら、これは役に立ちます。
* 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.
* Callエージェントが、あるタイプの失敗に続いて、役に立つ場合があるリセットをするよう終点の1つ以上のグループに要求するのを許容します。
2.1. NotifiedEntityList Extension Parameter
2.1. NotifiedEntityList拡大パラメタ
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"としてコード化されて、コロンとNotifiedEntity値のコンマで切り離されたリストはMGCP仕様[2]に基づき定義されるようにあとに続いています、以下の通りです:
RED/NL: ca1@myca.whatever.net, ca2@mybackupca.whatever.net
赤/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
NotifiedEntityListパラメタはNotifiedEntityパラメタが許容されているところでどんなコマンドや応答でも任意です。 再開に続いて、別の方法で食糧を供給されない場合、NotifiedEntityListは初めは、空です。 その後のコマンドでは、それは現行価値を明らかに変えるまで保有します。 NotifiedEntityパラメタと非空のNotifiedEntityListパラメタの両方が設定されたなら(必ず同時にであるというわけではない)、NotifiedEntityパラメタ価値はそれとなく始めに加えられると見なされるでしょう。
Foster & Andreasen Informational [Page 3] RFC 3991 MGCP Redirect and Reset Package February 2005
フォスターとAndreasenの情報[3ページ]のRFC3991MGCPはパッケージ2005年2月を向け直して、リセットします。
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は「通知された実体」を定義します。 また、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 retransmission手順のように。 [2]、これが失敗しているなら、最初に指定されるとしてこのドメイン名のためのそれぞれのIPアドレスを試みなければなりません、次に、2番目のドメイン名のためのそれぞれのIP-アドレスを試みなければなりませんなど、正常なMGCP retransmission手順に従って、(「再-トランスミッション」の数)が各ドメイン名あたりゼロに設定する「N」で。([2])でセクション4.3を見てください。 SHOULD、新しいドメイン名への「再-トランスミッション」が開始されて、デフォルト再送信タイマーが値(RTO)などであるときはいつも、使用されてください。 トランスミッションに前のドメイン名に使用される見積り人(T-DELAY)と測定(AADとADEV)は時代遅れであると考えられます。 しかしながら、最大のトランザクション生涯問題がいつものように適用されることに注意してください。 したがって、ドメイン名のどれかのIPアドレスのどれかへの「再-トランスミッション」は初めはコマンドの秒後のT-マックスを送るより現れてはいけません、それが送られたところにおいて関係ありません。 Max1 DNS質問がそれぞれのドメイン名のために実行されるかもしれませんか、またはそれは最初のドメイン名のために単に実行されるかもしれません。 しかしながら、いずれにもかかわらず、最後のドメイン名のためにMax2 DNS質問を実行してはいけません。 また、最後のドメイン名のための最後のIP-アドレスだけがMax2 retransmissionsに達することができることに注意してください。 したがって、リストにおける最後のドメイン名の最後のIPアドレス以外のすべてのIPアドレスへの「再-トランスミッション」はMax1 retransmissionsの後に終わらなければなりません。
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.
AuditEndpointを通してNotifiedEntityListパラメタの現行価値を監査できます。 NotifiedEntityパラメタの値をここに含まれないで、別々に監査しなければなりません。 AuditConnectionのNotifiedEntityListのサポートが許されていますが、それは、必要でなく、また推薦されません。
2.2. Endpoint Specifier
2.2. 終点特許説明書の作成書
2.2.1. EndpointList and EndpointMap Extension Parameters
2.2.1. EndpointListとEndpointMap拡大パラメタ
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.
A簡単である、「オール、」 [2]で定義されるワイルドカードは、正確に興味がある終点を指定するために十分でないかもしれません。 この例はCallエージェントが失敗するケースです、終点との一時的な呼び出しがあるかかわった州のミスマッチをもたらして。 再連動するように、Callエージェントは活動していない終点が確実に事実上、活動していなくなるようにするためにこのドキュメントのセクション2.4で説明されたリセット拡大パラメタを使用できます。
Foster & Andreasen Informational [Page 4] RFC 3991 MGCP Redirect and Reset Package February 2005
フォスターとAndreasenの情報[4ページ]のRFC3991MGCPはパッケージ2005年2月を向け直して、リセットします。
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 Commandにおいて、興味がある終点を指定するのに使用されるかもしれないいくつかの新しいパラメタを紹介します。 これらは、EndpointListとEndpointMap拡大パラメタです。 ゲートウェイに対応する仮想の終点が以下などのLocalEndpointNameとして指定されるとき、これらのパラメタを使用するだけでよいです。
EPCF 1200 MG@gw1.whatever.net MGCP 1.0
EPCF1200 MG@gw1.whatever.net MGCP1.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)
「赤/高架鉄道:」 0*WSP RangedLocalName0*(「」、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]のAppendix E(セクションE.5)で説明された範囲ワイルドカード記法を含むかもしれないLocalEndpointNameですが、2つのフォームがただ一つのコマンドで複雑であってはいけません:
RangeWildcard = "*" / "[" NumericalRange *("," NumericalRange)"]" NumericalRange = 1*(DIGIT) [ "-" 1*(DIGIT) ]
RangeWildcardが「*」/と等しい、「[「NumericalRange*、(「」、NumericalRange)、」、]、」 NumericalRange=1*(ケタ)[「-」1*(ケタ)]
Example:
例:
RED/EL: ds/ds1-1/[1-24], ds/ds1-2/[1-24], ds/ds1-3/[1-24]
赤/高架鉄道: 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)
「赤/MP:」 0*WSP TrueOrFalse0*(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パラメタが使用されているなら、EndPointListパラメタはすぐに、それに先行して(すなわち、前の系列で)(EndPointListは「すべて」ワイルドカードを含んではいけません)、EndpointMapが言及している終点を指定しなければなりません。 そして数個EndpointList。
Foster & Andreasen Informational [Page 5] RFC 3991 MGCP Redirect and Reset Package February 2005
フォスターとAndreasenの情報[5ページ]のRFC3991MGCPはパッケージ2005年2月を向け直して、リセットします。
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.
EndpointConfigurationコマンドと共にEndpointListとEndpointMapパラメタを使用するだけでよいです。 EndpointMapパラメタなしでEndpointListパラメタを提供するかもしれません。 しかしながら、EndpointListパラメタはすぐに、より早く示されるようなEndpointMapパラメタに先行しなければなりません。 これらのパラメタのどちらも監査可能ではありません。
For an example of EndpointMap parameter usage, see Section 2.4.
EndpointMapパラメタ用法の例に関しては、セクション2.4を見てください。
2.2.2. Application to Out-of-Service Endpoints
2.2.2. 使われなくなっている終点へのアプリケーション
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要求をwildcarded 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を受けた後にCallエージェントが終点構成を再び使わなければならないだろうというとき)設定情報が主張されない。 食糧を供給された値は再開のときに使用されるでしょう、例えば、したがって、新しい「通知された実体」を提供するなら、それは効き目がないでしょうに。
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パラメタを使用するだけでよいです(上で示されるように)。 それがいかなる他の終点名と共にも使用されるなら(荒野がcardedされたか否かに関係なく)、エラーコード801(セクション2.5)を返さなければなりません。
2.3. Redirect
2.3. 再直接
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コマンドによる使用のための新しい拡大パラメタは定義されます。 「赤/N」パラメタは以下の通りで新しいNotifiedEntity値を含むことができます:
EPCF 1200 *@gw1.whatever.net MGCP 1.0 RED/N: ca1@ca1234.whatever.net
EPCF1200 *@gw1.whatever.net MGCP1.0赤/N: ca1@ca1234.whatever.net
Foster & Andreasen Informational [Page 6] RFC 3991 MGCP Redirect and Reset Package February 2005
フォスターとAndreasenの情報[6ページ]のRFC3991MGCPはパッケージ2005年2月を向け直して、リセットします。
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.
これは「通知された実体」を値への(s)が指定した終点に変えます。 「」 ワイルドカードコンベンションのすべてが使用されている、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にアドレスを決議するドメイン名であるなら、決心しているアドレスの1つを選択しなければなりません。 それらのIPアドレスの1つがIPアドレスSHOULDが最初に選択されるという要求を送るCallエージェントの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
EPCF1200 *@gw1.whatever.net MGCP1.0赤/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
EPCF1200 MG@gw1.whatever.net MGCP1.0赤/高架鉄道: * 赤/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(「赤/NL」)パラメタはNotifiedEntityパラメタが許容されているどんなコマンドと共にも使用されるかもしれません。 しかしながら、「赤/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).
「赤/N」パラメタには、デフォルト値がありません、そして、"NotifiedEntity"を監査するための監査の振舞いは[2]で指定されたそれから変わりがありません、"NotifiedEntity"がどう設定されたか(すなわち、「赤/N」パラメタに関連しているどんな特定の監査もありません、そして、したがって、「赤/N」パラメタは監査できません)にかかわらず。
2.4. Reset Extension Parameter
2.4. リセット拡大パラメタ
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パラメタ(「赤/R」)で、呼び出しエージェントは1つ以上の終点をリセットできます。 パラメタ行のためのABNF構文は以下の通りです:
Foster & Andreasen Informational [Page 7] RFC 3991 MGCP Redirect and Reset Package February 2005
フォスターとAndreasenの情報[7ページ]のRFC3991MGCPはパッケージ2005年2月を向け直して、リセットします。
"RED/R:" 0*WSP "reset"
「赤/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
EPCF1200 mg@gw1.whatever.net MGCP1.0赤/高架鉄道: ds/e1-3/[1-30]RED/MP: TFTTTTTFFFTTTTTFFFFTFFTTFTTTFF赤/高架鉄道: ds/e1-5/[1-30]RED/MP: TFFFFFTFFFTTFTTFFFFTFFFTFTTTTT赤/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.
この場合、1Eの長さのds/e1-3とds/e1-5のEndpointMapパラメタによる「T」によって指定された特定の終点はリセットされます。
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.
終点構成コマンド以外のどんなコマンドと共にも「赤/R」パラメタを使用してはいけません。 パラメタのためのデフォルト値が全くありません、そして、したがって、省略されると、それは影響を受けないです。 このパラメタに関連しているどんな特定の監査の振舞いもありません、すなわち、それは監査できません。
2.5. Return Codes
2.5. 復帰コード
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.
800 EndpointMapパラメタが含まれていたとき、EndpointListパラメタによって指定された範囲の外にRangeのEndpointMap Either EndpointMapパラメタOutがあったか、またはEndpointList Parameterは含まれていませんでした。
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.
パラメタの不正確なUsage Incorrect用法(EndpointListパラメタなどのOf Parameters)が終点名が仮想の終点でなかったところで使用した801はゲートウェイとの対応を命名します。
Foster & Andreasen Informational [Page 8] RFC 3991 MGCP Redirect and Reset Package February 2005
フォスターとAndreasenの情報[8ページ]のRFC3991MGCPはパッケージ2005年2月を向け直して、リセットします。
3. IANA Considerations
3. IANA問題
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].
タイトルが名前「赤」とバージョンNo.0で「向け直して、リセットする」MGCPパッケージはIANAに登録されました、[2]の付録C.1にみられるように。
4. Security Considerations
4. セキュリティ問題
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などのように。(RFC2401[3](RFC2406[4]))が、認証されたソースから要求と応答を得て、メッセージを変更していないのを確実にするのに必要です。 これらのサービスがなければ、ゲートウェイとCallエージェントは攻撃にオープンです。
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.
例えば、攻撃者は、有効な判定にかかわった終点をリセットすることによって、Callエージェントのふりをして、サービス不能攻撃を開始できるでしょう。 本書では説明されたパッケージを使用する別の攻撃が、攻撃者に終点を向け直すことを伴うかもしれないので、それはそれらの終点へのCallエージェントとして務めます。
5. Normative References
5. 引用規格
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[2] Andreasen、F.、およびB.フォスター、「メディアゲートウェイコントロールは2003年1月にバージョン1インチ、(MGCP)RFC3435について議定書の中で述べます」。
[3] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[3] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[4] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[4] ケントとS.とR.アトキンソン、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC2406、1998年11月。
Foster & Andreasen Informational [Page 9] RFC 3991 MGCP Redirect and Reset Package February 2005
フォスターとAndreasenの情報[9ページ]のRFC3991MGCPはパッケージ2005年2月を向け直して、リセットします。
Authors' Addresses
作者のアドレス
Flemming Andreasen Cisco Systems 499 Thornall Street, 8th Floor Edison, NJ 08837
ニュージャージー フレミングAndreasenシスコシステムズ499Thornall通り、第8Floorエディソン、08837
EMail: fandreas@cisco.com
メール: fandreas@cisco.com
Bill Foster Cisco Systems
ビルフォスターシスコシステムズ
EMail: bfoster@cisco.com
メール: bfoster@cisco.com
Foster & Andreasen Informational [Page 10] RFC 3991 MGCP Redirect and Reset Package February 2005
フォスターとAndreasenの情報[10ページ]のRFC3991MGCPはパッケージ2005年2月を向け直して、リセットします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78と、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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でISOC Documentsの権利に関するISOCの手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Foster & Andreasen Informational [Page 11]
フォスターとAndreasen情報です。[11ページ]
一覧
スポンサーリンク