T38 Fax Relay

Tue, 09 Feb 2016 | Voice Gateways

T.38 is a fax relay standard defined by the ITU-T. Because it is a standard, T.38 is now the predominant choice for fax relay scenarios, especially in networks where multivendor interoperability is necessary.

Cisco voice gateways fully support the original 1998 version of the T.38 specification. Although later versions of T.38 introduce such features as Real-Time Protocol (RTP) encapsulation and support for SG3/V.34 faxing, these are not discussed in this chapter. Only the aspects of T.38 related to the Cisco-supported 1998 version are covered.

T.38 defines three transport methods: UDP, TCP, and RTP. Currently, Cisco voice gateways only use UDP encapsulation as diagrammed in Figure 5-4. The TCP encapsulation method is optional, and RTP encapsulation is introduced in a later version of the T.38 specification.

Figure 5-4 UDP Encapsulated T.38

Figure 5-4 UDP Encapsulated T.38

2 Bytes

For T.38 to provide additional error control when using UDP, a UDP transport layer (UDPTL) header is included. This header is simply a 2-byte sequence number to assist in internet fax packet (IFP) reordering at the receiving gateway. Also, the T.38 UDPTL encapsulation does not use an assigned UDP port number. In the case of Cisco voice gateways, the existing RTP port numbers set up during the initial voice call are reused by T.38 fax relay.

Inside the UDPTL payload, IFPs transport the T.30 and T.4 fax information. Optional redundancy or forward error checking (FEC) packets may also reside in the UDPTL payload.

There are two types of IFPs: T30_INDICATOR packets and T30_DATA packets. Indicator packets signal T.30 messages such as calling tone (CNG), called terminal identification (CED), and the various trainings for different modulations, while T30_DATA handles the HDLC message framing and the transmission of fax page data.

Both of these IFP types include a sequence number. Upon transmission of a T30_INDICATOR or T30_DATA IFP, this sequence number becomes the UDPTL header. When this occurs, the IFP packet immediately following the UDPTL header in the UDPTL payload is referred to as the primary. Additional IFPs can be included after the primary, and these are referred to as secondaries. Secondary IFP packets are mostly seen when an error correction method such as redundancy is used. Redundancy for T.38 fax relay along with primary and secondary IFPs are discussed later in this section. The IFP format for a T30_INDICATOR packet is illustrated in Figure 5-5.

Figure 5-5 T.38 T30JNDICATORIFP Frame Format

16 bit Sequence Number

IFP Size (bytes)

Data Field

Type

T30_INDICATOR

Fill

The T30_INDICATOR packet is only 2 bytes, not including the sequence number. The most important field is the T30_INDICATOR field itself, and the value here specifies the exact T.30 message that is being signaled. Table 5-1 defines the T30_INDICATOR field and the other fields that make up this IFP.

Table 5-1 T.38 T30_INDICATOR IFP Frame Field Definitions

Field Name

Value

Definition

Sequence Number

0x00-0x1111

16-bit sequence number to uniquely identify the IFP

IFP Size (in bytes)

1

1-byte for T30_INDICATOR packets (does not include sequence number or IFP Size fields)

Data Field

0

Only set when optional data field is present

Type

0

T30_INDICAT0R message

T30_INDICATOR

0x00

No Signal

0x01

CNG

0x02

CED

0x03

V.21 Preamble (HDLC flags)

0x04

V.27 2400 bps training

0x05

V.27 4800 bps training

0x06

V.29 7200 bps training

0x07

V.29 9600 bps training

0x08

V.17 7200 bps short training

0x09

V.17 7200 bps long training

continues continues

Table 5-1 T.38 T30JNDICATOR IFP Frame Field Definitions (Continued)

Field Name

Value

Definition

T30_INDICATOR (Continued)

0x0a

V.17 9600 bps short training

0x0b

V.17 9600 bps long training

0x0c

V.17 12000 bps short training

0x0d

V.17 12000 bps long training

0x0e

V.17 14400 bps short training

0x0f

V.17 14400 bps long training

Fill

0

Last bit set to 0

The T30_INDICATOR IFP provides an efficient method for transporting fax signals across VoIP. Instead of CNG and CED tones and training signals being captured and played out on the far side, T.38 uses a simple T30_INDICATOR IFP message. This saves bandwidth and processing time on the voice gateways.

