Table Of Contents

Configuring Fax Applications

Fax Applications Overview

On-Ramp Gateway

Off-Ramp Gateway

Call Discrimination Process

POTS Dial Peers

MMoIP Dial Peers

On-Ramp Gateway Security

Attribute-Value Pairs for AAA

Access Control Lists

ESMTP Accounting Services

Message Delivery Notifications

Delivery Status Notifications

T.37 Store and Forward Fax

Modem Pooling

Fax Relay Packet Loss Concealment

Handling of Enclosures

T.37/T.38 Fax Gateway

Using Interactive Voice Response

T.38 Fax Relay for VoIP H.323

Fax Applications Prerequisites

T.37 Store and Forward Fax Prerequisites

Configuring the SMTP Server

Configuring the MTAs

Configuring Fax Operation

Configuring All Mail Through One Mailer

Configuring Sendmail 8.8.5 for Single Recipients

Configuring the Redialers

Fax Relay Packet Loss Concealment Prerequisite Tasks

T.37/T.38 Fax Gateway Prerequisite Tasks

Downloading VCWare to the VFC

Copying Flash Files to the VFC

Unbundling VCWare

Adding Files to the Default File List

Adding Codecs to the Capability List

Deleting Files from VFC Flash Memory

Erasing the VFC Flash Memory

Configuring IVR

T.38 Fax Relay for VoIP H.323 Prerequisites

Fax Applications Configuration Tasks List

Configuring the On-Ramp Gateway

Configuring the Called Subscriber Number

Configuring the Sending MTA

Configuring POTS Dial Peers

Configuring MMoIP Dial Peers

Verifying the Gateway Configuration

Configuring the Off-Ramp Gateway

Configuring the Transmitting Subscriber Number

Configuring the Fax Transmission Speed

Configuring the Receiving Mail Transfer Agent

Configuring the POTS Dial Peer

Configuring the MMoIP Dial Peer

Configuring the Faxed Header Information

Configuring the Fax Cover Page Information

Verifying the Gateway Configuration

Configuring Gateway Security

Configuring On-Ramp Gateway Security

Configuring Off-Ramp Gateway Security

Configuring the Gateway Security for TCL Application Files

Verifying the Gateway Security Configuration

Configuring MDNs

Verifying MDN Configuration

Configuring DSNs

Verifying DSN Configuration

Configuring T.37 Store and Forward Fax

Configuring On-Ramp Modem Pooling

Configuring ECM

Configuring the T.37/T.38 Fax Gateway

Specifying the Interface Type for Fax Calls

Configuring IVR Functionality

Verify the IVR Configuration

Configuring T.38 Fax Relay for VoIP H.323

Fax Applications Configuration Examples

T.37 Store and Forward Fax Configuration Examples

T.37/T.38 Fax Gateway Examples

T.38 Fax Relay for VoIP H.323 Configuration Example

Configuring Fax Applications

---

This chapter describes T.37 Store and Forward Fax and T.38 Fax Gateway concepts and describes how to configure the fax applications for Cisco AS5300 universal access server access servers. The applications are T.37 Store and Forward Fax, T.38 Fax Relay for Voice over IP (VoIP) H.323, Fax Relay Packet Loss Concealment, and T.37/T.38 Fax Gateways. The applications enable the Cisco AS5300 universal access server to send and receive faxes across packet-based networks, using modems or voice feature cards (VFCs).

This chapter includes the following sections:

•Fax Applications Overview

•Fax Applications Prerequisites

•Fax Applications Configuration Tasks List

•Fax Applications Configuration Examples

For a complete description of the commands used in this chapter, refer to the Cisco IOS Voice, Video, and Fax Command Reference. To locate documentation of other commands that appear in this chapter, use the command reference master index or search online.

To identify the hardware platform or software image information mentioned in this chapter, use the Feature Navigator on Cisco.com to search for information about the feature or refer to the software release notes for a specific release. For more information, see the "Identifying Supported Platforms" section in the "Using Cisco IOS Software" chapter.

Fax Applications Overview

Fax applications enable Cisco AS5300 universal access servers to send and receive faxes across packet-based networks using modems or VFCs. Some of the benefits of the Fax Gateway are as follows:

•Universal inbox for fax and e-mail—Faxes and e-mails can go to the same mailbox using direct inward dialing (DID) numbers. E-mail and fax recipients can be combined.

•Toll bypass—In an enterprise environment in which offices in different cities are connected using a WAN, toll charges can be bypassed by transmitting faxes over the network connection. Because a fax message is stored on the mail server until Simple Mail Transfer Protocol (SMTP) forwards messages to the recipient, SMTP can forward fax e-mail attachments during off-peak hours (for example, during evenings and weekends), thereby reducing long-distance charges.

•Broadcast to multiple recipients—E-mail fax attachments can be sent to multiple recipients simultaneously.

•Improve robustness—The Fax Relay Packet Loss Concealment feature improves the robustness of the facsimile relay. It eliminates fax failures and lost data caused by excessive page errors. Field diagnostics and troubleshooting capabilities are improved by available debug commands. Statistics give better visibility into the real-time fax operation in the gateway, allowing for improved field diagnostics and troubleshooting.

•Cost savings and port density using T.37/T.38 Fax Gateway—The cost of maintaining one architecture (either fax or voice) is eliminated. Service providers can do the following:

–Use a single port for voice, fax relay, and Store and Forward Fax. For smaller points of presence (POPs), the single-port configuration for these technologies is even more significant because mixed traffic can be handled more efficiently requiring only a single pool of ports versus splitting traffic across two pools.

–Offer the new service of a single number for subscriber voice and fax access. The applications that use a single number for voice and fax require only half as many dialed number identification service (DNIS) numbers and dial peers as would be required with separate voice and fax applications.

–Offer applications that require toggling from voice to fax. Applications such as never-busy fax service can be addressed once the gateway can dynamically switch from fax relay to fax store and forward.

