RFC 5347: Media Gateway Control Protocol Fax Package 中文翻译

URL : https://datatracker.ietf.org/doc/html/rfc5347
标题 : RFC 5347
翻译类型 : 自动生成

Network Working Group                                       F. Andreasen
Request for Comments: 5347                                 Cisco Systems
Category: Informational                                       D. Hancock
                                                               CableLabs
                                                            October 2008

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）包。该软件包允许以两种不同的方式支持传真呼叫。第一种方法利用ITU-T建议T.38进行呼叫代理控制下的传真中继。第二种方法让网关决定传真传输的方法，并在不涉及呼叫代理的情况下处理传真呼叫的细节。

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

   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

1. Introduction

1. 介绍

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）[RFC3435]包，该包使MGCP控制的网关能够支持传真呼叫。该软件包支持两种不同方式的传真呼叫。第一种方法利用ITU-T建议T.38，在呼叫代理的控制下，对传真中继使用UDP传输层（UDPTL）或TCP（见[T38]）。第二种方法让网关决定传真传输的方法，并在不涉及呼叫代理的情况下处理传真呼叫的细节。

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节提供了三个调用流示例，展示了如何使用它。安全注意事项见第4节，然后是IANA注意事项和参考。

1.1. Conventions Used in This Document

1.1. 本文件中使用的公约

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC-2119 [RFC2119].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC-2119[RFC2119]中的说明进行解释。

2. Fax Package Definition

2. 传真包定义

A package is defined for fax. The package defines new LocalConnectionOptions, events, and connection parameters as detailed below:

为传真定义了一个包。该包定义了新的LocalConnectionOptions、events和connection参数，详情如下：

Package Name: FXR Package Version: 0

包名称：FXR包版本：0

2.1. LocalConnectionOptions

2.1. 本地连接选项

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.1节至第2.1.4节）：

* T.38 Strict: Use T.38 [T38] with either UDPTL or TCP for fax relay and have the Call Agent control it. Assuming the procedure can be used (see Section 2.1.1), a switch to T.38 procedures will be initiated upon fax detection, and a "t38(start)" event will be generated (see Section 2.2). This mode requires an indication of T.38 support from the remote side in order to be used, as described further in Section 2.1.1.

* T.38严格：将T.38[T38]与UDPTL或TCP一起用于传真中继，并由呼叫代理控制。假设可以使用该程序（见第2.1.1节），则在检测到传真时将启动切换到T.38程序，并生成“t38（启动）”事件（见第2.2节）。如第2.1.1节所述，该模式需要远程侧的T.38支架指示，以便使用。

* T.38 Loose: Identical to T.38 Strict procedure, except that an indication of T.38 support from the remote side is not required for the procedure to be used.

* T.38松动：与T.38严格程序相同，但使用程序时不需要远程侧的T.38支架指示。

* Off: Do not invoke any special procedure for fax, except for echo cancellation adjustment and possibly switching to another codec.

* 关闭：不要调用传真的任何特殊过程，除了回声消除调整和可能切换到其他编解码器。

* 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（start）”事件来通知呼叫代理（参见第2.2节）。然后，呼叫代理应避免向网关发出可能存在冲突的命令，直到网关结束其特殊传真处理过程。

A gateway that ends up not being able to invoke any special procedure for fax will generate a "nopfax(start)" event (see Section 2.2) upon detection of fax.

如果网关无法调用传真的任何特殊过程，则在检测到传真时将生成“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，或者如果ModifyConnection命令中不包括传真LCO，则保留连接的先前传真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 Strict”的使用，并且现在接收到的ModifyConnection命令没有传真LCO，但是RemoteConnectionDescriptor指示不支持T.38。在这种情况下，ModifyConnection命令将成功，但在检测到传真时将不再调用T.38过程（将生成“nopfax”事件）。如果呼叫代理将传真LCO设置为“T.38 Strict”，则该命令将失败。

If multiple fax parameter values are provided, the gateway MUST choose one of the procedures specified according to the order in which they are supplied, except as follows:

如果提供了多个传真参数值，网关必须根据提供这些参数值的顺序选择指定的程序之一，以下情况除外：

1. If "gateway" would have been selected and it would have resulted in no special procedure being applied, and

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.

然后，网关必须使用可支持的那些后续过程中最首选的过程。如果这些后续过程都不受支持，网关将恢复为不调用传真的任何特殊过程。请参阅第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参数编码为关键字“fx”（前缀为[RFC3435]规定的包名），后跟冒号和分号分隔的值列表，其中T.38 Strict编码为“t38”，T.38 Loose编码为“t38 Loose”，gateway编码为“gw”，off编码为“off”。

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严格传真中继（首选）或网关控制进行传真：

      L: a:PCMU;G729, fxr/fx:t38;gw

      L: a:PCMU;G729, fxr/fx:t38;gw

It should be noted that MGCP allows the CreateConnection command to omit both LocalConnectionOptions and RemoteConnectionDescriptor, thereby letting the gateway decide upon the media parameters to use. When the T.38 fax package is supported, the gateway could thus choose to do either audio or T.38 fax relay in such cases. Most likely, the Call Agent requires one or the other to be used, and hence it SHOULD NOT omit both LocalConnectionOptions and RemoteConnectionDescriptor in CreateConnection commands.

应该注意，MGCP允许CreateConnection命令省略LocalConnectionOptions和RemoteConnectionDescriptor，从而让网关决定要使用的媒体参数。当支持T.38传真包时，网关可以选择在这种情况下进行音频或T.38传真中继。最有可能的情况是，调用代理需要使用其中一个选项，因此它不应在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, ...

A:A:image/t38，fxr/fx:mypar。。。

In the following subsections, we provide additional detail on the above-defined fax procedures.

在以下小节中，我们将提供有关上述传真程序的更多详细信息。

2.1.1. T.38 Procedure (Strict or Loose)

2.1.1. T.38程序（严格或宽松）

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（除非还指示网关对媒体流使用“image/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=audio 3456 RTP/AVP 18
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 18
      a=cdsc: 2 image udptl t38

For a list of T.38 related parameters to be included in the SDP, please refer to T.38 Annex D [T38].

关于SDP中包含的T.38相关参数列表，请参考T.38附录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).

1. 启动T.38传真中继程序，并在发送和接收方向使媒体频道静音（除非媒体频道已在使用T.38）。

2. Generate a "t38(start)" event.

2. 生成“t38（启动）”事件。

3. Await further instructions from the Call Agent in order to initiate the actual media change (unless the media channel is already using T.38).

3. 等待呼叫代理的进一步指示，以启动实际的媒体更换（除非媒体频道已经在使用T.38）。

The Call Agent instructs the gateway to perform the media change by sending it a ModifyConnection command with "image/t38" listed as the encoding method in the LocalConnectionOptions (receipt of a ModifyConnection command without LocalConnectionOptions but with a RemoteConnectionDescriptor containing an "m=" line with the MIME type "image/t38" would achieve the same). Per the normal MGCP codec negotiation procedures (see [RFC3435] Section 2.6), if a

呼叫代理通过向网关发送ModifyConnection命令，将“image/t38”列为LocalConnectionOptions中的编码方法，指示网关执行媒体更改（接收不带LocalConnectionOptions但带有RemoteConnectionDescriptor的ModifyConnection命令，其中包含“m=”line with The MIME type“image/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，它需要包含一个带有“image/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.

