Configuring Your Cisco IOS Gateway for T.37 On-Ramp and Off-Ramp Fax Support

Fax Call Flow

The fax call is established in phases. First, the call originator prepares a fax and dials a destination number. When the destination fax device picks up the call, the originator and destination are connected in voice call. However, to transition to fax transmission, one party must signal that it is a fax device.

Each device can send its signal using one of the following methods:

• The calling device sends a Calling Tone (CNG) tone, which identifies the calling party as a fax device
• The called device sends a Called Station Identifier (CED) tone, which identifies the called device as a fax machine

After the fax call is established, the devices identify the facilities and capabilities. The next phases are transmitting the content, signaling the end of the transmission and confirmation, and releasing the call. The Cisco IOS fax gateways support the following methods:

• Fax Pass-Through and Fax Pass-Through with Upspeed
• Cisco Fax Relay
• T.38 Fax Relay
• T.37 Store-and-Forward Fax
• IVR Applications for Fax

The T.37 Store-and-Forward Cisco IOS fax gateway uses the T.37 store-and-forward fax application, which consists of two processes:

• On-ramp
• Off-ramp

These processes are shown in Figure 3 and explained in the following sections.

Figure 3 T.37 Store and forward Call Flow

On-Ramp Faxing

With the On-ramp process, a voice gateway handles incoming calls from the standard fax machine or the PSTN and converts a traditional Group 3 fax to an e-mail message with a Tagged Image File Format (TIFF) attachment. The fax e-mail message and attachment are handled by an e-mail server while traversing the packet network. When acting as the On-ramp gateway, the Cisco gateway receives faxes from end users, converts them into TIFF files, creates standard MIME e-mail messages, attaches the TIFF files to the e-mail messages, and forwards the fax-mail messages to the designated SMTP server for storage. The gateway uses the sending MTA and dial peers to complete these tasks. The sending MTA, which is the Cisco gateway, defines delivery parameters associated with the e-mail message to which the fax TIFF file is attached. The delivery parameters include defining a return e-mail path or designating a destination mail server.

Off-Ramp Faxing

With the Off-ramp process, a voice gateway handles calls going out from the network to fax machine or the PSTN and converts a fax e-mail with TIFF attachment into a traditional fax format that can be delivered to a standard fax machine or the PSTN. Off-ramp faxing requires that the Cisco gateway act as an Off-ramp gateway to dial the POTS and communicate with a remote fax machine (Group 3 fax device), using standard fax protocols. The Off-ramp gateway provides the following functionality:

• Converts a fax-mail to TIFF file (or plain text file) into a standard format and delivers it to the recipient. The Store-and-Forward Fax application does not alter the TIFF or plain text file in any way from its original format when converting it into a standard fax format. The Off-ramp gateway uses the receiving MTA and dial peers to perform the conversion.
• Delivers an e-mail message as a standard fax transmission. The Cisco gateway generates information that is appended to the top of each faxed page (text-to-fax pages) and creates a fax cover sheet. The Off-ramp gateway uses the receiving MTA, dial peers, and commands specific to formatting the appended information and generating a fax cover sheet to deliver e-mail messages as fax transmissions.
• Uses only POTS dial peers to define the line characteristics between the forwarding Off-ramp gateway and the fax device. Optionally configure the MMoIP dial peers can be configured to define fax compression schemes and resolution. This option is useful only if those parameters are to be altered for the received fax-mails.
• Defines the parameters associated with the gateway SMTP server, using the receiving MTAs. This can be its SMTP host aliases, which can be different than its normal DNS hostnames, or internal Cisco IOS hostname.

---

Note You can combine On-ramp and Off-ramp faxing processes on a single gateway, or you can put them on separate gateways. Both On-ramp and Off-ramp are available with Cisco IOS Release 12.3(7) T or higher.

Using Separate DIDs for Fax

Using a separate DID for the fax, enables you to configure a unique extension that can be used exclusively for sending faxes to the Cisco Unity Express in either Cisco Unified CME or Cisco Unified Communications Manager mode. To use this option, you must configure an ephone-dn or extension for the fax DID on the Cisco Unified CME or Cisco Unified Communications Manager. This enables:

• Voice calls to be forwarded to the outbound dial-peer for the On-ramp process
• Fax calls (based on DID) to be directly routed to the outbound dial-peer for the On-ramp process

On the Cisco Unity Express node, you must:

• Configure the inbound fax gateway.
• Enable the mailbox to receive the faxes from a fax gateway.
• Assign the fax number to this user to create a separate fax DID.

The configuration steps are exactly the same as for voice mailboxes except that you must also enable the mailbox to receive faxes from a fax gateway and create a fax number for the user. The user can login to this mailbox using a voice number. Logging in to a mailbox using the fax DID is not supported.

You can use separate DIDs for Fax with either:

– Connect First Mode

– Listen First Mode

Using a Single DID for Voice and Fax

When configuring a single DID number for the voice and fax, use the Primary extension for the subscriber. All the fax calls are routed to the fax detect application on the fax gateway. Then the fax gateway either:

• Routes the call either to a MMoIP dial-peer if it is a fax call.
• Routes the call to voice dial-peer.

On the Cisco Unity Express, you must:

• Enable a mailbox to receive faxes from a fax gateway
• Configure the fax number as the extension of the user.

If no fax number is configured, by default the subscriber’s extension is used.

You can use single DID for voice and fax with either:

– Connect first mode

– Listen first mode

Using Connect First Mode with Single DID

The Cisco Unity Express relies on the fax detection application to support single DID functionality. The fax detection application has a limitation that causes the fax call to get disconnected and requires the fax to be resent when the either of the following sequences occur:

• Sequence 1:

– A fax call comes through the gateway (with fax detection application configured to work in connect first mode).

– The phone rings.

– A subscriber picks up the call and disconnects the call before the application detects it is the fax call.

• Sequence 2:

– A fax call comes through the gateway (with the fax detection application configured to work in connect first mode).

– The phone rings.

– A subscriber picks up the call and hears CNG tones.

– When a subscriber tries to transfer the call to fax dial peer (MMoIP), the fax call is disconnected.

To completely understand this use of the connect first mode with a single DID, you must first understand the high-level fax call flow. Figure 4 shows the various stages in the fax call, with each call flow labeled to indicate the corresponding step described in detail below.

---

Note This scenario assumes that the fax detection application running on the IOS gateway.

Figure 4 High-Level Fax Call Flow

When the fax detect application is configured in connect first mode, it connects the call before listening for the fax tones. The sequence of events, as shown in Figure 4, are:

• The fax call is initiated from the fax machine. The fax machine establishes a POTS connection to the Cisco IOS fax gateway POTS dial peer using an FXS or FXO port. (This is shown in Figure 4 as step 1.)
• The inbound POTS dial peer that is configured with the fax detection application creates a call leg between an FXO or FXS port, a POTS dial peer, and a VoIP dial-peer. (This is shown in Figure 4 as step 2.)
• The fax detection application establishes second leg of call between a VoIP/SIP dial peer and a phone, or a VoIP/H.323 dial peer and a phone. When the phone starts ringing (corresponding to the phone number in the single DID case), the user picks up the phone or call and is transferred to the voice mail. After the call is established, the gateway starts listening for the CNG tones. If the gateway is not able to establish that it is fax call within the equivalent of two CNG tones (six seconds), the call is treated as a voice mail call. (This is shown in Figure 4 as steps 3 and 5) However, if the gateway detects that it is a fax call, the voice leg of call is disconnected and call is transferred to a MMoIP dial peer. (This is shown in Figure 4 as step 4.)
• If the call is a voice call and Cisco Unity Express is integrated with Cisco Unified Communications Manager, the voice call is established. (This is shown in Figure 4 as step 3.) If there is no answer, the call is forwarded to Cisco Unity Express. (This is shown in Figure 4 as step 6.)
• If the call is a voice call and Cisco Unity Express is integrated with Cisco Unified CME, the voice call is established. (This is shown in Figure 4 as step 5.) If there is no answer, the call is forwarded to Cisco Unity Express (This is shown in Figure 4 as step 8.)
• If the call is a fax call, irrespective of how Cisco Unity Express is integrated, the fax application configured on the outbound MMoIP dial peer converts the fax into an e-mail message with TIFF attachment(s) and sends the message over SMTP to Cisco Unity Express (This is shown in Figure 4 as step 7.)