•Interoperability with T.37 fax relay for VoIP H.323—The Cisco 2600 and 3600 series routers and Cisco MC3810 multiservice concentrator gateways with International Telecommunication Union Telecommunication (ITU-T) T.38 fax relay capability can interoperate with third-party gateways and gatekeepers over an IP H.323 network. The goal is to work with third-party gateways and gatekeepers to provide ITU-T standards-based T.38 fax relay services for multivendor networks.

The Cisco 2600 and 3600 series routers and Cisco MC3810 multiservice concentrator gateways provide standards-based toll bypass for fax and voice calls. In addition to existing voice and fax toll bypass capabilities, the multiservice gateways provide toll bypass for fax relay with the standards-based ITU-T T.38 fax relay implementation.

On-Ramp Gateway

The Cisco AS5300 universal access server acts as an on-ramp gateway to receive faxes from end users and uses call discrimination to determine call type and destination. It converts the faxes into TIFF files, creates standard Multipurpose Internet Mail Extension (MIME) e-mail messages, attaches the TIFF files to e-mail messages, and forwards the fax-mail messages to the messaging infrastructure of a designated SMTP server, where fax-mail messages are stored.

The on-ramp gateway uses the sending Message Transfer Agent (MTA) and dial peers to receive the faxes. The sending MTA, the Cisco AS5300 universal access server, defines delivery parameters associated with the e-mail message to which the fax TIFF file is attached. These delivery parameters include defining a return e-mail path or designating a destination mail server.

The on-ramp plain old telephone service (POTS) dial peers define the call as a fax transmission and identify the DNIS of the incoming fax call. The on-ramp Multimedia Mail over IP (MMoIP) dial peer defines the destination fax telephone number and the session target, which in this case is the SMTP server.

The configuration of the on-ramp gateway involves the following:

•Called subscriber number—Displayed number in the liquid crystal display (LCD) of the fax device sending a fax to a recipient. With a standard Group 3 fax device, this is the telephone number associated with the receiving fax device.

•Sending MTA—Contains the following elements in the e-mail message to which the fax TIFF file is attached:

–Subject

–Destination

–Return path

–Postmaster

–Any additional identifying e-mail header information

–Address to which any disposition notices are sent

•POTS dial peer—Defines the characteristics of the Public Switched Telephone Network (PSTN) connection between the sending fax device and the on-ramp gateway. The on-ramp gateway uses these characteristics to determine the call type and call destination using call discrimination.

•MMoIP dial peer—Describes the line characteristics generally associated with a packet network connection. With T.37 Store and Forward Fax, this is the IP network connection between the on-ramp gateway and the SMTP server. On-ramp MMoIP dial peers do the following:

–Define the destination fax telephone number

–Specify a destination e-mail address, which identifies the SMTP server

–Define the image encoding and resolution specifics for the associated fax-mail TIFF files

–Request DSNs, MDNs, or both.

If DID is enabled, the incoming called number for the on-ramp POTS dial peer should match the destination pattern of the on-ramp MMoIP dial peer. If DID is not enabled, a redialer must be configured and enabled. In this case, the destination pattern must match the forwarded dialed digits from the redialer.

Off-Ramp Gateway

Off-ramp faxing requires that the Cisco AS5300 universal access server act as an off-ramp gateway and dial POTS and communicate with a remote Group 3 fax device using standard fax protocols. It uses call discrimination to determine call type and destination.

Off-ramp faxing activities are not mutually exclusive. An e-mail can be sent as a fax, and a TIFF file can be attached to it. When the Cisco AS5300 universal access server converts the e-mail to fax format, it also converts the attached TIFF file to standard Group 3 fax format.

The off-ramp gateway does the following:

•Converts a fax-mail TIFF file or plain text file into a standard format and delivers it to the recipient. Store and Forward Fax 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 AS5300 universal access server 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 and dial peers 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. The dial peers also define the telephone number of the destination fax device. Number expansion can be used because the destination pattern is defined. As an option, the MMoIP dial peers can be configured, but MMoIP dial peers has limited functionality. They only define fax compression schemes and resolution and is useful only if those parameters are to be altered for the received fax-mails.

•Defines the parameters associated with the AS5300 SMTP server using the receiving MTAs. The MTAs can be SMTP host aliases, which can be different from the normal Domain Name System (DNS) host names, or an internal Cisco IOS host name.

The configuration of the on-ramp gateway involves configuring the following:

•Transmitting subscriber number—Displayed number in the LCD of the receiving fax device. Typically, with a standard Group 3 fax device, this is the telephone number associated with the transmitting or sending fax device.

•Fax transmission speed—Transmission speed of the fax device; this should be set to the speed of the other devices, if possible. This functionality is particularly helpful if the off-ramp gateway is sending faxes into an area where the fax transmission speed is always negotiated down to a slower speed.

•Receiving MTA—Accepts incoming mail (from the Cisco AS5300 universal access server to the SMTP server) if the destination host name of the incoming mail matches one of the aliases configured by the mta receive aliases command.

•Off-ramp POTS dial peer—Defines the line characteristics between the off-ramp gateway forwarding the converted e-mail message and the receiving fax device.

•Off-ramp MMoIP dial peer—Specifies a particular resolution for the fax transmission or defines an encoding type, which is optional. If the MMoIP dial peer is configured, the incoming called number must match the destination pattern telephone number of the corresponding on-ramp POTS dial peer.

•Faxed header information—Information appended to the top of each cover and text page indicates the telephone number of the sending fax device, the date, and the time of transmission. The header information is required.

•Fax cover page—Captures information taken from the originating e-mail messages. The destination address of an e-mail message controls the generation of a cover page on a per-recipient basis.

Call Discrimination Process

When the on-ramp gateway receives a call, it immediately identifies whether the call is being delivered using a PRI or T1 channel associated signaling (CAS) interface. If the call is on a T1-CAS interface, the gateway checks the service type field of the CAS group configuration. If the service type of the CAS group is fax, the interface forwards the fax to the MMoIP dial peer. If the gateway determines that the call is on a PRI interface, then the on-ramp gateway looks at several POTS dial peer data fields to determine what kind of call it has received.

