[要約] RFC 5347は、Media Gateway Control Protocol（MGCP）のFax Packageに関する仕様です。このRFCの目的は、MGCPを使用してファックス通信を制御するためのプロトコル仕様を提供することです。
Network Working Group F. Andreasen
Request for Comments: 5347 Cisco Systems
Category: Informational D. Hancock
CableLabs
October 2008
Media Gateway Control Protocol Fax Package
メディアゲートウェイ制御プロトコルファックスパッケージ
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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
概要
This document defines a Media Gateway Control Protocol (MGCP) package to support fax calls. The package allows for fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement.
このドキュメントでは、FAXコールをサポートするメディアゲートウェイ制御プロトコル（MGCP）パッケージを定義します。このパッケージでは、2つの異なる方法でファックス呼び出しをサポートできます。最初のものは、コールエージェントの制御下でFAXリレーにITU-T推奨T.38を使用します。2番目には、ゲートウェイがファックス伝送の方法を決定するだけでなく、コールエージェントの関与なしにファックスコールの詳細を処理できます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
2. Fax Package Definition ..........................................3
2.1. LocalConnectionOptions .....................................3
2.1.1. T.38 Procedure (Strict or Loose) ....................6
2.1.2. Gateway Procedure ...................................8
2.1.3. Off Procedure .......................................8
2.1.4. Mode Operation ......................................8
2.1.5. Detecting a Fax Call ...............................10
2.1.6. Considerations for Determining Which
Procedures to Request ..............................11
2.2. Events and Signals ........................................13
2.2.1. Gateway Controlled Fax (gwfax) .....................13
2.2.2. No Special Fax Handling (nopfax) ...................14
2.2.3. T.38 Fax Relay (t38) ...............................14
2.3. Connection Parameters .....................................15
2.4. Negotiation of T.38 Parameters ............................16
2.5. Implementation Considerations .............................18
2.5.1. Media IP Address and Port for T.38 .................18
2.5.2. Case Sensitivity ...................................18
2.5.3. Boolean Indicator After T.38 Parameters ............19
3. Call Flow Examples .............................................19
3.1. Call Agent Controlled T.38 Strict .........................20
3.2. Multiple and Different Options ............................29
3.3. Interaction with SIP Endpoints ............................37
4. Security Considerations ........................................44
5. IANA Considerations ............................................44
6. Normative References ...........................................44
7. Informative References .........................................45
This document defines a Media Gateway Control Protocol (MGCP) [RFC3435] package that enables MGCP controlled gateways to support fax calls. The package enables fax calls to be supported in two different ways. The first one utilizes ITU-T Recommendation T.38 using either UDP Transport Layer (UDPTL) or TCP (see [T38]) for fax relay under the control of the Call Agent. The second one lets the gateway decide upon a method for fax transmission as well as handle the details of the fax call without Call Agent involvement.
このドキュメントでは、MGCP制御ゲートウェイがFAXコールをサポートできるようにするメディアゲートウェイ制御プロトコル（MGCP）[RFC3435]パッケージを定義します。このパッケージにより、FAXコールを2つの異なる方法でサポートできます。最初のものは、コールエージェントの制御下でFAXリレーにUDP輸送層（UDPTL）またはTCP（[T38]を参照）を使用して、ITU-T推奨T.38を使用します。2番目には、ゲートウェイがファックス伝送の方法を決定するだけでなく、コールエージェントの関与なしにファックスコールの詳細を処理できます。
The fax package definition is provided in Section 2, and in Section 3 we provide three call flow examples showing how to use it. Security considerations are found in Section 4, followed by the IANA considerations and references.
FAXパッケージの定義はセクション2で提供されており、セクション3では、使用方法を示す3つのコールフロー例を示します。セキュリティ上の考慮事項はセクション4にあり、その後にIANAの考慮事項と参照が続きます。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC-2119 [RFC2119]に記載されているように解釈される。
A package is defined for fax. The package defines new LocalConnectionOptions, events, and connection parameters as detailed below:
パッケージはFAX用に定義されています。パッケージは、以下に詳述する新しいLocalConnectionOptions、イベント、および接続パラメーターを定義します。
Package Name: FXR Package Version: 0
パッケージ名：FXRパッケージバージョン：0
A new Fax LocalConnectionOptions (LCO) parameter is defined for fax handling. The Call Agent supplies this fax LCO to indicate the desired fax handling procedure to the Media Gateway. The fax LCO contains a list of desired fax handling procedures ordered by preference, with the most desired procedure listed first. When the parameter is explicitly included in a command, the gateway MUST be able to use at least one of the listed procedures for the command to succeed. Currently, the list can indicate one or more of the following procedures (see Sections 2.1.1 to 2.1.4 for further details on these):
新しいFAX LocalConnectionOptions（LCO）パラメーターは、FAX処理用に定義されています。コールエージェントは、このFAX LCOを提供して、メディアゲートウェイに目的のFAX処理手順を示します。FAX LCOには、優先順位で注文された目的のFAX処理手順のリストが含まれており、最初に最も望ましい手順がリストされています。パラメーターがコマンドに明示的に含まれている場合、ゲートウェイは、コマンドが成功するためにリストされている手順の少なくとも1つを使用できる必要があります。現在、このリストは、次の手順の1つ以上を示すことができます（これらの詳細については、セクション2.1.1〜2.1.4を参照してください）：
* T.38 Strict: Use T.38 [T38] with either UDPTL or TCP for fax relay and have the Call Agent control it. Assuming the procedure can be used (see Section 2.1.1), a switch to T.38 procedures will be initiated upon fax detection, and a "t38(start)" event will be generated (see Section 2.2). This mode requires an indication of T.38 support from the remote side in order to be used, as described further in Section 2.1.1.
* T.38 Strict：FAXリレーにUDPTLまたはTCPを使用してT.38 [T38]を使用し、コールエージェントにコントロールしてもらいます。手順を使用できると仮定すると（セクション2.1.1を参照）、FAX検出時にT.38への切り替えが開始され、「T38（Start）」イベントが生成されます（セクション2.2を参照）。このモードでは、セクション2.1.1でさらに説明するように、使用するためにリモート側からのT.38サポートを示す必要があります。
* T.38 Loose: Identical to T.38 Strict procedure, except that an indication of T.38 support from the remote side is not required for the procedure to be used.
* T.38ルーズ：T.38の厳密な手順と同じですが、手順を使用するには、リモート側からのT.38サポートの兆候が必要ないことを除きます。
* Off: Do not invoke any special procedure for fax, except for echo cancellation adjustment and possibly switching to another codec.
* OFF：エコーキャンセルの調整と場合によっては別のコーデックに切り替えることを除いて、FAXの特別な手順を呼び出さないでください。
* Gateway: Let the gateway control and decide how to handle fax calls without Call Agent involvement. This includes the case where the gateway does not do anything special for fax; hence, by definition this procedure can always be supported. If the gateway invokes a special procedure upon detection of fax, it will generate a "gwfax(start)" event to inform the Call Agent of this (see Section 2.2). The Call Agent SHOULD then refrain from issuing potentially conflicting commands to the gateway until the gateway ends its special fax handling procedure.
* ゲートウェイ：ゲートウェイコントロールを使用して、コールエージェントの関与なしにファックスコールを処理する方法を決定します。これには、ゲートウェイがFAXに特別なことをしない場合が含まれます。したがって、定義上、この手順はいつでもサポートできます。GatewayがFAXの検出時に特別な手順を呼び出す場合、「GWFAX（Start）」イベントが生成され、コールエージェントにこれを通知します（セクション2.2を参照）。コールエージェントは、ゲートウェイが特別なファックス処理手順を終了するまで、ゲートウェイに潜在的に矛盾するコマンドを発行することを控える必要があります。
A gateway that ends up not being able to invoke any special procedure for fax will generate a "nopfax(start)" event (see Section 2.2) upon detection of fax.
ファックスの特別な手順を呼び出すことができなくなったゲートウェイは、FAXの検出時に「nopfax（start）」イベント（セクション2.2を参照）を生成します。
The set of possible values (i.e., procedures) for the fax LCO is extensible. The prefix "x-", which indicates an optional extension, and the prefix "x+", which indicates a mandatory extension, are reserved for vendor-specific use.
FAX LCOの可能な値（つまり、手順）のセットは拡張可能です。オプションの拡張子を示すプレフィックス「x-」と、必須の拡張機能を示すプレフィックス「x」は、ベンダー固有の使用のために予約されています。
In CreateConnection commands, the fax LCO value defaults to "gateway". In ModifyConnection commands, the fax LCO value defaults to its current value on the connection. Thus, if LocalConnectionOptions are omitted or if the fax LCO is not included in a ModifyConnection command, the previous fax LCO value for the connection is retained without affecting the outcome of the command; consequently, the gateway may now not apply any special procedure to fax. If the Call Agent wants to ensure that a command succeeds only when a fax procedure is applied, the command needs to include the fax LCO explicitly.
CreateConnectionコマンドでは、FAX LCO値はデフォルトで「ゲートウェイ」になります。ModiyConnectionコマンドでは、FAX LCO値は接続上の現在の値にデフォルトです。したがって、LocalConnectionOptionsが省略されている場合、またはFAX LCOがModieConnectionコマンドに含まれていない場合、コマンドの結果に影響を与えることなく、接続の以前のFAX LCO値が保持されます。したがって、ゲートウェイはファックスに特別な手順を適用できないようになりました。コールエージェントが、FAX手順が適用されたときにのみコマンドが成功することを確認したい場合、コマンドはFAX LCOを明示的に含める必要があります。
As an example of this, assume that the CreateConnection command successfully specified the use of "T.38 Strict", and a ModifyConnection command is now received without the fax LCO but with a RemoteConnectionDescriptor indicating no support for T.38. In this case, the ModifyConnection command will succeed, but T.38 procedures will no longer be invoked upon fax detection (a "nopfax" event will be generated). Had the Call Agent instead included the fax LCO set to "T.38 Strict", the command would have failed.
この例として、CreateConnectionコマンドが「T.38 Strict」の使用を正常に指定したと仮定し、ModieConnectionコマンドがFax LCOなしで受信されましたが、T.38のサポートがないことを示すRemoteConnectionDescriptorを使用します。この場合、ModieConnectionコマンドは成功しますが、T.38手順はFAX検出時に呼び出されなくなります（「NOPFAX」イベントが生成されます）。代わりに、コールエージェントがFAX LCOを「T.38 Strict」に設定した場合、コマンドが失敗していたでしょう。
If multiple fax parameter values are provided, the gateway MUST choose one of the procedures specified according to the order in which they are supplied, except as follows: 1. If "gateway" would have been selected and it would have resulted in no special procedure being applied, and
複数のFAXパラメーター値が提供されている場合、ゲートウェイは、次のようなものを除き、「ゲートウェイ」が選択されていて、それが特別な手順がなかった場合を除き、それらが提供される順序に従って指定された手順のいずれかを選択する必要があります。適用されている、そして
2. if there are procedures other than "off" that are specified after "gateway" (e.g., "t38"),
2. 「ゲートウェイ」（「T38」など）の後に指定された「オフ」以外の手順がある場合、
then the gateway MUST use the most preferred of those subsequent procedures that can be supported. If none of those subsequent procedures can be supported, the gateway reverts to not invoking any special procedure for fax. Please refer to Section 2.1.4 for further details on determining which procedures can be supported.
次に、ゲートウェイは、サポートできるこれらの後続の手順の中で最も優先されるものを使用する必要があります。これらの後続の手順をサポートできない場合、ゲートウェイはFAXの特別な手順を呼び出しないように戻します。どの手順をサポートできるかを決定する詳細については、セクション2.1.4を参照してください。
The fax LCO parameter is encoded as the keyword "fx" (prefixed with the package name per [RFC3435]), followed by a colon and then a semicolon separated list of values, where T.38 Strict is encoded as "t38", T.38 Loose is encoded as "t38-loose", gateway is encoded as "gw", and off is encoded as "off".
FAX LCOパラメーターは、キーワード「FX」（[RFC3435]ごとにパッケージ名が付いている）としてエンコードされ、その後にコロンが続き、次にセミコロン分離された値のリストが続きます。.38ルーズは「T38-loose」としてエンコードされ、ゲートウェイは「GW」としてエンコードされ、オフは「オフ」としてエンコードされます。
The following example illustrates the use of PCMU or G.729 for audio encoding, and T.38 Strict fax relay (preferred) or gateway control for fax:
次の例は、オーディオエンコードにPCMUまたはG.729の使用、およびT.38 Strict Faxリレー（優先）またはFAXのゲートウェイコントロールを示しています。
L: a:PCMU;G729, fxr/fx:t38;gw
It should be noted that MGCP allows the CreateConnection command to omit both LocalConnectionOptions and RemoteConnectionDescriptor, thereby letting the gateway decide upon the media parameters to use. When the T.38 fax package is supported, the gateway could thus choose to do either audio or T.38 fax relay in such cases. Most likely, the Call Agent requires one or the other to be used, and hence it SHOULD NOT omit both LocalConnectionOptions and RemoteConnectionDescriptor in CreateConnection commands.
MGCPにより、CreateConnectionコマンドがLocalConnectionOptionsとRemoteConnectionDescriptorの両方を省略できるようにすることに注意してください。T.38 Faxパッケージがサポートされている場合、ゲートウェイはそのような場合にオーディオまたはT.38 Faxリレーのいずれかを選択できます。ほとんどの場合、コールエージェントはどちらか一方を使用する必要があるため、CreateConnectionコマンドでLocalConnectionOptionsとRemoteConnectionDescriptorの両方を省略しないでください。
When auditing capabilities, the fax LCO may be returned with a semicolon-separated list of supported fax handling parameters. The values "t38", "t38-loose", "off", and "gw" MAY be omitted from such a list as they are always implied. Gateways that implement additional parameters SHOULD return these additional parameters when capabilities are audited, as illustrated by the following example:
監査機能の場合、FAX LCOは、サポートされているFAX処理パラメーターのセミコロン分離されたリストで返される場合があります。値「T38」、「T38-Loose」、「Off」、および「GW」は、常に暗示されているように、そのようなリストから省略できます。追加のパラメーターを実装するゲートウェイは、次の例で示すように、機能を監査したときにこれらの追加パラメーターを返す必要があります。
A: a:image/t38, fxr/fx:mypar, ...
In the following subsections, we provide additional detail on the above-defined fax procedures.
以下のサブセクションでは、上記のFAX手順の詳細を追加します。
When a gateway is instructed to use one of the T.38 procedures (strict or loose), also known as Call Agent controlled T.38 mode, the "m=" line in the Session Description Protocol (SDP) returned will not indicate use of UDPTL-based or TCP-based T.38 (unless the gateway was also instructed to use "image/t38" for the media stream). Any other entity seeing this SDP will not know whether or not T.38 is supported and hence whether it is safe to attempt a switch to T.38 upon fax detection. To remedy this dilemma, capability information for T.38 (if supported) using the SDP Simple Capability Declaration extensions [RFC3407] MUST be included. Other capability information is included as well, regardless of whether the Call Agent authorized use of those in the connection handling command. A subsequent attempt to actually use these may of course not succeed, e.g., because the Call Agent LCO does not allow them to be used. The following example illustrates the RFC 3407 [RFC3407] capability descriptor--note the inclusion of both current (audio) and latent (T.38) capabilities, as specified in RFC 3407 [RFC3407]:
コールエージェント制御T.38モードとも呼ばれるT.38プロシージャ（厳密または緩み）のいずれかを使用するようにゲートウェイが指示されている場合、セッション説明プロトコル（SDP）の「M =」行は使用を示していません。UDPTLベースまたはTCPベースのT.38の（ゲートウェイがメディアストリームに「画像/T38」を使用するように指示されていない限り）。このSDPを見ている他のエンティティでは、T.38がサポートされているかどうかはわかりません。したがって、FAX検出時にT.38への切り替えを試してみてください。このジレンマを改善するには、SDPの単純な機能宣言拡張[RFC3407]を使用してT.38（サポートされている場合）の能力情報を含める必要があります。コールエージェントが接続処理コマンド内のそれらの使用を許可したかどうかに関係なく、他の機能情報も含まれています。これらを実際に使用しようとするその後の試みは、もちろん成功しない可能性があります。たとえば、コールエージェントLCOはそれらを使用することを許可していないためです。次の例は、RFC 3407 [Audio）と潜在（T.38）の両方の機能を包含しているRFC 3407 [RFC3407]能力記述子を示しています。RFC3407[RFC3407]：
m=audio 3456 RTP/AVP 18
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 18
a=cdsc: 2 image udptl t38
For a list of T.38 related parameters to be included in the SDP, please refer to T.38 Annex D [T38].
SDPに含まれるT.38関連パラメーターのリストについては、T.38 Annex D [T38]を参照してください。
Upon fax detection, a gateway that has successfully been instructed to use one of the T.38 procedures will:
FAX検出時に、T.38手順の1つを使用するように成功裏に指示されたゲートウェイは次のとおりです。
1. Initiate the T.38 fax relay procedure and mute the media channel in both the send and receive direction (unless the media channel is already using T.38).
1. T.38ファックスリレー手順を開始し、送信方向と受信方向の両方でメディアチャネルをミュートします（メディアチャネルが既にT.38を使用している場合を除く）。
2. Generate a "t38(start)" event.
2. 「T38（Start）」イベントを生成します。
3. Await further instructions from the Call Agent in order to initiate the actual media change (unless the media channel is already using T.38).
3. 実際のメディアの変更を開始するために、コールエージェントからのさらなる指示を待っています（メディアチャネルが既にT.38を使用している場合を除く）。
The Call Agent instructs the gateway to perform the media change by sending it a ModifyConnection command with "image/t38" listed as the encoding method in the LocalConnectionOptions (receipt of a ModifyConnection command without LocalConnectionOptions but with a RemoteConnectionDescriptor containing an "m=" line with the MIME type "image/t38" would achieve the same). Per the normal MGCP codec negotiation procedures (see [RFC3435] Section 2.6), if a RemoteConnectionDescriptor was included as well, it needs to include an "m=" line with "image/t38" as an acceptable media format in order for the command to succeed. The gateway may choose between the UDPTL and TCP transport protocols at its own discretion subject to the normal MGCP codec negotiation procedures (in practice, TCP-based implementations are currently rare).
コールエージェントは、localConnectionOptionsのエンコードメソッドとしてリストされている「Image/T38」を使用してModieConnectionコマンドを送信することにより、メディア変更を実行するようにゲートウェイに指示します（ローカルコネクションオプションなしで、「M =」ラインを含むRemoteConnectionDescriptorを使用してModieConnectionコマンドの受領MIMEタイプ「Image/T38」は同じことを達成します）。通常のMGCPコーデック交渉手順（[RFC3435を参照]セクション2.6を参照）に従って、RemoteConnectionDescriptorも含まれている場合、コマンドの順に許容可能なメディア形式として「M =」行を含む「M =」行を含める必要があります。成功するために。ゲートウェイは、通常のMGCPコーデック交渉手順の対象となる独自の裁量でUDPTLとTCPトランスポートプロトコルのいずれかを選択できます（実際には、TCPベースの実装は現在まれです）。
If a RemoteConnectionDescriptor was not included with the ModifyConnection command sent to a gateway that initiated the T.38 procedure, it is possible (in fact likely), that the last received RemoteConnectionDescriptor did not include an "m=" line listing "image/t38" as an acceptable media format. In that case, the endpoint cannot send T.38 media to the other side. The endpoint MUST instead wait for an updated RemoteConnectionDescriptor that contains "image/t38" as an acceptable media format and a supported transport protocol (UDPTL or TCP). The T.38 fax procedure continues when an acceptable RemoteConnectionDescriptor is received. An acceptable RemoteConnectionDescriptor contains an "m=" line with the "image/t38" MIME type (using the normal SDP syntax) and a supported transport protocol (UDPTL or TCP). If the fax call fails (e.g., due to a fax timeout) while waiting for either the Call Agent to instruct the gateway to switch to "image/t38" or for an acceptable RemoteConnectionDescriptor, a "t38(stop)" or a "t38(failure)" event MUST be generated. When the T.38 procedure ends, a "t38(stop)" or "t38(failure)" event MUST be generated.
RemoteConnectionDescriptorがT.38手順を開始したゲートウェイに送信されたModiyConnectionコマンドに含まれていない場合、最後に受信したRemoteConnectionDescriptorに「M = "Lineリスト」画像/T38が含まれていないことが可能です。「許容可能なメディア形式として。その場合、エンドポイントはT.38メディアを反対側に送信できません。代わりに、エンドポイントは、許容可能なメディア形式とサポートされているトランスポートプロトコル（UDPTLまたはTCP）として「Image/T38」を含む更新されたRemoteConnectionDescriptorを待つ必要があります。T.38 Fax手順は、許容可能なRemoteConnectionDescriptorを受信したときに継続します。許容可能なRemoteConnectionDescriptorには、「Image/T38」MIMEタイプ（通常のSDP構文を使用）とサポートされている輸送プロトコル（UDPTLまたはTCP）の「M =」ラインが含まれます。コールエージェントがゲートウェイに「画像/T38」に切り替えるように指示するように指示するか、許容可能なRemoteConnectionDescriptor、または「T38（STOP）」または「T38」または「T38」のいずれかを待っているときに、FAXコールが失敗した場合（例：FAXタイムアウトのため）（障害）「イベントを生成する必要があります。T.38の手順が終了すると、「T38（停止）」または「T38（故障）」イベントを生成する必要があります。
Finally, the Call Agent may need to abort a T.38 procedure that is in progress. This can for example be done when the remote side is unable to switch to T.38, and a fallback to fax passthrough using an audio codec is attempted. The Call Agent instructs the endpoint to abort an in-progress T.38 procedure by use of the "off" fax LCO as illustrated below:
最後に、コールエージェントは、進行中のT.38手順を中止する必要がある場合があります。これは、リモート側がt.38に切り替えることができない場合に実行でき、オーディオコーデックを使用してファックスパススルーへのフォールバックが試行されます。コールエージェントは、以下に示すように、「オフ」FAX LCOを使用して、進行中のT.38手順を中止するようにエンドポイントに指示します。
L: fxr/fx:off
L：FXR/FX：オフ
We now define "time t38init" as the point in time where the T.38 procedure was initiated, and "time t38abort" as the point in time where the Call Agent aborts an in-progress T.38 procedure. If the Call Agent at time t38abort instructs or enables the endpoint to revert to one or more codecs that were in use just prior to time t38init, the endpoint SHOULD use media stream parameters that mimic the most recent LocalConnectionDescriptor issued before time t38init. For example, IP-address and UDP port, payload formats used and their payload type mapping, should all be the same as before time t38init. This will enable the fallback to be as rapid as possible. A LocalConnectionDescriptor is returned as usual, i.e., only if one or more parameters changed since the last LocalConnectionDescriptor issued (e.g., if a T.38 LCD was issued or a transport address in the audio LCD was changed).
「Time T38Init」をT.38手順が開始された時点として、「T38Abort」をコールエージェントが進行中のT.38手順を中止する時点として定義します。時間T38ABORTのコールエージェントが、エンドポイントが時間T38Initの直前に使用されていた1つ以上のコーデックに戻ることを指示または有効にする場合、エンドポイントは、T38Initの前に発行された最新のローカルコネクションデスプトレスを模倣するメディアストリームパラメーターを使用する必要があります。たとえば、IP-AddressおよびUDPポート、使用したペイロードフォーマット、およびそのペイロードタイプマッピングは、すべてT38Init以前と同じである必要があります。これにより、フォールバックができるだけ速くなります。LocalConnectionDescriptorは、通常どおりに返されます。つまり、最後のLocalConnectionDescriptorが発行されてから1つ以上のパラメーターが変更された場合にのみ（たとえば、T.38 LCDが発行された場合、またはAudio LCDの輸送住所が変更された場合）。
A gateway using the gateway procedure, also known as Gateway controlled mode, may initiate special fax handling upon detecting a fax call. The details of this special fax handling are outside the scope of this document. However, in order to use any special fax handling, support for it MUST be negotiated with the other side by passing and recognizing relevant parameters via the LocalConnectionDescriptor and RemoteConnectionDescriptor (this includes the use of RTP-based T.38). If the other side has not indicated support for the special fax handling desired, the gateway MUST NOT attempt to initiate it. When special fax handling is initiated, a "gwfax(start)" event MUST be generated, thereby enabling the Call Agent to differ between the Call Agent and gateway controlled mode while still being informed about the actual change to fax. When the special gateway handling of fax ends, a "gwfax(stop)" or "gwfax(failure)" event MUST be generated.
ゲートウェイ制御モードとも呼ばれるゲートウェイ手順を使用したゲートウェイは、ファックスコールを検出すると特別なFAX処理を開始する場合があります。この特別なファックス処理の詳細は、このドキュメントの範囲外です。ただし、特別なFAX処理を使用するには、LocalConnectionDescriptorおよびRemoteConnectionDescriptorを介して関連するパラメーターを通過および認識することにより、サポートを反対側と交渉する必要があります（これにはRTPベースのT.38の使用が含まれます）。反対側が特別なファックス処理の希望のサポートを示していない場合、ゲートウェイはそれを開始しようとしてはなりません。特別なFAX処理が開始されると、「GWFAX（START）」イベントを生成する必要があります。これにより、コールエージェントがコールエージェントとゲートウェイ制御モードの間で異なることを可能にしながら、ファックスへの実際の変更について通知されます。FAXの特別なゲートウェイ処理が終了する場合、「GWFAX（停止）」または「GWFAX（故障）」イベントを生成する必要があります。
A gateway using the "off" procedure will not invoke any special fax procedures, e.g., T.38, when detecting a fax. However, the gateway may still adjust local echo cancellation and/or switch to an alternative codec as needed. Also, a "nopfax(start)" event MUST be generated; a corresponding "stop" event, however, will not.
「オフ」手順を使用したゲートウェイでは、FAXを検出する場合、T.38などの特別なFAX手順は呼び出されません。ただし、ゲートウェイは、必要に応じて、ローカルエコーキャンセルおよび/または代替コーデックに切り替えることを調整する場合があります。また、「nopfax（start）」イベントを生成する必要があります。ただし、対応する「停止」イベントはそうではありません。
Generating a "stop" event would imply that the gateway had to infer when the fax call ends, which involves processing the media stream. However, when using the "off" mode, such processing is not expected to occur.
「停止」イベントを生成することは、メディアストリームの処理を伴うFAXコールが終了するときにゲートウェイが推測する必要があることを意味します。ただし、「オフ」モードを使用する場合、そのような処理は発生するとは予想されません。
For each of the above modes, the RemoteConnectionDescriptor provides information on what procedure(s) the other side supports. The following rules are used to determine which procedure to use:
上記の各モードのそれぞれについて、RemoteConnectionDescriptorは、反対側がサポートする手順に関する情報を提供します。以下のルールは、使用する手順を決定するために使用されます。
1. Whatever the Call Agent specified in the Fax LocalConnectionOptions for the current command MUST be adhered to. If the gateway cannot satisfy any of the options, the command fails (error code 532 -- unsupported value(s) in LocalConnectionOptions is RECOMMENDED).
1. 現在のコマンドのFAX LocalConnectionOptionsで指定されたコールエージェントがどのように順守する必要があります。ゲートウェイがオプションのいずれかを満たすことができない場合、コマンドは失敗します（エラーコード532-ローカルコネクションオプションのサポートされていない値が推奨されます）。
2. If both Fax LocalConnectionOptions and a RemoteConnectionDescriptor are provided, the procedure selected MUST be supported by both sides -- this is currently only an issue for "T.38 Strict". A procedure can be satisfied by the remote side if:
2. FAX LocalConnectionOptionsとRemoteConnectionDescriptorの両方が提供されている場合、選択された手順は双方によってサポートされなければなりません。これは現在、「T.38 Strict」の問題にすぎません。次の場合、手順はリモート側によって満たすことができます。
* the relevant MIME media type, e.g., "image/t38", is included in the "m=" line in the RemoteConnectionDescriptor, or
* 関連するMIMEメディアタイプ、例えば「Image/T38」は、RemoteConnectionDescriptorの「M =」行に含まれています。
* the relevant MIME media type is included as a capability (see [RFC3407]) in the RemoteConnectionDescriptor.
* 関連するMIMEメディアタイプは、RemoteConnectionDescriptorの機能（[RFC3407を参照]を参照）として含まれています。
If the gateway cannot select any of the procedures in the Fax LocalConnectionOptions, the command fails (error code 532 is RECOMMENDED). Note that "T.38 Loose", "gateway", and "off" -- by definition -- can always be supported by an implementation that supports this package, irrespective of what the RemoteConnectionDescriptor indicates.
GatewayがFax localConnectionOptionsで手順を選択できない場合、コマンドは失敗します（エラーコード532が推奨されます）。「T.38ルーズ」、「ゲートウェイ」、および「オフ」は、定義上、RemoteConnectionDescriptorが示すものに関係なく、このパッケージをサポートする実装によって常にサポートできることに注意してください。
3. If the Call Agent did not include any Fax LocalConnectionOptions or a RemoteConnectionDescriptor with the command, the gateway MUST continue using whichever procedure it is currently using.
3. コールエージェントに、コマンドを備えたFAX LocalConnectionOptionsまたはRemoteConnectionDescriptorを含めなかった場合、ゲートウェイは現在使用している手順を使用し続ける必要があります。
4. If the Call Agent did not include any Fax LocalConnectionOptions, but a RemoteConnectionDescriptor was included, the gateway MUST follow rule 2 in selecting a procedure. In so doing, the default Fax LocalConnectionOptions, i.e., "gateway" in CreateConnection, or the current value in ModifyConnection, MUST be used. In the case of ModifyConnection, the outcome of the command does not depend on the gateway being able to select one of these "default" procedures (as described in Section 2.1). Note that this is not an issue for the CreateConnection command, since the default value can always be supported by definition.
4. コールエージェントにFAX LocalConnectionOptionsを含めなかったが、RemoteConnectionDescriptorが含まれていた場合、ゲートウェイは手順を選択する際にルール2に従う必要があります。そうすることで、デフォルトのFAX LocalConnectionOptions、つまりCreateConnectionの「ゲートウェイ」、またはModifyConnectionの現在の値を使用する必要があります。ModifyConnectionの場合、コマンドの結果は、これらの「デフォルト」手順のいずれかを選択できるゲートウェイに依存しません（セクション2.1で説明されています）。デフォルト値は定義上常にサポートできるため、これはCreateConnectionコマンドの問題ではないことに注意してください。
5. A previously received RemoteConnectionDescriptor does not affect what procedure can be selected. Only a RemoteConnectionDescriptor supplied with the current command affects the procedure selection. However, in order to send media of a given type (e.g., "image/t38"), the most recently received RemoteConnectionDescriptor MUST include a corresponding media line.
5. 以前に受信したRemoteConnectionDescriptorは、選択できる手順には影響しません。現在のコマンドに付属のRemoteConnectionDescriptorのみが手順の選択に影響します。ただし、特定のタイプのメディア（「Image/T38」など）を送信するには、最近受信したRemoteConnectionDescriptorには対応するメディアラインを含める必要があります。
The following examples illustrate the use of the above rules:
次の例は、上記のルールの使用を示しています。
Per rule 1, a gateway that only supports standard T.38 fax relay will fail a command that only contains the fax option "mypar", whereas it will succeed a command that contains "t38-loose", "gw", "off", or no fax LCO. A command that only contained "t38", i.e., use of T.38 in "strict" mode, may or may not succeed (depending on the RemoteConnectionDescriptor).
ルール1によると、標準のT.38 Faxリレーのみをサポートするゲートウェイは、FAXオプション「MyPar」のみを含むコマンドに失敗しますが、「T38-Loose」、「GW」、「Off」を含むコマンドが成功します。、またはFAX LCOなし。「T38」のみを含むコマンド、つまり、「厳密な」モードでT.38を使用することができますが、成功する場合と成功しない場合があります（RemoteConnectionDescriptorによって異なります）。
A gateway supporting T.38 that receives a CreateConnection command with the fax handling LCO set to "t38" and a RemoteConnectionDescriptor with neither a T.38 capability nor a T.38 media stream will fail per rule 2. Had the fax handling LCO included either "t38-loose", "gw" or "off", the command would have succeeded, and any of the procedures included could have been selected.
fax Handling LCOを「T38」に設定し、T.38機能もT.38メディアストリームもルール2に従って故障しない場合のRemoteConnectionDescriptorを使用してCreateConnectionコマンドを受信するT.38をサポートするゲートウェイT.38をサポートするゲートウェイ。「T38-Loose」、「GW」、または「Off」のいずれかで、コマンドは成功し、含まれる手順のいずれかが選択されている可能性があります。
Assume a gateway supporting T.38 has successfully executed a CreateConnection command with fax handling set to "t38" (i.e., strict). If the gateway now receives a ModifyConnection command without a fax handling LCO but with a RemoteConnectionDescriptor that has neither a T.38 capability nor a media stream with "image/t38", the command will succeed (since rule 1 has no effect in that case). However, per rule 2 and 4, there will not be any T.38 procedure in place. Had the Call Agent instead included a fax handling LCO set to "t38" again, the command would have failed per rule 2.
T.38をサポートするゲートウェイが、「T38」（つまり、厳格）に設定されたFAX処理を備えたCreateConnectionコマンドを正常に実行したと仮定します。GatewayがLCOを処理するが、T.38機能も「Image/T38」を持つメディアストリームを持たないRemoteConnectionDescriptorを使用しないModieConnectionコマンドを受信するようになりました。）。ただし、ルール2と4によると、T.38の手順はありません。代わりに、コールエージェントに「T38」に設定されたFAX処理LCOを再び含めていれば、コマンドはルール2ごとに失敗したでしょう。
Finally, it should be noted that a switch to T.38 can be initiated by either one or both of the originating and terminating gateways and hence implementations MUST be prepared to handle this. This includes the case where both sides initiate the switch, which for example can occur when the originating fax generates Calling Tone (CNG) and the terminating fax detects V.21 fax preamble (see [T30]) before the switch to T.38 has been performed on the terminating side.
最後に、T.38への切り替えは、発信ゲートウェイと終端の両方のゲートウェイのいずれかまたは両方によって開始できるため、これを処理するために実装を準備する必要があることに注意する必要があります。これには、双方がスイッチを開始する場合が含まれます。たとえば、発信元のFAXが呼び出しトーン（CNG）を生成し、T.38への切り替え前にv.21 Fax Preamble（[T30]を参照）を検出する場合に発生する場合があります。終端側で実行されました。
A fax call can be detected by several different means (e.g., V.21 fax preamble, T.30 CNG tone, or V.8 signals) depending on the fax transmission method being used. Implementations of this package MUST at a minimum detect a fax call based on V.21 fax preamble.
ファックスコールは、使用されているFAX伝送方法に応じて、いくつかの異なる手段（v.21 Fax Preamble、T.30 CNGトーン、またはv.8信号）で検出できます。このパッケージの実装は、V.21 Fax Preambleに基づくFAXコールを最小限に検出する必要があります。
Triggering based on T.30 CNG tone MAY be done; this is generally considered acceptable for G3 and lower fax speeds. However, when used with T.38 version 2 or earlier, it will impact V.34 high-speed fax. The reason is that T.38 version 2 (and earlier) does not support the V.8 ANSam and CM signals used with V.34 fax, and hence the V.34 faxes will downspeed to G3 (14.400 bps) or lower when using T.38 version 2 (or earlier). Also, a few rare cases of modems generating T.30 CNG tones for non-fax calls have been reported; such modems would generate a false trigger for fax. As a consequence of the above, it is RECOMMENDED that implementations of this package that support T.30 CNG-based fax detection provide a configuration option to disable it for T.38 version 2 (or earlier).
T.30 CNGトーンに基づくトリガーを実行できます。これは一般に、G3および低いファックス速度で許容できると見なされます。ただし、T.38バージョン2以前に使用すると、V.34高速ファックスに影響を与えます。その理由は、T.38バージョン2（および以前）がV.34 Faxで使用されるV.8 ANSAMおよびCM信号をサポートしていないため、V.34 FAXは使用するとG3（14.400 bps）以下に拡大します。T.38バージョン2（またはそれ以前）。また、非ファックス呼び出しのためにT.30 CNGトーンを生成するモデムのまれなケースが報告されています。このようなモデムは、FAXの誤トリガーを生成します。上記の結果として、T.30 CNGベースのFAX検出をサポートするこのパッケージの実装は、T.38バージョン2（またはそれ以前）に対してそれを無効にする構成オプションを提供することをお勧めします。
It is important to understand the implications of using any one of the above defined procedures. Furthermore, multiple alternative procedures can be requested, however not all combinations make sense. In this section, we elaborate on both of these issues.
上記の手順のいずれかを使用することの意味を理解することが重要です。さらに、複数の代替手順を要求できますが、すべての組み合わせが理にかなっているわけではありません。このセクションでは、これらの両方の問題について詳しく説明します。
Use of the T.38 Strict mode is ideal in an environment where it is known that other endpoints generate RFC 3407 [RFC3407] capability descriptions with T.38 fax relay information. If a RemoteConnectionDescriptor without T.38 fax relay capabilities is received in such an environment, it is known that the other side does not support T.38, and hence an unsuccessful attempt to switch to T.38 (which in turn may lead to a failed fax call) can be avoided. If it is not known whether other endpoints support the RFC 3407 [RFC3407] capability descriptors, the trade-off is less clear. The advantage is that a switch to T.38 will only be attempted if it is known that the other side supports it, but endpoints that do not indicate support for T.38 may still support it; however, T.38 will not be used with these, which in turn may lead to unnecessary fax failures with low-bandwidth codecs or lossy networks.
T.38 Strictモードの使用は、他のエンドポイントがT.38 Faxリレー情報を使用してRFC 3407 [RFC3407]機能の説明を生成することが知られている環境で理想的です。T.38 Faxリレー機能のないRemoteConnectionDescriptorがそのような環境で受信された場合、反対側がT.38をサポートしていないことが知られているため、T.38に切り替えようとする試みが失敗しました（これにより、失敗したFAXコール）は回避できます。他のエンドポイントがRFC 3407 [RFC3407]機能記述子をサポートするかどうかがわからない場合、トレードオフはそれほど明確ではありません。利点は、T.38への切り替えは、反対側がそれをサポートしていることがわかっている場合にのみ試行されることですが、T.38のサポートを示さないエンドポイントはまだそれをサポートする可能性があります。ただし、T.38はこれらで使用されません。これにより、低帯域幅コーデックまたは損失ネットワークで不必要なFAX障害につながる可能性があります。
Use of the T.38 loose mode involves the same considerations as for T.38 Strict, however the pros and cons are reversed. If a peer endpoint does not support T.38, the T.38 loose mode will still attempt to switch to T.38 (and fail), which in turn may lead to a failed fax call. On the other hand, if the peer endpoint does not support the RFC 3407 [RFC3407] capability descriptors, but the peer endpoint does in fact support T.38, T.38 would still be used with this mode.
T.38ルーズモードの使用には、T.38の厳格と同じ考慮事項が含まれますが、長所と短所は逆になります。ピアエンドポイントがT.38をサポートしない場合、T.38ルーズモードは引き続きT.38（および失敗）に切り替えようとします。一方、ピアエンドポイントがRFC 3407 [RFC3407]機能記述子をサポートしていない場合、ピアエンドポイントは実際にT.38、T.38をサポートしています。
In summary, there is no single good answer to the use of either T.38 Strict or T.38 loose mode; it depends on the capabilities of the endpoints involved as well as the trade-off between potentially letting fax calls fail due to lack of capability indications (where T.38 is otherwise supported) versus potentially letting fax calls fail due to an unsuccessful switch to T.38 (because T.38 in fact was not supported). It should be noted that Call Agents may have means beyond RFC 3407 [RFC3407] capability descriptors to determine if a peer endpoint supports T.38 or not. For example, when SIP is used as the signaling protocol with other peers (e.g., Call Agents or other SIP devices), the SIP OPTIONS method can be used to learn whether T.38 is supported. Also, if the Call Agent allows use of high-bandwidth codecs with redundancy when support for T.38 is not indicated, fax calls may still succeed without the use of T.38, even in networks with non-negligible packet loss.
要約すると、t.38 StrictまたはT.38ルーズモードの使用に対する良い答えはありません。これは、関連するエンドポイントの機能に依存します。また、潜在的に機能の適応症の欠如によりファックスコールを失敗させる可能性があること（T.38がサポートされている場合）のトレードオフに依存するのに対して、Tへの切り替えのためにFAXコールを失敗させる可能性があります.38（T.38は実際にはサポートされていなかったため）。コールエージェントには、RFC 3407 [RFC3407]機能記述子を超えて、ピアエンドポイントがT.38をサポートしているかどうかを判断する手段がある場合があることに注意してください。たとえば、SIPが他のピア（コールエージェントや他のSIPデバイスなど）とのシグナリングプロトコルとして使用される場合、SIPオプション方法を使用して、T.38がサポートされているかどうかを知ることができます。また、T.38のサポートが示されていない場合、コールエージェントが冗長性を備えた高帯域幅コーデックの使用を許可している場合、無視できないパケット損失を持つネットワークであっても、T.38を使用せずにFAXコールを成功させることができます。
When the gateway controlled mode is selected, there will only be special fax handling if the two peer endpoints support the same fax handling method; note that the details of the actual method is entirely up to the vendor. Also note that if the two peer endpoints do not support the same method for fax handling or if the method is not indicated in the SDP exchanged, there will be no special fax handling in place. Furthermore, the Call Agent will not be aware that this is the case until the fax transmission starts and a "nopfax(start)" event is generated.
ゲートウェイ制御モードが選択されている場合、2つのピアエンドポイントが同じファックス処理方法をサポートしている場合にのみ、特別なFAX処理が行われます。実際の方法の詳細は、完全にベンダー次第であることに注意してください。また、2つのピアエンドポイントがファックス処理のために同じ方法をサポートしていない場合、またはSDP交換でメソッドが示されていない場合、特別なファックス処理は整っていないことに注意してください。さらに、コールエージェントは、ファックス伝送が開始され、「nopfax（start）」イベントが生成されるまで、これが当てはまることを認識しません。
The off mode is straightforward; there will be no special procedure in place for fax handling, except for the usual handling of echo cancellation and possibly a change to a higher bandwidth codec.
オフモードは簡単です。エコーキャンセルの通常の取り扱いと、おそらくより高い帯域幅コーデックへの変更を除いて、ファックス処理のための特別な手順はありません。
Having looked at the individual procedures in more detail, we now elaborate on some of the combinations of procedures that may be requested:
個々の手順をより詳細に調べた後、要求される可能性のある手順の組み合わせのいくつかについて詳しく説明します。
* T.38 strict: If the T.38 strict procedure is placed after the T.38 loose or the off procedure (both of which can always be supported), it will not be selected. Apart from this, it makes little sense to request both T.38 strict and T.38 loose.
* T.38 Strict：T.38の厳格手順がT.38の緩みまたはオフ手順（両方とも常にサポートできます）の後に配置された場合、選択されません。これとは別に、T.38の厳格とT.38の両方を緩めることを要求することはほとんど意味がありません。
* T.38 loose: The T.38 loose procedure can always be supported, so any procedure specified after T.38 loose will not be selected.
* T.38ルーズ：T.38ルーズ手順はいつでもサポートできます。そのため、T.38ルーズ後に指定された手順は選択されません。
* Gateway: The gateway controlled procedure can always be supported. If the gateway controlled procedure would have resulted in no special fax procedure and further options (except off) are provided, those procedures will be attempted. If neither of those procedures can be supported, there will be no special fax procedure in place.
* ゲートウェイ：ゲートウェイ制御手順はいつでもサポートできます。ゲートウェイ制御された手順で特別なFAX手順がなくなり、さらなるオプション（OFFを除く）が提供された場合、それらの手順が試みられます。これらの手順のいずれもサポートできない場合、特別なFAX手順はありません。
* Off: The off procedure can always be supported. Any procedure specified after this one will not be selected.
* オフ：オフ手順はいつでもサポートできます。この後に指定された手順は選択されません。
The following events are defined in support of the above:
次のイベントは、上記をサポートして定義されています。
------------------------------------------------------------------
| Symbol | Definition | R | S Duration |
|---------|----------------------------|-----|---------------------|
| gwfax | Gateway controlled fax | x | |
| nopfax | No special fax handling | x | |
| t38 | T.38 fax relay | x | |
------------------------------------------------------------------
The definitions of the individual events are provided in the following subsections.
個々のイベントの定義は、次のサブセクションで提供されています。
The "gateway controlled fax" event occurs when the gateway handled fax procedure either starts, stops, or fails. The event is encoded as "gwfax", and the following event parameters, which apply to ObservedEvents only, are defined:
「ゲートウェイ制御ファックス」イベントは、ゲートウェイがFAX手順を処理したときに発生します。イベントは「GWFAX」としてエンコードされており、観察されたイベントのみに適用される次のイベントパラメーターが定義されています。
* start: Gateway controlled fax procedure was initiated. The Call Agent SHOULD refrain from issuing media handling instructions to the gateway until either a "gwfax(stop)" or "gwfax(failure)" event is generated.
* 開始：ゲートウェイ制御ファックス手順が開始されました。コールエージェントは、「GWFAX（STOP）」または「GWFAX（故障）」イベントが生成されるまで、ゲートウェイへのメディア処理手順を発行することを控える必要があります。
* stop: Gateway controlled fax procedure ended and the gateway did not detect any errors. Note that this does not necessarily imply a successfully transmitted fax. It merely indicates that the gateway controlled fax procedure has ended and the procedure itself did not encounter any errors. Media parameters for the connection are as before the gateway handled fax procedure started.
* 停止：ゲートウェイ制御ファックス手順が終了し、ゲートウェイはエラーを検出しませんでした。これは必ずしも正常に送信されたFAXを意味するわけではないことに注意してください。これは、ゲートウェイ制御されたFAX手順が終了し、手順自体がエラーに遭遇しなかったことを示すだけです。接続のメディアパラメーターは、ゲートウェイ処理されたFAX手順が開始される前と同じです。
* failure: The gateway controlled fax procedure ended abnormally. Some kind of problem was encountered in the gateway controlled fax procedure, and the procedure ended. Media parameters are as before the gateway handled fax procedure started.
* 障害：ゲートウェイ制御ファックス手順は異常に終了しました。ゲートウェイ制御FAX手順で何らかの問題が発生し、手順が終了しました。メディアパラメーターは、ゲートウェイ処理されたFAX手順が開始される前と同じです。
One of the above parameters will be present when the event is reported. The "gwfax" event MAY be parameterized with additional parameters in ObservedEvents, however it is RECOMMENDED that one of the above parameters is the first parameter supplied. Unknown parameters MUST be ignored.
イベントが報告されると、上記のパラメーターの1つが存在します。「GWFAX」イベントは、観察されたイベットに追加のパラメーターでパラメーター化される場合がありますが、上記のパラメーターの1つが最初のパラメーターであることをお勧めします。不明なパラメーターは無視する必要があります。
The following example illustrates the encoding of the "gwfax" event:
次の例は、「GWFAX」イベントのエンコードを示しています。
O: fxr/gwfax(start)
O: fxr/gwfax(stop, foobar)
The "no special fax handling" event occurs when there is no special fax handling procedure in place and a fax call is detected. This can happen either because no special fax handling procedure was requested (including "off") or negotiation resulted in no special fax handling procedure being supported. The event is encoded as "nopfax", and the following event parameter, which applies to ObservedEvents only, is defined:
「特別なFAX処理」イベントは、特別なFAX処理手順が存在せず、FAXコールが検出されたときに発生します。これは、特別なFAX処理手順（「オフ」を含む）が要求されなかったため、または交渉が特別なFAX処理手順がサポートされていないために発生する可能性があります。イベントは「nopfax」としてエンコードされており、次のイベントパラメーターは、観察された平均にのみ適用されます。
* start: No special fax handling procedure is in place, however a fax call is now detected. The Call Agent may have to issue further commands in order to ensure a successful fax call (e.g., switch to another codec).
* 開始：特別なFAX処理手順はありませんが、FAXコールが検出されました。コールエージェントは、ファックスコールを成功させるために、さらにコマンドを発行する必要がある場合があります（たとえば、別のコーデックに切り替えるなど）。
The above parameter will be present when the event is reported. The "nopfax" event MAY be parameterized with additional parameters on ObservedEvents, however it is RECOMMENDED that the above parameter is the first parameter supplied. Unknown parameters MUST be ignored. Note that this event currently cannot be parameterized with "stop" or "failure" as it only detects the beginning of a fax call.
イベントが報告されると、上記のパラメーターが存在します。「nopfax」イベントは、観測された平均点で追加のパラメーターでパラメーター化される場合がありますが、上記のパラメーターが最初のパラメーターであることをお勧めします。不明なパラメーターは無視する必要があります。このイベントは現在、FAXコールの開始のみを検出するため、「停止」または「失敗」でパラメーター化することはできないことに注意してください。
The following example illustrates the encoding of the "nopfax" event:
次の例は、「nopfax」イベントのエンコーディングを示しています。
O: fxr/nopfax(start)
O：fxr/nopfax（start）
The "T.38 fax relay" event occurs when one of the T.38 fax relay procedures (strict or loose) either starts, stops, or fails. The event is encoded as "t38", and the following event parameters, which apply to ObservedEvents only, are defined:
「T.38 FAXリレー」イベントは、T.38 FAXリレー手順（厳格または緩み）の1つが起動、停止、または故障のいずれかで発生したときに発生します。イベントは「T38」としてエンコードされており、観察された平均にのみ適用される次のイベントパラメーターが定義されています。
* start: A fax call was detected on the endpoint and the Call Agent controlled T.38 fax relay procedure was initiated. The Call Agent SHOULD modify each side of the connection to start using the "image/t38" media format, unless they already do. Note that, as long as use of the Call Agent controlled T.38 relay procedure is in effect, the event will be generated upon fax call detection, irrespective of the current encoding method on any connections on the endpoint (incl. "image/t38"). The "t38(start)" event MUST be generated at most once by the endpoint per fax call, regardless of whether or not it is requested again in a subsequent requested events list.
* 開始：エンドポイントでFAXコールが検出され、コールエージェントが制御されたT.38 FAXリレー手順が開始されました。コールエージェントは、接続の各側面を変更して、「Image/T38」メディア形式の使用を開始する必要があります。コールエージェント制御T.38リレー手順の使用が有効である限り、イベントは、エンドポイント上の任意の接続の現在のエンコード方法に関係なく、ファックスコール検出時に生成されることに注意してください（ "image/t38を含む"）。「T38（start）」イベントは、後続の要求されたイベントリストで再度要求されるかどうかに関係なく、ファックスごとのエンドポイントごとにせいぜい1回生成する必要があります。
* stop: Call Agent controlled T.38 fax relay procedure ended and the gateway did not detect any errors. Note that this does not necessarily imply a successfully transmitted fax. It merely indicates that the Call Agent controlled T.38 fax relay procedure has ended and the procedure itself did not encounter any errors. The Call Agent may want to modify the media parameters for each side of the connection. Note that, in contrast to the gateway controlled fax procedure case, media parameters such as codecs do not automatically revert to their values before the start of the fax call; however, echo cancellation and silence suppression do per the procedures in [RFC3435] Section 2.3.5. The "t38(stop)" event MUST NOT be generated unless a corresponding "t38(start)" event for the fax call in question was generated earlier.
* 停止：コールエージェント制御T.38ファックスリレー手順が終了し、ゲートウェイはエラーを検出しませんでした。これは必ずしも正常に送信されたFAXを意味するわけではないことに注意してください。コールエージェントがT.38ファックスリレー手順が終了し、手順自体がエラーに遭遇しなかったことを示すだけです。コールエージェントは、接続の各側のメディアパラメーターを変更する場合があります。ゲートウェイ制御FAX手順のケースとは対照的に、コーデックなどのメディアパラメーターは、FAXコールの開始前に自動的に値に戻ることはないことに注意してください。ただし、[RFC3435]セクション2.3.5の手順に従って、エコーキャンセルと沈黙の抑制が行われます。「T38（STOP）」イベントは、問題のFAXコールの対応する「T38（START）」イベントが以前に生成されない限り、生成する必要はありません。
* failure: Call Agent controlled T.38 fax relay procedure ended abnormally. Some kind of problem in the Call Agent controlled T.38 fax relay procedure was encountered, and the procedure ended. The Call Agent may want to modify the media parameters for each side of the connection. Note that, in contrast to the gateway controlled fax procedure case, media parameters such as codecs do not automatically revert to their state before the start of the fax call; however, echo cancellation and silence suppression do per the procedures in [RFC3435] Section 2.3.5. The "t38(failure)" event MUST NOT be generated unless a corresponding "t38(start)" event for the fax call in question was generated earlier.
* 障害：コールエージェント制御T.38ファックスリレー手順は異常に終了しました。コールエージェントが制御されたT.38ファックスリレー手順の何らかの問題が発生し、手順が終了しました。コールエージェントは、接続の各側のメディアパラメーターを変更する場合があります。ゲートウェイ制御されたFAX手順のケースとは対照的に、コーデックなどのメディアパラメーターは、FAXコールの開始前に自動的に状態に戻っていないことに注意してください。ただし、[RFC3435]セクション2.3.5の手順に従って、エコーキャンセルと沈黙の抑制が行われます。問題のFAXコールの対応する「T38（START）」イベントが以前に生成されない限り、「T38（故障）」イベントを生成してはなりません。
One of the above parameters will be present when the event is reported. The "t38" event MAY be parameterized with additional parameters, however it is RECOMMENDED that one of the above parameters is the first parameter supplied. Unknown parameters MUST be ignored.
イベントが報告されると、上記のパラメーターの1つが存在します。「T38」イベントは追加のパラメーターでパラメーター化される場合がありますが、上記のパラメーターのいずれかが最初のパラメーターであることをお勧めします。不明なパラメーターは無視する必要があります。
The following example illustrates the encoding of the "t38" event:
次の例は、「T38」イベントのエンコードを示しています。
O: fxr/t38(start)
O: fxr/t38(stop, foobar)
The connection parameters for the connection, that measures packets and octets sent and received, MUST include packets and octets for fax handling as well. Interarrival jitter and average transmission delay calculation however MAY NOT be performed while fax is in progress, e.g., if T.38 is used. In such cases, the interarrival jitter and average transmission delay calculations are simply suspended until calculations can resume, e.g., by changing back to an RTP-based media stream.
送信および受信したパケットとオクテットを測定する接続の接続パラメーターには、ファックス処理用のパケットとオクテットも含める必要があります。ただし、FAXが進行中の場合、T.38を使用している場合は、FAXが使用されている場合、到着間ジッターと平均送信遅延計算は実行されない場合があります。そのような場合、登録ジッターと平均伝送遅延計算は、たとえばRTPベースのメディアストリームに戻ることにより、計算が再開できるまで単純に停止されます。
In addition to these connection parameters, the fax package defines the following connection parameters, which gateways MAY support:
これらの接続パラメーターに加えて、FAXパッケージは、ゲートウェイがサポートできる次の接続パラメーターを定義します。
Number of fax pages sent (PGS):
送信されるFAXページの数（PGS）：
The cumulative number of fax pages sent by the endpoint for the life of the connection. The parameter is encoded as "PGS", and the value supplied is a string of up to nine decimal digits.
接続の寿命のためにエンドポイントから送信されたFAXページの累積数。パラメーターは「PGS」としてエンコードされており、提供される値は最大9桁までの列です。
Number of fax pages received (PGR):
受信したFAXページの数（PGR）：
The cumulative number of fax pages received by the endpoint for the life of the connection. The parameter is encoded as "PGR", and the value supplied is a string of up to nine decimal digits.
接続の寿命のためにエンドポイントによって受信されたFAXページの累積数。パラメーターは「PGR」としてエンコードされており、提供される値は最大9桁までの文字列です。
The following example illustrates the use of these parameters:
次の例は、これらのパラメーターの使用を示しています。
P: FXR/PGS=3, FXR/PGR=0, PS=1245, OS=62345, ...
T.38 Annex D [T38] defines a number of T.38 parameters that can be negotiated in the SDP. Currently, T.38 does not specify procedures for how each of these parameters is negotiated or in particular whether each side has to use the same value. Therefore, we considered adding such definitions and procedures here. However, it is expected that T.38 will rectify the above, which could lead to conflicting definitions and procedures. To avoid that, we instead assume the existence of an offer/answer [RFC3264] section for T.38, where T.38 Annex D parameters are classified as either declarative or negotiated, and we then provide guidelines for how to map such definitions and procedures to the MGCP fax package defined here.
T.38 Annex D [T38]は、SDPで交渉できる多くのT.38パラメーターを定義しています。現在、T.38は、これらの各パラメーターがどのように交渉されるか、特に各側が同じ値を使用する必要があるかどうかについての手順を指定していません。したがって、このような定義と手順をここに追加することを検討しました。ただし、T.38が上記を修正することが予想されます。これにより、矛盾する定義と手順につながる可能性があります。それを回避するために、代わりにT.38のオファー/回答[RFC3264]セクションの存在を想定しています。ここで、T.38の付属書Dパラメーターは宣言的または交渉されたものとして分類され、そのような定義をマッピングする方法のガイドラインを提供します。ここで定義されているMGCP FAXパッケージの手順。
MGCP does not specify use of the offer/answer model but instead operates with the concept of connection handling commands (e.g., CreateConnection and ModifyConnection) that may include a RemoteConnectionDescriptor (SDP) and in turn may generate a LocalConnectionDescriptor (SDP) in their response.
MGCPは、オファー/回答モデルの使用を指定するのではなく、代わりに、RemoteConnectionDescriptor（SDP）を含む可能性のある接続処理コマンド（CreateConnectionおよびModifyConnection）の概念で動作し、応答中にローカルコネクションデスプリシスタル（SDP）を生成する場合があります。
When an MGCP endpoint receives a CreateConnection command without a RemoteConnectionDescriptor, it should follow the corresponding T.38 procedures for generating an initial offer and return the resulting SDP in its LocalConnectionDescriptor.
MGCPエンドポイントがRemoteConnectionDescriptorなしでCreateConnectionコマンドを受信する場合、初期オファーを生成するための対応するT.38手順に従い、RocalConnectionDescriptorの結果のSDPを返します。
When an MGCP endpoint receives a CreateConnection command with a RemoteConnectionDescriptor, it should follow the corresponding T.38 procedures for receiving an initial offer and generating an answer to it. The resulting SDP is returned in the LocalConnectionDescriptor.
MGCPエンドポイントがRemoteConnectionDescriptorを使用してCreateConnectionコマンドを受信する場合、初期オファーを受信して回答を生成するための対応するT.38手順に従う必要があります。結果のSDPは、LocalConnectionDescriptorで返されます。
When an MGCP endpoint receives a ModifyConnection command with a RemoteConnectionDescriptor, it cannot determine whether this corresponds to an answer to an initial offer or to a new offer. This is not an issue for declarative parameters since they can be specified independently in either direction. Negotiated parameters, however, require some consideration:
MGCPエンドポイントがRemoteConnectionDescriptorを使用してModieConnectionコマンドを受信した場合、これが初期オファーまたは新しいオファーへの回答に対応するかどうかを判断できません。これは、どちらの方向でも独立して指定できるため、宣言的パラメーターの問題ではありません。ただし、交渉されたパラメーターには、ある程度の考慮が必要です。
When an offerer receives an answer to a previous offer, the negotiation has completed and the parameters negotiated can no longer be changed with this offer/answer exchange. The negotiated parameters may be subject to certain validation checks. Conversely, when an answerer receives an offer, the negotiation is open and the answerer may change some of the offered negotiated parameters. Since the MGCP endpoint does not know which situation it is in, it cannot perform the "offerer" validation checks. Likewise, in order to ensure that any required negotiation actually takes place, it needs to process an incoming SDP as an offer. If the SDP in fact does correspond to an offer, then this is obviously correct behavior. However, if the SDP corresponds to an answer, and one or more negotiated parameters did change, then this will result in a new SDP. The Call Agent may or may not contain sufficient intelligence to determine whether or not this new SDP needs to result in another offer/answer exchange.
申し出人が以前の申し出に対する回答を受け取ると、交渉が完了し、交渉されたパラメーターは、このオファー/回答の交換でもはや変更できなくなります。ネゴシエートされたパラメーターには、特定の検証チェックの対象となる場合があります。逆に、応答者がオファーを受け取ると、交渉が開かれ、応答者が提供された交渉されたパラメーターの一部を変更する可能性があります。MGCPエンドポイントは、どの状況にあるかを知らないため、「Offerer」検証チェックを実行できません。同様に、必要な交渉が実際に行われることを確認するために、受信SDPをオファーとして処理する必要があります。実際にSDPがオファーに対応している場合、これは明らかに正しい動作です。ただし、SDPが回答に対応し、1つ以上のネゴシエートされたパラメーターが変更された場合、これにより新しいSDPが発生します。コールエージェントは、この新しいSDPが別のオファー/回答交換をもたらす必要があるかどうかを判断するのに十分なインテリジェンスを含む場合と含まない場合があります。
For example, if the initial offer (in response to a CreateConnection without SDP) contained fax version 2, and the answer (in response to a CreateConnection with SDP) contained fax version 0, then the corresponding ModifyConnection command (with SDP) will result in an updated SDP with fax version also set to zero. If this was the only change in the updated SDP, a new offer/answer exchange would not be needed. Note that this example does not imply that it is generally considered a good idea for Call Agents to parse SDP in order to determine whether or not new offer/answer exchanges are needed.
たとえば、初期オファー（SDPのないCreateConnectionに応じて）にFaxバージョン2が含まれていて、回答（SDPとのCreateConnectionに応じて）にFaxバージョン0が含まれている場合、対応するModifyConnectionコマンド（SDPを使用）になります。FAXバージョンを備えた更新されたSDPもゼロに設定されています。これが更新されたSDPの唯一の変更である場合、新しいオファー/回答の交換は必要ありません。この例は、一般に、新しいオファー/回答の交換が必要かどうかを判断するために、コールエージェントがSDPを解析する良いアイデアと見なされることを意味しないことに注意してください。
Finally, a ModifyConnection without SDP that generates an SDP needs to be considered. The SDP generated may either correspond to an initial offer/answer exchange or a subsequent offer/answer exchange.
最後に、SDPを生成するSDPを使用しないModieConnectionを考慮する必要があります。生成されたSDPは、最初のオファー/回答交換またはその後のオファー/回答の交換に対応する場合があります。
The endpoint should generate SDP as if it was part of a subsequent offer/answer exchange. If the Call Agent does not desire such semantics, it can simply create a new connection instead.
エンドポイントは、まるでその後のオファー/回答交換の一部であるかのようにSDPを生成する必要があります。コールエージェントがそのようなセマンティクスを望まない場合、代わりに新しい接続を作成するだけです。
When an endpoint is instructed to change to or from T.38 for a media stream, it SHOULD continue using the same IP address and port the media stream is currently using, since this will minimize any Quality of Service, Network Address Translator (NAT), and Firewall interactions from the change. However, if an endpoint has a good reason, it MAY choose not to follow this recommendation.
メディアストリームのT.38との間で変更するようにエンドポイントが指示されている場合、同じIPアドレスを使用し続け、メディアストリームが現在使用しているポートを使用する必要があります。、および変更からのファイアウォールの相互作用。ただし、エンドポイントに正当な理由がある場合、この推奨に従わないことを選択する場合があります。
When an endpoint uses the same port for RTP audio and T.38 with either UDPTL or TCP, packets of one type (e.g., T.38) may be received while expecting packets of another type (RTP audio). Since there is explicit signaling to indicate which type is expected at any given point in time, this does not introduce any new problems. In other words, the receiver does not operate as a demultiplexer with a need to determine if a given packet received is an RTP audio packet or a T.38 UDPTL/TCP packet. The receiver simply processes incoming packets as usual. If T.38 packets are expected, then incoming packets are validated against T.38, and if RTP audio packets are expected, then incoming packets are validated against RTP.
エンドポイントがRTPオーディオに同じポートとUDPTLまたはTCPのいずれかを使用してT.38を使用する場合、1つのタイプのパケット（T.38など）を受信することができます。特定の時点でどのタイプが予想されるかを示す明示的なシグナル伝達があるため、これは新しい問題を導入しません。言い換えれば、受信者は、受信した特定のパケットがRTPオーディオパケットまたはT.38 UDPTL/TCPパケットであるかどうかを判断する必要があるDemultiplexerとして動作しません。受信者は、通常どおり受信パケットを処理するだけです。T.38パケットが予想される場合、着信パケットはt.38に対して検証され、RTPオーディオパケットが予想される場合、着信パケットはRTPに対して検証されます。
IANA has registered the uppercase string "UDPTL" as the transport protocol identifier to be used for UDP-based T.38. However, the examples provided in Recommendation T.38, as well as most (if not all) current implementations, use the lowercase string "udptl" instead. Implementations conforming to this package SHOULD generate the lowercase string "udptl" and accept the lowercase, uppercase, and mixed upper/lowercase strings as being equivalent.
IANAは、UDPベースのT.38に使用されるトランスポートプロトコル識別子として大文字の文字列「udptl」を登録しています。ただし、推奨T.38で提供されている例と、ほとんどの（すべてではないにしても）現在の実装では、代わりに小文字の文字列「udptl」を使用します。このパッケージに準拠した実装は、小文字の文字列「udptl」を生成し、小文字、大文字、および混合された上部/小文字の文字列を同等であると受け入れる必要があります。
The attribute "T38MaxBitRate" was once incorrectly registered with IANA as "T38maxBitRate" (lower-case "m"). In accordance with T.38 examples and common implementation practice, the form "T38MaxBitRate" SHOULD be generated by implementations conforming to this package.
属性「T38Maxbitrate」は、かつてIANAに「T38Maxbitrate」（低ケース「M」）として誤って登録されていました。T.38の例と一般的な実装の実践に従って、このパッケージに準拠した実装によって「T38maxbitrate」という形式を生成する必要があります。
In general, it is RECOMMENDED that implementations of this package accept lowercase, uppercase, and mixed upper/lowercase encodings of all the T.38 attributes.
一般に、このパッケージの実装は、すべてのT.38属性の小文字、大文字、および上部/小文字の混合エンコーディングを受け入れることをお勧めします。
Some implementations incorrectly use a colon (':') followed by a number (zero or one) after the attributes T38FaxFillBitRemoval, T38FaxTranscodingMMR, and T38FaxTranscodingJBIG. Implementations that receive such erroneous encodings MAY interpret the value ":0" as lack of support for the option and all other values as support for the option.
いくつかの実装は、t38FaxFillbitRemoval、T38FaxTransCodingMMR、およびT38FaxTransCodingJBigを属性にした後、コロン（ '：'）の後に誤って使用します（ゼロまたは1）。このような誤ったエンコーディングを受信する実装は、値「：0」をオプションのサポートの欠如として解釈し、オプションのサポートとして他のすべての値を解釈できます。
In this section, we provide three example call flows. The first one illustrates a T.38 fax call under Call Agent control on both the originating and terminating side. The second one illustrates the use of multiple and different options on the two sides. The third one illustrates the interaction with a SIP endpoint.
このセクションでは、3つの例の呼び出しフローを提供します。最初のものは、発信側と終端側の両方のコールエージェントコントロールの下でT.38ファックスコールを示しています。2つ目は、両側に複数の異なるオプションの使用を示しています。3つ目は、SIPエンドポイントとの相互作用を示しています。
In this example, both sides are under strict T.38 Call Agent control. We assume the originating and terminating Call Agents communicate via the Session Initiation Protocol (SIP) [RFC3261]. Furthermore, the originating fax machine does not generate CNG tone, which is typical of early (i.e., pre-1993) fax machines.
この例では、双方は厳密なT.38コールエージェントコントロールの下にあります。セッション開始プロトコル（SIP）[RFC3261]を介して、発信および終了のコールエージェントが通信すると仮定します。さらに、発信元のファックスマシンはCNGトーンを生成しません。これは、初期（つまり、1993年以前）ファックスマシンに典型的です。
------------------------------------------------------------------
| #| GW-o | CA-o | CA-t | GW-t |
|==|===============|===============|===============|===============|
| 1| <-|CRCX | | |
| 2| 200(sdp-o)|-> | | |
| 3| | INVITE(sdp-o)|-> | |
| 4| | | CRCX(sdp-o)|-> |
| 5| | | <-|200 (sdp-t) |
| 6| | <-|200(sdp-t) | |
| 7| <-|MDCX(sdp-t) | | |
| 8| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
| 9| | | | <- ANS/ |
| | | | | T.30 CED |
|10| | | | <- V.21 fax |
| | | | | preamble |
|11| | | <-|NTFY(t38 start)|
|12| | | 200|-> |
|13| | | MDCX(t38)|-> |
|14| | | <-|200(sdp-t2) |
|15| | <-|INVITE(sdp-t2) | |
|16| <-|MDCX(sdp-t2) | | |
|17| 200(sdp-o2)|-> | | |
|18| | 200(sdp-o2)|-> | |
|19| | | MDCX(sdp-o2)|-> |
|20| | | <-|200 |
|21| V.21 fax -> | | | |
| | preamble | | | |
|22|NTFY(t38 start)|-> | | |
|23| <-|200 | | |
|24| <-|RQNT(T38 event)| | |
|25| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
|26| | | | (fax ends) |
|27| | | <-|NTFY(t38 stop) |
|28| | | 200|-> |
|29|NTFY(t38 stop) |-> | | |
|30| <-|200 | | |
------------------------------------------------------------------
Step 1:
ステップ1：
The Call Agent issues a CreateConnection command to the gateway, instructing it to use PCMU media encoding and to use the strict Call Agent controlled T.38 procedure. Consequently, the Call Agent asks the gateway to notify it of the "t38" event:
コールエージェントは、GatewayにCreateConnectionコマンドを発行し、PCMUメディアエンコードを使用し、厳密なコールエージェント制御T.38手順を使用するよう指示します。その結果、コールエージェントはゲートウェイに「T38」イベントを通知するように依頼します。
CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
L: a:PCMU, fxr/fx:t38
M: recvonly
R: fxr/t38
X: 1
Step 2:
ステップ2：
The gateway acknowledges the command and includes SDP with codec information and RFC 3407 [RFC3407] capability information:
ゲートウェイはコマンドを認め、コーデック情報とRFC 3407 [RFC3407]機能情報を含むSDPを含めます。
200 1000 OK I:1
200 1000 OK I：1
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 3456 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 3:
ステップ3：
The originating Call Agent sends a SIP INVITE message with the SDP to the terminating Call Agent.
発信元のコールエージェントは、SDPを含むSIP招待メッセージを終了コールエージェントに送信します。
Step 4:
ステップ4：
The terminating Call Agent issues a CreateConnection command to the terminating gateway, instructing it to use PCMU media encoding and to use the strict Call Agent controlled T.38 procedure. Consequently, the Call Agent asks the gateway to notify it of the "t38" event:
終了コールエージェントは、終了ゲートウェイへのCreateConnectionコマンドを発行し、PCMUメディアエンコードを使用し、厳密なコールエージェント制御T.38手順を使用するように指示します。その結果、コールエージェントはゲートウェイに「T38」イベントを通知するように依頼します。
CRCX 2000 ds/ds1-1/2@gw-t.example.net MGCP 1.0
C: 2
L: a:PCMU, fxr/fx:t38
M: sendrecv
R: fxr/t38
X: 20
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 3456 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 5:
ステップ5：
The terminating gateway supports T.38, and the RemoteConnectionDescriptor included indicates that the other side supports T.38 as well, so the strict T.38 Call Agent controlled procedure requested can be used. The terminating gateway sends back a success response with its SDP, which also includes capability information:
終端ゲートウェイはT.38をサポートし、remoteconnectionDescriptorに含まれることは、反対側がT.38もサポートしていることを示しているため、要求された厳密なT.38コールエージェント制御手順を使用できます。終了ゲートウェイは、SDPで成功応答を送り返します。これには、機能情報も含まれています。
200 2000 OK I:2
200 2000 OK I：2
v=0
o=- 25678 753849 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=audio 1296 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 6:
ステップ6：
The terminating Call Agent sends back a SIP 200 OK response to the originating Call Agent, which in turn sends a SIP ACK (not shown).
終了コールエージェントは、発信元のコールエージェントにSIP 200 OK応答を送り返し、SIP ACKを送信します（図示せず）。
Step 7:
ステップ7：
The originating Call Agent in turn sends a ModifyConnection command to the originating gateway:
発信元のコールエージェントは、順番にModieConnectionコマンドを発信ゲートウェイに送信します。
MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0 C: 1 I: 1 M: sendrecv
MDCX 1001 DS/DS1-1/1@GW-O.EXAMPLE.NET MGCP 1.0 C：1 I：1 M：SENDRECV
v=0
o=- 25678 753849 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=audio 1296 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
The ModifyConnection command does not repeat the LocalConnectionOptions sent previously. As far as fax handling is concerned, the gateway therefore attempts to continue using the current fax handling procedure, i.e., strict Call Agent controlled T.38. Since the capability information indicates the other side supports T.38, the gateway will in fact be able to use the strict Call Agent controlled T.38 procedure. Had there not been any support for T.38 in the RemoteConnectionDescriptor, then this command would still have succeeded, however there would be no special fax handling procedure (since strict mode could not be supported).
ModieConnectionコマンドは、以前に送信されたLocalConnectionOptionsを繰り返しません。したがって、FAXの取り扱いに関する限り、ゲートウェイは現在のFAX処理手順、つまり厳密なコールエージェントがT.38を制御し続けようとします。機能情報は反対側がt.38をサポートしていることを示しているため、ゲートウェイは実際には厳密なコールエージェント制御T.38手順を使用できます。RemoteConnectionDescriptorでT.38のサポートがなかったら、このコマンドはまだ成功していたでしょうが、特別なFAX処理手順はありません（厳密なモードをサポートできなかったため）。
Step 8:
ステップ8：
The gateway acknowledges the command. At this point, a call is established using PCMU encoding, and if a fax call is detected, the Call Agent controlled T.38 procedure will be initiated.
ゲートウェイはコマンドを認めます。この時点で、PCMUエンコーディングを使用してコールが確立され、FAXコールが検出された場合、コールエージェントがT.38手順を制御します。
Steps 9-11:
ステップ9-11：
A fax call now occurs. The T.30 CED tone (a.k.a. V.25 ANS) is sent -- in this case, it is simply passed through the current PCMU encoding. Since both fax and modem calls can start with this sequence, it is not possible to determine that this is a fax call until step 10, where the V.21 fax preamble is detected.
ファックスコールが発生するようになりました。T.30 CEDトーン（別名V.25 ANS）が送信されます。この場合、現在のPCMUエンコードを通過するだけです。FAXコールとモデム呼び出しの両方がこのシーケンスで開始できるため、V.21 Fax Preambleが検出されるステップ10までこれがFAXコールであると判断することはできません。
The gateway was instructed to apply the Call Agent controlled T.38 procedure for fax calls, so it begins to mute audio, generates the "t38(start)" event, and notifies the Call Agent:
ゲートウェイは、ファックスコールにコールエージェント制御T.38手順を適用するように指示されたため、オーディオをミュートし始め、「T38（start）」イベントを生成し、コールエージェントに通知します。
NTFY 2500 ds/ds1-1/2@gw-t.example.net MGCP 1.0 O: fxr/t38(start) X: 20
NTFY 2500 DS/DS1-1/2@GW-T.EXAMPLE.NET MGCP 1.0 O：FXR/T38（START）X：20
Step 12:
ステップ12：
The Call Agent acknowledges the Notify command:
コールエージェントは、notifyコマンドを確認します。
200 2500 OK
200 2500 OK
Step 13:
ステップ13：
The Call Agent then instructs the terminating gateway to use the "image/t38" MIME type instead:
次に、コールエージェントは、終了ゲートウェイに、代わりに「画像/T38」MIMEタイプを使用するよう指示します。
MDCX 2002 ds/ds1-1/2@gw-t.example.net MGCP 1.0 C: 2 I: 2 L: a:image/t38 R: fxr/t38 X: 21
MDCX 2002 DS/DS1-1/2/2@gw-t.example.net MGCP 1.0 C：2 I：2 L：A：Image/T38 R：FXR/T38 X：21
Step 14:
ステップ14：
The gateway changes to T.38 and sends back a success response with updated SDP:
ゲートウェイはT.38に変更され、更新されたSDPで成功応答を送り返します。
200 2002 OK
200 2002 OK
v=0
o=- 25678 753850 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=image 1296 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Note that since the gateway's current RemoteConnectionDescriptor (as opposed to the LocalConnectionDescriptor returned here) does not list "image/t38" as a valid encoding method, the terminating gateway is still muting the media and is now waiting for an updated RemoteConnectionDescriptor with "image/t38".
Gatewayの現在のRemoteConnectionDescriptor（LocalConnectionDescriptorとは対照的に）は「Image/T38」を有効なエンコーディング方法としてリストしていないため、終端ゲートウェイはまだメディアをミューティングしており、「画像/」で更新されたRemotonectionDescriptorを待っています。T38 "。
Step 15:
ステップ15：
The terminating Call Agent sends a re-INVITE to the originating Call Agent with the updated SDP.
終了コールエージェントは、更新されたSDPを使用して発信元のコールエージェントに再入力を送信します。
Step 16:
ステップ16：
The originating Call Agent then sends a ModifyConnection command to the originating gateway:
その後、発信元のコールエージェントは、ModifyConnectionコマンドを発信ゲートウェイに送信します。
MDCX 1003 ds/ds1-1/1@gw-o.example.net MGCP 1.0 C: 1 I: 1
MDCX 1003 DS/DS1-1/1@GW-O.EXAMPLE.NET MGCP 1.0 C：1 I：1
v=0
o=- 25678 753850 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=image 1296 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 17:
ステップ17：
The originating gateway changes to T.38 and sends back a success response with updated SDP:
発信元のゲートウェイはT.38に変更され、更新されたSDPで成功応答を送り返します。
200 1003 OK
200 1003 OK
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 18:
ステップ18：
The originating Call Agent sends a SIP 200 OK response with the updated SDP to the terminating Call Agent, which in turn sends a SIP ACK (not shown).
発信元のコールエージェントは、更新されたSDPを使用してSIP 200 OK応答を終了コールエージェントに送信し、SIP ACKを送信します（図示せず）。
Step 19:
ステップ19：
The terminating Call Agent sends a ModifyConnection with the updated SDP to the terminating gateway:
終了コールエージェントは、更新されたSDPとのModifyConnectionを終了ゲートウェイに送信します。
MDCX 2003 ds/ds1-1/2@gw-t.example.net MGCP 1.0 C: 2 I: 2
MDCX 2003 DS/DS1-1/2@gw-t.example.net MGCP 1.0 C：2 I：2
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 20:
ステップ20：
The terminating gateway sends back a success response:
終了ゲートウェイは、成功応答を送り返します。
200 2003 OK
200 2003 OK
Since the terminating gateway now has a RemoteConnectionDescriptor with "image/t38" as valid media, it can start exchanging T.38 with the originating gateway.
終了ゲートウェイには、有効なメディアとして「Image/T38」を備えたRemoteConnectionDescriptorがあるため、T.38の発信元のゲートウェイと交換を開始できます。
Steps 21, 22:
ステップ21、22：
The originating endpoint detects V.21 fax preamble. Even though the endpoint is already using "image/t38" for media, it generates a "t38(start)" event and notifies the Call Agent.
発信元のエンドポイントは、v.21ファックスのプリアンブルを検出します。エンドポイントは既にメディアに「Image/T38」を使用していますが、「T38（Start）」イベントを生成し、コールエージェントに通知します。
NTFY 3500 ds/ds1-1/1@gw-o.example.net MGCP 1.0 O: fxr/t38(start) X: 1
NTFY 3500 DS/DS1-1/1/gw-o.example.net mgcp 1.0 O：fxr/t38（start）x：1
Steps 23, 24:
ステップ23、24：
The Call Agent acknowledges the Notify command, then issues a new request for notification of the "t38" event.
コールエージェントはNotifyコマンドを確認し、「T38」イベントの通知の新しいリクエストを発行します。
200 3500 OK . RQNT 1004 ds/ds1-1/1@gw-o.example.net MGCP 1.0 R: fxr/t38 X: 2
200 3500 OK。RQNT 1004 DS/DS1-1/1@GW-O.EXAMPLE.NET MGCP 1.0 R：FXR/T38 X：2
Step 25:
ステップ25：
The gateway acknowledges the command.
ゲートウェイはコマンドを認めます。
200 1004 OK
200 1004 OK
Steps 26, 27:
手順26、27：
When the fax ends, a "t38(stop)" event is generated by the terminating endpoint, which is notified to the Call Agent:
FAXが終了すると、「T38（STOP）」イベントが終了エンドポイントによって生成され、コールエージェントに通知されます。
NTFY 2501 ds/ds1-1/2@gw-t.example.net MGCP 1.0 O: t38(stop) X: 21
NTFY 2501 DS/DS1-1/2@GW-T.EXAMPLE.NET MGCP 1.0 O：T38（STOP）X：21
Step 28:
ステップ28：
The Call Agent acknowledges the Notify command:
コールエージェントは、notifyコマンドを確認します。
200 2501 OK
200 2501 OK
Step 29:
ステップ29：
The originating endpoint also generates a "t38(stop)" event, which is notified to the Call Agent:
元のエンドポイントは、「T38（STOP）」イベントも生成します。これは、コールエージェントに通知されます。
NTFY 3502 ds/ds1-1/1@gw-o.example.net MGCP 1.0 O: t38(stop) X: 2
NTFY 3502 DS/DS1-1/1/gw-o.example.net MGCP 1.0 O：T38（停止）X：2
Step 30:
ステップ30：
The Call Agent acknowledges the Notify command:
コールエージェントは、notifyコマンドを確認します。
200 3502 OK
200 3502 OK
The fax call is now over. The Call Agent may now decide to change back to a voice codec, delete the connection, or do something different.
ファックスコールは終了しました。コールエージェントは、音声コーデックに戻って変更したり、接続を削除したり、違うことをしたりすることを決定する場合があります。
In this example, the originating gateway is instructed to use the gateway procedure, whereas the terminating gateway is given a choice between the gateway procedure and the strict t38 procedure. Furthermore, the originating fax machine is generating CNG tone.
この例では、元のゲートウェイはゲートウェイ手順を使用するように指示されますが、終端ゲートウェイにはゲートウェイ手順と厳密なT38手順の間に選択肢が与えられます。さらに、発信元のFAXマシンはCNGトーンを生成しています。
------------------------------------------------------------------
| #| GW-o | CA-o | CA-t | GW-t |
|==|===============|===============|===============|===============|
| 1| <-|CRCX | | |
| 2| 200(sdp-o)|-> | | |
| 3| | INVITE(sdp-o)|-> | |
| 4| | | CRCX(sdp-o)|-> |
| 5| | | <-|200 (sdp-t) |
| 6| | <-|200(sdp-t) | |
| 7| <-|MDCX(sdp-t) | | |
| 8| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
| 9| CNG ->| | | |
|10| | | |<- ANS/T.30 CED|
|11| | | |<- V.21 fax |
| | | | | preamble |
|12| | | <-|NTFY(t38 start)|
|13| | | 200|-> |
|14| | | MDCX(t38)|-> |
|15| | | <-|200(sdp-t2) |
|16| | <-|INVITE(sdp-t2) | |
|17| <-|MDCX(sdp-t2) | | |
|18| 200(sdp-o2)|-> | | |
|19| | 200(sdp-o2)|-> | |
|20| | | MDCX(sdp-o2)|-> |
|21| | | <-|200 |
|--|---------------|---------------|---------------|---------------|
|22| | | | (fax ends) |
|23| | | <-|NTFY(t38 stop) |
|24| | | 200|-> |
------------------------------------------------------------------
Step 1:
ステップ1：
The Call Agent issues a CreateConnection command to the gateway, instructing it to use PCMU media encoding and to use the gateway procedure. Consequently, the Call Agent asks the gateway to notify it of the "gwfax" event:
コールエージェントは、GatewayにCreateConnectionコマンドを発行し、PCMUメディアエンコードを使用し、ゲートウェイ手順を使用するように指示します。その結果、コールエージェントはゲートウェイに「GWFAX」イベントを通知するように依頼します。
CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
L: a:PCMU, fxr/fx:gw
M: recvonly
R: fxr/gwfax
X: 1
Step 2:
ステップ2：
The gateway acknowledges the command and includes SDP with codec information and capability information:
ゲートウェイはコマンドを認め、コーデック情報と機能情報を含むSDPを含めます。
200 1000 OK I:1
200 1000 OK I：1
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 3456 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
a=X-FaxScheme: 123
We assume the gateway supports some other fax scheme, and it indicates this by including an attribute "X-FaxScheme: 123".
ゲートウェイは他のFAXスキームをサポートしていると仮定し、「X-Faxscheme：123」属性を含めることでこれを示します。
Step 3:
ステップ3：
The originating Call Agent sends a SIP INVITE message with the SDP to the terminating Call Agent.
発信元のコールエージェントは、SDPを含むSIP招待メッセージを終了コールエージェントに送信します。
Step 4:
ステップ4：
The terminating Call Agent issues a CreateConnection command to the terminating gateway, instructing it to use PCMU media encoding and to use either the gateway procedure or the strict Call Agent controlled T.38 procedure. Consequently, the Call Agent asks the gateway to notify it of both the "gwfax" and "t38" events:
終了コールエージェントは、終了ゲートウェイへのCreateConnectionコマンドを発行し、PCMUメディアエンコードを使用し、ゲートウェイ手順または厳密なコールエージェント制御T.38手順のいずれかを使用するよう指示します。その結果、コールエージェントはゲートウェイに「GWFAX」と「T38」イベントの両方を通知するように依頼します。
CRCX 2000 ds/ds1-1/2@gw-t.example.net MGCP 1.0
C: 2
L: a:PCMU, fxr/fx:gw;t38
M: sendrecv
R: fxr/t38, fxr/gwfax
X: 20
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 3456 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
a=X-FaxScheme: 123
Step 5:
ステップ5：
The terminating gateway does not support any special gateway fax handling; however, it does support T.38, and the RemoteConnectionDescriptor included indicates that the other side supports T.38 as well, so the strict T.38 Call Agent controlled procedure requested can be honored. The terminating gateway sends back a success response with its SDP, which also includes capability information:
終了ゲートウェイは、特別なゲートウェイファックス処理をサポートしていません。ただし、T.38をサポートしており、RemoteConnectionDescriptorに含まれるRemoteConnectionDescriptorは、反対側がT.38もサポートしていることを示しているため、要求された厳密なT.38コールエージェント制御手順を尊重できます。終了ゲートウェイは、SDPで成功応答を送り返します。これには、機能情報も含まれています。
200 2000 OK I:2
200 2000 OK I：2
v=0
o=- 25678 753849 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=audio 1296 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 6:
ステップ6：
The terminating Call Agent sends back a SIP 200 OK response to the originating Call Agent, which in turn sends a SIP ACK (not shown).
終了コールエージェントは、発信元のコールエージェントにSIP 200 OK応答を送り返し、SIP ACKを送信します（図示せず）。
Step 7:
ステップ7：
The originating Call Agent in turns sends a ModifyConnection command to the originating gateway:
発信元のコールエージェントは、順番に、ModieConnectionコマンドを発信ゲートウェイに送信します。
MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0 C: 1 I: 1 M: sendrecv
MDCX 1001 DS/DS1-1/1@GW-O.EXAMPLE.NET MGCP 1.0 C：1 I：1 M：SENDRECV
v=0
o=- 25678 753849 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=audio 1296 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
The ModifyConnection command does not repeat the LocalConnectionOptions sent previously. As far as fax handling is concerned, the gateway therefore attempts to continue using the current fax handling, i.e., the gateway procedure. The SDP information returned however does not indicate support for the "X-FaxScheme: 123", and hence the originating gateway will not invoke any special fax handling procedure for this call.
ModieConnectionコマンドは、以前に送信されたLocalConnectionOptionsを繰り返しません。したがって、FAXの取り扱いに関する限り、ゲートウェイは現在のFAX処理、つまりゲートウェイ手順の使用を継続しようとします。ただし、返されたSDP情報は、「X-Faxscheme：123」のサポートを示すものではないため、この呼び出しの特別なFAX処理手順は呼び出されません。
Step 8:
ステップ8：
The gateway acknowledges the command. At this point, a call is established using PCMU encoding, and if a fax call is detected, no special fax handling procedure will occur.
ゲートウェイはコマンドを認めます。この時点で、PCMUエンコーディングを使用してコールが確立され、FAXコールが検出された場合、特別なFAX処理手順は発生しません。
Steps 9-12:
ステップ9-12：
A CNG tone is generated by the originating fax, thereby indicating a fax call. If the gateway was using either of the T.38 modes, or if it had negotiated support for a special gateway handling procedure with the other side, a "t38(start)" or "gwfax(start)" event would now have been generated and the switch to T.38 (or special gateway handling) could start. However, since the negotiation with the terminating gateway resulted in the originating gateway not doing anything special for fax, no such event is generated. Instead, the "nopfax(start)" event is now generated, but since the Call Agent has not requested this event, it is not detected and hence not reported to the Call Agent. Consequently, the CNG tone is simply passed through the current PCMU encoding without the (originating) Call Agent being aware of the fax call.
CNGトーンは、発信元のFAXによって生成され、それによりFAXコールを示します。ゲートウェイがT.38モードのいずれかを使用していた場合、または反対側との特別なゲートウェイ処理手順のサポートを交渉した場合、「T38（START）」または「GWFAX（START）」イベントが生成されるようになりましたT.38（または特別なゲートウェイ処理）への切り替えが開始される可能性があります。ただし、終了ゲートウェイとの交渉により、発信元のゲートウェイがファックスに特別なことをしないことになったため、そのようなイベントは生成されません。代わりに、「nopfax（start）」イベントが生成されましたが、コールエージェントがこのイベントを要求していないため、検出されていないため、コールエージェントに報告されません。その結果、CNGトーンは、FAXコールを認識している（発信する）コールエージェントがなくなることなく、現在のPCMUエンコードを通過するだけです。
Subsequently, the T.30 CED tone (a.k.a. V.25 ANS) occurs -- in this case, it is also simply passed through the current PCMU encoding. Since both fax and modem calls can start with this sequence, it is not possible to determine that this is a fax call until step 11, where the V.21 fax preamble is detected.
その後、T.30 CEDトーン（別名V.25 ANS）が発生します。この場合、現在のPCMUエンコードを通過するだけです。FAXコールとモデム呼び出しの両方がこのシーケンスで開始できるため、V.21 Fax Preambleが検出されるステップ11までこれがFAXコールであると判断することはできません。
The terminating gateway is using the Call Agent controlled T.38 procedure for fax calls, so it begins to mute audio, generates the "t38(start)" event, and notifies the Call Agent:
終了ゲートウェイは、ファックスコールにコールエージェント制御T.38手順を使用しているため、オーディオをミュートし始め、「T38（start）」イベントを生成し、コールエージェントに通知します。
NTFY 2500 ds/ds1-1/2@gw-t.example.net MGCP 1.0 O: fxr/t38(start) X: 20
NTFY 2500 DS/DS1-1/2@GW-T.EXAMPLE.NET MGCP 1.0 O：FXR/T38（START）X：20
Step 13:
ステップ13：
The Call Agent acknowledges the Notify command:
コールエージェントは、notifyコマンドを確認します。
200 2500 OK
200 2500 OK
Step 14:
ステップ14：
The Call Agent then instructs the terminating gateway to use the "image/t38" MIME type instead:
次に、コールエージェントは、終了ゲートウェイに、代わりに「画像/T38」MIMEタイプを使用するよう指示します。
MDCX 2002 ds/ds1-1/2@gw-t.example.net MGCP 1.0 C: 2 I: 2 L: a:image/t38 R: fxr/t38 X: 21
MDCX 2002 DS/DS1-1/2/2@gw-t.example.net MGCP 1.0 C：2 I：2 L：A：Image/T38 R：FXR/T38 X：21
Step 15:
ステップ15：
The gateway changes to T.38 and sends back a success response with updated SDP:
ゲートウェイはT.38に変更され、更新されたSDPで成功応答を送り返します。
200 2002 OK
200 2002 OK
v=0
o=- 25678 753850 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=image 1296 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Note that since the terminating gateway's last received RemoteConnectionDescriptor (as opposed to the LocalConnectionDescriptor returned here) did not list "image/t38" as a valid encoding method, the terminating gateway is still muting the media and is now waiting for an updated RemoteConnectionDescriptor with "image/t38".
終了ゲートウェイの最後にRemoteConnectionDescriptorを受信したため（LocalConnectionDescriptorとは対照的に）、ここに戻っているのとは対照的に）は、「Image/T38」を有効なエンコーディング方法としてリストしなかったため、終端ゲートウェイはまだメディアをミュートしており、今では更新されたRemoteConnectionDescriptorを待っています。画像/T38 "。
Step 16:
ステップ16：
The terminating Call Agent sends a re-INVITE to the originating Call Agent with the updated SDP.
終了コールエージェントは、更新されたSDPを使用して発信元のコールエージェントに再入力を送信します。
Step 17:
ステップ17：
The originating Call Agent then sends a ModifyConnection command to the originating gateway:
その後、発信元のコールエージェントは、ModifyConnectionコマンドを発信ゲートウェイに送信します。
MDCX 1003 ds/ds1-1/1@gw-o.example.net MGCP 1.0 C: 1 I: 1
MDCX 1003 DS/DS1-1/1@GW-O.EXAMPLE.NET MGCP 1.0 C：1 I：1
v=0
o=- 25678 753850 IN IP4 192.0.2.2
s=-
c=IN IP4 192.0.2.2
t=0 0
m=image 1296 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 18:
ステップ18：
The originating gateway changes to T.38 and sends back a success response with updated SDP:
発信元のゲートウェイはT.38に変更され、更新されたSDPで成功応答を送り返します。
200 1003 OK
200 1003 OK
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 19:
ステップ19：
The originating Call Agent sends a SIP 200 OK response with the updated SDP to the terminating Call Agent, which in turn sends a SIP ACK (not shown).
発信元のコールエージェントは、更新されたSDPを使用してSIP 200 OK応答を終了コールエージェントに送信し、SIP ACKを送信します（図示せず）。
Step 20:
ステップ20：
The terminating Call Agent sends a ModifyConnection with the updated SDP to the terminating gateway:
終了コールエージェントは、更新されたSDPとのModifyConnectionを終了ゲートウェイに送信します。
MDCX 2003 ds/ds1-1/2@gw-t.example.net MGCP 1.0 C: 2 I: 2
MDCX 2003 DS/DS1-1/2@gw-t.example.net MGCP 1.0 C：2 I：2
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 21:
ステップ21：
The terminating gateway sends back a success response:
終了ゲートウェイは、成功応答を送り返します。
200 2003 OK
200 2003 OK
Since the terminating gateway now has a RemoteConnectionDescriptor with "image/t38" as valid media, it can start exchanging T.38 with the originating gateway.
終了ゲートウェイには、有効なメディアとして「Image/T38」を備えたRemoteConnectionDescriptorがあるため、T.38の発信元のゲートウェイと交換を開始できます。
Steps 22, 23:
ステップ22、23：
When the fax ends, a "t38(stop)" event is generated, which is notified to the Call Agent:
FAXが終了すると、「T38（STOP）」イベントが生成され、コールエージェントに通知されます。
NTFY 2501 ds/ds1-1/2@gw-t.example.net MGCP 1.0 O: t38(stop) X: 21
NTFY 2501 DS/DS1-1/2@GW-T.EXAMPLE.NET MGCP 1.0 O：T38（STOP）X：21
Step 24:
ステップ24：
The Call Agent acknowledges the Notify command:
コールエージェントは、notifyコマンドを確認します。
200 2501 OK
200 2501 OK
The fax call is now over. The Call Agent may now decide to change back to a voice codec, delete the connection, or do something different.
ファックスコールは終了しました。コールエージェントは、音声コーデックに戻って変更したり、接続を削除したり、違うことをしたりすることを決定する場合があります。
In this example, we show interaction with a SIP endpoint that does not support the RFC 3407 [RFC3407] capability descriptors. To accommodate such endpoints, the T.38 loose mode is being used (at the risk of initiating T.38 to an endpoint that does not support it). Once again, the originating fax does not generate CNG tone.
この例では、RFC 3407 [RFC3407]機能記述子をサポートしていないSIPエンドポイントとの相互作用を示します。このようなエンドポイントに対応するために、T.38ルーズモードが使用されています（T.38をサポートしないエンドポイントに開始するリスクがあります）。繰り返しになりますが、発信元のファックスはCNGトーンを生成しません。
------------------------------------------------------------------
| #| GW-o | CA-o | SIP-UA-t | fax |
|==|===============|===============|===============|===============|
| 1| <-|CRCX | | |
| 2| 200(sdp-o)|-> | | |
| 3| | INVITE(sdp-o)|-> | |
| 4| | <-|200(sdp-t) | |
| 5| | ACK|-> | |
| 6| <-|MDCX(sdp-t) | | |
| 7| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
| 8| | | | <- ANS/ |
| | | | | T.30 CED |
| 9| | | | <- V.21 fax |
| | | | | preamble |
|10| | <-|INVITE(sdp-t2) | |
|11| <-|MDCX(sdp-t2) | | |
|12| 200(sdp-o2)|-> | | |
|13| | 200(sdp-o2)|-> | |
|14| | <-|ACK | |
|15| V.21 fax -> | | | |
| | preamble | | | |
|16|NTFY(t38 start)|-> | | |
|17| <-|200 | | |
|18| <-|RQNT(T38 event)| | |
|19| 200|-> | | |
|--|---------------|---------------|---------------|---------------|
|20| | | | (fax ends) |
|21| | <-|BYE | |
|22| | 200|-> | |
|23|NTFY(t38 stop) |-> | | |
|24| <-|200 | | |
------------------------------------------------------------------
Step 1:
ステップ1：
The Call Agent issues a CreateConnection command to the gateway, instructing it to use PCMU media encoding and to use the loose Call Agent controlled T.38 procedure. Consequently, the Call Agent asks the gateway to notify it of the "t38" event:
コールエージェントは、GatewayにCreateConnectionコマンドを発行し、PCMUメディアエンコードを使用し、ルーズコールエージェント制御T.38手順を使用するように指示します。その結果、コールエージェントはゲートウェイに「T38」イベントを通知するように依頼します。
CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
C: 1
L: a:PCMU, fxr/fx:t38-loose
M: recvonly
R: fxr/t38
X: 1
Step 2:
ステップ2：
The gateway acknowledges the command and includes SDP with codec information and RFC 3407 [RFC3407] capability information:
ゲートウェイはコマンドを認め、コーデック情報とRFC 3407 [RFC3407]機能情報を含むSDPを含めます。
200 1000 OK I:1
200 1000 OK I：1
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 3456 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 3:
ステップ3：
The originating SIP User Agent (UA) sends a SIP INVITE message with the SDP to the terminating Call Agent (not all SIP details shown here):
発信元のSIPユーザーエージェント（UA）は、SDPを含むSIP招待メッセージを終了コールエージェントに送信します（ここに示されているすべてのSIPの詳細はありません）：
INVITE sip:bob@biloxi.example.com SIP/2.0
...
Content-Type: application/sdp
Content-Length: 167
v=0
o=- 25678 753849 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=audio 3456 RTP/AVP 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 4:
ステップ4：
The terminating SIP User Agent sends back a SIP 200 OK response (not all SIP details shown) to the originating Call Agent:
終了SIPユーザーエージェントは、SIP 200 OK応答（すべてのSIPの詳細が表示されるわけではありません）を元のコールエージェントに送り返します。
SIP/2.0 200 OK
...
Content-Type: application/sdp
Content-Length: 100
v=0 o=- 25678 753849 IN IP4 192.0.2.2 s=- c=IN IP4 192.0.2.2 t=0 0 m=audio 1296 RTP/AVP 0
V = 0 O = -25678 753849 IN IP4 192.0.2.2 S = -C = IN IP4 192.0.2.2 T = 0 0 M =オーディオ1296 RTP/AVP 0
Note that the terminating SIP User Agent does not use the RFC 3407 [RFC3407] capability descriptor to indicate support for (or lack of support for) T.38.
終了SIPユーザーエージェントは、RFC 3407 [RFC3407]機能記述子を使用して、T.38のサポート（またはサポートの欠如）を示すことはないことに注意してください。
Step 5:
ステップ5：
The originating Call Agent receives the SIP 200 response and sends a SIP ACK message to the terminating SIP UA.
発信元のコールエージェントは、SIP 200応答を受信し、SIP ACKメッセージを終了SIP UAに送信します。
Note that the Call Agent does not know whether the peer entity supports T.38. In order to figure this out, the Call Agent could send a SIP OPTIONS request to the terminating SIP UA, requesting it to return its capabilities (not shown). Note that this can of course be done towards any SIP peer, e.g., if the other side was a Call Agent speaking SIP it could be done there too.
コールエージェントは、ピアエンティティがT.38をサポートしているかどうかを知らないことに注意してください。これを把握するために、コールエージェントは終了SIP UAにSIPオプションリクエストを送信し、機能を返すように要求できます（図示せず）。もちろん、これはあらゆるSIPピアに向かって行うことができることに注意してください。
Step 6:
ステップ6：
The originating Call Agent in turns sends a ModifyConnection command to the originating gateway:
発信元のコールエージェントは、順番に、ModieConnectionコマンドを発信ゲートウェイに送信します。
MDCX 1001 ds/ds1-1/1@gw-o.example.net MGCP 1.0 C: 1 I: 1 M: sendrecv
MDCX 1001 DS/DS1-1/1@GW-O.EXAMPLE.NET MGCP 1.0 C：1 I：1 M：SENDRECV
v=0 o=- 25678 753849 IN IP4 192.0.2.2 s=- c=IN IP4 192.0.2.2 t=0 0 m=audio 1296 RTP/AVP 0
V = 0 O = -25678 753849 IN IP4 192.0.2.2 S = -C = IN IP4 192.0.2.2 T = 0 0 M =オーディオ1296 RTP/AVP 0
The ModifyConnection command does not repeat the LocalConnectionOptions sent previously. As far as fax handling is concerned, the gateway therefore attempts to continue using the current fax handling procedure, i.e., loose Call Agent controlled T.38. The T.38 loose procedure can always be supported, and hence a switch to T.38 will be attempted if the originating gateway detects a fax call.
ModieConnectionコマンドは、以前に送信されたLocalConnectionOptionsを繰り返しません。したがって、FAXの取り扱いに関する限り、ゲートウェイは現在のFAX処理手順、つまりルーズコールエージェントがT.38を制御し続けようとします。T.38の緩い手順はいつでもサポートできます。したがって、発信元のゲートウェイがFAXコールを検出した場合、T.38への切り替えが試行されます。
Step 7:
ステップ7：
The gateway acknowledges the command. At this point, a call is established using PCMU encoding, and if a fax call is detected, the Call Agent controlled T.38 procedure will be initiated.
ゲートウェイはコマンドを認めます。この時点で、PCMUエンコーディングを使用してコールが確立され、FAXコールが検出された場合、コールエージェントがT.38手順を制御します。
Steps 8, 9:
ステップ8、9：
A fax call now occurs. The T.30 CED tone (a.k.a. V.25 ANS) is sent--in this case, it is simply passed through the current PCMU encoding. Since both fax and modem calls can start with this sequence, it is not possible to determine that this is a fax call until step 9, where the V.21 fax preamble is detected.
ファックスコールが発生するようになりました。T.30 CEDトーン（別名V.25 Ans）は送信されます。この場合、現在のPCMUエンコードを通過するだけです。FAXコールとモデム呼び出しの両方がこのシーケンスで開始できるため、V.21 Fax Preambleが検出されるステップ9までこれがFAXコールであると判断することはできません。
Step 10:
ステップ10：
The terminating SIP UA does in fact support T.38 and, upon detecting the fax call, attempts to change to T.38. Consequently, it sends a re-INVITE to the originating Call Agent with an updated SDP indicating a switch to T.38.
終了SIP UAは、実際にはT.38をサポートし、FAXコールを検出すると、T.38に変更しようとします。その結果、T.38へのスイッチを示す更新されたSDPを使用して、元のコールエージェントに再インバイトを送信します。
INVITE sip:ca@ca-o.example.net SIP/2.0
...
Content-Type: application/sdp
Content-Length: 100
v=0 o=- 25678 753850 IN IP4 192.0.2.2 s=- c=IN IP4 192.0.2.2 t=0 0 m=image 1296 udptl t38
V = 0 O = -25678 753850 IN IP4 192.0.2.2 S = -C = IN IP4 192.0.2.2 T = 0 0 M =画像1296 UDPTL T38
Step 11:
ステップ11：
The originating Call Agent then sends a ModifyConnection command to the originating gateway:
その後、発信元のコールエージェントは、ModifyConnectionコマンドを発信ゲートウェイに送信します。
MDCX 1003 ds/ds1-1/1@gw-o.example.net MGCP 1.0 C: 1 I: 1
MDCX 1003 DS/DS1-1/1@GW-O.EXAMPLE.NET MGCP 1.0 C：1 I：1
v=0 o=- 25678 753850 IN IP4 192.0.2.2 s=- c=IN IP4 192.0.2.2 t=0 0 m=image 1296 udptl t38
V = 0 O = -25678 753850 IN IP4 192.0.2.2 S = -C = IN IP4 192.0.2.2 T = 0 0 M =画像1296 UDPTL T38
Step 12:
ステップ12：
The originating gateway changes to T.38 and sends back a success response with updated SDP:
発信元のゲートウェイはT.38に変更され、更新されたSDPで成功応答を送り返します。
200 1003 OK
200 1003 OK
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 13:
ステップ13：
The originating Call Agent sends a SIP 200 OK response with the updated SDP to the terminating SIP User Agent:
発信元のコールエージェントは、更新されたSDPを使用してSIP 200 OK応答を終了SIPユーザーエージェントに送信します。
SIP/2.0 200 OK
...
Content-Type: application/sdp
Content-Length: 167
v=0
o=- 25678 753850 IN IP4 192.0.2.1
s=-
c=IN IP4 192.0.2.1
t=0 0
m=image 3456 udptl t38
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 image udptl t38
Step 14:
ステップ14：
The terminating SIP User Agent receives the SIP 200 and sends a SIP ACK.
終了SIPユーザーエージェントはSIP 200を受け取り、SIP ACKを送信します。
Since the terminating SIP User Agent now has a RemoteConnectionDescriptor with "image/t38" as valid media, it can start exchanging T.38 with the originating gateway (and vice versa).
終了SIPユーザーエージェントには、有効なメディアとして「Image/T38」を備えたRemoteConnectionDescriptorがあるため、T.38の発信ゲートウェイと交換を開始できます（およびその逆）。
Steps 15, 16:
ステップ15、16：
The originating endpoint detects V.21 fax preamble. Even though the endpoint is already using "image/t38" for media, it generates a "t38(start)" event and notifies the Call Agent.
発信元のエンドポイントは、v.21ファックスのプリアンブルを検出します。エンドポイントは既にメディアに「Image/T38」を使用していますが、「T38（Start）」イベントを生成し、コールエージェントに通知します。
NTFY 3500 ds/ds1-1/1@gw-o.example.net MGCP 1.0 O: fxr/t38(start) X: 1
NTFY 3500 DS/DS1-1/1/gw-o.example.net mgcp 1.0 O：fxr/t38（start）x：1
Steps 17, 18:
ステップ17、18：
The Call Agent acknowledges the Notify command and issues a new (piggybacked) request for notification of the T38 event.
コールエージェントは、Notifyコマンドを認め、T38イベントの通知の新しい（ピギーバック）リクエストを発行します。
200 3500 OK . RQNT 1004 ds/ds1-1/1@gw-o.example.net MGCP 1.0 R: fxr/t38 X: 2
200 3500 OK。RQNT 1004 DS/DS1-1/1@GW-O.EXAMPLE.NET MGCP 1.0 R：FXR/T38 X：2
Step 19:
ステップ19：
The gateway acknowledges the command.
ゲートウェイはコマンドを認めます。
200 1004 OK
200 1004 OK
Steps 20-22:
ステップ20-22：
When the fax ends, the terminating SIP UA decides to tear down the call and hence sends a SIP BYE message, which the Call Agent responds to with a SIP 200.
FAXが終了すると、終了SIP UAはコールを取り壊すことを決定し、したがって、SIP Byeメッセージを送信します。これは、SIP 200で応答します。
Step 23:
ステップ23：
The originating endpoint also generates a "t38(stop)" event, which is notified to the Call Agent:
元のエンドポイントは、「T38（STOP）」イベントも生成します。これは、コールエージェントに通知されます。
NTFY 3502 ds/ds1-1/1@gw-o.example.net MGCP 1.0 O: t38(stop) X: 2
Step 24:
ステップ24：
The Call Agent acknowledges the Notify command:
コールエージェントは、notifyコマンドを確認します。
200 3502 OK
200 3502 OK
The fax call is now over. The Call Agent may now decide to change back to a voice codec, delete the connection, or do something different.
ファックスコールは終了しました。コールエージェントは、音声コーデックに戻って変更したり、接続を削除したり、違うことをしたりすることを決定する場合があります。
The MGCP fax package itself is not known to introduce any new security concerns. However, implementers should note that T.38 media is currently transported over UDP (UDPTL) or TCP in the clear and without any integrity protection. If for example security services are in place to protect RTP media streams, these will thus not be in effect for the T.38 media stream. If such lack of security is a concern, the fax LocalConnectionOptions allowing T.38 in this package SHOULD NOT be used, i.e., the "off" (or a new secure extension) fax LocalConnectionOption should be used.
MGCP Faxパッケージ自体は、新しいセキュリティ上の懸念を導入することは知られていません。ただし、実装者は、T.38メディアが現在、UDP（UDPTL）またはTCPを介して明確で、整合性保護なしで輸送されていることに注意する必要があります。たとえば、RTPメディアストリームを保護するためにセキュリティサービスが整っている場合、これらはT.38メディアストリームでは有効ではありません。このようなセキュリティの欠如が懸念事項である場合、このパッケージでT.38を許可するFAX LocalConnectionOptionsは使用しないでください。つまり、「オフ」（または新しい安全な拡張機能）Fax LocalConnectionOptionを使用する必要があります。
IANA has registered the following MGCP package:
IANAは次のMGCPパッケージを登録しました。
Package Title Name Version
------------- ---- -------
Fax FXR 0
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.
[RFC3435] Andreasen、F。およびB. Foster、「Media Gateway Control Protocol（MGCP）バージョン1.0」、RFC 3435、2003年1月。
[T38] ITU-T Recommendation T.38, "Procedures for real-time Group 3 facsimile communication over IP networks", March 2002.
[T38] ITU-Tの推奨T.38、「IPネットワーク上のリアルタイムグループ3ファクシミリ通信の手順」、2002年3月。
[RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple Capability Declaration", RFC 3407, October 2002.
[RFC3407] Andreasen、F。、「セッション説明プロトコル（SDP）シンプルな機能宣言」、RFC 3407、2002年10月。
[T30] ITU-T Recommendation T.30, "Procedures for document facsimile transmission in the general switched telephone network", July 2003.
[T30] ITU-Tの推奨T.30、「一般的なスイッチ付き電話ネットワークでのドキュメントファクシミリ送信の手順」、2003年7月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION Intioniation Protocol」、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
Acknowledgements
謝辞
Several people have contributed to the development of the MGCP fax package. In particular, the author would like to thank Bill Foster, Paul Jones, Gary Kelly, Rajesh Kumar, Dave Horwitz, Hiroshi Tamura, Rob Thompson, and the CableLabs PacketCable NCS focus team for their contributions.
数人がMGCP Faxパッケージの開発に貢献しています。特に、著者は、ビル・フォスター、ポール・ジョーンズ、ゲイリー・ケリー、ラジェシュ・クマール、デイブ・ホーウィッツ、田村ヒロシ、ロブ・トンプソン、ケーブルラブのパケットNCSフォーカスチームに貢献に感謝したいと思います。
Authors' Addresses
著者のアドレス
Flemming Andreasen Cisco Systems 499 Thornall Street, 8th Floor Edison, NJ 08837
フレミングアンドレアセンシスコシステム499 Thornall Street、8階エジソン、ニュージャージー08837
EMail: fandreas@cisco.com
David Hancock CableLabs 858 Coal Creek Circle Louisville, CO 80027
David Hancock Cablelabs 858 Coal Creek Circle Louisville、Co 80027
EMail: d.hancock@cablelabs.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、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への情報をお問い合わせください。