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.
この文書は、ファックスコールをサポートするメディアゲートウェイコントロールプロトコル（MGCP）パッケージを定義します。ファックスは、2つの異なる方法でサポートするコールのパッケージができます。最初のコールエージェントの制御下でのファックスリレーのためのITU-T勧告T.38を利用しています。もう一つは、ゲートウェイがFAX送信のための方法に決めるだけでなく、コールエージェントの関与なしにファックスコールの詳細を処理することができます。
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制御のゲートウェイを可能メディアゲートウェイコントロールプロトコル（MGCP）[RFC3435]のパッケージを定義します。パッケージには、2つの異なる方法でサポートされるファックス通話を可能にします。最初のコールエージェントの制御下で、ファックスリレーのために（[T38]を参照）UDPトランスポート層（UDPTL）またはTCPのいずれかを使用してITU-T勧告T.38を利用しています。もう一つは、ゲートウェイがFAX送信のための方法に決めるだけでなく、コールエージェントの関与なしにファックスコールの詳細を処理することができます。
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.
ファックスパッケージ定義は、第2節に提供され、そして第3節では、我々はそれを使用する方法を示す三のコールフローの例を示します。セキュリティの考慮事項は、IANAの考慮や参照に続いて、第4章に記載されています。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC2119 [RFC2119]に記載されているように解釈されます。
A package is defined for fax. The package defines new LocalConnectionOptions, events, and connection parameters as detailed below:
パッケージは、ファックスのために定義されています。下記のとおり、パッケージは新しい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):
新しいファックスLocalConnectionOptions（LCO）パラメータは、ファックスの取り扱いのために定義されています。コール・エージェントは、メディアゲートウェイに目的のファクス処理手順を示すために、このファックスLCOを提供しています。ファックスLCOは、最初に記載されている最も希望の手順で、好みの順目的のファクス処理手順のリストが含まれています。パラメータが明示的にコマンドに含まれている場合、ゲートウェイは成功するコマンドにリストされている手順の少なくとも一方を使用することができなければなりません。現在、リストは（これらの詳細は、2.1.4へのセクション2.1.1を参照）、以下の手順の一つ以上を示すことができます：
* 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：ファックスリレーのUDPTLまたはTCPのいずれかで使用T.38 [T38]とは、コールエージェントがそれを制御できます。手順を想定すると、使用することができます（2.1.1項を参照）、（2.2節を参照）T.38手順への切り替えは、ファックス検出時に開始され、「T38（スタート）」イベントが生成されます。セクション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.
*オフ：別のコーデックに切り替える可能性エコーキャンセレーション調整とを除いて、ファックスのために特別な手順を起動しないでください。
* 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.
*ゲートウェイ：ゲートウェイ制御をしようとコールエージェントの関与なしにファックス・コールを処理する方法を決定します。これは、ゲートウェイがファックスのための特別な何もしない場合も含まれます。したがって、定義によって、この手順は常にサポートすることができます。ゲートウェイは、ファックスの検出時に特別な手順を呼び出した場合、それは「gwfax（スタート）」は、このコールエージェントに通知するイベントを（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.
ファックス用に特別な手順を起動することができない終わるゲートウェイ「はnopfax（開始）」ファックスを検出すると、イベントを（セクション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.
ファックス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コマンドでは、ファックスLCO値のデフォルトは「ゲートウェイ」にします。 ModifyConnectionコマンドでは、接続の現在の値にファックスLCO値をデフォルトとします。 LocalConnectionOptionsが省略されている場合、またはファックスLCOはModifyConnectionコマンドに含まれていない場合したがって、接続の前のファックスLCO値は、コマンドの結果に影響を与えることなく保持されます。その結果、ゲートウェイは現在のファックスに特別な手順を適用されない場合があります。コールエージェントはコマンドがファックス手続きが適用された場合にのみ成功することを保証したい場合、コマンドは、明示的にファックス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」の使用を指定し、ModifyConnectionコマンドは、現在のファックスLCOなしではなくT.38はサポートがないことを示すRemoteConnectionDescriptorで受信されていることを前提としています。この場合、ModifyConnectionコマンドは成功しますが、T.38手順はもはやファックス検出したときに呼び出されません（「nopfax」イベントが生成されます）。コールエージェントは代わりに「厳格なT.38」に設定ファックスLCOを含めた、コマンドが失敗しただろう。
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
1.「ゲートウェイ」を選択されたであろうと、それが適用されている特別な手順をもたらした希望の場合、および
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".
ファックスLCOパラメータは、コロン、次に厳密T.38が「T38」として符号化される値は、セミコロンで区切られたリストに続いて、T（[RFC3435]あたりのパッケージ名接頭辞）キーワード「FX」として符号化されますルーズ0.38を「T38-ルーズ」、ゲートウェイは「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厳格FAXリレー（好ましい）またはゲートウェイの制御を示します。
L: a:PCMU;G729, fxr/fx:t38;gw
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、それによって、ゲートウェイが使用するメディアパラメータに決定させること、の両方LocalConnectionOptionsとRemoteConnectionDescriptorを省略するのCreateConnectionコマンドを可能にすることに留意すべきです。 T.38ファックスパッケージがサポートされている場合、ゲートウェイは、このようなケースでは、音声またはT.38ファックスリレーのいずれかを行うことを選択することができます。ほとんどの場合、コールエージェントが使用する1つまたは他を必要とし、ひいてはそれがの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:
能力を監査すると、ファックスLCOは、サポートされているファックス処理パラメータをセミコロンで区切ったリストで返されることがあります。彼らは常に暗示しているような値「T38」、「T38-緩い」は、「オフ」、および「GW」などのリストから省略されるかもしれません。機能が監査されている場合は、次の例に示すように、追加のパラメータは、これらの追加のパラメータを返すべきで実装するゲートウェイ：
A: a:image/t38, fxr/fx:mypar, ...
：：画像/ T38、FXR / FX：mypar、...
In the following subsections, we provide additional detail on the above-defined fax procedures.
以下のサブセクションでは、我々は、上記に定義されたファックスの手順に関する追加の詳細を提供します。
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がサポートされているかどうか分からないし、ファックス検出時にT.38への切り替えを試みても安全ですので、か。このジレンマ、SDP単純能力宣言拡張[RFC3407]を使用して（サポートされている場合）T.38のための機能情報を改善するために含まれなければなりません。その他の機能情報は関係なく、コールエージェントが接続処理コマンドでそれらの使用を許可するかどうかの、同様に含まれています。コールエージェントLCOがそれらを使用することはできませんので、実際にこれらを使用するため、後続の試みはもちろん、例えば、成功しないことがあります。 ：RFC 3407 [RFC3407]で指定されるように、両方の電流（オーディオ）を含めることに注意して潜（T.38）機能 - 次の例では、RFC 3407 [RFC3407]能力記述子を示します
m=audio 3456 RTP/AVP 18 a=sqn: 0 a=cdsc: 1 audio RTP/AVP 18 a=cdsc: 2 image udptl t38
M =オーディオ3456 RTP / AVP 18 = SQN = CDSC 0 A：1つのオーディオRTP / AVP 18 = CDSC：2画像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付属書D [T38]を参照してください。
Upon fax detection, a gateway that has successfully been instructed to use one of the T.38 procedures will:
ファックス検出すると、成功しますT.38の手順のいずれかを使用するように指示されたゲートウェイ：
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).
（メディアチャネルが既にT.38を使用していない限り）1 T.38 FAXリレーの手順を開始し、送信の両方のメディアチャネルをミュートおよび方向を受け取ります。
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を使用していない場合）、実際のメディアの変更を開始するためにCallエージェントからのさらなる指示を待ちます。
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
CallエージェントはLocalConnectionOptionsにおける符号化方法LocalConnectionOptions含まないが、「M =」行を含むRemoteConnectionDescriptorとModifyConnectionコマンド（領収書として記載されている「画像/ T38」とそれにModifyConnectionコマンドを送信することにより、培地交換を実行するためにゲートウェイに指示しますMIMEタイプ「イメージ/ T38」で）同じことを達成するであろう。通常MGCPコーデックネゴシエーション手順に従って（[RFC3435]セクション2.6を参照）、もし
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).
RemoteConnectionDescriptorは、それが成功するコマンドのために許容されるメディアフォーマットとして「画像/ T38」と「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手順を開始したゲートウェイに送信ModifyConnectionコマンドに含まれていなかった場合、それはライン「画像/ T38をリスト「= M」最後に受信RemoteConnectionDescriptorが含まれていないこと、（実際にはありそうな）が可能です「許容されるメディアフォーマットとして。その場合、エンドポイントは、他の側にT.38メディアを送信することはできません。エンドポイントではなく、許容されるメディア形式とサポートされているトランスポート・プロトコル（UDPTLまたはTCP）のように、「画像/ T38」が含まれている更新RemoteConnectionDescriptorを待たなければなりません。許容されるRemoteConnectionDescriptorを受信したときにT.38ファックス手順が継続します。許容されるRemoteConnectionDescriptorは「画像/ T38」MIMEタイプ（通常SDP構文を使用して）、サポート転送プロトコル（UDPTLまたはTCP）を有する「M =」行を含みます。 「画像/ T38」または許容RemoteConnectionDescriptor、「T38（停止）」または「T38のために切り替えるためにゲートウェイを指示するいずれかのコール・エージェントを待っている間にファックスコールが（例えば、原因ファックスタイムアウトに）失敗した場合（失敗）」イベントが生成されなければなりません。 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).
私たちは今、コールエージェントは、進行中のT.38手順を中止した時間にT.38手順が開始された時点として「時間t38init」、および点として「時間t38abort」を定義します。コールエージェントが一度にt38abortが指示またはエンドポイントは、時間t38initに直前に使用されていた1つのまたは複数のコーデックに戻すことができた場合、エンドポイントは、時間t38init以前に発行された最新のLocalConnectionDescriptorを模倣するメディア・ストリーム・パラメータを使用すべきです。たとえば、IPアドレスとUDPポート、使用ペイロード形式とそのペイロードタイプ・マッピングは、すべての時間t38init前と同じにする必要があります。これは、可能な限り迅速にするフォールバックを可能にします。 LocalConnectionDescriptorは、通常通りに戻され、すなわち、1つまたは複数のパラメータが、発行された最後LocalConnectionDescriptor以降に変更された場合にのみ（例えば、T.38のLCDが発行された、またはオーディオ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コールを検出すると、特別なファックスの取り扱いを開始することができます。この特別なファックスの取り扱いの詳細は、このドキュメントの範囲外です。しかし、特別なファックスの取り扱いを使用するために、それに対するサポートはLocalConnectionDescriptorとRemoteConnectionDescriptor（これは、RTPベースのT.38の使用を含む）を介して関連するパラメータを渡すことと認識して他方の側と交渉しなければなりません。他の側は希望を扱う特殊なファックスのサポートを示していない場合、ゲートウェイはそれを開始することを試みてはいけません。特別ファックスの取り扱いが開始されると、「gwfax（スタート）」イベントは、それによってまだファックスする実際の変更を知らされながらコールエージェントとゲートウェイ制御モード間で異なるためにコールエージェントを有効にする、生成されなければなりません。ファックスの特別ゲートウェイの処理は、「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.
「オフ」の手順を使用して、ゲートウェイは、例えば、T.38は、ファックスを検出した場合、特別なファックスプロシージャを起動しないであろう。しかし、ゲートウェイは依然としてローカルエコーキャンセルを調整および/または必要に応じて別のコーデックに切り替えることができます。また、「nopfax（スタート）」イベントが生成されなければなりません。対応する「停止」イベントは、しかし、ではないでしょう。
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.
「停止」イベントを生成すると、ゲートウェイがファックス通話が終了したときに、メディアストリームを処理することを伴う、推測しなければならなかったことを意味します。 「オフ」モードを使用する場合しかし、このような処理が発生しないと予想されます。
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は何手順（S）他側支持体上の情報を提供します。以下の規則が使用する手順を決定するために使用されます。
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).
コールエージェントは、現在のコマンドのためにファックスLocalConnectionOptionsに指定されたどのような1.に付着しなければなりません。ゲートウェイは、オプションのいずれかを満たすことができない場合、コマンドが失敗（エラーコード532 - LocalConnectionOptionsでサポートされていない値（S）が推奨します）。
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.両方のファックスLocalConnectionOptionsとRemoteConnectionDescriptorが提供されている場合、選択された手順は両面でサポートしなければならない - これは、現在、「厳格なT.38」のための唯一の問題です。手順は、以下の場合、リモート側によって満たすことができます。
* the relevant MIME media type, e.g., "image/t38", is included in the "m=" line in the RemoteConnectionDescriptor, or
*関連するMIMEメディアタイプ、例えば、「画像/ 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.
ゲートウェイは、ファックス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.コール・エージェントはどんなファックス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.コール・エージェントはどんなファックスLocalConnectionOptionsが含まれていませんでしたが、RemoteConnectionDescriptorが含まれている場合、ゲートウェイは、手順を選択するには、ルール2に従わなければなりません。そうすることで、デフォルトのファックス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. Aは、以前RemoteConnectionDescriptorを選択することができますどのような手順には影響しません受け取りました。現在のコマンドに付属のRemoteConnectionDescriptorは、手続きの選択に影響を与えます。しかし、特定のタイプのメディアを送信するために（例えば、「画像/ 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).
それは、「T38-緩い」含むコマンドを成功するのに対し、原則1につき、唯一の標準T.38ファックスリレーをサポートするゲートウェイは、唯一のFAXオプション「mypar」を含むコマンドを失敗し、「GW」、「オフ」 、または全くファックス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.
「T38」とT.38機能もT.38メディアストリームでもないとRemoteConnectionDescriptorに設定LCOを取り扱うファックスでのCreateConnectionコマンドを受信ゲートウェイサポートT.38は、LCOを扱うファックスが含まれていたルール2あたりに失敗します「T38-緩い」、「GW」または「オフ」、コマンドが成功しただろう、と手順のいずれかが選択されている可能性が含まのいずれか。
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」（すなわち、厳密）にセット処理でのCreateConnectionコマンドが正常に実行されたと仮定する。ゲートウェイは今LCOを扱うファックスすることなく、しかし、T.38機能や「画像/ T38」と、メディアストリームもないRemoteConnectionDescriptorでModifyConnectionコマンドを受信した場合、ルール1は、その場合には効果がないため、コマンドは（成功します）。しかし、ルール2及び4につき、代わりに任意のT.38手順がありません。コールエージェントは代わりに「T38」に設定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への切り替えは、発信および終端ゲートウェイのいずれか一方または両方によって開始することができ、従って、実装がこれを処理するために準備しなければならないことに留意すべきです。 T.38への切り替えが有する前に、これは両側が発信側ファックストーン（CNG）を呼び出し生成し、終端ファックスV.21ファックスプリアンブルを検出した場合、例えば起こり得るスイッチを開始する場合を含む（[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コールは、使用されているFAX送信方法に応じて（例えば、V.21ファックスプリアンブル、T.30 CNGトーン、またはV.8信号）は、いくつかの異なる手段によって検出することができます。このパッケージの実装は、最低でもV.21ファックスプリアンブルに基づいて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.8のANSamのとV.34ファックスと共に使用されるCM信号、ひいてはV.34のファックスは、G3（14.400 BPS）以下にdownspeedうがサポートされていない使用T.38バージョン2（またはそれ以前）。また、非ファックスコールのT.30 CNGトーンを生成するモデムの数まれなケースが報告されています。そのようなモデムは、ファックスのための偽のトリガを生成します。上記の結果として、T.30 CNGベースのファックス検出をサポートし、このパッケージの実装が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厳格なモードの使用は、他のエンドポイントは、T.38ファックスリレー情報とRFC 3407 [RFC3407]の機能の説明を生成することが知られている環境では理想的です。 T.38ファックスリレー機能のないRemoteConnectionDescriptorは、このような環境の中で受信された場合、他の側がT.38をサポートしていないことが知られており、順番ににつながる可能性がT.38（に切り替えるので、失敗した試みファックス・コールに失敗した）を回避することができます。それは他のエンドポイントは、RFC 3407 [RFC3407]の能力記述子をサポートするかどうかは知られていない場合は、トレードオフがそれほど明確ではありません。利点は、他の側がそれをサポートしていることが分かっている場合T.38への切り替えのみが試行されるということですが、T.38のサポートを示すものではありませんエンドポイントはまだそれをサポートすることが可能。しかし、T.38は、順番に、低帯域幅コーデックや損失の多いネットワークと不要なファックスの失敗につながる可能性がある、これらと一緒に使用されることはありません。
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 looseモードの使用はT.38厳格な、しかし、長所と短所が逆転していると同じ配慮を必要とします。ピアエンドポイントがT.38をサポートしていない場合は、T.38緩いモードはまだ順番に失敗したFAXコールにつながる可能性がある、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厳格またはT.38緩いモードのいずれかを使用する単一の良い答えはありません。それが原因Tに失敗したスイッチに潜在的にファックスコールが潜在的にファックスコールが失敗させる対による（T.38がそうでなければサポートされている）機能表示の不足のために失敗させることの間のトレードオフだけでなく、関連するエンドポイントの能力に依存します0.38（実際にはT.38がサポートされていなかったため）。コールエージェントは、ピアエンドポイントがT.38かをサポートしているかどうかを判断するために、[RFC3407]の能力記述子RFC 3407を超えた手段を有していてもよいことに留意すべきです。 SIPは、他のピア（例えば、コールエージェントまたは他のSIPデバイス）とのシグナリングプロトコルとして使用する場合、例えば、SIP OPTIONSメソッドは、かどうかを学習するために使用することができます
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がサポートされています。 T.38のサポートが示されていないときのコールエージェントが冗長性を備えた高帯域幅コーデックの使用を許可する場合も、ファックスコールはまださえ無視できないパケット損失のネットワークで、T.38を使用せずに成功することがあります。
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つのピアエンドポイントがメソッドを取り扱う同じファックスをサポートしている場合、唯一ファックスハンドリング特別があるだろう。実際の方法の詳細は、ベンダーまで完全であることに注意してください。また、2つのピアのエンドポイントは、ファックス処理のための同じメソッドをサポートしたりしていない場合、このメソッドは、交換SDPに示されていない場合は、かわりに扱う特別なファックスがないことに注意してください。さらに、コールエージェントは、FAX送信が開始され、「nopfax（スタート）」イベントが発生するまでこれが事実であることを認識しません。
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：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.
*ゲートウェイ：ゲートウェイ制御手順常にサポートすることができます。ゲートウェイ制御手順は、特別なファックス手順と、さらにオプション（オフを除く）に提供されているが生じていた場合は、これらの手順が試みられます。これらの手順のどちらもサポートすることができた場合は、代わりに特別なファックスの手順はありません。
* Off: The off procedure can always be supported. Any procedure specified after this one will not be selected.
*オフ：オフの手順は、常にサポートすることができます。この1の後に指定された手順が選択されることはありません。
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:
ゲートウェイは、起動、停止、または失敗するかのいずれかファックス手続きを取り扱う際に、「制御ファックスゲートウェイ」イベントが発生します。イベントが「gwfax」として符号化され、そしてのみObservedEventsに適用される次のイベントパラメータが、定義されています。
* 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（停止）」または「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.
*ストップ：ゲートウェイが終了したファックスの手順を制御し、ゲートウェイがエラーを検出しませんでした。これは必ずしも正常に送信ファクスを意味するものではないことに注意してください。それは単にゲートウェイ制御のファックス手続きが終了したことを示し、手続き自体は、何らかのエラーが発生しませんでした。接続のためのメディアパラメータは、ゲートウェイ扱わファックス手続き開始前の通りです。
* 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.
*失敗：ゲートウェイ制御のファックス手順が異常終了しました。問題のいくつかの種類は、ゲートウェイ制御のファックス手順で遭遇し、手続きは終了しました。メディアパラメータは、ゲートウェイ扱わファックス手続き開始前の通りです。
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」イベントはObservedEventsに追加のパラメータを用いてパラメータ化されてもよく、しかし、上記のパラメータのいずれかが供給される第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:
場所に手続きを取り扱う特別なファックスやファックスコールが検出されなかったがあった場合、「特別なファックスの取り扱い」イベントが発生しません。これは特別なファックスの取り扱い手順が要求されなかったので、どちらか（「オフ」を含む）またはネゴシエーションがサポートされている手順を扱う特別なファックスの結果発生する可能性があります。イベントが「nopfax」、およびのみ、定義されるObservedEventsに適用される次のイベントパラメータとして符号化されます。
* 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).
*開始：手順を扱う特別なファックスしかしファックス・コールは、現在検出され、所定の位置にありません。コールエージェントは成功したファックス・コール（別のコーデックに、例えば、スイッチ）を確保するために、さらにコマンドを発行する必要があります。
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」イベントがObservedEvents上の追加のパラメータでパラメータ化されるかもしれない、しかし上記のパラメータが供給された第1パラメータであることが推奨されます。未知のパラメータを無視しなければなりません。それが唯一のファックス通話の開始を検出すると、このイベントは、現在、「停止」または「失敗」をパラメータ化することができないことに注意してください。
The following example illustrates the encoding of the "nopfax" event:
次の例は、「nopfax」イベントのエンコーディングを示します。
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ファックスリレーのいずれかの手順（厳密か緩い）は、起動、停止、または失敗時に「T.38ファックスリレー」イベントが発生します。イベントは、「T38」として符号化され、そしてのみObservedEventsに適用される次のイベントパラメータが、定義されています。
* 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.
*開始：ファックスコールエンドポイントで検出されたとコールエージェント制御のT.38 FAXリレー手続きが開始されました。コール・エージェントは、彼らがすでに行う場合を除き、「画像/ T38」メディアフォーマットの使用を開始するために、接続のそれぞれの側を変更する必要があります。エンドポイント（税込上の任意の接続に関わらず、現在の符号化方式の、コールエージェント制御T.38リレー手順の使用が有効である限り、イベントがFAXコール検出時に生成される、ということに注意してください。「画像/ T38 「）。 「T38（スタート）」イベントに関係なく、それがその後の要求イベントリストに再度要求されているかどうかの、ファックスコールあたりのエンドポイントで、最高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ファックスリレーの手続きが終了し、ゲートウェイがエラーを検出しませんでした。これは必ずしも正常に送信ファクスを意味するものではないことに注意してください。それは単にコールエージェント制御のT.38 FAXリレー手続きが終了したことを示し、手続き自体は、何らかのエラーが発生しませんでした。コール・エージェントは、接続の各側面のためのメディアパラメータを変更することがあります。ゲートウェイ制御ファックス手順ケースとは対照的に、そのようなコーデックのようなメディアパラメータが自動的にファックス通話の開始前に、それらの値に戻らないことに留意されたいです。しかし、エコーキャンセル及びサイレンス抑制は[RFC3435]セクション2.3.5の手順ごとに行います。 「T38（停止）」イベントは、対応する「T38（スタート）」問題のファックス・コールのためのイベントが以前に生成された場合を除き、生成してはなりません。
* 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 FAXリレー手順が異常終了しました。コールエージェント制御のT.38ファックスリレーの手順で問題のいくつかの種類が検出されました、そして手続きが終了しました。コール・エージェントは、接続の各側面のためのメディアパラメータを変更することがあります。ゲートウェイ制御ファックス手順ケースとは対照的に、そのようなコーデックのようなメディアパラメータが自動的にファックス通話の開始前の状態に戻らないことに留意されたいです。しかし、エコーキャンセル及びサイレンス抑制は[RFC3435]セクション2.3.5の手順ごとに行います。 「T38（失敗）」のイベントが対応する「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」イベントは、しかし、上記のパラメータのいずれかが供給される第1パラメータであることが推奨され、追加のパラメータでパラメータ化されるかもしれません。未知のパラメータを無視しなければなりません。
The following example illustrates the encoding of the "t38" event:
次の例は、「T38」イベントのエンコーディングを示します。
O: fxr/t38(start) O: fxr/t38(stop, foobar)
O：FXR / T38 O（開始）：FXR / T38（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.
送信され、受信したパケットとオクテットを測定し、接続のための接続パラメータは、ファックスが同様に処理するためのパケットとオクテットを含まなければなりません。ファックスの進行中にT.38が使用される場合到着間ジッタと平均伝送遅延計算は、しかし、例えば、実行されなくてもよいです。計算はRTPベースのメディア・ストリームに戻る変更することにより、例えば、再開することができるまで、このような場合には、到着間ジッタ及び平均伝送遅延の計算は、単に懸濁させます。
In addition to these connection parameters, the fax package defines the following connection parameters, which gateways MAY support:
これらの接続パラメータに加えて、ファックスパッケージは、ゲートウェイがサポートする可能性がある、以下の接続パラメータを定義します。
Number of fax pages sent (PGS):
（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.
接続の人生のためのエンドポイントによって送られたファックスページの累積数。パラメータは、「PGS」としてエンコードされ、提供された値は、最大9進数の文字列です。
Number of fax pages received (PGR):
ファックスページ数は（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, ...
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付属書D [T38]はSDPで交渉することができるT.38パラメータの数を定義します。現在、T.38は、それぞれの側が同じ値を使用するために持っているかどうか、これらのパラメータのそれぞれが交渉されるかまたは特定の手順を指定していません。そこで、ここではそのような定義と手順を追加することを検討しました。しかし、T.38が競合の定義や手続きにつながる可能性があり、上記是正することが期待されます。それを避けるために、我々は代わりにT.38附属書Dパラメータは、宣言や交渉さのいずれかに分類し、我々はそのような定義をマップする方法についてのガイドラインを提供しているT.38のためのオファー/アンサー[RFC3264]セクションの存在を仮定し、ここで定義されたMGCPファックスパッケージへの手順。
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）を含んでいてもよいし、今度はその応答でLocalConnectionDescriptor（SDP）を生成することがあり、接続処理コマンド（例えば、のCreateConnectionとModifyConnection）の概念で動作しません。
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の手順に従うと、そのLocalConnectionDescriptorもたらす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とModifyConnectionコマンドを受信すると、これは最初のオファーに対する答えにするか、新しいプランに対応するかどうかを判断することはできません。彼らはどちらかの方向に独立して指定することができるので、これは、宣言のパラメータの問題ではありません。交渉されたパラメータは、しかし、いくつかの検討が必要です。
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エンドポイントは、それがどのような状況を知らないので、それは「オファー側」検証チェックを実行することはできません。同様に、任意の必要な交渉が実際に行われることを確保するためには、オファーと、着信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に応答して）最初のオファーは（SDPとのCreateConnectionに応答して）ファックスバージョン2、及び答えが含まれている場合、例えば、ファックスバージョン0を含んでいた、（SDPと）、対応するModifyConnectionコマンドがもたらしますまた、ゼロに設定ファックスバージョンで更新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のないModifyConnectionを考慮する必要があります。生成された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アドレスとポートを使用し続けるべきで、ネットワークアドレス変換（NAT）変更から、とファイアウォールの相互作用。エンドポイントが正当な理由がある場合は、それがこの勧告に従わないことを選択することができます。
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.
エンドポイントがUDPTLまたはTCPのRTPオーディオ及びT.38に同じポートを使用する場合、別のタイプ（RTPオーディオ）のパケットを期待しながら、いずれかのタイプ（例えば、T.38）のパケットが受信されてもよいです。任意の時点で予想されているタイプを示すための明示的なシグナリングがあるので、これは何の問題も生じていません。換言すれば、受信機は、受信された所与のパケットは、RTP音声パケット又はT.38 UDPTL / TCPパケットであるかどうかを決定する必要のあるデマルチプレクサとして動作しません。受信機は、単に通常通り着信パケットを処理します。 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は」一度誤っ「T38maxBitRate」（小文字の「M」）としてIANAに登録されました。 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後数（0または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ファックスコールを示しています。二つ目は、両側の複数の異なるオプションの使用を示します。 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]を介して通信発信および着信コールを取ります。また、発信元ファックス装置は、早期（すなわち、プレ1993）ファックスの典型である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| | | | <- 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:
コールエージェントはPCMUメディアエンコーディングを使用し、厳格なコールエージェント制御のT.38手順を使用するように指示し、ゲートウェイにのCreateConnectionコマンドを発行します。その結果、コールエージェントは、「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
CRCX千ds/ds1-1/1@gw-o.example.net MGCP 1.0 C：1 L：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
V = 0 0 = - C = IN IP4 192.0.2.1 T = 0、M =オーディオ3456 RTP / AVP 0 = SQN - IP4 192.0.2.1 S = IN 25678 753849：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像UDPTLのT38
Step 3:
ステップ3：
The originating Call Agent sends a SIP INVITE message with the SDP to the terminating Call Agent.
発信エージェントは、SIPを終端するコールエージェントにSDPをINVITEメッセージを送信します。
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:
着呼エージェントはPCMUメディアエンコーディングを使用し、厳格なコールエージェント制御のT.38手順を使用するように指示し、終端ゲートウェイへのCreateConnectionコマンドを発行します。その結果、コールエージェントは、「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
CRCX 2000 ds/ds1-1/2@gw-t.example.net MGCP 1.0 C：2 L：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
V = 0 0 = - C = IN IP4 192.0.2.1 T = 0、M =オーディオ3456 RTP / AVP 0 = SQN - IP4 192.0.2.1 S = IN 25678 753849：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像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 Callエージェント制御手順を使用することができます。終端ゲートウェイはまた、能力情報を含むその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
V = 0 0 = - C = IN IP4 192.0.2.2 T = 0、M =オーディオ1296 RTP / AVP 0 = SQN - IP4 192.0.2.2 S = IN 25678 753849：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像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 ACKを送信発信エージェントにSIP 200 OK応答を返す（図示せず）。
Step 7:
ステップ7：
The originating Call Agent in turn sends a ModifyConnection command to the originating gateway:
順番に発信エージェントは発信ゲートウェイにModifyConnectionコマンドを送信します。
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
V = 0 0 = - C = IN IP4 192.0.2.2 T = 0、M =オーディオ1296 RTP / AVP 0 = SQN - IP4 192.0.2.2 S = IN 25678 753849：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像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).
ModifyConnectionコマンドは、以前に送られたLocalConnectionOptionsを繰り返していません。限りファックスの取り扱いに関しては、ゲートウェイは、したがって、現在のファックス処理手順、すなわち、厳密Callエージェント制御T.38を継続して使用しようとします。能力情報は、他の側がT.38をサポートして示しているので、ゲートウェイは、実際には、厳密なコールエージェント制御のT.38手順を使用することができるようになります。 （strictモードがサポートされていない可能性があるので）そこRemoteConnectionDescriptorでT.38のための任意のサポートされていなかった場合、このコマンドは、まだ成功しているだろう、しかし、特別なファックスの取り扱い手順はないだろう。
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エンコードを通過させます。両方のファックスモデムコールがこの順序で開始することができるので、V.21ファックスプリアンブルが検出されるステップ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（スタート）」イベント、およびコールエージェントに通知を生成します。
NTFY 2500 ds/ds1-1/2@gw-t.example.net MGCP 1.0 O: fxr/t38(start) X: 20
MGCP 1.0 O ds/ds1-1/2@gw-t.example.net NTFY 2500：FXR / T38（開始）X：20
Step 12:
ステップ12：
The Call Agent acknowledges the Notify command:
コール・エージェントは通知コマンドを認識します：
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@gw-t.example.net MGCP 1.0 C：2 I：2 L：画像/ 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
V = 0 0 = - IP4 192.0.2.2 S = IN 25678 753850 - C = IN IP4 192.0.2.2 T = 0、M =画像1296 UDPTLのT38のA = SQN：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像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".
ゲートウェイの現在のRemoteConnectionDescriptor以来（LocalConnectionDescriptorとは対照的に、ここで返される）ことに注意してください終端ゲートウェイは、まだメディアをミュートされ、現在は/画像」で更新RemoteConnectionDescriptorを待っている、有効な符号化方式として、「画像/ T38」が表示されません。 T38" 。
Step 15:
ステップ15：
The terminating Call Agent sends a re-INVITE to the originating Call Agent with the updated SDP.
着呼エージェントが更新されSDPに発信エージェントに再INVITEを送信します。
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
V = 0 0 = - IP4 192.0.2.2 S = IN 25678 753850 - C = IN IP4 192.0.2.2 T = 0、M =画像1296 UDPTLのT38のA = SQN：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像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
V = 0 0 = - IP4 192.0.2.1 S = IN 25678 753850 - C = IN IP4 192.0.2.1 T = 0、M =画像3456 UDPTLのT38のA = SQN：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像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).
発信エージェントが順番にSIP ACKを送信終了のコールエージェントへの更新SDPとSIP 200 OK応答を送信し（図示せず）。
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
V = 0 0 = - IP4 192.0.2.1 S = IN 25678 753850 - C = IN IP4 192.0.2.1 T = 0、M =画像3456 UDPTLのT38のA = SQN：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像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.
終端ゲートウェイは、現在有効なメディアとして「画像/ T38」とRemoteConnectionDescriptorを有しているので、元のゲートウェイとT.38交換を開始することができます。
Steps 21, 22:
22、21ステップ：
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ファックスプリアンブルを検出します。エンドポイントは、すでにメディアの「画像/ T38」を使用しているにもかかわらず、それが「T38（スタート）」イベントを生成し、コールエージェントに通知します。
NTFY 3500 ds/ds1-1/1@gw-o.example.net MGCP 1.0 O: fxr/t38(start) X: 1
MGCP 1.0 O ds/ds1-1/1@gw-o.example.net NTFY 3500：FXR / T38（開始）X：1
Steps 23, 24:
24、23ステップ：
The Call Agent acknowledges the Notify command, then issues a new request for notification of the "t38" event.
コールエージェントが通知コマンドを認識し、その後、「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:
27、26ステップ：
When the fax ends, a "t38(stop)" event is generated by the terminating endpoint, which is notified to the Call Agent:
ファックスが終了すると、「T38（停止）」はイベントがコールエージェントに通知され、終端エンドポイントによって生成された場合：
NTFY 2501 ds/ds1-1/2@gw-t.example.net MGCP 1.0 O: t38(stop) X: 21
MGCP 1.0 O ds/ds1-1/2@gw-t.example.net NTFY 2501：T38（ストップ）X：21
Step 28:
ステップ28：
The Call Agent acknowledges the Notify command:
コール・エージェントは通知コマンドを認識します：
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（ストップ）」コールエージェントに通知されるイベントを生成します。
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:
コール・エージェントは通知コマンドを認識します：
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の手順の間の選択を与えられるのに対し、この例では、発信側ゲートウェイは、ゲートウェイ・プロシージャを使用するように指示されます。さらに、元のファクス機が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:
コールエージェントはPCMUメディアエンコーディングを使用すると、ゲートウェイ・プロシージャを使用するように指示し、ゲートウェイにのCreateConnectionコマンドを発行します。その結果、コールエージェントは「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
MGCP 1.0 C ds/ds1-1/1@gw-o.example.net CRCX 1：1000 L：および：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
V = 0 0 = - C = IN IP4 192.0.2.1 T = 0、M =オーディオ3456 RTP / AVP 0 = SQN - IP4 192.0.2.1 S = IN 25678 753849：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像はT38 UDPTL =のX-FaxScheme：123
We assume the gateway supports some other fax scheme, and it indicates this by including an attribute "X-FaxScheme: 123".
私たちは、ゲートウェイは、いくつかの他のファックススキームをサポートして想定し、それが属性「X-FaxScheme：123」を含むことによって、これを示しています。
Step 3:
ステップ3：
The originating Call Agent sends a SIP INVITE message with the SDP to the terminating Call Agent.
発信エージェントは、SIPを終端するコールエージェントにSDPをINVITEメッセージを送信します。
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:
終端コール・エージェントはPCMUメディアエンコーディングを使用し、ゲートウェイプロシージャまたは厳密呼エージェント制御T.38手順のいずれかを使用するように指示し、終端ゲートウェイへのCreateConnectionコマンドを発行します。その結果、コールエージェントは、両方の「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
CRCX 2000 ds/ds1-1/2@gw-t.example.net MGCP 1.0 C：2：PCMU、FXR / FX：GW; T38 Q：の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
V = 0 0 = - C = IN IP4 192.0.2.1 T = 0、M =オーディオ3456 RTP / AVP 0 = SQN - IP4 192.0.2.1 S = IN 25678 753849：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像はT38 UDPTL =の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が含ま反対側も同様に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
V = 0 0 = - C = IN IP4 192.0.2.2 T = 0、M =オーディオ1296 RTP / AVP 0 = SQN - IP4 192.0.2.2 S = IN 25678 753849：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像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 ACKを送信発信エージェントにSIP 200 OK応答を返す（図示せず）。
Step 7:
ステップ7：
The originating Call Agent in turns sends a ModifyConnection command to the originating gateway:
ターンで発信エージェントは発信ゲートウェイにModifyConnectionコマンドを送信します。
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
V = 0 0 = - C = IN IP4 192.0.2.2 T = 0、M =オーディオ1296 RTP / AVP 0 = SQN - IP4 192.0.2.2 S = IN 25678 753849：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像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.
ModifyConnectionコマンドは、以前に送られたLocalConnectionOptionsを繰り返していません。限りファックスの取り扱いに関しては、ゲートウェイは、したがって、すなわち、ゲートウェイ手順、現在のファックス処理を継続して使用しようとします。 「X-FaxScheme：123」SDP情報には、次のサポートを示すものではありませんが返され、したがって元のゲートウェイは、このコールのための手続きを取り扱う特別なファクスを呼び出しません。
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コールが検出された場合、特別なファックスの取り扱い手順は発生しません。
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トーンは、これによりファックス呼を示す、発信元ファックスによって生成されます。ゲートウェイはT.38モードのいずれかを使用していた、あるいはそれが他の側で手続きを扱う特殊なゲートウェイのサポートを交渉していた場合、「T38（開始）」または「gwfax（スタート）」イベントが今生成されていた場合そしてT.38への切り替え（または特別なゲートウェイの処理）が開始することができます。終端ゲートウェイとの交渉がファックスのための特別な何もしていない発信ゲートウェイになったので、そのようなイベントが発生しません。代わりに、「nopfax（スタート）」イベントが今生成されますが、コールエージェントは、このイベントを要求していないので、それは検出されず、したがって、コールエージェントに報告されていません。その結果、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.
その後、（V.25 ANS別名）T.30 CEDトーンが発生 - この場合には、それは単に現在PCMUエンコードを通過させます。両方のファックスモデムコールがこの順序で開始することができるので、V.21ファックスプリアンブルが検出されるステップ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（スタート）」イベント、およびコールエージェントに通知を生成します。
NTFY 2500 ds/ds1-1/2@gw-t.example.net MGCP 1.0 O: fxr/t38(start) X: 20
MGCP 1.0 O ds/ds1-1/2@gw-t.example.net NTFY 2500：FXR / T38（開始）X：20
Step 13:
ステップ13：
The Call Agent acknowledges the Notify command:
コール・エージェントは通知コマンドを認識します：
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@gw-t.example.net MGCP 1.0 C：2 I：2 L：画像/ 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
V = 0 0 = - IP4 192.0.2.2 S = IN 25678 753850 - C = IN IP4 192.0.2.2 T = 0、M =画像1296 UDPTLのT38のA = SQN：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像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有効な符号化方式として、「画像/ T38」が表示されませんでした（LocalConnectionDescriptorとは対照的に、ここに戻っ）以来、終端ゲートウェイは、まだメディアをミュートされ、現在は「で更新RemoteConnectionDescriptorを待っていることに注意してください画像/ T38" 。
Step 16:
ステップ16：
The terminating Call Agent sends a re-INVITE to the originating Call Agent with the updated SDP.
着呼エージェントが更新されSDPに発信エージェントに再INVITEを送信します。
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
V = 0 0 = - IP4 192.0.2.2 S = IN 25678 753850 - C = IN IP4 192.0.2.2 T = 0、M =画像1296 UDPTLのT38のA = SQN：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像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
V = 0 0 = - IP4 192.0.2.1 S = IN 25678 753850 - C = IN IP4 192.0.2.1 T = 0、M =画像3456 UDPTLのT38のA = SQN：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像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).
発信エージェントが順番にSIP ACKを送信終了のコールエージェントへの更新SDPとSIP 200 OK応答を送信し（図示せず）。
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
V = 0 0 = - IP4 192.0.2.1 S = IN 25678 753850 - C = IN IP4 192.0.2.1 T = 0、M =画像3456 UDPTLのT38のA = SQN：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像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.
終端ゲートウェイは、現在有効なメディアとして「画像/ T38」とRemoteConnectionDescriptorを有しているので、元のゲートウェイとT.38交換を開始することができます。
Steps 22, 23:
23、22ステップ：
When the fax ends, a "t38(stop)" event is generated, which is notified to the Call Agent:
ファックスが終了すると、「T38（ストップ）」イベントが発生した場合、コールエージェントに通知されます。
NTFY 2501 ds/ds1-1/2@gw-t.example.net MGCP 1.0 O: t38(stop) X: 21
MGCP 1.0 O ds/ds1-1/2@gw-t.example.net NTFY 2501：T38（ストップ）X：21
Step 24:
ステップ24：
The Call Agent acknowledges the Notify command:
コール・エージェントは通知コマンドを認識します：
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:
コールエージェントはPCMUメディアエンコーディングを使用すると、緩いコールエージェント制御のT.38手順を使用するように指示し、ゲートウェイにのCreateConnectionコマンドを発行します。その結果、コールエージェントは、「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
CRCX千ds/ds1-1/1@gw-o.example.net MGCP 1.0 C：1 L：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
V = 0 0 = - C = IN IP4 192.0.2.1 T = 0、M =オーディオ3456 RTP / AVP 0 = SQN - IP4 192.0.2.1 S = IN 25678 753849：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像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メッセージを送信します。
INVITE sip:bob@biloxi.example.com SIP/2.0 ... Content-Type: application/sdp Content-Length: 167
SIPのINVITE：bob@biloxi.example.com SIP / 2.0 ...のContent-Type：アプリケーション/ SDPコンテンツの長さ：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
V = 0 0 = - C = IN IP4 192.0.2.1 T = 0、M =オーディオ3456 RTP / AVP 0 = SQN - IP4 192.0.2.1 S = IN 25678 753849：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像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を詳細に示す）SIP 200 OK応答を返します：
SIP/2.0 200 OK ... Content-Type: application/sdp Content-Length: 100
SIP / 2.0 200 OK ...のContent-Type：アプリケーション/ SDPコンテンツの長さ：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
C = IN IP4 192.0.2.2 T = 0、M =オーディオ1296 RTP / AVP 0 - V = 0 0 = - IP4 192.0.2.2 S = IN 25678 753849
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ユーザーエージェントがサポート（またはのためのサポートの欠如）T.38を示すために、RFC 3407 [RFC3407]の能力記述子を使用していないことに注意してください。
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 UAにSIP ACKメッセージを送信します。
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 OPTIONS要求を送信することができます。他の側は、それはあまりにもそこに行うことができるコールエージェント話すSIPであった場合、もちろん、この缶は、例えば、任意のSIPピアに向けて行われることに注意してください。
Step 6:
ステップ6：
The originating Call Agent in turns sends a ModifyConnection command to the originating gateway:
ターンで発信エージェントは発信ゲートウェイにModifyConnectionコマンドを送信します。
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
C = IN IP4 192.0.2.2 T = 0、M =オーディオ1296 RTP / AVP 0 - V = 0 0 = - IP4 192.0.2.2 S = IN 25678 753849
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.
ModifyConnectionコマンドは、以前に送られたLocalConnectionOptionsを繰り返していません。限りファックスの取り扱いに関しては、ゲートウェイは、したがって、現在のファックス処理手順、即ち、ルーズCallエージェント制御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エンコードを通過させます。両方のファックスモデムコールがこの順序で開始することができるので、V.21ファックスプリアンブルが検出されるとステップ9までファックス通話であることを決定することは不可能です。
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を送信します。
INVITE sip:ca@ca-o.example.net SIP/2.0 ... Content-Type: application/sdp Content-Length: 100
SIPのINVITE：ca@ca-o.example.net SIP / 2.0 ...のContent-Type：アプリケーション/ SDPコンテンツの長さ：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 0 = - C = IN IP4 192.0.2.2 T = 0、M =画像1296 UDPTLのT38 - IP4 192.0.2.2 S = IN 25678 753850
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 0 = - C = IN IP4 192.0.2.2 T = 0、M =画像1296 UDPTLのT38 - IP4 192.0.2.2 S = IN 25678 753850
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
V = 0 0 = - IP4 192.0.2.1 S = IN 25678 753850 - C = IN IP4 192.0.2.1 T = 0、M =画像3456 UDPTLのT38のA = SQN：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像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:
発信エージェントは、終端SIPユーザーエージェントに更新SDPとSIP 200 OK応答を送信します。
SIP/2.0 200 OK ... Content-Type: application/sdp Content-Length: 167
SIP / 2.0 200 OK ...のContent-Type：アプリケーション/ SDPコンテンツの長さ：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
V = 0 0 = - IP4 192.0.2.1 S = IN 25678 753850 - C = IN IP4 192.0.2.1 T = 0、M =画像3456 UDPTLのT38のA = SQN：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3画像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ユーザエージェントは、現在有効なメディアとして「画像/ T38」とRemoteConnectionDescriptorを有しているので、発信ゲートウェイ（及びその逆）とT.38交換を開始することができます。
Steps 15, 16:
16、15ステップ：
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ファックスプリアンブルを検出します。エンドポイントは、すでにメディアの「画像/ T38」を使用しているにもかかわらず、それが「T38（スタート）」イベントを生成し、コールエージェントに通知します。
NTFY 3500 ds/ds1-1/1@gw-o.example.net MGCP 1.0 O: fxr/t38(start) X: 1
MGCP 1.0 O ds/ds1-1/1@gw-o.example.net NTFY 3500：FXR / T38（開始）X：1
Steps 17, 18:
18、17ステップ：
The Call Agent acknowledges the Notify command and issues a new (piggybacked) request for notification of the T38 event.
コール・エージェントは通知コマンドを認識し、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.
ファックスが終了すると、終了SIP UAは、コールを切断することを決定し、したがって、コールエージェントがSIP 200で応答するSIP BYEメッセージを送信します。
Step 23:
ステップ23：
The originating endpoint also generates a "t38(stop)" event, which is notified to the Call Agent:
発信エンドポイントは「T38（ストップ）」コールエージェントに通知されるイベントを生成します。
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 24:
ステップ24：
The Call Agent acknowledges the Notify command:
コール・エージェントは通知コマンドを認識します：
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ファックスパッケージ自体は、任意の新しいセキュリティ上の懸念を導入することが知られていません。しかし、実装者はそのT.38メディアは、現在明確にし、任意の完全性保護なしでUDP（UDPTL）またはTCP上で伝送されていることに注意すべきです。例えばセキュリティサービスは、RTPメディアストリームを保護するために整備されている場合、これらは、このようにT.38メディアストリームのために有効になりません。セキュリティのこうした不足が懸念される場合は、このパッケージのT.38を使用すべきでない可能ファックスLocalConnectionOptionsは、すなわち、「オフ」（または新しいセキュア拡張）ファックス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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]アンドレア、F.およびB.フォスター、 "メディアゲートウェイコントロールプロトコル（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]、2002年3月ITU-T勧告T.38、 "IPネットワーク上のリアルタイムグループ3ファクシミリ通信のための手順"。
[RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple Capability Declaration", RFC 3407, October 2002.
[RFC3407]アンドレア、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
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ファックスパッケージの発展に貢献してきました。特に、著者はビル・フォスター、ポール・ジョーンズ、ゲイリー・ケリー、ラジェッシュクマー、デイブ・ホロウィッツ、宏田村、ロブ・トンプソン、そして彼らの貢献のためのCableLabsのPacketCableのNCSフォーカスチームに感謝したいと思います。
Authors' Addresses
著者のアドレス
Flemming Andreasen Cisco Systems 499 Thornall Street, 8th Floor Edison, NJ 08837
フレミングAndreasenのシスコシステムズ499 Thornallストリート、8階エジソン、NJ 08837
EMail: fandreas@cisco.com
メールアドレス：fandreas@cisco.com
David Hancock CableLabs 858 Coal Creek Circle Louisville, CO 80027
デビッド・ハンコックCableLabsの858コールクリークサークルルイビル、CO 80027
EMail: d.hancock@cablelabs.com
メールアドレス：d.hancock@cablelabs.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。