POTS Dial Peers

The on-ramp gateway looks at the incoming called number field of each POTS dial peer listed in the dial peer lookup table. It compares the number configured as the incoming called number to the number received and selects the first POTS dial peer whose data matches. If the on-ramp router does not find a match, it assumes that the incoming call is a data call and processes it accordingly.

If the on-ramp router does find a match, it will then look at the service type field of the POTS dial peer to determine whether this is a voice or fax call. If this call has been flagged as a voice call, the on-ramp gateway will process it appropriately as a voice call.

If the call has been flagged as a fax call, the on-ramp gateway checks to see whether DID has been enabled. If DID has been enabled, the gateway concludes that the telephone number it has received is the destination directory number (DN) and forwards the call to be matched with the appropriate on-ramp MMoIP dial peer.

If DID has not been enabled, the on-ramp gateway assumes that the telephone number it received is the access DN. In this case, the on-ramp gateway provides a secondary dial tone and collects another telephone number from the redialer at the other end of the connection that the gateway will use as the destination DN. After the gateway has received this number from the redialer, the number is forwarded and matched to the appropriate on-ramp MMoIP dial peer.

A redialer is an interface hardware device that connects a fax device to the PSTN network. The user enters the complete telephone number into the fax device and the attached redialer captures and stores those dialed digits. It dials the on-ramp Cisco AS5300 universal access server that provides a secondary dial tone. Use a redialer when one of the following is true:

•Provisioning a DID service is not possible.

•User information, such as a personal ID number (PIN) from the redialer, is required.

•T1-CAS is in use.

The redialer should be programmed to wait two seconds and then send the PIN with destination digits to the on-ramp gateway.

The fax protocol starts after 52 digits have been detected or the interdigit timeout has exceeded 5 seconds. If the debug fax receive command is enabled, the digits are displayed as received by the on-ramp gateway. If a dial peer is matched, the fax proceeds. If a dial peer is not matched, the fax fails.

By default, DID is disabled, which means that the on-ramp gateway assumes that the fax call was placed using a redialer. When the call arrives, the gateway collects digits until it can identify the destination. Once the destination is identified, the gateway forwards the call to the next call leg (MMoIP dial peer).

If DID is enabled, the on-ramp gateway uses the called number (DNIS) to find a dial peer for the outgoing call leg. DID enables the gateway to match the incoming called number with a dial peer and then directly place the outbound call. With DID, the server does not present a dial tone to the fax machine and does not collect digits. It forwards the call directly to the configured destination.

The off-ramp gateway looks at the destination-pattern field of each POTS dial peer listed in the dial peer lookup table. It compares the number configured as the destination pattern with the destination DN portion of the fax-mail address and selects the first match.

After the off-ramp gateway has identified the appropriate POTS dial peer, it matches call type information. If the call type is identified as fax, it forwards the fax-mail message to off-ramp services. If the off-ramp router does not find a match, the recipient identified by the given address is not accepted by the off-ramp router.

MMoIP Dial Peers

The MMoIP function in the call discrimination process determines the fax-mail destination, which is the off-ramp gateway over which the fax-mail is sent to the destination fax machine. The on-ramp gateway looks at the destination pattern field of each MMoIP dial peer listed in the dial peer lookup table. It compares the number configured as the destination pattern with the number received and selects the first MMoIP dial peer whose the data matches.

The on-ramp gateway then looks at the session target field for the selected MMoIP dial peer in order to identify the destination of the fax-mail message. This value could be a specific off-ramp gateway or, if the fax is being delivered as an e-mail message, an e-mail address for a specific mail server.

The resolution of a fax image can be increased or decreased using the MMoIP dial peer configuration. Pass-through is the default: the image is sent exactly as it is received. Depending on the capacity of the fax machines in the network, a different image encoding (compression) scheme could be required for the fax TIFF image. The encoding default is pass-through.

On-Ramp Gateway Security

On-ramp gateway security controls who can send fax messages to the network. It is facilitated by authentication, authorization, and accounting (AAA) security services using RADIUS or TACACS+ as the local security protocol. On-ramp gateway faxing is a client of the authentication server, whether it is RADIUS or TACACS+. User information is forwarded to the AAA interface, and the authentication request is forwarded to the security server.

Authentication must be completed before the first page of faxed material is accepted from the modem by the Fax Application Process (FAP). If a response is not received from the AAA server before the first page is received, the fax modem or voice feature card (VFC) disconnects the call.

The on-ramp gateway inserts whatever value was configured in the "X-account-ID" field of the e-mail header that is used for authentication and accounting by the on-ramp gateway.

Attribute-Value Pairs for AAA

RADIUS attributes define specific AAA elements in a user profile, which is stored on the RADIUS server. The Cisco implementation of RADIUS supports Internet Engineering Task Force (IETF) and vendor-proprietary attributes. IETF RADIUS attribute 26 enables vendors to support extended attributes not suitable for general use. The Cisco fax applications use the RADIUS implementation of vendor-specific options in the recommended format.

Table 50 lists the supported vendor-specific options (subtype numbers from 3 through 21) using IETF RADIUS attribute 26 and the Cisco vendor-ID company code of 9.

Table 50 Vendor-Specific RADIUS Attributes 

