Table Of Contents
Store and Forward Fax with ESMTP
Related Features and Technologies
Supported Standards, MIBs, and RFCs
Configuring the SMTP Server to Support Store and Forward Fax
Reconfiguring the Message Transfer Agents
Forcing All Mail Through One Mailer
Procedure for Tuning the Sending Mailer (sendmail) for Single Recipient
Using Redialers with Store and Forward Fax
Understanding Destination Patterns and Prefixes
Understanding Number Expansion
Configuring the On-Ramp Gateway
Configuring the Called Subscriber Number
Configuring On-Ramp POTS Dial Peers
Configuring On-Ramp MMoIP Dial Peers
Configuring On-Ramp Modem Pooling
Enabling the Nagle Congestion Control Algorithm
Verifying the On-Ramp Gateway Configuration
Configuring the Off-Ramp Gateway
Configuring the Transmitting Subscriber Number
Configuring the Fax Transmission Speed
Configuring the Receiving Mail Transfer Agent
Configuring Off-Ramp MMoIP Dial Peers
Configuring Off-Ramp POTS Dial Peers
Configuring the Faxed Header Information
Configuring the Fax Cover Page Information
Verifying the Off-Ramp Gateway Configuration
Configuring On-Ramp Gateway Security
Verifying the On-Ramp Gateway Security Configuration
Configuring Off-Ramp Gateway Security
Verifying the Off-Ramp Gateway Security Configuration
Attribute-Value Pairs for Store and Forward Fax
Configuring ESMTP Accounting Services
Configuring the On-Ramp Gateway Elements for MDN
Configuring the Off-Ramp Gateway Element for MDN
On-Ramp Gateway Configuration Example
Off-Ramp Gateway Configuration Example
On-Ramp and Off-Ramp Security Configuration Example
On-Ramp Modem Pool Configuration Example
Store and Forward Fax Configuration Output Example
Store and Forward Fax with ESMTP
This document describes how to configure the Store and Forward Fax feature, which enables Cisco AS5300 access servers to send and receive faxes across packet-based networks.
This chapter includes the following sections:
•
Supported Standards, MIBs, and RFCs
Feature Overview
Store and Forward Fax enables Cisco AS5300 access servers to send and receive faxes across packet-based networks. This feature is an implementation of the RFC 2305 proposed standard from the Internet Engineering Task Force (IETF), which is the same as the T.37 recommendation from the International Telegraph Union (ITU). With this feature, your access server becomes a multiservice platform, supplying both data and fax communication. With Store and Forward Fax, you can:
•
•
•
Store and Forward Fax functionality is facilitated through Simple Mail Transfer Protocol (SMTP). Additional functionality is provided in this product to provide confirmed delivery using existing SMTP mechanisms, such as Extended Simple Mail Transfer Protocol (ESMTP).
With Store and Forward Fax, the Cisco AS5300, acting as the on-ramp gateway, receives faxes from end users and converts them into TIFF files. It then creates a standard Multipurpose Internet Mail Extensions (MIME) e-mail message and attaches the TIFF file to it. The on-ramp gateway then forwards this "fax-mail" to the messaging infrastructure of a designated SMTP server, where the fax-mail message is stored. The messaging infrastructure performs message routing, message storage, and transport, and can be either a standard Internet Message Transfer Agent (MTA)—for example, UNIX sendmail—or custom store-and forward fax software. The responsibility of delivering the fax-mail message falls to SMTP and the mail server.
Fax-mail stored on the SMTP server can be delivered either as an e-mail message with attachment when the recipient downloads messages or as a standard fax to a Group 3 fax device. In the latter case, the SMTP server mail delivery infrastructure delivers the fax-mail to the Cisco AS5300 acting as an off-ramp gateway. The off-ramp router converts the attached TIFF file back into standard fax format and then sends the information to a standard Group 3 fax device. The off-ramp gateway is also responsible for generating delivery status notifications (DSNs) and message disposition notifications (MDNs).
Figure 1 shows a simple network topology using Store and Forward Fax.
Figure 1 Topology Showing Store and Forward Fax Functionality
Note
Store and Forward Fax is used in conjunction with Voice over IP (VoIP) for the Cisco AS5300; to use Store and Forward Fax, you must have the VoIP software component for the Cisco AS5300 installed on your access server.
Handling of Enclosures
Store and Forward Fax can process e-mail with the following MIME media content types:
•
•
•
Store and Forward Fax supports the following content transfer encodings:
•
•
•
•
These content transfer encodings can be wrapped in any multipart/* content type. When Store and Forward Fax receives messages with multiple sections, it processes the first part of the multipart message and records a count of what is and is not successfully sent. Store and Forward Fax then discards the rest of the message. For example, if a multipart/alternative message has a text/plain part and a text/html part (and the text/plain part is first), Store and Forward Fax processes only the text/plain part.
Note
Caution
Benefits
Universal Inbox for Fax and E-Mail
You can configure direct inward dialing (DID) numbers so that faxes and e-mails go to the same mailbox.
E-Mail Can Be Sent as a Fax Transmission
With Store and Forward Fax, you can create an e-mail message and send that transmission as a fax; this feature allows you to combine e-mail and fax recipients.
Toll Bypass
In an enterprise environment, where offices in different cities are connected via a WAN, you can bypass toll charges by transmitting faxes over the network connection. Because the fax message is stored on the mail server until SMTP forwards messages to the recipient, you can configure SMTP to forward fax e-mail attachments during off-peak hours (for example, during evenings and weekends), thereby reducing long distance charges.
Broadcast to Multiple Recipients
Because Store and Forward Fax uses e-mail messages as the transporting vehicle for the fax, you can send e-mail fax attachments to multiple recipients simultaneously.
Restrictions
Two modem cards are available for the Cisco AS5300: the Microcom modem card and the MICA technologies modem card. Microcom modem cards support both on-ramp and off-ramp fax activities. MICA technologies modem cards are unidirectional and only support off-ramp faxing.
Store and Forward Fax on-ramp has been designed to work in one of two ways: either using a feature called direct inward dial (DID) or using a redialer, which is an interface hardware device that interconnects between a fax device and a Public Switched Telephone Network (PSTN) network. If you choose not to enable DID, you must configure and enable a redialer on the originating fax machine for Store and Forward Fax to be operational.
Related Features and Technologies
The Store and Forward Fax feature module is related to the existing Voice over IP feature, which is documented in the Cisco IOS Release 12.0 Voice, Video, and Home Applications Configuration Guide and in the Cisco IOS Release 12.0(3)T feature module, Voice over IP for the Cisco AS5300. In addition, Store and Forward Fax uses elements from authentication, authorization, and accounting (AAA) security services, supporting the use of the RADIUS security server protocol. AAA and RADIUS are documented in the Cisco IOS Release 12.0 Security Configuration Guide.
Related Documents
For related information on this feature, refer to the following documents:
•
•
•
•
•
•
•
•
Supported Platforms
•
Supported Standards, MIBs, and RFCs
MIBs
•
•
•
•
•
For descriptions of supported MIBs and how to use MIBs, see the Cisco MIB web site on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
RFCs
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Store and Forward Fax is also compliant with the SMTP requirements in RFC 1123, Requirements for Internet Hosts—Application and Support.
Prerequisites
The following sections describe prerequisite tasks you need to perform and background information you need to understand before you configure Store and Forward Fax:
•
•
•
•
Basic Prerequisite Task List
Before you can configure Store and Forward Fax, you must perform the following basic prerequisite tasks:
•
•
–
–
–
–
For more information about any of the these configuration tasks, refer to the Cisco AS5300 Universal Access Server Software Configuration Guide.
•
•
–
–
For more information about downloading and installing new portware on your modem cards, refer to the Cisco AS5300 Universal Access Server Module Installation Guide and the Cisco AS5300 Universal Access Server Chassis Installation Guide.
Note
•
Note
Configuring the SMTP Server to Support Store and Forward Fax
Although it is not required, another prerequisite task is to configure your SMTP server to better support Store and Forward Fax. If you choose to configure your SMTP server, perform the following tasks:
•
If you create aliases to forward faxes to particular e-mail addresses, you need to configure the on-ramp multimedia over IP (MMoIP) dial peer session-target command as follows:
session target mailto: $d$@hostname.com.The $d$ keyword specifies that the destination fax machine telephone number is inserted in the envelope to: field of the fax-mail that gets sent to the SMTP server.
•
Fax transmission has delivery requirements that are different from e-mail; for example, in certain countries, it is illegal to try to send a fax more than three times in a row if transmission fails. In addition, the time between retransmission attempts can be extremely short. SMTP mail delivery requirements are not governed by such strict regulations; in general, if an e-mail message cannot be delivered, the SMTP server will continue trying to deliver the message 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:
–
–
–
–
Caution
Reconfiguring the Message Transfer Agents
Message Transfer Agents (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 most concrete example is retry timeouts. A typical MTA configuration will retry sending failed message transmissions every 30 minutes for up to 4 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 4-day retry limit. Therefore, although a typical unmodified MTA can be used with the AS5300 for off-ramp operations, you need to tune the MTA for fax operation.
Fax Operation
The AS5300 off-ramp accepts only one e-mail recipient per SMTP transaction for the following reasons:
•
•
The AS5300 prevents multiple recipients in one SMTP transaction by responding to the second and subsequent RCPT commands with a "450" reply code. Because of the typical mailer configuration, this will cause a cumulative 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, and so on).
Forcing All Mail Through One Mailer
To simplify system administration, it is desirable to have all mail to the Cisco AS5300 go through one mailer. One way to do this is to set up a DNS MX record for the Cisco AS5300 pointing to that mailer, and set up that mailer to skip MX record processing for that one host (the Cisco AS5300).
For example, the following two records would exist in DNS:
sj-offramp in mx 10 sj-mailersj-offramp in mx 20 sj-offrampsj-offramp in a 1.2.3.4To help prevent unauthorized use of the fax off-ramp and to force all mail to go through this one mailer, we recommend that the Cisco AS5300 be configured with access control lists (ACLs) to block incoming mail from other mailers. 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.
Procedure for Tuning the Sending Mailer (sendmail) for Single Recipient
The following procedure describes how to tune the sending mailer (in this case, sendmail) to work faster with Store and Forward fax off-ramps and to reduce delays caused by attempting to send to multiple recipients. This procedure configures sendmail to send to each recipient serially, but without delays between each transmission. Configuring sendmail to send messages in parallel would require sending the single messages back through sendmail again (perhaps on a different port) and running multiple sendmail client processes on the system. Such sendmail configuration changes are beyond the intended scope of this document.
Note
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. At most sites, the postmaster is a different person from the network administrator. Interfering with a company mail system can cause a loss of mail service, which many companies rely upon for day-to-day operation.
Caution
1.
Kmailertable hash /etc/mailertableIf this line (Kmailertable) already exists in the configuration file, determine the name of the source text file used to build the mailertable.db file and edit that in Step 4 or the existing mailertable.db of the site will be overwritten. If not present, the line should be added toward the top of the configuration file with other "K" settings.
2.
# not local -- try mailer table lookupR$* <@ $+ > $* $: < $2 > $1 < @ $2 > $3 extract host nameR< $+ . > $* $: < $1 > $2 strip trailing dotR< $+ > $* $: < $(mailertable $1 $) > $2 lookupR< error : $- $+ > $* $#error $@ $1 $: $2 check -- error?R< $- : $+ > $* $# $1 $@ $2 $: $3 check -- resolved?R< $+ > $* $: $>90 <$1> $2 try domainIf they are not present, place the lines in Ruleset 0 (which starts at the line containing "S0") before the rules that deliver local mail (R$=L $#local ...).
3.
Mfaxofframp, P=[IPC], F=DFMuXa0, S=11/31, R=21, E=\r\n, L=2040,T=DNS/RFC822/SMTP,A=IPC $hIt is important that the S= and R= values are the same as those for the existing mailer specifications for mail relaying (existing S= and R= values can be found by looking for the lines beginning with an uppercase "M," usually toward the end of the sendmail.cf file). The S= and R= values control that sendmail rewrites rules are applied to the Sender and Recipient address of the message. The rule numbers (and the rules themselves) are often different on each system, especially at sites that have complex sendmail configurations.
It is important that the "F=m" flag is omitted, and the "F=0" (zero) flag is present, as shown. The "m" flag causes delivery to multiple recipients (which we do not want) and the "0" (zero) flag disables MX lookups (which we want). Note that the "0" (zero) flag is only available in sendmail version 8.8 or later (if you are running an earlier version of sendmail, omit the "0" and use [] in the mailertable as described in Step 4).
4.
For example, the hosts offramp-seattle.cisco.com and as5300-denver.csico.com would be as follows:
offramp-seattle.cisco.com faxofframp:offramp-seattle.cisco.comas5300-denver.cisco.com faxofframp:as5300-denver.cisco.comIf you are running a pre-V8.8 version of sendmail, use brackets around the right-side host name as follows:
offramp-seattle.cisco.com faxofframp:[offramp-seattle.cisco.com]5.
/usr/sbin/makemap hash /etc/mailertable.db < mailertable.txt
Note
6.
ps -e | grep sendmailkill pid # using PID indicated by above output/usr/lib/sendmail -bd7.
as5300-hostname in a a.b.c.din mx 10 sendmail-systemin mx 20 as5300-hostnameThis will cause mail to be delivered to sendmail-system first. Because the sendmail configuration disables MX lookups ("F=0") for the Cisco AS5300, sendmail will deliver directly to the Cisco AS5300's IP address.
Also, if the sendmail system is down or otherwise unavailable, mail will be queued directly to the Cisco AS5300. Alternatively, you can use the following configuration:
as5300-hostname in a a.b.c.din mx 10 sendmail-systemin mx 20 backup-mtaIn this example, backup-mta is another sendmail (or other) mailer.
8.
•
•
•
•
•
•
•
9.
Note
Using Redialers with Store and Forward Fax
Store and Forward Fax on-ramp has been designed to work either using DID or using a redialer. If you choose not to implement DID, you must configure and enable a redialer on the originating fax machine for Store and Forward Fax to be operational.
Use a redialer in the following circumstances:
•
•
•
For Store and Forward Fax to work with a redialer, you must perform the following tasks:
•
A redialer is an interface hardware device that interconnects between a fax device and a PSTN network that maps the numbers that a user dials to reach a specific destination to a different number, and forwards the dialed digits to that new number, transparent to the user. The user enters the complete telephone number into the fax device, and the attached redialer captures and stores those dialed digits. The redialer then dials the on-ramp Cisco AS5300, which provides a secondary dial tone.
When the no direct-inward-dial command is configured for the on-ramp POTS dial peer, the on-ramp gateway will answer the call and provide secondary dial tone. The redialer should be programmed to wait 2 seconds, then send the PIN and destination digits to the on-ramp gateway.
•
When the redialer forwards the original dialed digits to the on-ramp Cisco AS5300, the on-ramp gateway will collect the digits, separate the PIN from the destination, and attempt to match an on-ramp MMoIP dial peer with the destination. If the debug fax receive command is enabled, you can see the digits as they are 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.
Store and Forward Fax allows 19 digits (maximum) for the PIN and 32 digits (maximum) for the destination number. The PIN and destination number must be separated by a #, for example:
0000000012345678#01127116650945The fax protocol starts after 52 digits are detected or the interdigit timeout exceeds 5 seconds.
The following redialers are supported:
•
•
Understanding Dial Peers
Although you need not configure VoIP to use the Store and Forward Fax feature, you need to be familiar with the concept of dial peers. In fact, the key to understanding the Cisco telephony implementation is to understand the use of dial peers. Dial peers define the line characteristics associated with a call leg; a call leg is a discrete segment of a call connection. In general, the Cisco telephony implementation uses four call legs to establish an end-to-end call, as shown in Figure 2. Store and Forward Fax also uses four call legs to establish an end-to-end call, but one of the call legs, the leg from the SMTP server to the off-ramp gateway, is optional.
Figure 2 Dial Peer Call Legs
You use dial peers to apply specific attributes to call legs, such as identifying call origin and destination. In Store and Forward Fax, you also use dial peers to configure MDNs, DSNs, fax image resolution, and encoding type.
Two different kinds of dial peers are used in Store and Forward Fax as follows:
•
•
For more information about on-ramp MMoIP dial peers—for example, how to configure them and how the on-ramp router uses them—see the "Configure On-Ramp MMoIP Dial Peers" section later in this chapter. For more information about how and when to configure optional off-ramp MMoIP dial peers, refer to the "Configure Off-Ramp MMoIP Dial Peers" section later in this chapter. For more general background or supplementary information about voice-related dial peers, refer to the "Voice over IP" chapter.
Understanding Destination Patterns and Prefixes
Another VoIP concept that is important to understand is how the AS5300 uses destination patterns and prefixes in processing a call. A destination pattern is the telephone number of the destination telephony or fax device. When an off-ramp gateway receives a call, it selects an off-ramp POTS dial peer by comparing the called number (the full E.164 telephone number) in the call information with the number configured as the destination pattern for the POTS dial peer. The off-ramp gateway then strips the left-justified numbers corresponding to the destination pattern matching the called number. If you have configured a prefix, the prefix will be put in front of the remaining numbers, creating a dial string, which the router will then dial. If all numbers in the destination pattern are stripped, the user will receive (depending on the attached equipment) a dial tone.
For example, suppose there is a fax device whose E.164 called number is 1(408)555-1234 and that this fax device can be reached within the company by dialing its extension number, 51234. If you configure a destination pattern of "1408555...." (the periods represent wild cards) for the associated off-ramp POTS dial peer, the off-ramp gateway will strip out the digits "1408555" when it receives a call for 1(408)555-1234. For the off-ramp gateway to forward the call to the appropriate destination, the digit "5" needs to be prepended to the remaining digits. In this case, you would configure a prefix of 5.
Suppose there is a fax device whose E.164 called number is 1(408)555-1234 and to reach this device you need to dial "9." In this case, you might configure "1408......." as the destination pattern, and "9" as the prefix. In this example, the off-ramp router will strip the digits "1408" from the called number and append the digit "9" to the front of the remaining numbers, so that the actual number dialed is "9,5551234." The comma in this example means that the router will pause for one second between dialing the "9" and the "5551234" to allow for a secondary dial tone.
For more information about the destination-pattern and prefix commands, refer to the Cisco IOS Multiservice Applications Command Reference publication.
Understanding Number Expansion
Another VoIP concept that is important to understand is number expansion. In many cases, when you define a destination pattern or an incoming called number for a Store and Forward Fax dial peer, you define the full E.164 telephone number associated with it. There may be times, though, when you might need to use number expansion in connection with your defined destination pattern. In most corporate environments, the telephone network is configured so that you can reach a destination by dialing only a portion (the extension number) of the full E.164 telephone number. VoIP functionality (which Store and Forward Fax uses) lets you define an extension number as the destination pattern for a dial peer. If you need to expand the extension to its full E.164 set of digits, you use number expansion. Number expansion lets you define a set of digits to be prepended to the front of a defined and identified destination pattern.
You implement number expansion by using the num-exp command. The extension-number argument defines the number pattern to be expanded. The extension-string argument defines the number to be prepended to the defined extension number. You can verify the number expansion information by using the show num-exp command to show that you have mapped the telephone numbers correctly. After you have configured dial peers and assigned destination patterns to them, you can verify number expansion information by using the show dialplan number command to see how a telephone number maps to a dial peer.
Using a simple telephony-based example, suppose John works in a company where you dial the last four digits of the full E.164 telephone number to reach his extension. The E.164 telephone number is 555-2123; his extension number is 2123. Suppose every employee on his floor has a telephone number that begins with the same first four digits: 555-2. You could define each dial peer's destination pattern using each peer's extension number, and then use number expansion to prepend the first four digits on to the extension. In John's case, the Cisco AS5300 could be configured as follows:
configure terminalnum-exp 2... 5552...dial peer voice 1 potsdestination pattern 2123Number expansion can also be used to replace a dialed number with another number, as in the case of call forwarding. Suppose John, for some reason, needs to have all of his telephone calls forwarded to another number, 555-6611. In this case, you would configure the Cisco AS5300 as follows:
configure terminalnum-exp 2123 5556611dial peer voice 1 potsdestination pattern 2123In this example, every time the device receives a call for extension 2123, the dialed digits will be replaced with 555-6611 and forwarded to that telephone.
The way that you use number expansion with Store and Forward Fax depends on how you have implemented your dial plan. In general, you can use number expansion if you have used the destination-pattern command to define a destination telephone number for a dial peer. For example, off-ramp POTS dial peers define the telephone number of the destination fax device using the destination-pattern command. In this case, if you need to, you could use number expansion.
Configuration Tasks
To configure Store and Forward Fax, perform the tasks in the following sections :
•
•
•
•
Configuring the On-Ramp Gateway
As mentioned, the Cisco AS5300, acting as the on-ramp gateway, receives faxes from end users and converts them into TIFF files, creates standard MIME e-mail messages, attaches the TIFF files to them, and then forwards these fax-mail messages to the messaging infrastructure of a designated SMTP server, where fax-mail messages are stored. The on-ramp gateway accomplishes these activities by using the sending MTA and dial peers. The sending MTA (which is the Cisco AS5300) 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 POTS dial peers define the call as being a fax transmission and the DNIS of the incoming fax call. The on-ramp MMoIP dial peer defines the destination fax telephone number and the session target, which in this case is the SMTP server.
To configure the on-ramp gateway, perform the tasks described in the following sections:
•
•
•
•
•
Configuring the Called Subscriber Number
The first step in configuring the on-ramp gateway is to configure called subscriber number—the number displayed in the LCD of the fax device when you are sending a fax to a recipient. Typically, with a standard Group 3 fax device, this is the telephone number associated with the receiving fax device. To configure the called subscriber number, use the following commands beginning in privileged EXEC mode:
Configuring the Sending MTA
The next step in configuring inbound faxing is to define the characteristics associated with the sending MTA. You use MTAs to define the elements of the e-mail message to which the fax TIFF file is attached; these elements include the following:
•
•
•
•
•
•
Of these configuration steps, you must define the originator of the e-mail fax, the destination mail server, the subject of the message, and the postmaster, which is the default mail station for undeliverable e-mail messages. The remaining configuration steps are optional.
Note
To configure the sending MTA, use the following commands in global configuration mode:
Configuring On-Ramp POTS Dial Peers
On-ramp POTS dial peers define the characteristics of the telephony (PSTN) connection between the sending fax device and the on-ramp gateway. In general, the on-ramp gateway uses the line characteristics defined by POTS dial peers to determine call type and call destination. The on-ramp gateway determines call type and call destination through call discrimination. It matches various POTS peer configuration parameters until it comes up with an appropriate match.
On-Ramp Gateway POTS Dial Peer/Call Discrimination Process
An understanding of how the on-ramp gateway uses POTS dial peers in the course of call discrimination is helpful before you configure on-ramp POTS dial peers. First, though, some functional definitions should be created. As mentioned, Store and Forward Fax uses either DID or a redialer to process a fax call. In both of these cases, a different telephone number is used. For the purposes of the following discussion, the term destinationDN refers to the telephone number of the fax machine where the user wants a fax to be sent and accessDN refers to the telephone number dialed by a redialer to access an on-ramp gateway.
The process of call discrimination begins when the on-ramp router receives a call. It immediately identifies whether the call is being delivered via a PRI interface or a T1-CAS interface. If the on-ramp gateway determines that the call is coming in over a T1-CAS interface, it checks the service type field of the CAS group configuration. If the service type of the CAS group is fax, it flags the call as a Store and Forward Fax call and forwards it to the MMoIP dial peer to be processed as a fax call. If it determines that the call is coming in over a PRI interface, then the on-ramp gateway begins to look at several POTS dial peer data fields to determine what kind of call it has received.
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 where the data matches. If the on-ramp router does not find a match, it assumes that this is a data call and processes the call 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, it concludes that the telephone number it has received is the destinationDN 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 accessDN. In this case, the on-ramp router provides a secondary dial tone and collects another telephone number from the redialer at the other end of the connection that it will use as the destinationDN. After it has received this number from the redialer, the on-ramp gateway forwards the call to be matched to the appropriate on-ramp MMoIP dial peer.
Redialers Versus DID for POTS Peers
By default, DID is disabled, which means that the on-ramp gateway assumes that the fax call it receives is being placed using a redialer. In this situation, when a call arrives on the on-ramp gateway, it presents a dial tone and collects digits until it can identify the destination, as described. After the destination has been identified, it forwards the call through to the next call leg (in this case, the MMoIP dial peer) to the destination.
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.
To configure on-ramp gateway POTS dial peers, use the following commands beginning in global configuration mode:
Configuring On-Ramp MMoIP Dial Peers
MMoIP dial peers describe the line characteristics generally associated with a packet network connection; in the case of Store and Forward Fax, this is the IP network connection between the on-ramp gateway and the SMTP server.
On-ramp MMoIP dial peers are used to define the destination fax telephone number, to specify a destination e-mail address (which in this case identifies the SMTP server), to define the image encoding and resolution specifics for the associated fax-mail TIFF files, and to request either DSNs, MDNs, or both. If you enabled DID and specified an incoming called number for the on-ramp POTS dial peer, the destination pattern of the on-ramp MMoIP dial peer should be the same as the configured incoming called number. If you did not enable DID, then you need to configure and enable a redialer to use Store and Forward Fax. If you use a redialer, you need to configure the destination pattern to match the forwarded dialed digits from the redialer.
On-Ramp Gateway MMoIP Dial Peer/Call Discrimination Process
An understanding of how the on-ramp gateway uses MMoIP dial peers is helpful before configuring on-ramp MMoIP dial peers. As with on-ramp POTS dial peers, for the purposes of the following discussion, the term destinationDN refers to the telephone number of the fax machine where the user wants a fax to be sent, and accessDN refers to the telephone number dialed by a redialer to access an on-ramp gateway.
The function of the on-ramp call discrimination process using MMoIP dial peers is to determine the destination of the fax-mail, which in this case means 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 to the number received and selects the first MMoIP dial peer where the data matches. The on-ramp gateway then looks at the session target field for the selected MMoIP dial peer to identify the destination of the fax-mail message—this could be a specific off-ramp gateway for a Store and Forward fax or, if the fax is being delivered as an e-mail message, an e-mail address for a specific mail server.
Image Encoding and Image Resolution
Depending on your specific needs, you might want to increase or decrease the resolution of the received fax image. As a default, image resolution in Store and Forward Fax is set to passthrough, which means that the image is forwarded exactly as it is received. If you want to specify a different resolution for the fax TIFF image, whether greater or lesser, use the image resolution dial-peer configuration command as an attribute of the on-ramp MMoIP dial peer.
Depending on the capacity of the fax machines in your network, you might want to use a different image encoding (compression) scheme for the fax TIFF image Store and Forward Fax creates. As a default, image encoding in Store and Forward Fax is set to passthrough, which means that the image is forwarded exactly as it is received. If you want to specify a specific encoding (compression) scheme for the fax TIFF image, use the image encoding dial-peer configuration command.
DSN
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. Three different states can be reported back to the sender as follows:
•
•
•
Because these delivery states are not mutually exclusive, you can configure Store and Forward Fax to generate these messages for all or any combination of these events.
You enable DSN requests as part of the on-ramp MMoIP dial peer configuration. For complete instructions on how to configure DSNs using Store and Forward Fax, refer to the "Configuring Delivery Status Notification" section later in this chapter.
MDN
One basic e-mail operation that Store and Forward Fax supports is MDN. Described in RFC 2298, MDN is where a message is returned to the originator of an e-mail message indicating that the e-mail message has been opened. To configure MDN for Store and Forward Fax, you need to configure elements on both the on-ramp and off-ramp gateways. You enable MDN requests as part of the on-ramp MMoIP dial peer configuration. For complete instructions on how to configure MDNs using Store and Forward Fax, see the "Configuring Message Delivery Notification" section later in this chapter.
To configure on-ramp gateway MMoIP dial peers, use the following commands beginning in global configuration mode:
Configuring On-Ramp Modem Pooling
You can use modem pooling on the on-ramp gateway to determine which modems are available for the following:
•
•
As a default, Store and Forward Fax receives faxes on modems that are in the on-ramp gateway default modem pool—meaning that these modems are available for both fax and data calls. The on-ramp gateway determines the call type by using the DNIS. The on-ramp gateway compares the DNIS to the configured value for the incoming called-number POTS dial-peer configuration command; if the DNIS matches the incoming called number, then it 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.
You can specify which incoming fax calls will not be presented to the default modem pool by defining a named modem pool. This is particularly useful if you have both MICA and Microcom faxes; it allows you to divert fax traffic from MICA modems, which at this time do not support fax transmission.
To configure on-ramp modem pooling, use the following commands beginning in privileged EXEC mode:
Enabling the Nagle Congestion Control Algorithm
In the past, when a standard TCP application sent data between machines, TCP tended to send a series of small packets—for example, TCP would send one packet for each keystroke typed when sending keystrokes between machines. On larger networks, many small packets use up bandwidth and contribute to congestion. John Nagle's algorithm (RFC 896) helped alleviate the small-packet problem in TCP and now is being used, by default, in most modern TCP applications. The effect of this algorithm is to accumulate characters into larger chunks and pace them out to the network at a rate matching the round-trip time of the given connection. For more information about the Nagle algorithm (including a good description of how this algorithm works), refer to RFC 2001.
You need to enable Cisco routers and access servers to support the Nagle congestion control algorithm. To optimize Store and Forward Fax performance and to avoid packet congestion, enable the Nagle congestion control algorithm by using the service nagle global configuration command.
To enable the Nagle Congestion Algorithm, use the following command in global configuration mode:
Router(config)# service nagle(Optional) Enables the Nagle congestion control algorithm to optimize Store and Forward Fax performance.
Note
Verifying the On-Ramp Gateway Configuration
•
•
•
•
•
•
•
•
Configuring the Off-Ramp Gateway
Off-ramp faxing requires the Cisco AS5300 acting as the off-ramp gateway to dial the POTS and communicate with a remote fax machine using standard fax protocols. The off-ramp gateway can send a message containing a TIFF image, a plain text message, or a message containing both.
The off-ramp gateway performs the following activities:
•
•
Note
The off-ramp gateway usually uses only POTS dial peers to define the line characteristics between the off-ramp gateway forwarding the converted e-mail message and the fax device; as an option, you can configure MMoIP dial peers, but MMoIP dial peers have limited functionality in off-ramp faxing activities. In general, off-ramp MMoIP dial peers merely define fax compression schemes and resolution and are useful only if you want to alter those parameters for the fax-mails being received.
Note
The off-ramp gateway uses receiving MTAs to define the parameters associated with the AS5300 SMTP server, such as its SMTP host alias(es), which can be different than its normal DNS host name(s) or internal Cisco IOS host name. Off-ramp POTS dial peers basically define the telephone number of the destination fax device. Because a destination pattern is defined for an outbound POTS peer, you can use number expansion.
To configure the off-ramp gateway, perform the tasks in the following sections:
•
•
•
•
•
•
•
The first four tasks are applicable to all off-ramp faxing activities. The last two tasks apply only to off-ramp faxing activities where the fax transmission originates as an e-mail message.
Configuring the Transmitting Subscriber Number
The first step in configuring the off-ramp gateway, whether the off-ramp gateway will be converting a fax TIFF file to a standard fax or sending an e-mail message as a fax, is to configure the transmitting subscriber number. The transmitting subscriber number is the number that will be displayed 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.
To configure the transmitting subscriber number, use the following commands beginning in privileged EXEC mode:
Configuring the Fax Transmission Speed
The next step is to configure the maximum speed of the fax transmission. This 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.
To configure the fax transmission speed, use the following command in global configuration mode:
Specifies the maximum speed at which an off-ramp fax is sent.
Configuring the Receiving Mail Transfer Agent
The next step in configuring the off-ramp gateway is to configure the receiving MTA. Receiving MTAs define the parameters associated with the SMTP server, such as defining the SMTP host alias(es). To configure the receiving MTA, use the following commands in global configuration mode:
Configuring Off-Ramp MMoIP Dial Peers
When implementing Store and Forward Fax on a modem card, the off-ramp gateway does not necessarily need to have MMoIP dial peers configured to establish connectivity with the receiving fax device; therefore, off-ramp MMoIP dial peers are optional when using a modem card. You basically use off-ramp MMoIP dial peers if you need to specify a particular resolution for the fax transmission or if you need to define an encoding type. For example, it might suit your company's needs to send the fax-mail using the least definition as possible to save network resources. In that case, you might want to define a higher image resolution using an off-ramp MMoIP dial peer. Another case where you might want to use an MMoIP dial peer would be if the fax devices in your network could only process a particular type of encoding or compression. If you do decide to configure a MMoIP dial peer, be sure to match the incoming called number command value with the destination pattern telephone number you configured for the corresponding on-ramp POTS dial peer.
Only two resolutions are available for this release: standard and fine. If you select any other image resolution command options (such as passthrough or super-fine), the fax will be sent using the fine resolution. Encoding type defines the type of compression scheme the off-ramp gateway uses for the TIFF image. There are four available compression options: Modified Huffman, Modified Read, Modified Modified Read, and passthrough.
Off-Ramp Gateway MMoIP Dial Peer/Call Discrimination Process
Once again, understanding how the off-ramp gateway uses MMoIP dial peers in the course of call discrimination is helpful before you configure off-ramp MMoIP dial peers. For the purposes of the following discussion, the term destinationDN refers to the telephone number of the fax machine where the user wants a fax to be sent, and accessDN refers to the telephone number dialed by a redialer to access an on-ramp gateway. For the on-ramp gateway to forward the fax-mail to the appropriate SMTP server, it converts the destinationDN into an e-mail address. The left side of this address is the destinationDN; the right side of this e-mail address defines the domain.
When the off-ramp router receives the fax-mail message, it looks at the destinationDN portion of the e-mail address and tries to match that value with the incoming called number field for each of the defined off-ramp MMoIP dial peers in its lookup table. If the off-ramp gateway finds an appropriate match, it uses the specified resolution and encoding values for the fax-mail message. If it cannot find a match, or if no resolution or encoding information has been defined for a matched off-ramp MMoIP dial peer, it applies fine resolution and non (passthrough) encoding for those parameters.
To configure off-ramp gateway MMoIP dial peers, use the following commands beginning in global configuration mode:
Configuring Off-Ramp POTS Dial Peers
POTS dial peers configured for the off-ramp gateway define the line characteristics between the off-ramp gateway forwarding the converted e-mail message and the receiving fax device.
Off-Ramp Gateway POTS Dial Peer/Call Discrimination Process
Once again, understanding how the off-ramp gateway uses POTS dial peers in the course of call discrimination is helpful before you configure off-ramp POTS dial peers. For the purposes of the following discussion, the term destinationDN refers to the telephone number of the fax machine where the user wants a fax to be sent, and accessDN refers to the telephone number dialed by a redialer to access an on-ramp gateway. For the on-ramp gateway to forward the fax-mail to the appropriate SMTP server, it converts the destinationDN into an e-mail address. The left side of this address is the destinationDN; the right side of this e-mail address defines the domain.
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 to the destination DN portion of the fax-mail address and selects the first POTS dial peer where the data matches.
After the off-ramp gateway identifies the appropriate POTS dial peer, it then 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 this address will not be accepted by the off-ramp router.
To generate E.164 e-mail addresses compliant with RFC 2304, use the following address format: fax=+$d$@your.hostname.com. If the off-ramp gateway receives this type of e-mail address, it strips the + and matches an off-ramp POTS dial peer on the remaining digits.The number contained in "$d$" must be a fully qualified E.164 telephone number (that is, it must include the country code) and it must not include an access code (such as "9" to get an outside line).
To configure off-ramp gateway POTS dial peers, use the following commands beginning in global configuration mode:
Configuring the Faxed Header Information
Store and Forward Fax lets you convert standard e-mail messages into fax transmissions. When you send a fax using a standard Group 3 device, there is usually header information appended to the top of each faxed cover and text page, indicating (among other things) the telephone number of the sending fax device, the date, and the time of transmission. Faxes created using an e-mail application need that header information appended to each faxed page. Store and Forward Fax lets you configure exactly what header information is appended to the top of each faxed cover and text page, along with its placement. In addition, you can also use the destination address of an e-mail message to control the cover page generation on a per-recipient basis.
Note
To configure faxed header information, use the following commands in global configuration mode:
Configuring the Fax Cover Page Information
You can configure the off-ramp gateway to create fax cover pages for those faxes that originate from e-mail messages.
Note
To configure fax cover page information, use the following commands in global configuration mode:
You can also use the destination address of an e-mail message to control the cover page generation on a per-recipient basis. You use the fax send coverpage e-mail-controllable command to configure the router to defer to the cover page setting in the e-mail header.
In essence, the off-ramp router defers to the setting configured in the e-mail address itself. For example, if the address has a parameter set to cover=no, this parameter will override the setting for the fax send coverpage enable command and the off-ramp gateway will not generate and send a fax cover page. If the address has a parameter set to cover=yes, the off-ramp gateway will defer to the setting configured in the e-mail address and generate and send a fax cover page.
Table 1 contains examples of what the user would enter in the To: field of the e-mail message.
To configure the router to defer to the cover page setting in the e-mail header, use the following commands in global configuration mode:
Verifying the Off-Ramp Gateway Configuration
You can verify the off-ramp gateway configuration by performing the following tasks:
•
•
•
•
•
•
•
•
Configuring On-Ramp Gateway Security
On-ramp security controls who is allowed to send Store and Forward Fax messages into the network. On-ramp security is facilitated by AAA security services using either RADIUS or TACACS+ as the local security protocol. On-ramp faxing is a client of the authentication server, whether RADIUS or TACACS+. User information is forwarded to the AAA interface, which is then forwarded as an authentication request to the security server. The server responds with either a success or failure to authenticate the on-ramp client. 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 disconnects the call.
To configure on-ramp security, use the following commands in global configuration mode:
Verifying the On-Ramp Gateway Security Configuration
You can verify the on-ramp gateway security configuration by performing the following tasks:
•
•
•
Configuring Off-Ramp Gateway Security
Off-ramp security controls who is allowed to send outgoing Store and Forward Fax messages. Off-ramp security is facilitated by AAA security services using either RADIUS or TACACS+ as the local security protocol. In off-ramp authentication, authentication begins as soon as a fax e-mail message header is received from the e-mail server on the off-ramp gateway. The Cisco AS5300 does not dial the destination fax device until authentication for each fax-mail is successfully completed.
When you enable authentication, the on-ramp gateway inserts whatever value you configure for the mmoip aaa receive-id primary command in the X-account-ID field of the e-mail header. This X-account ID field contains the value that is used for authentication and accounting by the on-ramp gateway. For example, if the mmoip aaa receive-id primary command is set to gateway, the on-ramp gateway name (for example, hostname.domain-name) is inserted in the X-account-ID field of the e-mail header of the fax-mail message.
If you want to use this configured gateway value in the X-account-ID field, you must configure the mmoip aaa send-id primary command with the account-id keyword. This particular keyword enables Store and Forward Fax to generate end-to-end authentication and accounting tracking records. If you do not enable authentication on the on-ramp gateway, the X-account-ID field is left blank.
Note
Note
To configure off-ramp security, use the following commands in global configuration mode:
Verifying the Off-Ramp Gateway Security Configuration
You can verify your off-ramp gateway security configuration by performing the following tasks:
•
•
•
Configuring Off-Ramp ACLs
You can use incoming ACLs on Ethernet or FastEthernet interfaces to filter SMTP traffic for Store and Forward Fax. We recommend that you configure ACLs to restrict access to the SMTP port (port 25) to only trusted e-mail servers.
Creating ACLs is a relatively complicated task and beyond the scope of this document. The following example, though, provides a starting point.
The following configuration example shows how to restrict access to the SMTP port 25 to a trusted e-mail server (IP address 10.0.0.1):
! Enter global configuration mode.configure terminal!! Configure ACLs to restrict access to the SMTP port (port 25) to only "trusted"! e-mail servers. Depending on the topology of your particular network, replace the! any keyword with the destination IP addresses of the Ethernet and FastEthernet! interfaces. Define all trusted e-mail servers using the tcp host ip-address! portion of this command.access-list 100 permit tcp host 10.0.0.1 any eq smtpaccess-list 100 deny tcp any any eq smtpaccess-list 100 permit ip any any!! Enter interface configuration mode for Ethernet interface 0.interface ethernet 0! Apply the access list to this interface.access-group 100 in!! Enter interface configuration mode for FastEthernet interface 0.interface fastethernet 0! Apply the access list to this interface.access-group 100 inFor complete information about configuring ACLs, refer to the relative chapters in the Cisco IOS Security Configuration Guide.
Attribute-Value Pairs for Store and Forward Fax
RADIUS attributes are used to define specific AAA elements in a user profile, which is stored on the RADIUS daemon. The Cisco implementation of RADIUS supports both IETF and vendor-proprietary attributes. IETF RADIUS attribute 26 allows vendors to support their own extended attributes not suitable for general use. Store and Forward Fax uses the Cisco RADIUS implementation of vendor-specific options using the format recommended in the specification. The Cisco vendor-ID company code is 9; the vendor-specific options are represented by subtype numbers from 3 through 21.
Table 2 lists the Store and Forward Fax vendor-specific options supported using vendor-specific IETF RADIUS attribute 26.
For more information about using vendor-specific RADIUS attributes, refer to "RADIUS Attributes" appendix in the Cisco IOS Security Configuration Guide. This appendix file contains a complete list of supported vendor-specific, vendor-proprietary, and IETF-compliant RADIUS attributes, the Cisco IOS releases in which they were implemented, and their definitions.
Configuring ESMTP Accounting Services
In Store and Forward Fax, you can collect accounting information about fax services in two ways:
•
•
The ESMTP Accounting in Store and Forward Fax feature enables you to collect accounting information about fax services 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 in its capacity 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 means that it supports ESMTP accounting. If the MTA recognizes the xaccounting service extension, the MTA (acting as the client) can accept the ESMTP accounting information sent from the off-ramp gateway. If the MTA does not recognize the xaccounting service extension, it will not send the xact command to the off-ramp gateway. In that case, the off-ramp gateway will not respond with ESMTP accounting data.
To use SMTP to collect accounting data, then, you must configure the MTA to explicitly request accounting information as part of the e-mail session—meaning that you must program the MTA to do the following:
•
•
You need not configure any commands on the Cisco AS5300 to enable ESMTP accounting.
In the following example, ESMTP accounting is manually activated via a Telnet session. The output from the MTA is in bold; the output from the off-ramp Cisco AS5300 is in italics.
Note
telnet 172.14.120.2 25Trying 172.14.120.2...Connected to 1.14.120.2.Escape character is '^]'.220 mmoip-b.cisco.com Cisco NetWorks ESMTP serverehlo anyserver.com250-mmoip-b.cisco.com, hello anyserver.com [223.255.254.10] (really)250-ENHANCEDSTATUSCODES250-8BITMIME250-PIPELINING250-HELP250-DSN250-XSESSION250 XACCOUNTINGmail from:<>250 2.5.0 Sender <> okrcpt to:<FAX=+1408555-7442@cisco.com>250 2.1.5 Recipient <FAX=+1408555-7442@cisco.com> ok, maps to '5557442' (cp=yes)xact250 2.5.0 XACCOUNTING enableddata354 Enter mail, end with a single "."Testing 1 2 3Testing 1 2 3Testing 1 2 3Testing 1 2 3Testing 1 2 3Testing 1 2 3Testing 1 2 3.The following example shows the accounting information sent to the SMTP server from the off-ramp gateway when the fax transmission is successful:
250-2.5.0 Message delivered to remote fax machine250-2.5.0 fax_modem_time = 32/41250-2.5.0 fax_pages = 2250-2.5.0 gateway_id = mmoip-b.cisco.com250-2.5.0 fax_connect_speed = 14400bps250-2.5.0 transmit_bytes = 16870250-2.5.0 port_used = slot:1 port:2250-2.5.0 call_type = Fax Send250-2.5.0 abort_cause = 0250-2.5.0 T30_error_code = 0250-2.5.0 ISDN_disconnect_code = 16250 2.5.0 CSID =555-7442The following example shows the accounting information sent to the SMTP server from the off-ramp gateway when the fax transmission is unsuccessful. In this particular example, the fax transmission was unsuccessful because the line was busy.
450-4.3.2 Modem busy450-4.3.2 fax_modem_time = 0/59450-4.3.2 fax_pages = 0450-4.3.2 gateway_id = mmoip-b.cisco.com450-4.3.2 fax_connect_speed = 2400bps450-4.3.2 transmit_bytes = 0450-4.3.2 port_used = slot:1 port:3450-4.3.2 call_type = Fax Send450-4.3.2 abort_cause = 1450-4.3.2 T30_error_code = 11450-4.3.2 ISDN_disconnect_code = 17450 4.3.2 CSID =Table 3 explains the example communication between the MTA and the Cisco AS5300 off-ramp gateway.
Table 3 Communication Between the MTA and the Off-Ramp Cisco AS5300 Access Server
The Telnet connection to the off-ramp Cisco AS5300 is established.
The off-ramp responds to the ESMTP server.
Extended hello—the MTA requests capability information from the off-ramp Cisco AS5300.
The off-ramp gateway responds, advertising its capabilities. In this example, it provides its device name, its IP address, and a list of its capabilities.
XACCOUNTING must be one of the enabled capabilities for ESMTP accounting to work.
The sender is defined.
The sender is acknowledged.
The recipient is defined.
Recipient is acknowledged.
The xact command is issued to enable ESMTP accounting.
ESMTP accounting is enabled.
The MTA notifies the off-ramp gateway that the following information is the body text of the fax-mail message.
The off-ramp gateway acknowledges the request to send data.
The body of the fax-mail message is sent.
End of data.
The off-ramp gateway sends the accounting data. These accounting fields are defined in Table 4.
Table 4 defines the ESMTP accounting information provided by the off-ramp Cisco AS5300.
Table 4 ESMTP Accounting Field Definitions
fax_modem_time =
Indicates the amount of time in seconds the modem sent fax data (x) and the amount of time in seconds of the total fax session (y), which includes both fax-mail and PSTN time, in the form x/y.
fax_pages =
Indicates the total number of faxed pages sent.
gateway_id =
Indicates the hostname.domain-name of the gateway.
fax_connect_speed =
Indicates the fax connection speed in bits per second (bps).
transmit_bytes =
Indicates the total number of bytes sent during the connection.
port_used =
Indicates the port over which this data was received.
call_type =
Indicates the type of call.
abort_cause =
Defines the internal gateway component that signaled that the fax transmission be aborted. Abort causes are defined as follows:
•
•
•
•
•
•
T30_error_code =
Defines the standard applicable T.30 (Rockwell Class 2) error code, as defined in the T.30 specification. Table 6 lists the T.30 error codes.
ISDN_disconnect_code =
Defines the lists the applicable Q.931 (ISDN) call disconnection value. Table 7 lists the Q.931 call disconnection values.
CSID =
Indicates the CSI number, which is an identifier whose coding format contains the telephone number from the remote fax terminal.
Table 5 explains the ESMTP mail system status codes in the previous examples.
Table 6 lists the T.30 (Rockwell Class 2) error codes used in the previous examples. Error code 0 indicates a normal connection.
Note
Table 7 lists the applicable Q.931 (ISDN) call disconnection cause values. Error code 16 indicates a normal transmission.
Configuring MDN
One basic e-mail operation that Store and Forward Fax supports is MDN. Described in RFC 2298, MDN is where a message is returned to the originator of an e-mail message indicating that the e-mail message has been opened. Basically, a sender can request that an MDN (otherwise known as a return receipt) be sent back when the receiver opens an e-mail message. An MDN request is initiated by the originating (or sender) e-mail client; the return response itself is generated by the receiving e-mail client. Most PC-based e-mail software applications (such as Eudora, Netscape Messenger, and Microsoft Outlook) understand requests to generate MDNs.
The MDN is sent to an address chosen by the sender. When the sender requests an MDN, the following header is included in the e-mail header of the message:
Disposition-Notification-To:This header is followed by the address the recipient should use when sending the MDN itself.
RFC 2298 requires that the receiver be able to prevent the automatic generation of an MDN. Because of RFC requirement, it is difficult (if not impossible) to determine whether or not the user has actually received the e-mail message based solely on receiving an MDN, for example:
•
•
To configure MDN for Store and Forward Fax, you need to configure elements on both the on-ramp and off-ramp gateways.
Configuring the On-Ramp Gateway Elements for MDN
To configure the on-ramp gateway to support MDN, use the following commands beginning in global configuration mode:
Configuring the Off-Ramp Gateway Element for MDN
To configure the off-ramp gateway to support MDN, use the following command in global configuration mode:
Router(config)# mta receive generate-mdnSpecifies that the Cisco AS5300 acting as the off-ramp gateway will respond to a request for an MDN.
Verifying MDN Configuration
•
•
•
•
Configuring DSN
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. The on-ramp DSN request is included as part of the fax-mail message sent by the on-ramp gateway when the matching MMoIP dial peer has been configured. The on-ramp DSN response is generated by the SMTP server when the fax-mail message is accepted. The DSN is sent back to the user defined in the mta send mail-from command. The off-ramp DSN is requested by the e-mail client. The DSN response is generated by the off-ramp gateway when it receives a request as part of the fax-mail message.
DSNs can only be generated if the mail client on the SMTP server is capable of responding to a DSN request.
Because the SMTP server generates the DSNs, you need to configure both the mail from: and rcpt to: commands for the DSN feature to be operational, for example:
mail from: <user@mail-server.company.com>rcpt to: <fax=555-1212@company.com> NOTIFY=SUCCESS,FAILURE,DELAYThree different states can be reported back to the sender as follows:
•
•
•
Because these delivery states are not mutually exclusive, you can configure Store and Forward Fax to generate these messages for all or any combination of these events.
To configure DSN, use the following commands beginning in global configuration mode:
Verifying DSN Configuration
You can verify your DSN configuration by performing the following tasks:
•
•
•
•
•
Configuration Examples
Store and Forward Fax configuration examples are provided in the following sections:
•
•
•
•
•
On-Ramp Gateway Configuration Example
The following example shows a general Store and Forward Fax configuration for a Cisco AS5300 acting as an on-ramp gateway:
! Enter global configuration mode.configure terminal!! Define the called subscriber number—in this case, the number configured as the! destination pattern will be used as the called subscriber identifier.fax receive called-subscriber $d$!! Specify the originator of the e-mail address—in this case, the originator information! is derived from the calling number.mta send mail-from username $s$!! (Optional) Provide additional information about the sending device. In this example,! the sending device's hostname is alabamamta send origin-prefix alabama!! Define where this fax-mail should be delivered (which is the mail server postmaster! account) if it cannot be delivered to the defined destination.mta send postmaster postmaster@company.com!! (Optional) If you decide to configure MDNs, specify the address where they should be! sent.mta send return-receipt-to username postmaster@company.com!! Specify the destination e-mail server that accepts on-ramp fax-mail.mta send server california.fax.com!! Define the text string that will be displayed as the subject of the fax-mail.mta send subject Fax-Mail Message!!! Enter dial-peer configuration mode and define an on-ramp POTS peer.dial-peer voice 1000 pots!! Designate fax as the type of information handled by this dial peer.information-type fax!! Specify direct inward dial for this dial peer.direct-inward-dial!!Define the incoming called number associated with this dial peerincoming called number 5105551212!! (Optional) Define the maximum number of connections that will be used simultaneously! to transmit fax-mail.max-conns 10!!! Define an on-ramp MMoIP dial peer.dial-peer voice 1001 mmoip!! Define the telephone number associated with this dial peer.destination-pattern 14085554321!! Define a destination e-mail address for this dial peersession-target mailto:$d$@yourcompany.com!! (Optional) Request that DSNs be sent.dsn!! Specify a particular image encoding method to be used for fax images. In this! example, Modified Huffman (IETF standard) is being specified.image encoding mh!! Specify a particular fax image resolution. In this example, the image resolution was! set to 204 by 196 pixels per inch (fine).image resolution fine!! Designate fax as the type of information handled by this dial peer.info-type fax!! (Optional) Define the maximum number of connections that will be used simultaneously! to transmit fax-mail.max-conn 10!! (Optional) Request that MDNs be sent.mdn!! Specify SMTP as the protocol to be used for Store and Forward Fax.session protocol smtpOff-Ramp Gateway Configuration Example
The following example configures Store and Forward Fax on a Cisco AS5300 acting as the off-ramp gateway:
! Enter global configuration mode.configure terminal!! Define the transmitting subscriber number (TSI); this is the number that is! displayed in the LCD of the receiving fax machine. In this example, the sender's! name, captured by the on-ramp from the sending fax machine) will be used.fax send transmitting-subscriber $s$!! Configure the speed of the fax transmission. In this case, fax transmissions will be!sent at 14400 bits per second.fax send max-speed 14400!! Define a hostname to be used as an alias for the off-ramp AS5300 device.mta receive aliases yourcompany.com!! (Optional) Specify that the Cisco AS5300 will respond to an MDN request.mta receive generate-mdn!! Define the number of simultaneous SMTP recipients (in this case, 10) handled by this! Cisco AS5300.mta receive maximum-recipients 10!!! Specify that the company name will appear in the center position of the fax.! header information.fax send center-header Acme Company!! Specify that the page count will appear in the right position of the fax header! information.fax send right-header $p$!! Specify that the date will appear in the left position of the fax header! information.fax send left-header $a$!! Enable the Cisco AS5300 to send a cover sheet with faxes that originate from e-mail! messages.fax send coverpage enable!! Add a personalized comment to the title field of the fax cover sheet. In this case,! the phrase FAX TRANSMISSION was added.fax send coverpage comment FAX TRANSMISSION!! Enter dial-peer configuration mode and define an off-ramp POTS peer.dial-peer voice 1002 pots!! Designate fax as the type of information handled by this dial peer.information-type fax!! Define a telephone number to be associated with this dial peer.destination-pattern 1408555....!! Add prefix.prefix 9,555!! Define an off-ramp MMoIP peer.dial-peer voice 1003 mmoip!! Designate fax as the type of information handled by this dial peer.information-type fax!! Define an incoming called number to be associated with this dial peer.incoming called-number 14085556789!! Specify a particular fax image resolution. In this example, the image resolution was! set to 204 by 196 pixels per inch (fine).image resolution fineOn-Ramp and Off-Ramp Security Configuration Example
The following example configures on-ramp and off-ramp security for Store and Forward Fax on the Cisco AS5300:
! Enter global configuration mode.configure terminal! Enable AAA security services.aaa new-model! Define the method list to be used with Store and Forward Fax authentication.mmoip aaa method fax authentication onramp-auth! Define the method list to be used with Store and Forward Fax accounting services.mmoip aaa method fax accounting onramp-acct! Define and enable the AAA authentication method list for Store and Forward Fax.aaa authentication login onramp-auth radius local! Define and enable the AAA accounting method list for Store and Forward Fax.aaa accounting connection onramp-acct stop-only radius! Enable on-ramp authentication.mmoip aaa receive-authentication enable! Enable on-ramp accounting services.mmoip aaa receive-accounting enable! Enable off-ramp authorization.mmoip aaa send-authentication enable.! Enable off-ramp accounting services.mmoip aaa receive-accounting enable! Define the gateway ID as the means by which AAA identifies the user for! off-ramp authentication.mmoip aaa send-id primary gateway! Define the gateway ID as the means by which AAA identifies the user for on-ramp! authentication.mmoip aaa receive-id primary gateway! Configure the Cisco AS5300 to support RADIUS.radius-server host 173.13.11.13 auth-port 1645 acct-port 1646radius-server key password! Configure the RADIUS server to recognize and use vendor-specific attributes.radius-server vsa send accountingradius-server vsa send authenticationOn-Ramp Modem Pool Configuration Example
The following example configures a named modem pool on a Cisco AS5300 with 24 Microcom and 60 MICA modems. Microcom modems are in slot 1 and MICA modems are in slot 2. The purpose of this named modem pool (mica-inbound) is to prevent fax calls from going to the MICA modems (modems 25 through 84).
configure terminalmodem-pool mica-inboundpool-range 25-84Store and Forward Fax Configuration Output Example
The following example provides output for the show running configuration command for a complete Store and Forward Fax configuration on the Cisco AS5300:
router# show running configurationBuilding configuration...Current configuration:!! Last configuration change at 19:20:39 PST Mon Jul 14 1997! NVRAM config last updated at 19:11:04 PST Mon Jul 14 1997!version 12.0service timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice internalservice udp-small-serversservice tcp-small-servers!hostname mmoip-b!boot system tftp /auto/annex2/njoffe/c5300-is-mz 255.255.255.255boot system flash c5300-is-mzaaa new-modelaaa authentication login fax radius localaaa accounting connection fax stop-only radius!username njoffe password 0 passwordusername jfitzhug password 0 passwordusername wooksong password 0 passwordusername gmercuri password 0 passwordusername faryaman password 0 passwordusername ilyau password 0 passwordclock timezone PST -8clock calendar-valid!modem-pool mica-inboundmodem poll time 2ip subnet-zeroip host mail-server 10.14.116.1ip host keyer 223.255.254.254ip host mail-server.cisco.com 10.14.116.1ip domain-name cisco.comip name-server 10.14.116.1!isdn switch-type primary-5essfax receive called-subscriber $d$fax send transmitting-subscriber $s$fax send left-header $s$fax send center-header $t$fax send right-header Page:$p$fax send coverpage enablefax send coverpage email-controllablefax send coverpage comment Cisco cover page commentmta send server mail-server.cisco.commta send subject mmoip-b subject line heremta send origin-prefix Cisco Powered Fax Systemmta send postmaster gmercuri@mail-server.commta send mail-from hostname mail-from-hostname.commta send mail-from username $s$mta send return-receipt-to hostname mmoip-b.cisco.commta send return-receipt-to username $s$mta receive aliases mmoip-b.cisco.commta receive aliases [1.2.3.4]mta receive aliases cisco.commta receive maximum-recipients 24mta receive generate-mdnmmoip aaa send-id primary gatewaymmoip aaa receive-id primary gatewaymmoip aaa method fax authentication faxmmoip aaa method fax accounting faxmmoip aaa send-accounting enablemmoip aaa send-authentication enablemmoip aaa receive-accounting enablemmoip aaa receive-authentication enable!!controller T1 0framing esfclock source line primarylinecode b8zscablelength short 133pri-group timeslots 1-24!controller T1 1shutdownframing esfclock source line secondary 1linecode b8zscablelength short 133cas-group 0 timeslots 1-24 type e&m-fgb service fax!controller T1 2shutdownframing esflinecode b8zscablelength short 133cas-group 0 timeslots 1-24 type e&m-fgb!controller T1 3shutdownframing esflinecode b8zscablelength short 133pri-group timeslots 1-24!!voice-port 0:Dtimeouts call-disconnect 0!voice-port 1:0timeouts call-disconnect 0!voice-port 2:0timeouts call-disconnect 0!voice-port 3:Dtimeouts call-disconnect 0!dial-peer voice 5 mmoipdestination-pattern 55508..information-type faxmdndsn successdsn failuresession target mailto:$d$@mail-server.cisco.com!dial-peer voice 1001 potsincoming called-number 571....port 0:D!dial-peer voice 2 potsincoming called-number 5550839information-type faxdirect-inward-dial!dial-peer voice 1 potsdestination-pattern 5......information-type faxprefix 5!num-exp 01133...... 33.......!interface Loopback0no ip addressno ip directed-broadcast!interface Tunnel1no ip addressno ip directed-broadcast!interface Ethernet0ip address 10.14.120.2 255.255.0.0no ip directed-broadcast!interface Serial0:23no ip addressno ip directed-broadcastencapsulation pppno ip route-cachedialer rotary-group 1dialer-group 1isdn switch-type primary-5essisdn tei-negotiation first-callisdn incoming-voice modemno fair-queue!interface Serial3:23no ip addressno ip directed-broadcastshutdownisdn switch-type primary-5essisdn tei-negotiation first-callno cdp enable!interface FastEthernet0no ip addressno ip directed-broadcastshutdown!interface Group-Async1ip unnumbered Ethernet0no ip directed-broadcastencapsulation pppip tcp header-compressiondialer in-banddialer-group 1async mode interactivepeer default ip address pool defaultno fair-queueppp multilinkgroup-range 1 12hold-queue 10 in!interface Dialer1ip unnumbered Loopback0no ip directed-broadcastencapsulation pppdialer in-banddialer-group 1peer default ip address pool defno fair-queueppp multilink!ip default-gateway 10.14.0.1no ip http serverip classlessip route 223.255.254.0 255.255.255.0 10.14.0.1!dialer-list 1 protocol ip permitsnmp-server engineID local 00000009020000E01EA48784snmp-server community public RWradius-server host 10.14.116.1 auth-port 1645 acct-port 1646radius-server key passwordradius-server vsa send accountingradius-server vsa send authentication!line con 0exec-timeout 0 0logging synchronoustransport input noneline 1 12autobaudautoselect pppmodem InOutmodem autoconfigure type microcom_hdmsrotary 1transport input allline aux 0line vty 0 4exec-timeout 0 0password password!exception core-file /auto/annex2/gmercuri/coredumpexception dump 223.255.254.254ntp source Ethernet0ntp update-calendarntp peer 223.255.254.254scheduler heapcheck processscheduler interval 1000endGlossary
ANI—Automatic number identification. Feature of Signaling System 7 (SS7) in which a series of digits, either analog or digital, are included in the call, identifying the telephone number of the calling device. In other words, ANI identifies the number of the calling party.
Call leg—A discrete segment of a call connection.
CSI—Called subscriber identification. An identifier whose coding format contains the telephone number from the remote fax terminal.
DID—Direct inward dial. Allows a user outside a company to dial an internal extension number without having to pass through an operator or attendant. The dialed digits are passed to the PBX, which then completes the call.
DNIS—Dialed number identification service. Feature of trunk lines where the called number is identified; this called number information is used to route the call to the appropriate service.
DSN—Delivery status notification. Message returned to the originator indicating the delivery status of an e-mail message. There are three types of delivery status notifications that can be requested by a sender: delay, success, and failure. Specifications for DSN are described in RFC 1891, RFC 1892, RFC 1893, and RFC 1894.
E.164—ITU-T recommendation for international telecommunication numbering.
ESMTP—Extended Simple Mail Transfer Protocol. Extended version of the Simple Mail Transfer Protocol (SMTP), which includes additional functionality such as delivery notification and session delivery. ESMTP is described in RFC 1869, SMTP Service Extensions.
Group 3—Standard created by the International Telecommunications Union Telecommunications (ITU-T) relating to fax devices. A Group 3 fax device is a digital machine containing a 14400 baud modem that can transmit an 8 1/2 by 11 inch page in approximately 20 seconds with a resolution of either 203 by 98 dots per inch (dpi) or 203 by 196 dpi (fine), using Huffman code to compress fax data. Group 3 faxes use a standard dial-up telephone line for transmission.
LCD—Liquid crystal display. An alphanumeric display on computers and fax devices using liquid crystal sealed between two pieces of glass.
MDN—Message disposition notification. Message returned to the originator of an e-mail message indicating that the e-mail message has been opened. Specifications for MDN are described in RFC 2298.
MICA—Modem ISDN channel aggregation. Modem module and card used in the Cisco AS5300 universal access servers. A MICA modem provides an interface between an incoming or outgoing digital call and an Integrated Services Digital Network (ISDN) telephone line; the call does not have to be converted to analog as it does with a conventional modem and an analog telephone line. Each line can accommodate, or aggregate, up to 24 (T1) or 30 (E1)calls.
MIME—Multipurpose Internet Mail Extension. MIME is the standard for transmitting non-text data (or data that cannot be represented in plain ASCII code) in Internet mail, such as binary, foreign language text (such as Russian or Chinese), audio, or video data. MIME is defined in RFC 2045.
MMoIP—Multimedia Mail over Internet Protocol. Dial peer specific to Store and Forward Fax. The MMoIP dial peer is the vehicle you use to assign particular line characteristics (such as a destination telephone number) to the connection between the Cisco AS5300 and the SMTP mail server during on-ramp faxing.
MTA—Mail Transfer Agent. Software that implements SMTP and provides storage for mail messages to be forwarded or delivered to a local user. MTAs implement SMTP (RFC 821).
POTS dial peer—"Plain old telephone service" dial peer used as a vehicle to assign particular line characteristics to the connection between the user and the receiving Cisco AS5300 during inbound (or on-ramp) faxing and to the connection between the Cisco AS5300 and the receiving fax device during outbound (or off-ramp) faxing.
Redialer—Interface hardware device that interconnects between a fax device and a Public Switched Telephone Network (PSTN) network. A redialer is used to forward a dialed number to another destination. Redialers contain a database of referral telephone numbers. When the user dials a specific number, the redialer collects the dialed digits and matches them to a listing in its database. If there is a match, the redialer dials the referral number (transparent to the user) and forwards the call to the referral number.
SMTP—Simple Mail Transfer Protocol. Application-level protocol in the TCP/IP protocol suite involved with the transmission and reception of electronic mail. Specifications for SMTP are described in RFC 821 and RFC 822.
Store and Forward—Function whereby a message is transmitted to some intermediate relay point and temporarily stored before forwarding to the next relay point.
TSI—Transmitting subscriber information. A frame that can be sent by the caller with the caller's telephone number that can be used to screen calls.