NOTE As Figure 5-3 illustrates, Cisco voice gateways do not switch over to T.38 fax relay until the V.21 preamble or fax flags are detected. Because the CNG and CED signals are transmitted before the V.21 preamble and the subsequent switchover to T.38 fax relay, the CNG and CED signals are passed using the original voice codec in the RTP media stream. Therefore, the CNG and CED T30_INDICATOR messages are not typically seen with Cisco gateways. However, other vendors do use these messages frequently, and they can be seen when Cisco voice gateways interoperate with third-party T.38 devices.

An interesting T30_INDICATOR message to note is No Signal. This message specifies that there is currently not a TDM fax signal present on the voice gateway. When fax signals are not being received on the telephony interface, Cisco gateways tend to send this message quite regularly, whereas other brands of voice gateways might send this message more sparingly.

The other IFP packet type found in T.38 is T30_DATA. These packets handle the T.30 HDLC control information and the Phase C image data. The frame format for a T30_DATA IFP is diagrammed in Figure 5-6.

Figure 5-6 T.38 T30_DATA IFP Frame Format

First Field Type

Second Field Type

First Field Type

Second Field Type

16 bit Sequence Number

IFP Size (bytes)

Data/ Field

Type T30_DATA TYPE

Fill

Data Field Count

Data/ No Data

Field-Type

Fill

Fill

Fill

Fill

Length of Data Field (in bytes, N)

Data Byte 0

Data Byte 1

Data Byte 2

Data Byte N

Data/ No Data

Field-Type

Fill

Fill

Fill

Fill

Length of Data Field (in bytes, M)

Data Byte 0

Data Byte 1

Data Byte 2

Data Byte M

The T30_DATA packet contains some fields that are the same as those found in the T30_ INDICATOR message. However, there are also a number of new fields that may contain a range of values. Table 5-2 details each of the IFP frame fields and their values for a T.38 T30_DATA packet.

Table 5-2 T.38 T30_DATA IFP Frame Field Definitions

Field Name

Value

Definition

Sequence Number

0x00-0x1111

16-bit sequence number to uniquely identify IFP frames.

IFP Size (in bytes)

0x00-0x11

Length measured from first Data Field to last Data Byte N, not including IFP Size field.

Data Field

1

Data Field is present.

Type

1

T30_DATA message.

continues continues

Table 5-2 T.38 T30_DATA IFP Frame Field Definitions (Continued)

Field Name

Value

Definition

T30_DATA TYPE

0x00

V.21 300 bps.

0x01

V.27 2400 bps.

0x02

V.27 4800 bps.

0x03

V.29 7200 bps.

0x04

V.29 9600 bps.

0x05

V.17 7200 bps.

0x06

V.17 9600 bps.

0x07

V.17 12000 bps.

0x08

V.17 14400 bps.

Data Field Count

Variable

Number of data fields in IFP packet. Each data field consists of Data/No Data Indicator, Field-Type, Length of Data Field (optional), and Data Bytes (optional).

Data/No Data

1

Current Data Field has data.

Indicator

0

Current Data Field does not have data.

Field-Type

0x0

HDLC data. (Data bytes that follow contain some or all of a fax HDLC frame.)

0x1

HDLC-Sig-end. (HDLC signaling has ended; no data bytes with this Field-Type.)

0x2

HDLC-FCS-OK. (Indicates the end of an HDLC frame and correct FCS has been received; no data bytes with this Field-Type.)

0x3

HDLC-FCS-BAD. (Indicates the end of an HDLC frame and the FCS is incorrect; no data bytes with this Field-Type.)

0x4

HDLC-FCS-OK-Sig-End. (Indicates the end of an HDLC frame and a correct FCS has been received; no additional HDLC frames follow this one; no data bytes with this Field-Type.)
Table 5-2 T.38 T30_DATA IFP Frame Field Definitions (Continued)

Field Name

Value

Definition

Field-Type (Continued)

0x5

HDLC-FCS-BAD-Sig-End. (Indicates the end of an HDLC frame and an incorrect FCS has been received; no additional HDLC frames follow this one; no data bytes with this Field-Type.)

0x6

T.4-Non-ECM. (T.4 image data that is not sent using Error Correction Mode [ECM] or Training Check Function [TCF] data; additional data will follow.)

0x7