Subtype Number	Attribute	Description
3	Cisco-Fax-Account-Id-Origin	Account ID origin as defined by the system administrator for the mmoip aaa receive-id or the mmoip aaa send-id command.
4	Cisco-Fax-Msg-Id=	Unique fax message identification number.
5	Cisco-Fax-Pages	Number of pages sent or received during a fax session including cover pages.
6	Cisco-Fax-Coverpage-Flag	True/false flag that indicates whether a cover page was generated. True means a cover page was generated and false means it was not.
7	Cisco-Fax-Modem-Time	Number of seconds it takes to send fax data (x) and to complete the entire fax session (y) in the form x/y. For example, 10/15 means that the transfer time took 10 seconds and the full fax session took a total of 15 seconds.
8	Cisco-Fax-Connect-Speed	Modem speed. Possible values are 1200, 4800, 9600, and 14400.
9	Cisco-Fax-Recipient-Count	Number of recipients. Until e-mail servers support session mode, the number should be 1.
10	Cisco-Fax-Process-Abort-Flag	True/false flag indicating that fax session was aborted or successful. True is aborted and false is processed.
11	Cisco-Fax-Dsn-Address	Address to which DSNs are sent.
12	Cisco-Fax-Dsn-Flag	True/false flag to indicate if DSN is enabled. True is enabled and false is disabled.
13	Cisco-Fax-Mdn-Address	Address to which MDNs are sent.
14	Cisco-Fax-Mdn-Flag	True/Flash flag to indicate if MDN is enabled. True is enabled and false is disabled.
15	Cisco-Fax-Auth-Status	Authentication status—successful, failed, bypassed, or unknown.
16	Cisco-Email-Server-Address	E-mail server IP address handling the on-ramp fax-mail message.
17	Cisco-Email-Server-Ack-Flag	Acknowledgement that the e-mail server accepted the message.
18	Cisco-Gateway-Id	Processing gateway name in this format: hostname.domain-name.
19	Cisco-Call-Type	Type of call activity: fax receive or fax send.
20	Cisco-Port-Used	Slot/port number used to send or receive.
21	Cisco-Abort-Cause	System component that signalled an abort.

Access Control Lists

Incoming Access Control Lists (ACLs) can be used on Ethernet or FastEthernet interfaces to filter SMTP fax traffic. It is recommended that ACLs be configured to restrict access to the SMTP port (port 25) to only trusted e-mail servers. Creating ACLs is beyond the scope of this document. For information, refer to the Cisco IOS Security Configuration Guide.

ESMTP Accounting Services

Accounting information can be collected about fax services in two ways:

•Using RADIUS accounting

•Collecting the accounting information using SMTP

The extended simple mail transfer protocol (ESMTP) accounting feature enables the collection of accounting information as part of the SMTP session. This functionality is activated through the use of an intelligent fax client or MTA. In ESMTP accounting, the off-ramp gateway acting as an ESMTP server advertises capabilities to the MTA, which is acting as an e-mail client.

One of the capabilities the off-ramp gateway advertises is "xaccounting," which supports ESMTP accounting. If the MTA recognizes the xaccounting service extension, the MTA (acting as the client) accepts the ESMTP accounting information sent from the off-ramp gateway. If the MTA does not recognize the xaccounting service extension, it does not send the xact command to the off-ramp gateway. In that case, the off-ramp gateway does not respond with ESMTP accounting data.

To use SMTP to collect accounting data, the MTA must be configured to explicitly request accounting information as part of the e-mail session. The MTA must be able to do the following:

•Recognize the xaccounting service extension during the extended hello (ehlo) transaction

•Send the xact command to the off-ramp gateway to activate the ESMTP accounting feature

Message Delivery Notifications

Described in RFC 2298, an message delivery notification (MDN) is a message that is sent to the originator of an e-mail message indicating that the e-mail message was received. MDN elements must be configured for both the on-ramp and off-ramp gateways. MDN requests as part of the on-ramp MMoIP dial peer configuration must be enabled. For complete instructions on how to configure MDNs, see the "Configuring MDNs" section.

Delivery Status Notifications

Delivery status notifications (DSNs) are messages or responses that are automatically generated and sent to the sender or originator of an e-mail message by the SMTP server, notifying the sender of the status of the e-mail message. DSNs must be configured for both the on-ramp and off-ramp gateways.

Three different states can be reported back to the sender as follows:

•Delay—Delivery of the message was delayed.

•Success—Delivery of the message was successful.

•Failure—Message was undeliverable to the SMTP server.

Because the delivery states are not mutually exclusive, messages for all or any combination of these events can be generated.

DSN requests can be enabled as part of the on-ramp MMoIP dial peer configuration. For complete instructions on how to configure DSNs, refer to the "Configuring DSNs" section.

T.37 Store and Forward Fax

T.37 Store and Forward Fax is an implementation of the RFC 2305 proposed standard from the IETF and is the same as the T.37 recommendation of the International Telegraph Union (ITU). T.37 Store and Forward Fax enables the access server to become a multiservice platform, supplying both data and fax communication using modems.

T.37 Store and Forward Fax enables the following:

•Sending and receiving faxes to and from Group 3 fax devices

•Receiving faxes that are delivered as an e-mail attachment

•Creating and sending a standard e-mail message that is delivered as a fax to a standard Group 3 fax device

The basic functionality is facilitated through SMTP with additional functionality that provides confirmed delivery using existing SMTP mechanisms, such as ESMTP. Figure 117 shows a simple network topology using T.37 Store and Forward Fax.

Figure 117 T.37 Store and Forward Fax Functionality

The messaging infrastructure performs message routing, storage, and transport, and can be a standard Internet MTA—for example, UNIX sendmail or custom T.37 Store and Forward Fax software. The responsibility of delivering the fax-mail message falls to SMTP and the mail server.

Modem Pooling

As a default, T.37 Store and Forward Fax receives faxes on modems that are in the on-ramp gateway default modem pool. These modems are available for both fax and data calls. The on-ramp gateway determines the call type using DNIS and compares the DNIS number to the configured value for the incoming called-number POTS dial-peer configuration command.

If the DNIS number matches the incoming called number, DNIS treats the call as a fax transmission. If it does not find a match in its dial peer lookup table, it treats the call as a data call.

The incoming fax calls can be configured to bypass the default modem pool by defining a named modem pool. This is particularly useful if the calls have Modem ISDN channel aggregation (MICA) and Microcom faxes, because it diverts fax traffic from MICA modems that do not support fax transmission.

Fax Relay Packet Loss Concealment

Fax relay packet loss concealment improves the current real-time fax over IP (commonly known as fax relay) implementation in Cisco gateways, enabling fax transmissions to work reliably under higher packet loss conditions.