From the user’s point of view, this is the sequence of events:

1. The fax call is initiated.

2. The called number starts ringing.

3. The user picks up the phone or the call is transferred to the voice mail.

4. If the user picks up the phone, they hear CNG tones (in the case of fax calls) or voice (in the case of voice calls). At this point:

– If the user disconnects the call before the fax gateway can detect that it is a fax call, the call is disconnected and fax must be resent.

– If the user puts the call on hold for the six seconds that the gateway requires to detect that it is a fax call, the call leg between gateway and Cisco Unified CME or Cisco Unified Communications Manager is disconnected. The call is established to a MMoIP dial peer.

– If the user attempts to transfer the call to the fax number (MMoIP), the call transfer fails and subsequently the call is disconnected.

5. If the call is forwarded to the voice mail of the user, the voice mail prompt starts playing. If the call is a voice call, the user can leave a voice message. If the call is a fax, the CAG tone is detected within six seconds, the voice call is pulled back, and another call leg to MMoIP dial-peer is established. The voice leg of call is disconnected.

Using Connect First Mode with Separate DIDs

The sequence of events for the Connect First Mode with separate DIDs are similar to the sequence described in the “Using Connect First Mode with Single DID” section. However, there is no need for fax detection on the fax gateway because the fax has separate DID. Calls to the fax numbers are routed by the fax gateway, and the MMoIP dial-peer is used to send the faxes to Cisco Unity Express over SMTP in the form of e-mail messages (as described in the “Using the Fax Detection Application vs the On-ramp Application” section). The calls to the voice numbers are routed to the VoIP dial peer, using SIP for Cisco Unified CME and H.323 for Cisco Unified Communications Manager.

A single DID can exist along with separate DIDs. We recommend that you do not use the fax detection application when there are separate DIDs for fax and voice calls in order to give the users a better experience.

Using Listen First Mode with Single DID

When the fax detect application is configured in listen first mode, the fax detect application listens for the CNG tones first and connects the call either to VoIP or MMoIP dial-peer based on whether the call is a voice or fax call. The sequence of events, as shown in Figure 4, are:

1. The fax call is initiated from the fax machine. The fax machine establishes a POTS connection to POTS dial peer using an FXS or FXO port. The fax detection application on the POTS dial-peer listens for the fax tones. The fax application routes the call to either the MMoIP dial peer or VoIP/H.323 dial peer. When fax gateway is listening for the fax tones, it can play some prompts to the call originator. These prompts can be dial-tones, which simulate the tones that indicate that the destination device is ringing. (This is shown in Figure 4 as step 1.)

2. If the call is not detected as fax, a VoIP dial-peer is used (H.323 in case of Cisco Unified Communications Manager and SIP in case of Cisco Unified CME) to route the call to the call agent. (This is shown in Figure 4 as steps 3 and 5 respectively.) The call agent routes the call to the destination. (This is shown in Figure 4 as steps 6 and 8 respectively.) After the phone starts ringing, the user picks up the phone or call is transferred to the voice mail on CFNA/CFB.

3. If the call is a fax call, irrespective of how Cisco Unity Express is integrated, the call is handed over to outbound MMoIP dial peer. (This is shown in Figure 4 as in as step 4.) The fax application configured on the outbound MMoIP dial peer converts the fax into e-mail message with TIFF attachment(s) and sends it to Cisco Unity Express. (This shown in Figure 4 a as step 7.)

The user experience for this configuration can be described as follows:

1. A call is initiated.

2. The calling party starts hearing the ring tone, if the fax gateway is set up to play ring tone during fax detection. Otherwise, calling party hears silence.

3. The called phone does not ring until the call is detected as a voice call and the gateway routes the call to the phone.

4. If the call is detected as voice, the call is routed to the destination number using the SIP/H.323 dial peer and the phone starts ringing. The call then proceeds like any other voice phone call.

5. If the gateway detects that the call is a fax, it is sent to a MMoIP dial peer and the fax is converted into an e-mail message with a TIFF attachment. A fax then appears in the called party’s mailbox. The calling party hears the CED tones and the fax is sent.