T.4-Non-ECM-Sig-End. (T.4 image data that is not sent using ECM or TCF data; end of data.)

Length of Data Field

0x00 -0x1111

(Number of data bytes) - 1.

N/A

If Data/No Data is 0.

Fill

0

Last bit filled with a 0.

The shaded fields in Figure 5-6 illustrate how multiple Field-Types can be transported in the same T30_DATA IFP. The lighter shading indicates the first Field-Type and its information, and the darker shading highlights an additional Field-Type within the same IFP. One common example of multiple Field-Types in a single IFP may occur at the end of a T.30 message. The last portion of data for the T.30 message and the HDLC frame's FCS status can occupy the same IFP and a Field-Type of HDLC Data and HDLC-FCS-OK will be present.

On the other hand, when there are large HDLC frames present, such as during the transfer of fax image data, it might be necessary to separate an HDLC frame into multiple packets. Although sending large T.38 packets is possible, the T.38 standard recommends that smaller packets be sent. Figure 5-7 illustrates this concept by showing how a T.30 digital identification signal (DIS) message is broken into IFP packets by a Cisco voice gateway. Note that the data transport headers are not shown, and only the basic IFP fields of T30_DATA TYPE and Field-Type are shown for simplicity.

Figure 5-7 Segmenting of a T.30 Message into T.38 IFPs

HDLC

Flag

Address

Control

T:30 DIS Information

FCS

Flag

Frame

0x7E

0xFF

0xC8

0x01007315010188

Figure 5-7 Segmenting of a T.30 Message into T.38 IFPs

IFP #2
« 
 »

Related Posts

Post a comment

IFP #3

T30_DATA

Field-

TYPE

Type:

DIS

V.21

HDLC

(0x01)

(300 bps)

Data

T30_DATA TYPE V.21 (300 bps)

Field-Type: HDLC Data

T30_DATA TYPE V.21 (300 bps)

T30_DATA

Field-

TYPE

Type:

DIS

V.21

HDLC

(0x73)

(300 bps)

Data

Field-Type: HDLC Data

T30_DATA TYPE V.21 (300 bps)

DIS (0x15)

Field-Type: HDLC Data

DIS (0x01)

Field-Type: HDLC Data

T30_DATA

Field-

TYPE

Type:

DIS

V.21

HDLC

(0x01)

(300 bps)

Data

IFP #9

T30_DATA

Field-

Field-

TYPE:

Type:

DIS

Type:

V.21

HDLC

(0x88)

HDLC

(300 bps)

Data

FCS-OK

At the top of Figure 5-7, an HDLC frame carrying a T.30 DIS message is shown. The DIS message and its HDLC frame format was covered in detail in the section "DIS, NSF, and CSI Messages" in Chapter 2, "How Fax Works." When packaging the information from this

DIS HDLC frame into T.38 IFPs, the flags are stripped off, and only the shaded portion of the HDLC frame is transported.

Under the HDLC frame in Figure 5-7, nine IFPs are shown. Each of these IFPs is encapsulated in UDPTL and sent across an IP network as a separate packet. The Cisco voice gateway stuffs only 1 byte from this DIS HDLC frame into each IFP. Consequently, nine IFP packets are needed for transporting this HDLC frame via T.38 fax relay. Be aware that other vendor's implementations may not use numerous, small IFPs for the transport of this same frame. A vendor might opt for a single, larger IFP instead.

Two important fields highlighted in the IFPs in Figure 5-7 are T30_DATA TYPE and Field-Type. Because a DIS HDLC frame is V.21 modulated at 300 bps, the T30_DATA TYPE is set to V.21. The Field-Type is set to HDLC Data for each IFP where a data byte from the DIS HDLC frame is present.

Notice that the last IFP contains two Field-Types. The first Field-Type is set to HDLC Data, and it contains the last data byte from the DIS frame, 0x88. Following this data byte is the second Field-Type, HDLC-FCS-OK. This Field-Type indicates that the FCS for the DIS HDLC frame was received correctly. Also, it is important to note that the HDLC-FCS-OK Field-Type always has its Data/No Data Indicator field set to zero, so no data follows this Field-Type.

Now that the T.38 packet formats have been explained, it is important to visualize how these various T.38 packets form a typical T.38 call flow using Cisco voice gateways. Figure 5-8 illustrates how T.38 fax relay transports a fax call across an IP network.