In addition, this feature includes enhanced real-time fax debug capabilities and statistics for improved field diagnostics and troubleshooting. The capabilities and statistics give better visibility into the real-time fax operation in the gateway.

One improvement is fax relay Error Correction Mode (ECM) on the VoIP dial peer. When used, the DSP fax relay firmware disables ECM through modification of the DIS T.30 message in both directions.

ECM provides for error-free page transmission. It is available on fax machines that include memory for storage of the page data (usually high-end fax machines). The page is transmitted in a series of blocks. After receiving the complete page data, the receiving fax indicates any frames with errors. The transmitting fax then retransmits those frames. This process is repeated until all frames have been received without errors. If the receiving fax is not able to receive an error-free page, the fax transmission may fail, and one of the fax machines may disconnect. With packet-loss levels greater than 2 percent, fax transmissions consistently fail between page transmissions when ECM is enabled.

When ECM is disabled, the page is sent using high-speed modulation in its raw encoded format. When detecting line errors with ECM disabled, the receiving fax has three options (in order of severity):

•Respond to page reception with the ReTrain Positive command. This causes the transmitting fax to go through the training check process before transmitting the next page.

•Respond to the page reception with the ReTrain Negative command. This causes the transmitting fax to go through the TCF process with a lower modulation scheme.

•Disconnect immediately.

---

Note ECM disable is recommended when there is a known lossy network (especially with packet loss at 2 percent or greater) and if fax traffic is anticipated for the dial peer.

---

Handling of Enclosures

All Cisco fax applications can process e-mail with the following MIME media content types:

•Text (plain type)

•Text (enriched type)

•Image or TIFF ("Profile S" described in RFC 2301)

Further, all Cisco fax applications support the following content transfer encodings:

•Seven bit

•Eight bit

•Base 64

•Quotable-printable