如果发送到启动T.38过程的网关的ModifyConnection命令中未包含RemoteConnectionDescriptor，则最后接收到的RemoteConnectionDescriptor可能（事实上很可能）未包含“m=”line listing“image/t38”作为可接受的媒体格式。在这种情况下，端点无法将T.38媒体发送到另一端。端点必须等待更新的RemoteConnectionDescriptor，该脚本包含“image/t38”作为可接受的媒体格式和受支持的传输协议（UDPTL或TCP）。当收到可接受的RemoteConnectionDescriptor时，T.38传真过程继续。可接受的RemoteConnectionDescriptor包含具有“image/t38”MIME类型的“m=”行（使用正常SDP语法）和受支持的传输协议（UDPTL或TCP）。如果传真呼叫在等待呼叫代理指示网关切换到“image/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，并且尝试使用音频编解码器回退到传真直通时，可以执行此操作。呼叫代理使用“关闭”传真LCO指示端点中止正在进行的T.38过程，如下所示：

      L: fxr/fx:off

      L: fxr/fx:off

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

现在，我们将“时间t38init”定义为启动T.38过程的时间点，“时间t38abort”定义为呼叫代理中止正在进行的T.38过程的时间点。如果调用代理在t38abort时指示或启用端点还原到t38init之前正在使用的一个或多个编解码器，则端点应使用模拟t38init之前发出的最新LocalConnectionDescriptor的媒体流参数。例如，IP地址和UDP端口、使用的有效负载格式及其有效负载类型映射都应与t38init之前相同。这将使回退速度尽可能快。LocalConnectionDescriptor像往常一样返回，即仅当一个或多个

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).

自上次发出LocalConnectionDescriptor以来，更改了更多参数（例如，如果发出了T.38 LCD或更改了音频LCD中的传输地址）。

2.1.2. Gateway Procedure

2.1.2. 网关程序

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.

使用网关过程（也称为网关控制模式）的网关可在检测到传真呼叫时启动特殊传真处理。此特殊传真处理的详细信息不在本文件范围内。但是，为了使用任何特殊的传真处理，必须通过LocalConnectionDescriptor和RemoteConnectionDescriptor（这包括使用基于RTP的T.38）传递和识别相关参数，与另一方协商对其的支持。如果另一方未表示支持所需的特殊传真处理，则网关不得尝试启动它。启动特殊传真处理时，必须生成“gwfax（start）”事件，从而使呼叫代理能够区分呼叫代理和网关控制模式，同时仍被告知传真的实际更改。当传真的特殊网关处理结束时，必须生成“gwfax（停止）”或“gwfax（失败）”事件。

2.1.3. Off Procedure

2.1.3. 关闭程序

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（start）”事件；但是，相应的“停止”事件不会发生。

Generating a "stop" event would imply that the gateway had to infer when the fax call ends, which involves processing the media stream. However, when using the "off" mode, such processing is not expected to occur.

生成“停止”事件意味着网关必须推断传真呼叫何时结束，这涉及处理媒体流。但是，当使用“关闭”模式时，预计不会发生这种处理。

2.1.4. Mode Operation

2.1.4. 模式操作

For each of the above modes, the RemoteConnectionDescriptor provides information on what procedure(s) the other side supports. The following rules are used to determine which procedure to use:

对于上述每种模式，RemoteConnectionDescriptor都提供了关于另一端支持哪些过程的信息。以下规则用于确定要使用的程序：

1. Whatever the Call Agent specified in the Fax LocalConnectionOptions for the current command MUST be adhered to. If the gateway cannot satisfy any of the options, the command fails (error code 532 -- unsupported value(s) in LocalConnectionOptions is RECOMMENDED).

1. 必须遵守当前命令的Fax LocalConnectionOptions中指定的呼叫代理。如果网关无法满足任何选项，则命令将失败（错误代码532——建议使用LocalConnectionOptions中不支持的值）。

2. If both Fax LocalConnectionOptions and a RemoteConnectionDescriptor are provided, the procedure selected MUST be supported by both sides -- this is currently only an issue for "T.38 Strict". A procedure can be satisfied by the remote side if:

2. 如果同时提供了Fax LocalConnectionOptions和RemoteConnectionDescriptor，则双方都必须支持所选的过程——这目前只是“T.38 Strict”的一个问题。如果满足以下条件，远程端可以满足程序要求：

* the relevant MIME media type, e.g., "image/t38", is included in the "m=" line in the RemoteConnectionDescriptor, or

* 相关MIME媒体类型，例如“image/t38”，包含在RemoteConnectionDescriptor中的“m=”行中，或

* the relevant MIME media type is included as a capability (see [RFC3407]) in the RemoteConnectionDescriptor.

* 相关MIME媒体类型作为一种功能（请参见[RFC3407]）包含在RemoteConnectionDescriptor中。

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.

如果网关无法选择传真本地连接选项中的任何过程，则命令将失败（建议使用错误代码532）。请注意，根据定义，“T.38 Loose”、“gateway”和“off”始终可以由支持此包的实现支持，而不管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。这样做时，必须使用默认的Fax LocalConnectionOptions，即CreateConnection中的“网关”，或ModifyConnection中的当前值。在ModifyConnection的情况下，命令的结果不取决于网关是否能够选择这些“默认”程序之一（如第2.1节所述）。请注意，这不是CreateConnection命令的问题，因为定义始终支持默认值。

5. A previously received RemoteConnectionDescriptor does not affect what procedure can be selected. Only a RemoteConnectionDescriptor supplied with the current command affects the procedure selection. However, in order to send media of a given type (e.g., "image/t38"), the most recently received RemoteConnectionDescriptor MUST include a corresponding media line.

5. 以前收到的RemoteConnectionDescriptor不影响可以选择的过程。只有与当前命令一起提供的RemoteConnectionDescriptor才会影响过程选择。但是，为了发送给定类型的媒体（例如，“image/t38”），最近接收到的RemoteConnectionDescriptor必须包括相应的媒体行。

The following examples illustrate the use of the above rules:

以下示例说明了上述规则的使用：

Per rule 1, a gateway that only supports standard T.38 fax relay will fail a command that only contains the fax option "mypar", whereas it will succeed a command that contains "t38-loose", "gw", "off", or no fax LCO. A command that only contained "t38", i.e., use of T.38 in "strict" mode, may or may not succeed (depending on the RemoteConnectionDescriptor).

根据规则1，仅支持标准T.38传真中继的网关将使仅包含传真选项“mypar”的命令失败，而它将继承包含“t38松散”、“gw”、“off”或无传真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.

根据规则2，支持T.38的网关接收传真处理LCO设置为“t38”的CreateConnection命令，以及既没有T.38功能也没有T.38媒体流的RemoteConnectionDescriptor将失败。如果传真处理LCO包含“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的网关已成功执行CreateConnection命令，且传真处理设置为“t38”（即严格）。如果网关现在接收到ModifyConnection命令，但没有传真处理LCO，但使用的RemoteConnectionDescriptor既没有T.38功能，也没有“image/t38”媒体流，则该命令将成功（因为规则1在这种情况下无效）。然而，根据第2条和第4条，将不存在任何T.38程序。如果呼叫代理将传真处理LCO再次设置为“t38”，则根据规则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的切换可以由发起网关和终止网关中的一个或两个发起，因此实现必须准备好处理这个问题。这包括双方启动切换的情况，例如，当始发传真生成呼叫音（CNG）且终止传真在终端侧执行到T.38的切换之前检测到V.21传真前导（参见[T30]）时，可能会发生这种情况。

2.1.5. Detecting a Fax Call

2.1.5. 检测传真呼叫

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.