As shown in Figure 5-8, the analog fax signals are received by each voice gateway and converted into T.38 T30_INDICAT0R and T30_DATA IFPs for transportation across the IP network. The T30_INDICATOR IFPs are lightly shaded in the diagram, and the darker shading represents T30_DATA IFPs. The T30_DATA IFPs also specify the T30_Data Type and Field-Type parameters for each message.

If the T.38 IFPs are removed from the center of Figure 5-8, this diagram illustrates most of the same concepts and messaging as Figure 2-9. However, Figure 5-8 integrates Cisco voice gateways into the path and shows how a basic fax transaction functions when it is transported by T.38 fax relay. From a fax machine perspective, the T.38 transport is not visible.

The CNG and CED tones are not present in Figure 5-8 because this diagram aims to show what the T.38 messaging looks like for a call between Cisco voice gateways. With Cisco voice gateways, the CNG and CED tones are carried by the voice codec and not seen in the T.38 messaging. In the case of other vendors, the CNG and CED tones may be passed via the appropriate T30_INDICAT0R messages.

Figure 5-8 Fax Call Flow Using T.38 Fax Relay

Originating Fax

V.21 Flags

V.21 Flags

TCF V.17 14400

V.21 Flags

V.17 14400 Training

Image Data

V.21 Flags

V.21 Flags

V.21 Flags

Originating Gateway

Terminating Gateway

T30_IND:Preamble

V.21:HDLC:CSI/FCS

V.21:HDLC:DIS/FCS

T30 IND:Preamble

V.21:HDLC:TSI/FCS

V.21:HDLC:DCS/FCS

T30_IND: V.17 1 4400 Long Training

V.17:T.4-Non-ECM:TCF (binary 0s): T.4-Non-ECM-Sig-End

T30 IND:Preamble

V.21:HDLC:CFR/FCS

T30_IND: V.17 14400 Short Training

T30_IND:Preamble

V.21:HDLC:EOP/FCS

T30 IND:Preamble

V.21:HDLC:MCF/FCS

T30_IND:Preamble

V.21:HDLC:DCN/FCS

V.21 Flags

V.21 Flags

TCF V.17 14400

V.21 Flags

V.17 14400 Training

Image Data

V.21 Flags

V.21 Flags

V.21 Flags

Terminating Fax

Figure 5-8 begins with the terminating fax machine transmitting a T.30 called subscriber identification (CSI) and DIS message. These messages are preceded by a T30_INDICATOR message where the Type field is set to V.21 Preamble, which indicates the presence of V.21

modulated HDLC flags. T30_DATA IFPs with the T30_DATA TYPE set to V.21 and the Field-Type set to HDLC Data actually carry the CSI and DIS frames. An equivalent process is used to transport the T.30 transmitting subscriber identification (TSI) and digital command signal (DCS) messages from the originating fax machine.

The training or TCF occurs next in Figure 5-8. The T.38 specification defines two methods for handling the TCF training signal. These two methods are formally known as data rate management method 1 and data rate management method 2.

Data rate management 1 requires that the TCF is regenerated locally by the terminating gateway. The actual TCF data stream is not propagated across the T.38 session. This method is used with TCP encapsulated T.38, and it is optional for the UDP encapsulation.

Data rate management 2 passes the TCF bits within the T.38 session. This method of data rate management is used by Cisco voice gateways and is shown in Figure 5-8. A 14400 bps TCF is transported across T.38 using a T30_INDICAT0R packet that signals a V.17 14400 bps long training, and then a T30_DATA T.4-Non-ECM packet carries the binary 0s of the actual training pattern. For more information on the TCF message, see the section "TCF, CFR, and FTT Messages" in Chapter 2.

After the training has been confirmed with a T.30 CFR message, the fax page data is transmitted. A T30_INDICAT0R message signals a short training before the page data is sent using T30_DATA messages. The first message, T.4-Non-ECM, is transmitted for each IFP containing actual page data. After all the page data has been transmitted the T30_DATA message, T.4-Non-ECM-Sig-End is sent to signal the end of the page transmission.

The fax call is torn down after one page is sent using the T.30 end of procedure (EOP), message confirmation (MCF), and disconnect (DCN) messages. The transport of these messages follows the procedures for the CSI, DIS, TSI, and DCS messages from the beginning of the call.