Using Listen First Mode with Separate DID

After you configure the dial peers for fax & voice calls, the calls can be routed to either a fax MMoIP dial peer or a VoIP dial peer (for Cisco Unified CME, use SIP and for Cisco Unified Communications Manager, use H.323). If customer has separate DIDs, we recommend that you use the On-ramp application on the POTS dial peer (see the next section for more information about the On-ramp application). However, you might want to use a mixed mode configuration, with some users using a single DID for the fax and voice and other users using separate DIDs for fax and voice.

To configure fax detection application, see the “Configuring the Fax Gateway for the Fax Detection Application” section.

Using the Fax Detection Application vs the On-ramp Application

You must use the fax detection application if you want to use the single DID functionality. However, the fax detection application has limitations, as described in the “Using a Single DID for Voice and Fax” section.

We recommend that you configure the On-ramp application, instead of the fax detect application, on the fax gateway when you use separate DIDs for fax and voice calls. The sequence of events when you use the On-ramp application, as shown in Figure 4, are:

1. The fax call is initiated from the fax machine. The fax machine establishes a POTS connection to the Cisco IOS router POTS dial peer using an FXS or FXO port (shown in Figure 4 as step 1). The inbound POTS dial peer routes the call to the MMoIP dial-peer.

2. On the outbound MMoIP dial peer, the T.30 packets are converted into a fax e-mail message with a TIFF attachment (shown in Figure 4 as step 4).

3. The e-mail message is sent to the Cisco Unity Express module over a SMTP connection (shown in Figure 4 as step 7).

4. The fax is stored in the subscriber’s mailbox.

Prerequisites

Before you can configure fax feature, you must configure the fax gateway. As described in the “Configuration Options” section, you have the following options:

• Using the Off-Ramp application with the On-Ramp application
• Using the Off-Ramp application with the fax detect application

For instructions on how to configure these options, see:

• Configuring the Fax Gateway for T.37 On-Ramp
• Configuring the Fax Gateway for T.37 Off-Ramp
• Configuring the Fax Gateway for the Fax Detection Application

The decision of which option to use to configure the fax gateway is determined, as described in the “Configuration Options” section, by whether you will be:

• Using separate DIDs for Fax with either:

– Connect First Mode

– Listen First Mode

• Using single DID for Voice and Fax with either:

– Connect First Mode

– Listen First Mode

If you want to restrict specified extensions from using this feature, you must configure a restriction table as described in the “Configuring Restriction Tables” section.

After you complete the appropriate prerequisites, you can then configure the following parameters, as described in the “Configuring System-Wide Fax Parameters” section):

• The system level fax numbers used to print faxes.
• An association between a user and a fax number that can be used to receive faxes.

Configuring the Fax Gateway for T.37 On-Ramp

Prerequisites

You must configure incoming and outgoing dial peers in order to route the fax call through the gateway.

For the POTS dial-peer configuration, the incoming called-number command allows this dial-peer to match any inbound called number that comes into the gateway. Most real world scenarios usually have a specific fax number configured. The direct-inward-dial command takes the received call number as the number that is to be used when it makes a MMoIP dial-peer match. The port command associates this POTS dial-peer with a physical port on the gateway. The important command from a T.37 on-ramp perspective is the application name command. This command associates the on-ramp fax application with a specific POTS dial peer. The name field is defined by the user in the call application voice name file location command. In this example, the POTS dial peer uses the application onramp command because that is the name that was previously defined with the command call application voice onramp flash:app_faxmail_onramp.2.0.1.3.tcl.

For the outbound VoIP side, a multimedia or MMoIP dial-peer is necessary instead of the usual VoIP dial peer. Like the POTS dial-peer, the MMoIP dial-peer also needs the command application fax_on_vfc_onramp_app out-bound. This application command references a script that can be seen when you look at the command show call application voice summary. The script that is needed is fax_on_vfc_onramp_app. It is also important to remember the outbound keyword so that this application is only used on outbound calls through the MMoIP dial-peer.

The destination-pattern command is used to match the inbound call number to a specific outbound MMoIP dial-peer. In most circumstances, this dial-peer matches with a user’s inbound fax number. The information-type fax command associates the outbound MMoIP peer with T.37 fax. Without this command in the dial-peer, the gateway does not use the MMoIP peers and the onramp fax call fails.