These content transfer encodings can be wrapped in any multipart/* content type. When messages with multiple sections are received, the first part of the multipart message is processed, and a count of what is and is not successfully sent is stored. The rest of the message is discarded. For example, if a multipart, alternative message has a plain text part and an enriched, html text part and the plain text is first, the the plain text part is the only part processed.

---

Note The TIFF file format must conform to RFC 2301 (File Format for Internet Fax). Store and forward fax does not support uuencoded text, JPEG or JBIG files, or multiraster content.

---

---

Caution The Cisco AS5300 universal access server recognizes only the listed file attachment types. If it receives a file format different from one of the defined acceptable formats, the data is discarded.

---

T.37/T.38 Fax Gateway

When the Cisco AS5300 universal access server is equipped with VFCs, it supports carrier-class Voice over IP (VoIP) and Fax over IP services. Since the Cisco AS5300 universal access server is H.323 compliant, it supports a family of industry-standard voice codecs and provides echo cancellation and voice activity detection (VAD)/silence suppression.

The VFC is a coprocessor card with a powerful reduced instructions set computing (RISC) engine and dedicated, high-performance DSPs to ensure predictable, real-time voice processing. The design enables streamlined packet forwarding. The Cisco AS5300 universal access server supports two VFCs that are scalable up to 96 E1 or 120 T1 voice connections within a single chassis.

T.37 Store and Forward Fax was supported by modem cards while the voice applications ran on the C542 digital signal processing module (DSPM) and C549 DSPMs that populated Cisco AS5300 VFCs. Each type of call required different technologies. With this software release, a single DSPM technology supports the following:

•Voice, fax relay, and T.37 Store and Forward Fax on both the C542 and C549 DSPM and the same voice port

•Dynamic switching from one application to another in the same call (IVR, voice, Fax Relay, and T.37 Store and Forward Fax)

Figure 118 highlights the real-time (T.38 path) versus the T.37 Store and Forward processing (T.37 path) for fax transactions over IP networks.

Figure 118 Real-Time Versus T.37 Store and Forward Fax Processing

Fax over IP used a proprietary protocol and an H.323 connection, represented by the T.37 path in the diagram. The T.37 path used the ESMTP T.37 Store and Forward method. The on-ramp gateway router accepted fax data from the PSTN fax machine.

The fax data was converted into a TIFF attachment in a MIME e-mail message and transmitted to a T.37 Store and Forward SMTP server. The server would deliver the fax-mail message to the off-ramp gateway. Once the off-ramp gateway received the fax-mail message, it processed the message and initiated a session with the destination fax machine.

With this software release, the T.38 path takes precedence over the T.37 path whenever possible. This means that as a fax session is being set up, the sending gateway first communicates using the T.38 path. If the communication fails, the sending gateway rolls over to the Cisco T.37 path if it is configured to rollover.

Using Interactive Voice Response

Interactive voice response (IVR) applications control calls by using voice prompts and digit collection in order to authenticate the user and identify the call destination. The applications are assigned to specific ports or invoked based on DNIS. They accommodate many gateway services by customizing the presentation of the interfaces to callers.

IVR uses Tool Command Language (TCL) scripts to gather information. For example, a TCL script plays when the caller receives a voice prompt to enter a specific type of information, such as a PIN. After the caller inputs the PIN, TCL collects the digits and forwards the digits to the server for storage and retrieval.

T.38 Fax Relay for VoIP H.323

The T.38 Fax Relay for VoIP H.323 feature provides standards-based fax relay protocol support on the Cisco 2600 and 3600 series routers and the Cisco MC3810 multiservice concentrator gateways. The Cisco proprietary fax relay solution is sometimes not an ideal solution for Enterprise and Service Provider customers who have implemented a mixed-vendor network. Because the T.38 fax relay protocol is standards based, Cisco gateways and gatekeepers can interoperate with third-party T.38-enabled gateways and gatekeepers in a mixed-vendor network when real-time fax relay capabilities are required.

shows an IP H.323 network with Cisco and third-party gateways and gatekeepers using T.38 fax relay functionality. By using T.38 fax relay, all gateways and gatekeepers in this network are able to send faxes to other remote offices or to the offices of another company on the IP network.

Figure 119 IP Network for T.38 Fax Relay

For example, when a fax is sent from the originating gateway, a voice call is established. The terminating gateway detects the fax tone generated by the answering fax machine. The VoIP H.323 call stack then starts a T.38 mode request using H.245 procedures. If the opposite end of the call acknowledges the T.38 mode request, the initial audio channel is closed and a T.38 fax relay channel is opened. When the fax transmission is completed, the call reverts to voice mode.

Fax Applications Prerequisites

The following sections describe prerequisite tasks to perform before configuring all of the available fax applications:

•T.37 Store and Forward Fax Prerequisites

•Fax Relay Packet Loss Concealment Prerequisite Tasks

•T.37/T.38 Fax Gateway Prerequisite Tasks

•T.38 Fax Relay for VoIP H.323 Prerequisites

---

Note If you are using modem cards, only T.37 Store and Forward Fax is supported. If you are using VFCs, T.37 Store and Forward Fax and T.38 Fax Relay and real-time fax are supported.

---

T.37 Store and Forward Fax Prerequisites

Before the T.37 Store And Forward Fax can be configured, the following tasks are required:

•Install a modem card into the appropriate slot of the Cisco AS5300 universal access server. Both MICA and Microcom modem cards support Store and Forward Fax, although MICA modem cards support only off-ramp faxing. For more information about installing Microcom and MICA modem cards, refer to the Cisco AS5300 Universal Access Server Module Installation Guide and the Cisco AS5300 Universal Access Server Chassis Installation Guide.

–Update the Cisco AS5300 universal access server software configuration if modem cards are added or removed.

–Download and install the V.90n firmware for the Microcom modem card and the standard portware with fax transmission capabilities for the MICA modem card.

•Establish a working IP network. For more information about configuring IP, refer to the "IP Overview," "Configuring IP Addressing," and "Configuring IP Services" chapters in the Cisco IOS IP Routing Configuration Guide.

•Complete the basic configuration for the Cisco AS5300 universal access server that includes, as a minimum, the following tasks:

–Configure a host name and password for the Cisco AS5300 universal access server.

–Configure the Ethernet 10Base T/100Base T interface so that the Cisco AS5300 universal access server can be recognized as a device on the Ethernet LAN.

–Configure the Cisco AS5300 universal access server interfaces for ISDN PRI or T1 lines.

–Configure the ISDN D channels for each ISDN PRI or T1 line.

For more information about any of the these configuration tasks, refer to the Cisco AS5300 Universal Access Server Software Configuration Guide.

---

Note VoIP need not be configured for T.37 Store and Forward Fax to function.

---

The following sections describe specific prerequisite tasks to configure T.37 Store and Forward Fax:

•Configuring the SMTP Server

•Configuring the MTAs

•Configuring Fax Operation

•Configuring All Mail Through One Mailer

•Configuring Sendmail 8.8.5 for Single Recipients

•Configuring the Redialers

Configuring the SMTP Server

---

Note Before using SMTP in Cisco gateways, be sure to configure the domain name and host name.

---

Although it is not required, configuring the SMTP server enhances functionality. To configure the SMTP server, perform the following tasks:

•Edit the SMTP server alias file to include an alias for fax transmissions. The alias is an e-mail address that has the "fax=" prefix included in it. For example, fax=5551212, user@hostname.com. In this example, the on-ramp gateway automatically forwards the incoming fax to the mailbox for user@hostname.com.

–If aliases are used to forward faxes, configure the on-ramp multimedia over IP (MMoIP) dial peer session-target command as session target mailto: $d$@hostname.com. The $d$ wildcard specifies that the destination fax machine telephone number is inserted in the to: field of the fax-mail that gets sent to the SMTP server.

•Modify parameters involving SMTP delivery requirements. Failure to do so can result in a monopoly of bandwidth and fax resources.

Fax transmission has delivery requirements that are different from those of e-mail transmission. For example, in certain countries, it is illegal to try to send a fax more than three times in a row if transmission fails.

SMTP mail delivery requirements are not governed by such strict regulations. In general, if an e-mail message cannot be delivered, the SMTP server is supposed to continue trying every 30 minutes for up to 5 days. To avoid any complications arising from the difference between the SMTP e-mail and fax delivery requirements, modify the following parameters:

–Delivery to one recipient

–Message priority

–Connection cache size

–Minimum queue age

Configuring the MTAs

MTAs, such as sendmail, Post.Office, and others, are normally configured to provide fast and reliable service for transferring e-mail. However, the needs of fax users are different. The best example of differing fax requirements is retry timeouts.

A typical MTA configuration will retry sending failed message transmissions every 30 minutes for up to 5 days. Resending e-mail every 30 minutes is usually unacceptable to fax users—they want retries more often than every 30 minutes and usually want transmission aborted well before the typical 5-day retry limit. Although a typical unmodified MTA can be used with the Cisco AS5300 universal access server for off-ramp operations, the MTA may need to be fine-tuned for fax operation.

Configuring Fax Operation

The Cisco AS5300 universal access server off-ramp accepts only one e-mail recipient per SMTP transaction because the SMTP server does not do the following:

•Queue messages in the Cisco AS5300 universal access server memory. The reason is the size of the messages and the lack of sufficient nonvolatile storage.

•Include a mechanism to enable the receiving MTA to indicate the success or failure of each delivery. It indicates the success or failure of the entire transaction.

The Cisco AS5300 universal access server prevents one SMTP transaction from going to multiple recipients by responding to the second and subsequent RCPT commands with a "450" reply code. Because of the typical mailer configuration, this causes a 30-minute delay for each recipient: immediate delivery for the first recipient, 30-minute delay for the second recipient, 60-minute delay for the third recipient, etc.

Configuring All Mail Through One Mailer

To simplify system administration, have all mail to the Cisco AS5300 universal access server go through one mailer by setting up a DNS MX record for the Cisco AS5300 universal access server. The record points to and sets up the mailer to skip MX record processing for the Cisco AS5300 universal access server. For example, the following two records would exist in DNS:

sj-offramp  in mx 10 sj-mailer

sj-offramp  in mx 20 sj-offramp

sj-offramp  in a  1.2.3.4

Configure ACLs to block incoming mail from other mailers. This prevents unauthorized use of the fax off-ramp and forces all mail to go through one mailer.

If ACLs have been set up on the router, the second MX record should not be placed in the DNS. For more information about ACLs, refer to the Cisco IOS Security Configuration Guide.

Configuring Sendmail 8.8.5 for Single Recipients

Fine-tuning sendmail 8.8.5 for a single recipient enables the Cisco AS5300 universal access server to work faster with Store and Forward Fax off-ramps and reduce delays caused by attempting to send to multiple recipients. It is important that sendmail be configured to send to each recipient serially, but without a delay after each transmission. Parallel configuration of sendmail with a single recipient and multiple sendmail client processes would cause a single message to be returned through sendmail, perhaps on a different port. The parallel configuration is not within the intended scope of this document.

---

Caution Do not modify the sendmail configuration on any system without a full understanding of what mail that system is processing and without the approval of the postmaster of the site. Modifying a company mail system can cause a loss of mail service upon which many companies rely for day-to-day operation.

---

To configure sendmail 8.8.5 to send to a single recipient, perform the following tasks:

•Modify the sendmail configuration file (usually named /etc/sendmail.cf) to the following:

Kmailertable hash /etc/mailertable

---

Note The line could already exist, but be commented out.

---

•If Kmailertable already exists in the configuration file, determine the name of the source text file used to build the mailertable.db file and edit it in or the existing mailertable.db of the site will be overwritten. If Kmailertable does not exist, add the line in toward the top of the configuration file with other "K" settings. The mailer table usually displays like this:

# not local -- try mailer table lookup

R$* <@ $+ > $*         $: < $2 > $1 < @ $2 > $3       extract host name

R< $+ . > $*           $: < $1 > $2                   strip trailing dot

R< $+ > $*             $: < $(mailertable $1 $) > $2  lookup

R< error : $- $+ > $*  $#error $@ $1 $: $2            check -- error?

R< $- : $+ > $*        $# $1 $@ $2 $: $3              check -- resolved?

R< $+ > $*             $: $>90 <$1> $2                try domain

---

Note A rewrite rule must be specified that causes a matching of the hosts in the mailer table. Ensure that the rewrite rules (starting with "R") for mailer table are not commented out.

---

If the mailer table cannot be found, place the lines in Ruleset 0, which starts at the line containing "S0," before the rules that deliver local mail (R$=L $#local ...).

•Create a new mailer specification line in the section with other mailer specifications toward the bottom of the file as follows:

Mfaxofframp,    P=[IPC], F=DFMuXa0, S=11/31, R=21, E=\r\n, L=2040,

T=DNS/RFC822/SMTP,

A=IPC $h

Ensure that the S and R values are the same as those for the existing mailer specifications for mail relaying. The existing S and R values are the lines beginning with an uppercase "M," usually toward the end of the sendmail.cf file.

The S and R values control sendmail rewrite rules as applied to the Sender and Recipient addresses of the message. The rules and rule numbers must be different on each system, especially at sites that have complex sendmail configurations.

It is important to omit the "F=m" flag and include the "F=0" (zero) flag as shown. The "m" flag causes delivery to multiple recipients (which is unwanted) and the "0" (zero) flag disables MX lookups (which are desired). The "0" (zero) flag is available only in sendmail version 8.8 or later. If an earlier version of sendmail is configured, omit the "0" and use [ ] in the mailer table.

•Create a file (/etc/mailertable.txt) with one line for each fax off-ramp device, listing the host name, white space, then the string "faxofframp:" and the host name again. For example, the hosts offramp-seattle.cisco.com and as5300-denver.cisco.com would be inputted as follows:

offramp-seattle.cisco.com  faxofframp:offramp-seattle.cisco.com

as5300-denver.cisco.com    faxofframp:as5300-denver.cisco.com

If prior version of sendmail 8.8 is configured, use brackets around the right-side host name as follows:

offramp-seattle.cisco.com  faxofframp:[offramp-seattle.cisco.com]

•Input the following line to compile the new mailertable.txt using makemap (sometimes located in /usr/sbin):

/usr/sbin/makemap hash /etc/mailertable.db < mailertable.txt

---

Note If the system does not have makemap, sendmail will not support "hash." In this case, point sendmail at the mailertable.txt file by using "text" instead of "hash" on the Kmailertable line.

---

•Close and restart sendmail as follows:

ps -e | grep sendmail

kill pid                   # using PID indicated by above output

/usr/lib/sendmail -bd

•In DNS, set up A and MX records:

as5300-hostname     in a   a.b.c.d

in mx  10  sendmail-system

in mx  20  as5300-hostname

This causes mail to be delivered to the sendmail-system first. Because the sendmail configuration disables MX lookups ("F=0") for the Cisco AS5300 universal access server, sendmail delivers directly to the IP address of the Cisco AS5300 universal access server. Also, if the sendmail system is down or otherwise unavailable, mail is queued directly to the Cisco AS5300 universal access server. Alternatively, use the following configuration:

as5300-hostname     in a   a.b.c.d

in mx  10  sendmail-system

in mx  20  backup-mta

In this example, backup-mta is another sendmail (or other) mailer.

•Fine-tune the following parameters to control sendmail and provide near-real-time delivery of messages:

–"O MinQueueAge" controls how long an entry must be in the queue before an attempt is made to process it. Reduce this setting for use with Cisco fax off-ramps (the normal value is 30 minutes).

–"-q" switch starts sendmail and controls how often the queue is checked for reprocessing entries.

–"O Timeout.queuereturn" controls the lifetime of a message in the queue.

–"O Timeout.queuewarn" controls when sendmail issues a warning that the message has not been successfully relayed.

–"O QueueSortOrder=XXX" controls how sendmail sorts the queue for processing. The string XXX should be one of these: host, priority, or time.

–"O QueueLA" and "O QueueFactor" control the system load average, which causes sendmail to queue new messages instead of delivering them.

–"O ConnectionCacheSize" and "O ConnectionCacheTimeout" processes more than one mail transaction in one TCP session with the fax off-ramp.

•Set the "O DoubleBounceAddress" parameter to the local postmaster or other administrative human address.

---

Note If the sending MTA supports the X-SESSION SMTP service extension, the Cisco AS5300 universal access server will support multiple recipients in one SMTP transaction and will store only one copy of each fax data page in its memory.

---

Configuring the Redialers

Perform the following tasks to enable a redialer:

•Program the redialer to dial the Cisco AS5300 universal access server acting as the on-ramp gateway and capture the dialed digits.

•Configure an MMoIP dial peer to match the forwarded dialed digits from the redialer.

---

Note Only the Mitel and Telecom Research redialers are supported on the Cisco AS5300 universal access server.

---

Fax Relay Packet Loss Concealment Prerequisite Tasks

VCWare 7.04 or higher version must be running before configuring fax relay packet loss concealment.

T.37/T.38 Fax Gateway Prerequisite Tasks

To enable the T.37/T.38 Fax Gateway for the Cisco AS5300 universal access server, perform the following tasks:

•Downloading VCWare to the VFC

•Copying Flash Files to the VFC

•Unbundling VCWare

•Adding Files to the Default File List

•Adding Codecs to the Capability List

•Deleting Files from VFC Flash Memory

•Erasing the VFC Flash Memory

•Configuring IVR

Downloading VCWare to the VFC

VFCs for the Cisco AS5300 universal access server come with a single bundled image of VCWare stored in VFC Flash memory. Table 51 shows the extension types defined for these embedded firmware files.

Table 51 VFC Firmware Extensions 

Firmware	Filenames	Description
VCWare	vcw-vfc-*	Latest version of VCWare stored in Flash memory, including the following: •Datapath engine •Message dispatcher •DSP manager •VC manager •Process scheduler
DSPWare	btl-vfc-*	DSP bootloader
	cor-vfc-*	Core operating system and initialization
	bas-vfc-*	Base voice
	cdc-*-*	Voice codec files
	fax-vfc-*	Fax relay files

DSPWare is stored as a compressed file within VCWare. VCWare must be unbundled to install DSPWare in Flash memory. During the unbundling process, two default lists (default file and capability) are automatically created, populated with default files from that version of VCWare, and stored in VFC Flash memory. The default file list contains the names of the files that are initially loaded into DSP upon boot up, and the capability list defines the set of codecs that can be negotiated for a voice call.

VFC management enables the following functionality:

•Adding versions of VCWare to Flash memory by downloading and unbundling the files

•Erasing files contained in Flash memory

•Adding files to the default file and capability lists

•Deleting files from the default and capability lists

Before downloading VCWare to the VFC, determine whether or not the version of VFC ROM Monitor software is compatible with the installed Cisco IOS image. VFC ROM version 1.2 requires Cisco IOS image 0.14.1 (1.6 NA1) or later. VFC ROM Monitor version 1.2 can be made to work with Cisco IOS image 0.13 (or later) by appending the suffix ".VCW" to the VCWare image stored in VFC Flash memory.

The required tasks are as follows:

•Determining the Number of VFCs

•Identifying the VFC Mode

•Downloading the Software in VCWare Mode

•Downloading the Software in ROM Monitor Mode

Determining the Number of VFCs

To determine the number of installed VFCs and their location, use the following command in privileged EXEC mode:

Command	Purpose
Router# show vfc slot directory	Determines the number of installed VFCs and their location.

For each VFC identified and located, upgrade the system software on that VFC.

Identifying the VFC Mode

To identify the mode (whether VCWare or ROM Monitor), use the following command in privileged EXEC mode:

Command	Purpose
Router# show vfc slot board	Determines whether the VFC is operating in VCWare mode or ROM Monitor mode.

If the mode is VCWare, the VFC status will be "VCWARE running." If the mode is ROM monitor, the VFC status will be "ROMMON."

Downloading the Software in VCWare Mode

To download VFC software to the VFC while in VCWare mode, use the following commands in privileged EXEC mode:

	Command	Purpose
Step 1	Router# erase vfc slot	Erases the Flash memory.
Step 2	Router# show vfc slot directory	Displays that the VFC Flash memory is empty.
Step 3	Router# copy tftp: vfc: or Router# copy flash: vfc:	Downloads the VCWare from a TFTP Boot server into VFC Flash memory or Downloads the VCWare from the VFC motherboard into VFC Flash memory. Note The colons in this command are required.
Step 4	Router# clear vfc slot	Reboots the VFC.
Step 5	Router# show vfc slot board	Checks whether the VFC is back up in VCWare mode.
Step 6	Router# show vfc slot directory	Displays that VCWare is in the VFC Flash memory.
Step 7	Router# unbundle vfc slot	Unbundles the DSPWare from the VCWare and configures the default file list and the capability list.
Step 8	Router# show vfc slot directory	Displays that the DSPWare has been unbundled.
Step 9	Router# show vfc slot default-list	Displays that the default file list has been populated.
Step 10	Router# show vfc slot cap-list	Displays that the capability list has been populated.

The Cisco AS5300 universal access server must be rebooted before these changes can take effect.

---

Note If the VFC ROM is version 1.1, the image name must end in ".VCW." If the VFC ROM is version 1.2, the image name must start with "vcv-."

---

Downloading the Software in ROM Monitor Mode

To download VFC software while in ROM monitor mode, use the following commands in privileged EXEC mode:

	Command	Purpose
Step 1	Router# clear vfc slot purge	Erases the VFC Flash memory.
Step 2	Router# copy tftp: vfc: or Router# copy flash: vfc:	Downloads the VCWare from a TFTP server into VFC Flash memory. or Downloads the VCWare from the VFC motherboard into VFC Flash memory. Note The colons in this command are required.
Step 3	Router# clear vfc slot	Reboots the VFC.
Step 4	Router# show vfc slot board	Checks whether the VFC is back up in VCWare mode.
Step 5	Router# show vfc slot directory