T.38 is capable of different error correction features like FEC and redundancy. Although these features are optional, Cisco voice gateways support redundancy rather than FEC. This is a configurable option for both the low-speed V.21 messages and the high-speed training and data-transfer messages. Figure 5-9 illustrates how two redundant T.38 IFPs are transported along with a primary IFP in a UDTPL packet.

In Figure 5-9, the first data field at the top of the frame is the UDPTL header. As mentioned previously, the UDPTL header is just the sequence number that references the primary T.38 IFP. The primary T.38 IFP is composed of the lightly shaded fields following the sequence number.

When T.38 redundancy is enabled, a 2-byte field specifying the number of redundant IFPs is present. In the case of Figure 5-9, this field would be set to a value of 0x0002, which indicates that two redundant IFPs follow.

Notice in Figure 5-9 that sequence numbers are not present for the redundant IFP messages. Instead, the redundant IFPs always are an offset of the primary IFP's sequence number that is defined in the UDPTL header. The first redundant IFP's sequence number is one less than the sequence number of the primary IFP, and the second redundant IFP's sequence number is two less. Because the sequence numbers for the redundant IFP messages always follow this format, only the sequence number for the primary IFP in the UDPTL header is necessary. Therefore, with a redundancy level of two as shown in Figure 5-9, every T.38 packet will be composed of the current primary IFP and redundant copies of the two previous primary IFP messages.

Figure 5-9 T.38 Redundancy Frame Format

UDPTL Header

Primary IFP

(Associated with the sequence number in the UDPTL header)

Redundant IFP 1

(Sequence number is one less than the Primary IFPs)

Redundant IFP 2

(Sequence number is two less than the Primary IFPs)

Primary IFP

(Associated with the sequence number in the UDPTL header)

Redundant IFP 1

(Sequence number is one less than the Primary IFPs)

Redundant IFP 2

(Sequence number is two less than the Primary IFPs)

16 bit Sequence Number

IFP Size (bytes)

Data/ Field

Type

T30_DATA TYPE

Fill

Data Field Count

Data/ No Data

Field-Type

Fill

Fill

Fill

Fill

Length of Data Field (in bytes, X)

Data Byte 0

Data Byte 1

Data Byte 2

...Data Byte X

Number of Redundant IFPs

IFP Size (bytes)

Data/ Field

Type

T30_DATA TYPE

Fill

Data Field Count

Data/ No Data

Field-Type

Fill

Fill

Fill

Fill

Length of Data Field (in bytes, Y)

Data Byte 0

Data Byte 1

Data Byte 2

.Data Byte Y

IFP Size (bytes)

Data/ Field

Type

T30_DATA TYPE

Fill

Data Field Count

Data/ No Data

Field-Type

Fill

Fill

Fill

Fill

Length of Data Field (in bytes, Z)

Data Byte 0

Data Byte 1

Data Byte 2

8 bits

Both the primary and redundant IFP messages in Figure 5-9 can have a varying number of data bytes. For the low-speed T.30 messages, Cisco voice gateways typically only have 1 byte of data, as illustrated previously in Figure 5-7. However, during the high-speed transmission of the page data, many data bytes are present. Therefore, Figure 5-9 uses the field names of Data Byte X, Data Byte Y, and Data Byte Z to represent the varying amounts of data bytes that may exist in each IFP message.

In addition to understanding how the T.38 fax relay protocol works, you must understand how a Cisco voice gateway transitions to this fax transport protocol. Cisco voice gateways can transition from voice mode to T.38 fax relay using one of two signaling methods. One method is based on NSE packets, and the other takes advantage of the voice signaling protocol to effect the T.38 switchover.

NSE-Based Switchover for T.38

The proprietary NSE switchover method for T.38 fax relay is similar to the use of NSE messages during modem passthrough. The main difference is that unique NSE event IDs for T.38 fax switchover are used that are different from the event IDs used for modem passthrough. Table 5-3 lists the NSE event IDs found in an NSE-based T.38 fax relay switchover. For more information on NSE messages and their exact format within RTP, see the section "NSE-Based Passthrough" in Chapter 4, "Passthrough."

Table 5-3 NSE Event IDs for T.38 Fax Relay Switchover

NSE Event ID

Explanation

200

Instructs the peer gateway to switch over to T.38.