根据所使用的传真传输方法，可以通过几种不同的方式（例如，V.21传真前导、T.30 CNG音调或V.8信号）检测传真呼叫。此包的实现必须至少检测基于V.21传真前导的传真呼叫。

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

可根据T.30 CNG音调触发；这通常被认为适用于G3和更低的传真速度。但是，当与T.38版本2或更早版本一起使用时，它将影响V.34高速传真。原因是T.38版本2（及更早版本）不支持V.34传真使用的V.8 ANSam和CM信号，因此当使用T.38版本2（或更早版本）时，V.34传真速度将降低到G3（14.400 bps）或更低。还有一些罕见的调制解调器

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音调；这种调制解调器会产生传真的错误触发。由于上述原因，建议支持基于T.30 CNG的传真检测的此软件包的实现提供一个配置选项，以禁用T.38版本2（或更早版本）的传真检测。

2.1.6. Considerations for Determining Which Procedures to Request

2.1.6. 确定请求哪些程序的考虑因素

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传真中继信息生成RFC 3407[RFC3407]能力描述的环境中，使用T.38严格模式是理想的。如果在这样的环境中接收到没有T.38传真中继功能的RemoteConnectionDescriptor，则已知另一方不支持T.38，因此可以避免切换到T.38的失败尝试（这反过来可能导致传真呼叫失败）。如果不知道其他端点是否支持RFC 3407[RFC3407]功能描述符，那么权衡就不那么清楚了。优点是，只有在已知另一方支持T.38时，才会尝试切换到T.38，但不表示支持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松散模式涉及与T.38严格模式相同的考虑因素，但利弊相反。如果对等端点不支持T.38，T.38松散模式仍将尝试切换到T.38（并失败），这反过来可能导致传真呼叫失败。另一方面，如果对等端点不支持RFC 3407[RFC3407]功能描述符，但对等端点实际上支持T.38，则T.38仍将与此模式一起使用。

In summary, there is no single good answer to the use of either T.38 Strict or T.38 loose mode; it depends on the capabilities of the endpoints involved as well as the trade-off between potentially letting fax calls fail due to lack of capability indications (where T.38 is otherwise supported) versus potentially letting fax calls fail due to an unsuccessful switch to T.38 (because T.38 in fact was not supported). It should be noted that Call Agents may have means beyond RFC 3407 [RFC3407] capability descriptors to determine if a peer endpoint supports T.38 or not. For example, when SIP is used as the signaling protocol with other peers (e.g., Call Agents or other SIP devices), the SIP OPTIONS method can be used to learn whether

总之，使用T.38严格模式或T.38松散模式都没有一个好的答案；这取决于所涉及的端点的能力，以及由于缺乏能力指示（在其他情况下支持T.38）而可能让传真呼叫失败与由于切换到T.38失败而可能让传真呼叫失败（因为实际上不支持T.38）之间的权衡。应该注意的是，呼叫代理可能具有RFC 3407[RFC3407]能力描述符之外的方法来确定对等端点是否支持T.38。例如，当SIP用作与其他对等方（例如，呼叫代理或其他SIP设备）的信令协议时，SIP选项方法可用于了解

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.

当选择网关控制模式时，只有两个对等端点支持相同的传真处理方法时，才会有特殊的传真处理；请注意，实际方法的细节完全取决于供应商。还请注意，如果两个对等端点不支持相同的传真处理方法，或者如果交换的SDP中未指明该方法，则不会有特殊的传真处理。此外，在传真传输开始并生成“nopfax（start）”事件之前，呼叫代理不会意识到这种情况。

The off mode is straightforward; there will be no special procedure in place for fax handling, except for the usual handling of echo cancellation and possibly a change to a higher bandwidth codec.

关闭模式是直接的；除了通常处理回声消除和可能更改为更高带宽的编解码器外，传真处理没有特殊程序。

Having looked at the individual procedures in more detail, we now elaborate on some of the combinations of procedures that may be requested:

在更详细地研究了各个程序之后，我们现在详细说明可能需要的一些程序组合：

* T.38 strict: If the T.38 strict procedure is placed after the T.38 loose or the off procedure (both of which can always be supported), it will not be selected. Apart from this, it makes little sense to request both T.38 strict and T.38 loose.

* T.38严格：如果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.

* 关闭：始终支持关闭程序。在此步骤之后指定的任何步骤都不会被选择。

2.2. Events and Signals

2.2. 事件和信号

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  |                     |
    ------------------------------------------------------------------

    ------------------------------------------------------------------
   | 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.

各事件的定义见以下小节。

2.2.1. Gateway Controlled Fax (gwfax)

2.2.1. 网关控制传真（gwfax）

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.

报告事件时，将出现上述参数之一。“gwfax”事件可以在ObservedEvents中使用其他参数进行参数化，但是建议将上述参数之一作为提供的第一个参数。必须忽略未知参数。

The following example illustrates the encoding of the "gwfax" event:

以下示例说明了“gwfax”事件的编码：

      O: fxr/gwfax(start)
      O: fxr/gwfax(stop, foobar)

      O: fxr/gwfax(start)
      O: fxr/gwfax(stop, foobar)

2.2.2. No Special Fax Handling (nopfax)

2.2.2. 无特殊传真处理（nopfax）

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上的附加参数进行参数化，但建议将上述参数作为提供的第一个参数。必须忽略未知参数。请注意，此事件当前无法用“停止”或“失败”参数化，因为它仅检测传真呼叫的开始。

The following example illustrates the encoding of the "nopfax" event:

以下示例说明了“nopfax”事件的编码：

      O: fxr/nopfax(start)

      O: fxr/nopfax(start)

2.2.3. T.38 Fax Relay (t38)

2.2.3. T.38传真中继（t38）

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”，定义了以下仅适用于观测事件的事件参数：

* 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

* 开始：在端点上检测到传真呼叫，并启动呼叫代理控制的T.38传真中继过程。呼叫代理应修改连接的每一侧，以开始使用“image/t38”媒体格式，除非他们已经这样做。注意，只要使用呼叫代理控制的T.38中继程序有效，无论端点上的任何连接（包括“image/t38”）上的当前编码方法如何，都将在传真呼叫检测时生成事件。“t38（启动）”事件必须

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.

无论是否在后续请求的事件列表中再次请求，端点每次传真呼叫最多生成一次。

