RFC3991 日本語訳

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ページ]