201

An ACK to an NSE-200 confirming that the peer gateway has initiated a

switchover to T.38 and is ready to accept T.38 packets.

202

This is a NACK to an NSE-200 message signifying that the peer gateway

cannot process T.38 packets for the call. The call will remain in voice mode and

not switch over to T.38.

When a Cisco voice gateway is configured to use Cisco Named Signaling Events (NSE) for switching over to T.38, the signaling protocol in use (H.323, Session Initiation Protocol [SIP], Media Gateway Control Protocol [MGCP], or Skinny Client Control Protocol [SCCP]) is not involved or even aware that this switchover is taking place. The voice gateways themselves control the switchover within the RTP media stream that has already been set up by the signaling protocol. Figure 5-10 details a T.38 fax switchover using Cisco proprietary NSE packets.

Figure 5-10 T.38 Fax Relay Switchover Using NSE Packets

Sending Fax Machine

Figure 5-10 T.38 Fax Relay Switchover Using NSE Packets

Sending Fax Machine

Fax passthrough call is established if NSE passthrough is configured on the voice gateways. Otherwise, this step does not occur.

Answering Fax Machine

Fax passthrough call is established if NSE passthrough is configured on the voice gateways. Otherwise, this step does not occur.

OGW: Transition from voice mode to T.38

Fax Passthrough Call

NSE-200

NSE-201

T.38 Fax Relay Call

Answering Fax Machine

CED Tone

V.21 Preamble

TGW: T.38 ACK received, start T.38 session

Notice in Figure 5-10 that the fax call will actually transition to passthrough first if NSE-based passthrough has been configured. As discussed in the preceding chapter, NSE-based passthrough is triggered by the 2100 Hz fax CED tone, whereas T.38 will not be activated until later in the call when the fax V.21 preamble is detected. If NSE-based passthrough is not configured on the Cisco voice gateway, the 2100 Hz fax CED tone is ignored, and the call transitions straight to T.38 fax relay from voice mode upon detection of the V.21 preamble.

Even though the NSE switchover occurs independently of the voice signaling protocol, a Cisco voice gateway will still announce its support of an NSE-based switchover. This announcement is listed as a nonstandard capability in the H.245 terminal capability set (TCS) message for H.323, and it is present as an X-NSE line in the Session Description Protocol (SDP) portion of both SIP and MGCP messages. The purpose of this announcement is to validate ahead of time that both voice gateways will support an NSE-based switchover should one be necessary at any point during the VoIP call. The NSE values for both passthrough and T.38 are communicated using these methods. You can find more detailed information concerning this announcement of NSE switchover support in the section "Troubleshooting NSE-Based Switchovers" in Chapter 12, "Troubleshooting Passthrough and Relay."

Protocol-Based Switchover for T.38

The handling of the T.38 switchover by the call signaling protocol is another method for handling the gateway transition from voice mode to T.38 fax relay. This method must be used for Cisco voice gateways to interoperate with other vendor's equipment.

The three call signaling protocols supported by Cisco voice gateways for a T.38 switchover are H.323, SIP, and MGCP. As opposed to a T.38 switchover using NSEs, a protocol-based T.38 switchover uses the call control protocol for complete control of the transition from voice mode to T.38 fax relay.

For the H.323 call signaling protocol, the initial voice call is established using the underlying H.225 and H.245 protocols. When the fax V.21 preamble is detected by the terminating gateway (TGW), the voice gateways exchange H.245 request mode messages that establish the T.38 parameters for the fax relay session. Then, new media channels are created while the initial voice channels are closed. Figure 5-11 illustrates the T.38 fax relay switchover procedure for the H.323 protocol stack.

When SIP is the call signaling protocol, a mid-call INVITE message triggers the T.38 fax relay switchover process. This mid-call INVITE or re-INVITE message contains the request from the TGW to change the media stream from voice to T.38. Specific T.38 capabilities and parameter settings are included, too, in this re-INVITE, along with the socket information for the upcoming T.38 session.

The originating gateway (OGW) accepts this media change from voice mode to T.38 with a SIP 200 OK message. The SIP 200 OK message confirms the T.38 session parameters while providing the IP socket information for the OGW. Figure 5-12 illustrates the SIP messaging that occurs for a T.38 fax relay switchover.

Figure 5-11 T.38 Fax Relay Switchover for H.323