* 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传真中继程序已经结束，并且该程序本身没有遇到任何错误。呼叫代理可能需要修改连接每一侧的媒体参数。请注意，与网关控制的传真过程情况相反，媒体参数（如编解码器）不会在传真呼叫开始前自动恢复为其值；但是，回声消除和静音抑制应符合[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传真中继程序异常结束。呼叫代理控制的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.

报告事件时，将出现上述参数之一。“t38”事件可使用其他参数进行参数化，但建议将上述参数之一作为提供的第一个参数。必须忽略未知参数。

The following example illustrates the encoding of the "t38" event:

以下示例说明了“t38”事件的编码：

      O: fxr/t38(start)
      O: fxr/t38(stop, foobar)

      O: fxr/t38(start)
      O: fxr/t38(stop, foobar)

2.3. Connection Parameters

2.3. 连接参数

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”，提供的值是最多九位十进制数字的字符串。

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.

端点在连接生命周期内接收的传真页的累积数量。参数编码为“PGR”，提供的值是最多九位十进制数字的字符串。

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。。。

2.4. Negotiation of T.38 Parameters

2.4. T.38参数的协商

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存在报价/应答[RFC3264]部分，其中T.38附录D参数被归类为声明性或协商性参数，然后我们提供了如何将此类定义和程序映射到此处定义的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没有指定提供/应答模型的使用，而是使用连接处理命令（例如，CreateConnection和ModifyConnection）的概念进行操作，这些命令可能包括RemoteConnectionDescriptor（SDP），然后在响应中生成LocalConnectionDescriptor（SDP）。

When an MGCP endpoint receives a CreateConnection command without a RemoteConnectionDescriptor, it should follow the corresponding T.38 procedures for generating an initial offer and return the resulting SDP in its LocalConnectionDescriptor.

当MGCP端点在没有RemoteConnectionDescriptor的情况下接收到CreateConnection命令时，它应该遵循相应的T.38过程来生成初始报价，并在其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对应于一个答案，并且一个或多个协商参数发生了变化，则这将导致新的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）包含传真版本2，而应答（响应带SDP的CreateConnection）包含传真版本0，则相应的ModifyConnection命令（带SDP）将导致传真版本也设置为零的更新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，就像它是后续提供/应答交换的一部分一样。如果调用代理不需要这样的语义，它可以简单地创建一个新的连接。

2.5. Implementation Considerations

2.5. 实施考虑

2.5.1. Media IP Address and Port for T.38

2.5.1. T.38的媒体IP地址和端口

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或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.

当端点将RTP音频和T.38的同一端口与UDPTL或TCP一起使用时，一种类型（例如T.38）的数据包可能会被接收，而另一种类型（RTP音频）的数据包则会被接收。由于在任何给定的时间点都有明确的信号指示预期的类型，因此这不会引入任何新问题。换句话说，接收机不作为需要确定接收的给定分组是RTP音频分组还是T.38 UDPTL/TCP分组的解复用器来操作。接收器只是像往常一样处理传入的数据包。如果预期T.38数据包，则根据T.38验证传入数据包；如果预期RTP音频数据包，则根据RTP验证传入数据包。

2.5.2. Case Sensitivity

2.5.2. 区分大小写

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已将大写字符串“UDPTL”注册为传输协议标识符，用于基于UDP的T.38。然而，建议T.38中提供的示例以及大多数（如果不是全部）当前实现都使用小写字符串“udptl”。符合此包的实现应生成小写字符串“udptl”，并接受小写、大写和混合的大写/小写字符串作为等效字符串。

The attribute "T38MaxBitRate" was once incorrectly registered with IANA as "T38maxBitRate" (lower-case "m"). In accordance with T.38 examples and common implementation practice, the form "T38MaxBitRate" SHOULD be generated by implementations conforming to this package.

属性“T38MaxBitRate”曾在IANA中错误注册为“T38MaxBitRate”（小写“m”）。根据T.38示例和常见实施惯例，应通过符合本包要求的实施方式生成“T38MaxBitRate”表格。

In general, it is RECOMMENDED that implementations of this package accept lowercase, uppercase, and mixed upper/lowercase encodings of all the T.38 attributes.

一般来说，建议此包的实现接受所有T.38属性的小写、大写和混合大写/小写编码。

2.5.3. Boolean Indicator After T.38 Parameters

2.5.3. 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.

某些实现在属性T38FaxFillBitRemove、T38FaxTranscodingMMR和T38FaxTranscodingJBIG之后错误地使用冒号（“：”）和数字（零或一）。接收此类错误编码的实现可能会将值“：0”解释为不支持该选项，而将所有其他值解释为支持该选项。

3. Call Flow Examples

3. 调用流示例

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.

在本节中，我们提供三个示例调用流。第一个示例说明了在发起端和终止端的呼叫代理控制下的T.38传真呼叫。第二个例子说明了在双方使用多种不同的选项。第三个示例演示了与SIP端点的交互。

3.1. Call Agent Controlled T.38 Strict

3.1. 呼叫代理控制T.38严格

In this example, both sides are under strict T.38 Call Agent control. We assume the originating and terminating Call Agents communicate via the Session Initiation Protocol (SIP) [RFC3261]. Furthermore, the originating fax machine does not generate CNG tone, which is typical of early (i.e., pre-1993) fax machines.

在本例中，双方都受到严格的T.38呼叫代理控制。我们假设发起和终止呼叫代理通过会话发起协议（SIP）[RFC3261]进行通信。此外，原始传真机不产生CNG音调，这是早期（即1993年以前）传真机的典型特征。

    ------------------------------------------------------------------
   | #|     GW-o      |     CA-o      |      CA-t     |      GW-t     |
   |==|===============|===============|===============|===============|
   | 1|             <-|CRCX           |               |               |
   | 2|     200(sdp-o)|->             |               |               |
   | 3|               |  INVITE(sdp-o)|->             |               |
   | 4|               |               |    CRCX(sdp-o)|->             |
   | 5|               |               |             <-|200 (sdp-t)    |
   | 6|               |             <-|200(sdp-t)     |               |
   | 7|             <-|MDCX(sdp-t)    |               |               |
   | 8|            200|->             |               |               |
   |--|---------------|---------------|---------------|---------------|
   | 9|               |               |               |  <- ANS/      |
   |  |               |               |               |      T.30 CED |
   |10|               |               |               |  <- V.21 fax  |
   |  |               |               |               |     preamble  |
   |11|               |               |             <-|NTFY(t38 start)|
   |12|               |               |            200|->             |
   |13|               |               |      MDCX(t38)|->             |
   |14|               |               |             <-|200(sdp-t2)    |
   |15|               |             <-|INVITE(sdp-t2) |               |
   |16|             <-|MDCX(sdp-t2)   |               |               |
   |17|    200(sdp-o2)|->             |               |               |
   |18|               |    200(sdp-o2)|->             |               |
   |19|               |               |   MDCX(sdp-o2)|->             |
   |20|               |               |             <-|200            |
   |21|  V.21 fax ->  |               |               |               |
   |  |  preamble     |               |               |               |
   |22|NTFY(t38 start)|->             |               |               |
   |23|             <-|200            |               |               |
   |24|             <-|RQNT(T38 event)|               |               |
   |25|            200|->             |               |               |
   |--|---------------|---------------|---------------|---------------|
   |26|               |               |               |   (fax ends)  |
   |27|               |               |             <-|NTFY(t38 stop) |
   |28|               |               |            200|->             |
   |29|NTFY(t38 stop) |->             |               |               |
   |30|             <-|200            |               |               |
    ------------------------------------------------------------------

    ------------------------------------------------------------------
   | #|     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:

呼叫代理向网关发出CreateConnection命令，指示其使用PCMU媒体编码并使用严格的呼叫代理控制的T.38过程。因此，呼叫代理请求网关通知其“t38”事件：

      CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
      C: 1
      L: a:PCMU, fxr/fx:t38
      M: recvonly
      R: fxr/t38
      X: 1

      CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
      C: 1
      L: a:PCMU, fxr/fx:t38
      M: recvonly
      R: fxr/t38
      X: 1

Step 2:

步骤2：

The gateway acknowledges the command and includes SDP with codec information and RFC 3407 [RFC3407] capability information:

网关确认该命令，并包括带有编解码器信息的SDP和RFC 3407[RFC3407]功能信息：

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
      o=- 25678 753849 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 3456 RTP/AVP 0
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

Step 3:

步骤3：

The originating Call Agent sends a SIP INVITE message with the SDP to the terminating Call Agent.

发起呼叫代理使用SDP向终止呼叫代理发送SIP 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:

终止呼叫代理向终止网关发出CreateConnection命令，指示其使用PCMU媒体编码并使用严格的呼叫代理控制的T.38过程。因此，呼叫代理请求网关通知其“t38”事件：

      CRCX 2000 ds/ds1-1/2@gw-t.example.net MGCP 1.0
      C: 2
      L: a:PCMU, fxr/fx:t38
      M: sendrecv
      R: fxr/t38
      X: 20

      CRCX 2000 ds/ds1-1/2@gw-t.example.net MGCP 1.0
      C: 2
      L: a:PCMU, fxr/fx:t38
      M: sendrecv
      R: fxr/t38
      X: 20

      v=0
      o=- 25678 753849 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 3456 RTP/AVP 0
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

      v=0
      o=- 25678 753849 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 3456 RTP/AVP 0
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

Step 5:

步骤5：

The terminating gateway supports T.38, and the RemoteConnectionDescriptor included indicates that the other side supports T.38 as well, so the strict T.38 Call Agent controlled procedure requested can be used. The terminating gateway sends back a success response with its SDP, which also includes capability information:

终止网关支持T.38，其中包含的RemoteConnectionDescriptor表示另一端也支持T.38，因此可以使用严格的T.38调用代理控制过程。终端网关通过其SDP发回成功响应，SDP还包括能力信息：

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
      o=- 25678 753849 IN IP4 192.0.2.2
      s=-
      c=IN IP4 192.0.2.2
      t=0 0
      m=audio 1296 RTP/AVP 0
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

Step 6:

步骤6：

The terminating Call Agent sends back a SIP 200 OK response to the originating Call Agent, which in turn sends a SIP ACK (not shown).

终止呼叫代理向发起呼叫代理发回SIP 200 OK响应，发起呼叫代理又发送SIP ACK（未示出）。

Step 7:

步骤7：

The originating Call Agent in turn sends a ModifyConnection command to the originating gateway:

发起呼叫代理依次向发起网关发送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
      o=- 25678 753849 IN IP4 192.0.2.2
      s=-
      c=IN IP4 192.0.2.2
      t=0 0
      m=audio 1296 RTP/AVP 0
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

The ModifyConnection command does not repeat the LocalConnectionOptions sent previously. As far as fax handling is concerned, the gateway therefore attempts to continue using the current fax handling procedure, i.e., strict Call Agent controlled T.38. Since the capability information indicates the other side supports T.38, the gateway will in fact be able to use the strict Call Agent controlled T.38 procedure. Had there not been any support for T.38 in the RemoteConnectionDescriptor, then this command would still have succeeded, however there would be no special fax handling procedure (since strict mode could not be supported).

ModifyConnection命令不会重复先前发送的LocalConnectionOptions。就传真处理而言，网关因此试图继续使用当前的传真处理程序，即严格的呼叫代理控制的T.38。由于能力信息表明另一方支持T.38，网关实际上将能够使用严格的呼叫代理控制的T.38过程。如果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编码建立呼叫，如果检测到传真呼叫，呼叫代理控制的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之前，无法确定这是传真呼叫。

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

      NTFY 2500 ds/ds1-1/2@gw-t.example.net MGCP 1.0
      O: fxr/t38(start)
      X: 20

Step 12:

步骤12：

The Call Agent acknowledges the Notify command:

呼叫代理确认Notify命令：

200 2500 OK

200 2500行

Step 13:

步骤13：

The Call Agent then instructs the terminating gateway to use the "image/t38" MIME type instead:

呼叫代理然后指示终止网关使用“image/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: a:image/t38
      R: fxr/t38
      X: 21

Step 14:

步骤14：

The gateway changes to T.38 and sends back a success response with updated SDP:

网关更改为T.38，并使用更新的SDP发回成功响应：

200 2002 OK

200200200OK

      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
      o=- 25678 753850 IN IP4 192.0.2.2
      s=-
      c=IN IP4 192.0.2.2
      t=0 0
      m=image 1296 udptl t38
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

Note that since the gateway's current RemoteConnectionDescriptor (as opposed to the LocalConnectionDescriptor returned here) does not list "image/t38" as a valid encoding method, the terminating gateway is still muting the media and is now waiting for an updated RemoteConnectionDescriptor with "image/t38".

请注意，由于网关当前的RemoteConnectionDescriptor（与此处返回的LocalConnectionDescriptor相反）未将“image/t38”列为有效的编码方法，因此终止网关仍在禁用媒体，并正在等待更新后的RemoteConnectionDescriptor（带有“image/t38”）。

Step 15:

步骤15：

The terminating Call Agent sends a re-INVITE to the originating Call Agent with the updated SDP.

终止呼叫代理使用更新的SDP向发起呼叫代理发送重新邀请。

Step 16:

步骤16：

The originating Call Agent then sends a ModifyConnection command to the originating gateway:

然后，发起呼叫代理向发起网关发送ModifyConnection命令：

      MDCX 1003 ds/ds1-1/1@gw-o.example.net MGCP 1.0
      C: 1
      I: 1

      MDCX 1003 ds/ds1-1/1@gw-o.example.net MGCP 1.0
      C: 1
      I: 1

      v=0
      o=- 25678 753850 IN IP4 192.0.2.2
      s=-
      c=IN IP4 192.0.2.2
      t=0 0
      m=image 1296 udptl t38
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

      v=0
      o=- 25678 753850 IN IP4 192.0.2.2
      s=-
      c=IN IP4 192.0.2.2
      t=0 0
      m=image 1296 udptl t38
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

Step 17:

步骤17：

The originating gateway changes to T.38 and sends back a success response with updated SDP:

发起网关更改为T.38，并使用更新的SDP发回成功响应：

200 1003 OK

2001003好

      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
      o=- 25678 753850 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=image 3456 udptl t38
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

Step 18:

步骤18：

The originating Call Agent sends a SIP 200 OK response with the updated SDP to the terminating Call Agent, which in turn sends a SIP ACK (not shown).

发起呼叫代理向终止呼叫代理发送带有更新的SDP的SIP 200 OK响应，终止呼叫代理随后发送SIP ACK（未示出）。

Step 19:

步骤19：

The terminating Call Agent sends a ModifyConnection with the updated SDP to the terminating gateway:

终止呼叫代理向终止网关发送带有更新SDP的ModifyConnection：

      MDCX 2003 ds/ds1-1/2@gw-t.example.net MGCP 1.0
      C: 2
      I: 2

      MDCX 2003 ds/ds1-1/2@gw-t.example.net MGCP 1.0
      C: 2
      I: 2

      v=0
      o=- 25678 753850 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=image 3456 udptl t38
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

      v=0
      o=- 25678 753850 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=image 3456 udptl t38
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

Step 20:

步骤20：

The terminating gateway sends back a success response:

终止网关发回成功响应：

200 2003 OK

2002002003OK

Since the terminating gateway now has a RemoteConnectionDescriptor with "image/t38" as valid media, it can start exchanging T.38 with the originating gateway.

由于终止网关现在有一个RemoteConnectionDescriptor，其中“image/t38”作为有效介质，因此它可以开始与发起网关交换T.38。

Steps 21, 22:

步骤21、22：

The originating endpoint detects V.21 fax preamble. Even though the endpoint is already using "image/t38" for media, it generates a "t38(start)" event and notifies the Call Agent.

发起端点检测V.21传真前导码。即使端点已经在为媒体使用“image/t38”，它也会生成“t38（start）”事件并通知呼叫代理。

      NTFY 3500 ds/ds1-1/1@gw-o.example.net MGCP 1.0
      O: fxr/t38(start)
      X: 1

      NTFY 3500 ds/ds1-1/1@gw-o.example.net MGCP 1.0
      O: fxr/t38(start)
      X: 1

Steps 23, 24:

步骤23、24：

The Call Agent acknowledges the Notify command, then issues a new request for notification of the "t38" event.

呼叫代理确认Notify命令，然后发出新的“t38”事件通知请求。

200 3500 OK . RQNT 1004 ds/ds1-1/1@gw-o.example.net MGCP 1.0 R: fxr/t38 X: 2

200 3500正常。RQNT 1004 ds/ds1-1/1@gw-o、示例.net MGCP 1.0 R:fxr/t38 X:2

Step 25:

步骤25：

The gateway acknowledges the command.

网关确认该命令。

200 1004 OK

2001004好

Steps 26, 27:

步骤26、27：

When the fax ends, a "t38(stop)" event is generated by the terminating endpoint, which is notified to the Call Agent:

传真结束时，终止端点生成“t38（停止）”事件，并通知呼叫代理：

      NTFY 2501 ds/ds1-1/2@gw-t.example.net MGCP 1.0
      O: t38(stop)
      X: 21

      NTFY 2501 ds/ds1-1/2@gw-t.example.net MGCP 1.0
      O: t38(stop)
      X: 21

Step 28:

步骤28：

The Call Agent acknowledges the Notify command:

呼叫代理确认Notify命令：

200 2501 OK

2002501好

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(stop)
      X: 2

Step 30:

步骤30：

The Call Agent acknowledges the Notify command:

呼叫代理确认Notify命令：

200 3502 OK

2003502好

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.

传真电话现在结束了。呼叫代理现在可能决定更改回语音编解码器、删除连接或执行其他操作。

3.2. Multiple and Different Options

3.2. 多种不同的选择

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|->             |
    ------------------------------------------------------------------

    ------------------------------------------------------------------
   | #|     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:

呼叫代理向网关发出CreateConnection命令，指示其使用PCMU媒体编码并使用网关过程。因此，呼叫代理要求网关将“gwfax”事件通知它：

      CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
      C: 1
      L: a:PCMU, fxr/fx:gw
      M: recvonly
      R: fxr/gwfax
      X: 1

      CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
      C: 1
      L: a:PCMU, fxr/fx:gw
      M: recvonly
      R: fxr/gwfax
      X: 1

Step 2:

步骤2：

The gateway acknowledges the command and includes SDP with codec information and capability information:

网关确认该命令，并包括带有编解码器信息和功能信息的SDP：

200 1000 OK I:1

      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
      o=- 25678 753849 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 3456 RTP/AVP 0
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38
      a=X-FaxScheme: 123

We assume the gateway supports some other fax scheme, and it indicates this by including an attribute "X-FaxScheme: 123".

我们假设网关支持其他传真方案，它通过包含属性“X-FaxScheme:123”来表示这一点。

Step 3:

步骤3：

The originating Call Agent sends a SIP INVITE message with the SDP to the terminating Call Agent.

发起呼叫代理使用SDP向终止呼叫代理发送SIP 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:

终止呼叫代理向终止网关发出CreateConnection命令，指示其使用PCMU媒体编码，并使用网关过程或严格呼叫代理控制的T.38过程。因此，呼叫代理请求网关通知其“gwfax”和“t38”事件：

      CRCX 2000 ds/ds1-1/2@gw-t.example.net MGCP 1.0
      C: 2
      L: a:PCMU, fxr/fx:gw;t38
      M: sendrecv
      R: fxr/t38, fxr/gwfax
      X: 20

      CRCX 2000 ds/ds1-1/2@gw-t.example.net MGCP 1.0
      C: 2
      L: a:PCMU, fxr/fx:gw;t38
      M: sendrecv
      R: fxr/t38, fxr/gwfax
      X: 20

      v=0
      o=- 25678 753849 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 3456 RTP/AVP 0
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38
      a=X-FaxScheme: 123

      v=0
      o=- 25678 753849 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 3456 RTP/AVP 0
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38
      a=X-FaxScheme: 123

Step 5:

步骤5：

The terminating gateway does not support any special gateway fax handling; however, it does support T.38, and the RemoteConnectionDescriptor included indicates that the other side supports T.38 as well, so the strict T.38 Call Agent controlled procedure requested can be honored. The terminating gateway sends back a success response with its SDP, which also includes capability information:

终端网关不支持任何特殊网关传真处理；但是，它确实支持T.38，并且包含的RemoteConnectionDescriptor表明另一方也支持T.38，因此可以遵守严格的T.38调用代理控制过程。终端网关通过其SDP发回成功响应，SDP还包括能力信息：

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
      o=- 25678 753849 IN IP4 192.0.2.2
      s=-
      c=IN IP4 192.0.2.2
      t=0 0
      m=audio 1296 RTP/AVP 0
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

Step 6:

步骤6：

The terminating Call Agent sends back a SIP 200 OK response to the originating Call Agent, which in turn sends a SIP ACK (not shown).

终止呼叫代理向发起呼叫代理发回SIP 200 OK响应，发起呼叫代理又发送SIP ACK（未示出）。

Step 7:

步骤7：

The originating Call Agent in turns sends a ModifyConnection command to the originating gateway:

发起呼叫代理依次向发起网关发送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
      o=- 25678 753849 IN IP4 192.0.2.2
      s=-
      c=IN IP4 192.0.2.2
      t=0 0
      m=audio 1296 RTP/AVP 0
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

The ModifyConnection command does not repeat the LocalConnectionOptions sent previously. As far as fax handling is concerned, the gateway therefore attempts to continue using the current fax handling, i.e., the gateway procedure. The SDP information returned however does not indicate support for the "X-FaxScheme: 123", and hence the originating gateway will not invoke any special fax handling procedure for this call.

ModifyConnection命令不会重复先前发送的LocalConnectionOptions。就传真处理而言，网关因此尝试继续使用当前传真处理，即网关过程。然而，返回的SDP信息并不表示支持“X-FaxScheme:123”，因此发起网关不会为此呼叫调用任何特殊传真处理过程。

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编码建立呼叫，如果检测到传真呼叫，则不会发生特殊的传真处理过程。

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（start）”事件，但由于呼叫代理尚未请求此事件，因此不会检测到该事件，因此不会向呼叫代理报告。因此，CNG音调仅通过当前PCMU编码传递，而（发起）呼叫代理不知道传真呼叫。

Subsequently, the T.30 CED tone (a.k.a. V.25 ANS) occurs -- in this case, it is also simply passed through the current PCMU encoding. Since both fax and modem calls can start with this sequence, it is not possible to determine that this is a fax call until step 11, where the V.21 fax preamble is detected.

随后，出现T.30 CED音调（也称为V.25 ANS）——在这种情况下，它也只是通过当前的PCMU编码传递。由于传真和调制解调器呼叫都可以按此顺序开始，因此在检测到V.21传真前导码的步骤11之前，无法确定这是传真呼叫。

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

      NTFY 2500 ds/ds1-1/2@gw-t.example.net MGCP 1.0
      O: fxr/t38(start)
      X: 20

Step 13:

步骤13：

The Call Agent acknowledges the Notify command:

呼叫代理确认Notify命令：

200 2500 OK

200 2500行

Step 14:

步骤14：

The Call Agent then instructs the terminating gateway to use the "image/t38" MIME type instead:

呼叫代理然后指示终止网关使用“image/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: a:image/t38
      R: fxr/t38
      X: 21

Step 15:

步骤15：

The gateway changes to T.38 and sends back a success response with updated SDP:

网关更改为T.38，并使用更新的SDP发回成功响应：

200 2002 OK

200200200OK

      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
      o=- 25678 753850 IN IP4 192.0.2.2
      s=-
      c=IN IP4 192.0.2.2
      t=0 0
      m=image 1296 udptl t38
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

Note that since the terminating gateway's last received RemoteConnectionDescriptor (as opposed to the LocalConnectionDescriptor returned here) did not list "image/t38" as a valid encoding method, the terminating gateway is still muting the media and is now waiting for an updated RemoteConnectionDescriptor with "image/t38".

请注意，由于终止网关上一次收到的RemoteConnectionDescriptor（与此处返回的LocalConnectionDescriptor相反）未将“image/t38”列为有效的编码方法，因此终止网关仍在禁用媒体，并正在等待更新的带有“image/t38”的RemoteConnectionDescriptor。

Step 16:

步骤16：

The terminating Call Agent sends a re-INVITE to the originating Call Agent with the updated SDP.

终止呼叫代理使用更新的SDP向发起呼叫代理发送重新邀请。

Step 17:

步骤17：

The originating Call Agent then sends a ModifyConnection command to the originating gateway:

然后，发起呼叫代理向发起网关发送ModifyConnection命令：

      MDCX 1003 ds/ds1-1/1@gw-o.example.net MGCP 1.0
      C: 1
      I: 1

      MDCX 1003 ds/ds1-1/1@gw-o.example.net MGCP 1.0
      C: 1
      I: 1

      v=0
      o=- 25678 753850 IN IP4 192.0.2.2
      s=-
      c=IN IP4 192.0.2.2
      t=0 0
      m=image 1296 udptl t38
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

      v=0
      o=- 25678 753850 IN IP4 192.0.2.2
      s=-
      c=IN IP4 192.0.2.2
      t=0 0
      m=image 1296 udptl t38
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

Step 18:

步骤18：

The originating gateway changes to T.38 and sends back a success response with updated SDP:

发起网关更改为T.38，并使用更新的SDP发回成功响应：

200 1003 OK

2001003好

      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
      o=- 25678 753850 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=image 3456 udptl t38
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

Step 19:

步骤19：

The originating Call Agent sends a SIP 200 OK response with the updated SDP to the terminating Call Agent, which in turn sends a SIP ACK (not shown).

发起呼叫代理向终止呼叫代理发送带有更新的SDP的SIP 200 OK响应，终止呼叫代理随后发送SIP ACK（未示出）。

Step 20:

步骤20：

The terminating Call Agent sends a ModifyConnection with the updated SDP to the terminating gateway:

终止呼叫代理向终止网关发送带有更新SDP的ModifyConnection：

      MDCX 2003 ds/ds1-1/2@gw-t.example.net MGCP 1.0
      C: 2
      I: 2

      MDCX 2003 ds/ds1-1/2@gw-t.example.net MGCP 1.0
      C: 2
      I: 2

      v=0
      o=- 25678 753850 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=image 3456 udptl t38
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

      v=0
      o=- 25678 753850 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=image 3456 udptl t38
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

Step 21:

步骤21：

The terminating gateway sends back a success response:

终止网关发回成功响应：

200 2003 OK

2002002003OK

Since the terminating gateway now has a RemoteConnectionDescriptor with "image/t38" as valid media, it can start exchanging T.38 with the originating gateway.

由于终止网关现在有一个RemoteConnectionDescriptor，其中“image/t38”作为有效介质，因此它可以开始与发起网关交换T.38。

Steps 22, 23:

步骤22、23：

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

      NTFY 2501 ds/ds1-1/2@gw-t.example.net MGCP 1.0
      O: t38(stop)
      X: 21

Step 24:

步骤24：

The Call Agent acknowledges the Notify command:

呼叫代理确认Notify命令：

200 2501 OK

2002501好

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.

传真电话现在结束了。呼叫代理现在可能决定更改回语音编解码器、删除连接或执行其他操作。

3.3. Interaction with SIP Endpoints

3.3. 与SIP端点的交互

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            |               |               |
    ------------------------------------------------------------------

    ------------------------------------------------------------------
   | #|     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:

呼叫代理向网关发出CreateConnection命令，指示其使用PCMU媒体编码并使用松散呼叫代理控制的T.38过程。因此，呼叫代理请求网关通知其“t38”事件：

      CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
      C: 1
      L: a:PCMU, fxr/fx:t38-loose
      M: recvonly
      R: fxr/t38
      X: 1

      CRCX 1000 ds/ds1-1/1@gw-o.example.net MGCP 1.0
      C: 1
      L: a:PCMU, fxr/fx:t38-loose
      M: recvonly
      R: fxr/t38
      X: 1

Step 2:

步骤2：

The gateway acknowledges the command and includes SDP with codec information and RFC 3407 [RFC3407] capability information:

网关确认该命令，并包括带有编解码器信息的SDP和RFC 3407[RFC3407]功能信息：

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
      o=- 25678 753849 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 3456 RTP/AVP 0
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

Step 3:

步骤3：

The originating SIP User Agent (UA) sends a SIP INVITE message with the SDP to the terminating Call Agent (not all SIP details shown here):

发起SIP用户代理（UA）使用SDP向终止呼叫代理发送SIP INVITE消息（此处未显示所有SIP详细信息）：

      INVITE sip:bob@biloxi.example.com SIP/2.0
      ...
      Content-Type: application/sdp
      Content-Length: 167

      INVITE sip:bob@biloxi.example.com SIP/2.0
      ...
      Content-Type: application/sdp
      Content-Length: 167

      v=0
      o=- 25678 753849 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 3456 RTP/AVP 0
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

      v=0
      o=- 25678 753849 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 3456 RTP/AVP 0
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

Step 4:

步骤4：

The terminating SIP User Agent sends back a SIP 200 OK response (not all SIP details shown) to the originating Call Agent:

终止SIP用户代理向发起呼叫代理发回SIP 200 OK响应（未显示所有SIP详细信息）：

      SIP/2.0 200 OK
      ...
      Content-Type: application/sdp
      Content-Length: 100

      SIP/2.0 200 OK
      ...
      Content-Type: application/sdp
      Content-Length: 100

v=0 o=- 25678 753849 IN IP4 192.0.2.2 s=- c=IN IP4 192.0.2.2 t=0 0 m=audio 1296 RTP/AVP 0

v=0 o=-25678 753849在IP4 192.0.2.2中s=-c=在IP4 192.0.2.2中t=0 0 m=音频1296 RTP/AVP 0

Note that the terminating SIP User Agent does not use the RFC 3407 [RFC3407] capability descriptor to indicate support for (or lack of support for) T.38.

请注意，终止SIP用户代理不使用RFC 3407[RFC3407]功能描述符来表示支持（或不支持）T.38。

Step 5:

步骤5：

The originating Call Agent receives the SIP 200 response and sends a SIP ACK message to the terminating SIP UA.

发起呼叫代理接收SIP 200响应并向终止SIP 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

v=0 o=-25678 753849在IP4 192.0.2.2中s=-c=在IP4 192.0.2.2中t=0 0 m=音频1296 RTP/AVP 0

The ModifyConnection command does not repeat the LocalConnectionOptions sent previously. As far as fax handling is concerned, the gateway therefore attempts to continue using the current fax handling procedure, i.e., loose Call Agent controlled T.38. The T.38 loose procedure can always be supported, and hence a switch to T.38 will be attempted if the originating gateway detects a fax call.

ModifyConnection命令不会重复先前发送的LocalConnectionOptions。就传真处理而言，网关因此尝试继续使用当前传真处理程序，即松散呼叫代理控制的T.38。始终支持T.38松散过程，因此，如果始发网关检测到传真呼叫，将尝试切换到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编码建立呼叫，如果检测到传真呼叫，呼叫代理控制的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，并且在检测到传真呼叫时，尝试更改为T.38。因此，它向发起呼叫代理发送重新邀请，更新后的SDP指示切换到T.38。

      INVITE sip:ca@ca-o.example.net SIP/2.0
      ...
      Content-Type: application/sdp
      Content-Length: 100

      INVITE sip:ca@ca-o.example.net SIP/2.0
      ...
      Content-Type: application/sdp
      Content-Length: 100

v=0 o=- 25678 753850 IN IP4 192.0.2.2 s=- c=IN IP4 192.0.2.2 t=0 0 m=image 1296 udptl t38

v=0 o=-25678 753850在IP4 192.0.2.2中s=-c=在IP4 192.0.2.2中t=0 0 m=图像1296 udptl t38

Step 11:

步骤11：

The originating Call Agent then sends a ModifyConnection command to the originating gateway:

然后，发起呼叫代理向发起网关发送ModifyConnection命令：

      MDCX 1003 ds/ds1-1/1@gw-o.example.net MGCP 1.0
      C: 1
      I: 1

      MDCX 1003 ds/ds1-1/1@gw-o.example.net MGCP 1.0
      C: 1
      I: 1

v=0 o=- 25678 753850 IN IP4 192.0.2.2 s=- c=IN IP4 192.0.2.2 t=0 0 m=image 1296 udptl t38

v=0 o=-25678 753850在IP4 192.0.2.2中s=-c=在IP4 192.0.2.2中t=0 0 m=图像1296 udptl t38

Step 12:

步骤12：

The originating gateway changes to T.38 and sends back a success response with updated SDP:

发起网关更改为T.38，并使用更新的SDP发回成功响应：

200 1003 OK

2001003好

      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
      o=- 25678 753850 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=image 3456 udptl t38
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

Step 13:

步骤13：

The originating Call Agent sends a SIP 200 OK response with the updated SDP to the terminating SIP User Agent:

发起呼叫代理向终止SIP用户代理发送带有更新SDP的SIP 200 OK响应：

      SIP/2.0 200 OK
      ...
      Content-Type: application/sdp
      Content-Length: 167

      SIP/2.0 200 OK
      ...
      Content-Type: application/sdp
      Content-Length: 167

      v=0
      o=- 25678 753850 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=image 3456 udptl t38
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

      v=0
      o=- 25678 753850 IN IP4 192.0.2.1
      s=-
      c=IN IP4 192.0.2.1
      t=0 0
      m=image 3456 udptl t38
      a=sqn: 0
      a=cdsc: 1 audio RTP/AVP 0 18
      a=cdsc: 3 image udptl t38

Step 14:

步骤14：

The terminating SIP User Agent receives the SIP 200 and sends a SIP ACK.

终止SIP用户代理接收SIP 200并发送SIP ACK。

Since the terminating SIP User Agent now has a RemoteConnectionDescriptor with "image/t38" as valid media, it can start exchanging T.38 with the originating gateway (and vice versa).

由于终止SIP用户代理现在有一个RemoteConnectionDescriptor，其中“image/t38”作为有效介质，因此它可以开始与发起网关交换T.38（反之亦然）。

Steps 15, 16:

步骤15、16：

The originating endpoint detects V.21 fax preamble. Even though the endpoint is already using "image/t38" for media, it generates a "t38(start)" event and notifies the Call Agent.

发起端点检测V.21传真前导码。即使端点已经在为媒体使用“image/t38”，它也会生成“t38（start）”事件并通知呼叫代理。

      NTFY 3500 ds/ds1-1/1@gw-o.example.net MGCP 1.0
      O: fxr/t38(start)
      X: 1

      NTFY 3500 ds/ds1-1/1@gw-o.example.net MGCP 1.0
      O: fxr/t38(start)
      X: 1

Steps 17, 18:

步骤17、18：

The Call Agent acknowledges the Notify command and issues a new (piggybacked) request for notification of the T38 event.

呼叫代理确认Notify命令，并发出新的（搭载的）T38事件通知请求。

200 3500 OK . RQNT 1004 ds/ds1-1/1@gw-o.example.net MGCP 1.0 R: fxr/t38 X: 2

200 3500正常。RQNT 1004 ds/ds1-1/1@gw-o、示例.net MGCP 1.0 R:fxr/t38 X:2

Step 19:

步骤19：

The gateway acknowledges the command.

网关确认该命令。

200 1004 OK

2001004好

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 BYE消息，呼叫代理用SIP 200响应该消息。

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(stop) X: 2

Step 24:

步骤24：

The Call Agent acknowledges the Notify command:

呼叫代理确认Notify命令：

200 3502 OK

2003502好

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.

传真电话现在结束了。呼叫代理现在可能决定更改回语音编解码器、删除连接或执行其他操作。

4. Security Considerations

4. 安全考虑

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的传真本地连接选项，即应使用“关闭”（或新的安全扩展）传真本地连接选项。

5. IANA Considerations

5. IANA考虑

IANA has registered the following MGCP package:

IANA已注册以下MGCP包：

      Package Title         Name     Version
      -------------         ----     -------
      Fax                   FXR        0

      Package Title         Name     Version
      -------------         ----     -------
      Fax                   FXR        0

6. Normative References

6. 规范性引用文件

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。

[RFC3435] Andreasen, F. and B. Foster, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 3435, January 2003.

[RFC3435]Andreasen，F.和B.Foster，“媒体网关控制协议（MGCP）1.0版”，RFC 3435，2003年1月。

[T38] ITU-T Recommendation T.38, "Procedures for real-time Group 3 facsimile communication over IP networks", March 2002.

[T38]ITU-T建议T.38，“通过IP网络进行实时第3组传真通信的程序”，2002年3月。

[RFC3407] Andreasen, F., "Session Description Protocol (SDP) Simple Capability Declaration", RFC 3407, October 2002.

[RFC3407]Andreasen，F.，“会话描述协议（SDP）简单能力声明”，RFC3407，2002年10月。

7. Informative References

7. 资料性引用

[T30] ITU-T Recommendation T.30, "Procedures for document facsimile transmission in the general switched telephone network", July 2003.

[T30]ITU-T建议T.30，“通用交换电话网络中文件传真传输程序”，2003年7月。

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。

[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.

[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。

Acknowledgements

致谢

Several people have contributed to the development of the MGCP fax package. In particular, the author would like to thank Bill Foster, Paul Jones, Gary Kelly, Rajesh Kumar, Dave Horwitz, Hiroshi Tamura, Rob Thompson, and the CableLabs PacketCable NCS focus team for their contributions.

一些人为MGCP传真包的开发做出了贡献。特别是，作者要感谢比尔·福斯特、保罗·琼斯、加里·凯利、拉杰什·库马尔、戴夫·霍维茨、田村弘、罗布·汤普森和CableLabs PacketCable NCS焦点小组的贡献。

Authors' Addresses

作者地址

Flemming Andreasen Cisco Systems 499 Thornall Street, 8th Floor Edison, NJ 08837

弗莱明·安德里森思科系统公司，地址：新泽西州爱迪生市索纳尔街499号8楼，邮编：08837

   EMail: fandreas@cisco.com

   EMail: fandreas@cisco.com

David Hancock CableLabs 858 Coal Creek Circle Louisville, CO 80027

David Hancock CableLabs 858美国科罗拉多州路易斯维尔市煤溪圈80027

   EMail: d.hancock@cablelabs.com

   EMail: d.hancock@cablelabs.com

Full Copyright Statement

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。

Intellectual Property

知识产权

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.