The session target mailto: email address command identifies who the end user is from an e-mail perspective. This is used to address the e-mail sent to the mail server. All fax e-mails are sent to the mailbox defined by the dial-peer.

The following example shows a configuration for an incoming POTS dial-peer to match any inbound called number that comes into the gateway:

The following example shows a configuration for an outbound multimedia or MMoIP dial-peer that references the on-ramp script:

Required Data for This Procedure

This procedure requires the username and hostname for an e-mail’s “From” field. This enables the user to see “ username @ hostname ” in an e-mail’s “From” field.

SUMMARY STEPS

1. copy tftp flash

2. config t

3. fax interface-type fax-mail

4. config t

5. call application voice onramp flash:app_faxmail_onramp.2.0.1.3.tcl

6. ip domain name domain_name

7. mta send server [ IP address | DNSname ] port number

8. mta send with-subject both

9. mta send mail-from username name

10. mta send mail-from hostname name

11. end

DETAILED STEPS

 

Configuration Example

For a configuration example that also includes the configuration for T.37 Off-ramp, see the “Configuraton Example” section.

Configuring the Fax Gateway for T.37 Off-Ramp

Prerequisites

You must configure at least one of each of the following dial peers on the off-ramp gateway for T.37

• Incoming dial peer to associate the inbound SMTP message with a called fax number
• Outgoing dial peer to route the call to an outbound telephony circuit.

The following example shows a configuration for an incoming dial peer to associate the inbound SMTP message with a called fax number:

The following example shows a configuration for an outgoing dial peer to route the call to an outbound telephony circuit:

Required Data for This Procedure

This procedure requires the username and hostname for an e-mail’s “From” field. This enables the user to see “ username @ hostname ” in an e-mail’s “From” field.

SUMMARY STEPS

1. copy tftp flash

2. config t

3. fax interface-type fax-mail

4. call application voice offramp flash:app_faxmail_offramp.2.0.1.3.tcl

5. mta receive maximum recipients number

6. mta receive aliases string

7. mta receive generate permanent-error

8. end

DETAILED STEPS

 

Configuraton Example

This configuration is an example of a minimal Cisco IOS configuration for Cisco Unity inbound fax capability. This example includes the configuration of both the On-ramp and Off-ramp applications. The most important configuration commands are in bold font.

Configuring the Fax Gateway for the Fax Detection Application

Prerequisites

You must configure at least one of each of the following dial peers on the on-ramp gateway:

• Inbound POTS dial peer
• VoIP dial peer
• MMoIP dial peer

The following sections explain how to configure each of these dial peers.

Inbound POTS Dial Peer

When you configure an inbound POTS dial peer on the on-ramp gateway, the incoming called-number string specifies a pattern that represents either the prefix or the full E.164 telephone number (depending on your dial plan) that identifies the destination voice mail telephone number for this dial peer.

The following example shows a configuration for an inbound POTS dial peer on the on-ramp gateway:

VoIP Dial Peer

You must configure at least one outbound VoIP dial peer on the on-ramp gateway for voice messaging. In the example below, the IP address of the voice mail server is 172.16.2.2. If you have already configured an outgoing VoIP dial peer on this gateway with the appropriate destination pattern, you do not need to configure another one; there are no different dial-peer parameters for fax detection on the outbound VoIP dial peer for voice.

The following example shows a configuration for an outbound VOIP dial peer on the on-ramp gateway:

MMoIP Dial Peer

You must configure at least one outbound MMoIP dial peer on the on-ramp gateway. In the following example, the session target command specifies an address to which faxes are e-mailed, where the $d$ wildcard is replaced by the destination pattern.

The following example shows a configuration for an outbound MMoIP dial peer on the on-ramp gateway:

Required Data for This Procedure

This procedure requires the domain name and hostname for the fax detection gateway.

SUMMARY STEPS

1. config t

2. ip domain-name domain_name

3. hostname host_name

4. call application voice offramp flash:app_faxmail_offramp.2.0.1.3.tcl

5. end

DETAILED STEPS