Sending Fax Machine

Figure 5-11 T.38 Fax Relay Switchover for H.323

Sending Fax Machine

TGW

Answering Fax Machine

Fax passthrough call is established if NSE passthrough is configured on the voice gateways. Otherwise, this step does not occur.

T.38 parameters for the upcoming fax relay session are negotiated in the H.245 Request Mode messages.

Fax Passthrough Call

H.245 Request Mode T.38

H.245 Request Mode T.38 ACK

H.245 Close Logical Channel - Voice

H.245 Open Logical Channel - T.38

H.245 Close Logical Channel - Voice

H.245 Open Logical Channel - T.38

H.245 Close Logical Channel - Voice ACK

H.245 Close Logical Channel - Voice ACK

H.245 Open Logical Channel - T.38 ACK

H.245 Open Logical Channel - T.38 ACK

T.38 Fax Relay Call

Answering Fax Machine

CED Tone

V.21 Preamble

Each gateway closes its voice media channel and opens a T.38 fax relay media channel while acknowledging the same events by the other side.

Figure 5-12 T.38 Fax Relay Switchover for SIP

Sending Fax Machine

Sending Fax Machine

Fax passthrough call is established if NSE passthrough is configured on the voice gateways. Otherwise, this step does not occur.

T.38 parameters for the upcoming fax relay session are negotiated in the SIP INVITE and 200 OK messages.

Fax Passthrough Call

SIP INVITE for T.38 mode

SIP 100 Trying

SIP 200 OK

SIP ACK

T.38 Fax Relay Call

Answering Fax Machine

Answering Fax Machine

CED Tone

V.21 Preamble

T.38 fax relay switchover process using the

SIP protocol stack is complete.

A transition from a voice call to a T.38 fax relay call can also occur using the MGCP protocol stack. Although both H.323 and SIP can handle their switchovers with messages directly between the gateways, MGCP gateways must communicate through a call agent (CA). Figure 5-13 illustrates a T.38 switchover using the MGCP protocol stack.

Figure 5-13 T.38 Fax Relay Switchover for MGCP

MGCP

MGCP

Sending Fax Machine

Sending Fax Machine

Fax passthrough call is established if NSE passthrough is configured on the voice gateways. Otherwise, this step does not occur.

CA instructs OGW to switchover to

T.38 with an MDCX message.

Call Agent I

Call Agent I

Answering Fax Machine

VoIP Call - MGCP Signaling -1-

Fax Passthrough Call

MGCP NTFY

O: FXR/t38(start) 200 OK

200 OK

Answering Fax Machine

CED Tone

V.21 Preamble

TGW notifies the CA that fax V.21 flags are detected.

CA instructs TGW to switchover to

T.38 with an MDCX message.

200 OK with SDP

T.38 Fax Relay Call

TIP A T.38 fax relay switchover within the MGCP protocol stack as shown in Figure 5-13 is referred to as CA-controlled mode. Using NSEs for the T.38 fax relay switchover with MGCP as illustrated previously in Figure 5-10 is known as gateway-controlled mode.

Upon detection of the V.21 fax preamble, the MGCP TGW signals the CA using a notify (NTFY) message. This message contains the important observed event of FXR/t38(start). With confirmation that a fax call is now present, the CA can now begin the switchover process to T.38 fax relay.

A modify connection (MDCX) message is sent to the TGW from the CA instructing a switchover from voice mode to T.38 mode. Within this MDCX message is T.38 parameter information and the media connection information for the OGW, including the IP address and port. Generally, the same IP address and port that were used for the initial voice call are reused for the T.38 call. When this is not the case, the call flow in Figure 5-13 will vary.

Another MDCX message is sent to the OGW instructing it to transition to T.38. Again, any T.38 parameter information along with the other gateway's connection information is included in this message.

Once both MDCX messages have been sent and acknowledged by MGCP 200 OK messages, the OGW and TGW have all the information necessary to start communicating using the T.38 protocol. The switchover to T.38 fax relay at this point is complete.

NOTE Although this section provides a general overview of the call flow for protocol-based T.38 switchovers involving the H.323, SIP, and MGCP protocols, more detailed analysis of the key, specific messages for each of these protocols is provided in the section "Troubleshooting Protocol-Based Switchovers" in Chapter 12.
0 0