|
|
Store and Forward Fax enables Cisco AS5300 access servers to transmit 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)) for those features.
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 mail transport 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.
After the fax-mail is stored on the SMTP server, it can be delivered in two different ways: 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 transmits 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.
Store and Forward Fax is used in conjunction with the software feature, Voice over IP for the Cisco AS5300; to use Store and Forward Fax, you must have the software component of Voice over IP for the Cisco AS5300 installed on your access server. In addition, you need to have a modem card installed; Store and Forward Fax functionality depends on the type of modem card installed.
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 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 transmitted. 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.
 | Caution The Cisco AS5300 only recognizes the listed file attachment types for Store and Forward Fax activities. If the Cisco AS5300 receives a file format different from one of the defined acceptable formats, it discards the data. |
You can configure direct inward dialing (DID) numbers so that faxes and e-mails go to the same mailbox.
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.
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.
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.
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.
For related information on this feature, refer to the following documents:
The following sections describe prerequisite tasks you need to perform and background information you need to understand before you configure Store and Forward Fax:
Before you can configure Store and Forward Fax, you must perform the following basic prerequisite tasks:
Although 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:
session target mailto: $d$@hostname.com.
| Caution It is extremely important to modify SMTP delivery requirement parameters. Failure to do so can result in a monopoly of bandwidth and fax resources. |
Mail 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. This 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, while a typical unmodified MTA can be used with the AS5300 for off-ramp operations, you need to tune the MTA for fax operation.
The AS5300 off-ramp accepts only one e-mail recipient per SMTP transaction because:
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).
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-mailer sj-offramp in mx 20 sj-offramp sj-offramp in a 1.2.3.4
To help prevent unauthorized use of the fax offramp and to force all mail to go through this one mailer, we recommend that the Cisco AS5300 be configured with Access 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 Release 12.0 Security Configuration Guide.
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 also run multiple sendmail client processes on the system.Such sendmail configuration changes are beyond the intended scope of this document.
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 site's postmaster. At most sites, the postmaster is a different person from the network administrator. Interfering with a company's mail system can cause a loss of mail service, which many companies rely upon for day-to-day operation.
| Caution Modifying the sendmail configuration can break all e-mail into and out of the box for your entire enterprise. Perform sendmail configuration modifications only after you have notified your site's postmaster. |
1. The sendmail configuration file should be modified to contain the following line. The sendmail configuration file is usually named /etc/sendmail.cf. Note that the line may already exist but may be commented out.
Kmailertable hash /etc/mailertable
If 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 site's existing mailertable.db will be overwritten. If not present, the line should be added towards the top of the configuration file with other "K" settings.
2. For the above mailertable entry to be used by sendmail, a rewrite rule must be specified that causes a matching of the hosts in the mailertable. Make sure the rewrite rules (starting with "R") for mailertable are not commented out. They can be found by searching for "mailertable", and usually look 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
If 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. A new mailer specification line needs to be created. This should be done in the section with other mailer specifications, which is usually towards the bottom of the file. Create the following line:
Mfaxofframp, P=[IPC], F=DFMuXa0, S=11/31, R=21, E=\r\n, L=2040, T=DNS/RFC822/SMTP, A=IPC $h
It is important that the S= and R= values are the same as that 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 towards the end of the sendmail.cf file). The S= and R= values control which 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 above. The "m" flag causes delivery to multiple recipients (which we don't 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 higher (if running an earlier version of sendmail, omit the "0" and use [] in the mailertable as described in step 4).
4. The file /etc/mailertable.txt should be created with one line for each fax offramp device, listing the hostname, whitespace, then the string "faxofframp:" and the hostname again.
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.com as5300-denver.cisco.com faxofframp:as5300-denver.cisco.com
If running a pre-V8.8 version of sendmail, use brackets around the right-side hostname, like:
offramp-seattle.cisco.com faxofframp:[offramp-seattle.cisco.com]
5. Compile the new mailertable.txt using makemap (sometimes located in /usr/sbin). For example:
/usr/sbin/makemap hash /etc/mailertable.db < mailertable.txt
6. Close and restart sendmail:
ps -e | grep sendmail kill pid # using PID indicated by above output /usr/lib/sendmail -bd
7. 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 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 to directly to the Cisco AS5300. Alternatively, you can 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.
8. Tune the following parameters to control sendmail and provide behavior more desirable for the needs of users wanting near-real-time delivery of messages:
(a) The configuration file setting "O MinQueueAge" controls how long an entry must be in the queue before an attempt will be made to process it. It is likely a site will want to reduce this setting for use with Cisco Fax off-ramps (normal value is 30 minutes).
(b) The "-q" switch used to start sendmail controls how often the queue is checked for re-processing entries
(c) The configuration file setting "O Timeout.queuereturn" controls a message's lifetime in the queue.
(d) The configuration file setting "O Timeout.queuewarn" controls when sendmail issues a warning that the message hasn't been successfully relayed.
(e) The configuration file setting "O QueueSortOrder=XXX" controls how sendmail sorts the queue for processing. The string XXX should be one of: host, priority, or time.
(f) The configuration file settings "O QueeueLA" and "O QueueFactor" control the system load average which causes sendmail to queue new messages instead of delivering them.
(g) The configuration file setting "O ConnectionCacheSize" and "O ConnectionCacheTimeout" can be used to process more than one mail transaction in one TCP session with the fax offramp.
9. It is recommended that the configuration file setting "O DoubleBounceAddress" be set to the local postmaster or other administrative human address.
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. 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 if:
For Store and Forward Fax to work with a redialer, you must:
0000000012345678#01127116650945
The fax protocol starts after 52 digits are detected or the inter-digit timeout exceeds 5 seconds.
The following redialers are supported:
Although you do not need to configure Voice over IP 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 Cisco's 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, Cisco's 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.
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 message disposition notifications (MDNs), delivery status notifications (DSNs), fax image resolution, and encoding type.
There are two different kinds of dial peers used in Store and Forward Fax:
For more information about on-ramp MMoIP dial peers---for example, how to configure them and how the on-ramp router uses them---refer to the "Configure On-Ramp MMoIP Dial Peers" section. 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. For more general background or supplementary information about voice-related dial peers, refer to the "Voice over IP" chapter in the Cisco IOS Release 12.0 Voice, Video, and Home Applications Configuration Guide.
Another Voice over IP 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 out 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 out, 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 out the digits "1408" from the called number and append the digits "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 destination-pattern and prefix commands, refer to the Cisco IOS Release 12.0 Voice, Video, and Home Applications Command Reference.
Another Voice over IP 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. Voice over IP 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 beginning of 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 his or her 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 terminal num-exp 2... 5552... dial peer voice 1 pots destination pattern 2123
Number 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 terminal num-exp 2123 5556611 dial peer voice 1 pots destination pattern 2123
In 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.
For descriptions of supported MIBs and how to use MIBs, see Cisco's MIB web site on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
Store and Forward Fax is also compliant with the SMTP requirements in RFC 1123, Requirements for Internet Hosts---Application and Support.
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.
Perform the tasks in the following sections to configure Store and Forward Fax:
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 mail transport agent (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 following tasks:
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.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router# configure terminal | Enters global configuration mode. | ||
| Router(config)# fax receive called-subscriber {$d$|string} | Defines the number that is displayed in the LCD of the sending fax machine. This parameter defines the called subscriber identifier (CSI). |
The next step in configuring inbound faxing is to define the characteristics associated with the sending mail transfer agent (MTA). You use MTAs to define the elements of the e-mail message to which the fax TIFF file is attached; these elements include:
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.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)# mta send mail-from hostname string | Specifies the originator (hostname portion) of the e-mail fax message. This information appears in the RFC 822 "From:" field and the RFC 821 "MAIL FROM" field of the e-mail fax message. This information is also used for generating DSNs. Note When you configure the mta send mail-from hostname command, the host name configured is used with the mta send mail-from username command to form a complete e-mail address, like "faxuser@onramp-gateway.com." | ||
| Router(config)# mta send mail-from {username string|username $s$} | Specifies the originator (username portion) of the e-mail fax message. This information appears in the RFC 822 "From:" field and the RFC 821 "MAIL FROM" field of the e-mail fax message. This information is also used for generating DSNs. When you configure the mta send mail-from username command, the user name configured is used with the mta send mail-from hostname command to form a complete e-mail address, like "faxuser@onramp-gateway.com." | ||
| Router(config)# mta send server {host-name|IP-address} | Specifies the destination server. Note DNS MX records are not used to determine the IP address of the host specified with the mta send server command. | ||
| Router(config)# mta send subject string | Defines the text that appears in the subject field of the e-mail fax message. | ||
| Router(config)# mta send postmaster e-mail-address | Defines address to be used as the mta send mail-from address if the evaluated string is blank. An address such as fax-administrator@example.com is recommended (where company.com is replaced with your domain name, and fax-administrator is aliased to the person responsible for the operation of the Cisco AS5300's fax functions). At some sites this may be the same person as the e-mail postmaster, but at most sites this is likely to be a different person. | ||
| Router(config)# mta send origin-prefix string | (Optional) Defines additional identifying information to be appended in front of the e-mail header. | ||
| Router(config)# mta send return-receipt-to {hostname string username string} | (Optional) Specifies the address where MDNs are sent, if you request message disposition notification. |
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.
It is really helpful, before configuring on-ramp POTS dial peers, to understand how the on-ramp gateway uses POTS dial peers in the course of call discrimination. First, though, we need to create some functional definitions. As mentioned, Store and Forward Fax uses either direct inward dial (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.
First, 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 see 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 or not DID has been enabled. If DID has been enabled, it concludes that the telephone number is 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.
By default, DID is disabled, which means that the on-ramp gateway assumes that the fax call it receives it 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 above. 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.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)# dial-peer voice number pots | Defines the POTS dial peer tag number and enters the dial-peer configuration mode. | ||
| Router(config-dial-)# information-type fax | Identifies calls associated with this dial peer as being fax transmissions, as opposed to being voice calls. | ||
| Router(config-dial-)# direct-inward-dial | (Optional) Specifies DID. If you are not using a redialer, you must enable DID to use Store and Forward Fax. | ||
| Router(config-dial-)# incoming called-number string | Defines the telephone number associated with the POTS dial peer---in Store and Forward Fax, if DID is enabled, the incoming called number (DNIS number) is used to match the destination pattern of outgoing MMoIP dial peers. | ||
| Router(config-dial-)# max-conn number | (Optional) Defines the maximum number of on-ramp connections used simultaneously on this Cisco AS5300 to transmit fax-mail. |
MMoIP dial peers describe the line characteristics generally associated with a packet network connection; in the case of Store and Forward, 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.
It is really helpful, before configuring on-ramp MMoIP dial peers, to understand how the on-ramp gateway uses 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.
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.
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. Three different states can be reported back to the sender:
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 (DSN)" section.
One of the basic e-mail operations that Store and Forward Fax supports is message delivery notification (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, refer to the "Configuring Message Delivery Notification (MDN)" section.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)# dial-peer voice number mmoip | Defines the MMoIP dial peer tag number and enters the dial-peer configuration mode. | ||
| Router(config-dial-)# information-type fax | Identifies calls associated with this dial peer as being fax transmissions, as opposed to strictly being voice calls. | ||
| Router(config-dial-)# destination-pattern [+]string | Identifies the destination fax telephone number. If DNIS has been enabled, this number should be the same as the configured incoming called number. If DNIS is not enabled, this should be the number from the redialer DNIS. | ||
| Router(config-dial-)# session target {mailto:{name|$d$}@domain-name | ipv4:destination-address|dns:[$s$.|$d$.|$u$.| $e$.] host-name|loopback:rtp|loopback:compressed | loopback:uncompressed} | Defines the destination e-mail address for the fax-mail, meaning the e-mail address identifying the SMTP server. | ||
| Router(config-dial-)# session protocol smtp | Identifies the session protocol being used between the on-ramp gateway and the remote mail server as SMTP. | ||
| Router(config-dial-)# image encoding {mh|mr|mmr|passthrough} | Selects a specific encoding method for the fax-mail messages forwarded via this dial peer. | ||
| Router(config-dial-)# image resolution {fine|standard | super-fine|passthrough} | Selects a specific resolution for the TIFF images attached to the fax-mail message forwarded vis this dial peer. | ||
| Router(config-dial-)# max-conn number | (Optional) Defines the maximum number of connections used simultaneously on this Cisco AS5300 to transmit fax-mail. | ||
| Router(config-dial-)# dsn {delay|failure|success} | (Optional) Requests that a delivery status notification be generated by the last-hop mailer if the delivery was successful. This DSN is sent to the address specified by the mta send mail-from command. Three types of DSNs can be requested: delay, failure, and success. Note DSN must be supported by the remote mail server. | ||
| Router(config-dial-)# mdn | (Optional) Requests that a message disposition notification (MDN) be generated by the mail user agent when the message is processed (typically opened or read). The MDN is generated by the receiving mail user agent and sent to the address defined by the mta send return-receipt-to command. Note Return receipt must be supported/initiated by the receiving e-mail client. |
You can use modem pooling on the on-ramp gateway to determine which modems are available for:
As a default, Store and Forward Fax receives faxes on modems that are in the on-ramp gateway's 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, the call is then treated 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 do not support fax transmission.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router# configure terminal | Enters global configuration mode. | ||
| Router(config)# modem-pool name | Creates a modem pool. | ||
| Router(config)# pool-range number-number | Assigns a range of modems to the specified modem pool. |
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.
| Command | Purpose |
|---|---|
Router(config)# service nagle | (Optional) Enables the Nagle congestion control algorithm to optimize Store and Forward Fax performance. |
Off-ramp faxing requires the Cisco AS5300 acting as the off-ramp gateway dial the POTS and communicate with a remote fax machine using standard fax protocols. The off-ramp gateway is capable of transmitting a message containing a TIFF image, a plain text message, or a message containing both.
The off-ramp gateway performs the following activities:
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.
The off-ramp gateway uses receiving MTAs to define the parameters associated with the AS5300's SMTP server, such as its SMTP host alias(es), which can be different than its normal DNS hostname(s) or internal IOS hostname. 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 following tasks:
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.
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 transmitting 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.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router# configure terminal | Enters global configuration mode. | ||
| Router(config)# fax send transmitting-subscriber {$d$|string} | Defines the number that appears in the LCD of the receiving fax device. This parameter defines the transmitting subscriber identifier (TSI). |
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.
| Command | Purpose |
|---|---|
Router (config)# fax send max-speed {12000|14400|2400|4800|7200|7600} | Specifies the maximum speed at which an off-ramp fax is transmitted. |
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).
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)# mta receive aliases string | Defines a host name to be used as an alias for the off-ramp Cisco AS5300 device. You can define up to 10 different aliases. Note The Cisco AS5300's SMTP server will only accept incoming mail if the destination hostname of the incoming mail matches one of the aliases as configured by the mta receive aliases command. Note This command does not automatically include reception for a domain IP address---it must be explicitly added. If you add an IP address, you must enclose the address in brackets as follows: [xxx.xxx.xxx.xxx] | ||
| Router(config)# mta receive generate-mdn | (Optional) Configures the Cisco AS5300 to actually generate a MDN message when requested to do so. Some sites may want to enable or disable this feature depending on the types of mailers in use. | ||
| Router(config)# | Defines the number of simultaneous SMTP recipients handled by this device. This is intended to limit the number of resources (modems) allocated for fax transmissions. |
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. 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 transmit 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.
Once again, it is helpful, before configuring off-ramp MMoIP dial peers, to understand how the off-ramp gateway uses MMoIP dial peers in the course of call discrimination. 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.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)# dial-peer voice number mmoip | Defines the MMoIP dial peer tag number and enters the dial-peer configuration mode | ||
| Router(config-dial-)# information-type fax | Identifies calls associated with this dial peer as being fax transmissions, as opposed to strictly being voice calls. | ||
| Router(config-dial-)# incoming called-number string | Identifies the destination fax telephone number. | ||
| Router(config-dial-)# image resolution {fine|standard|super-fine|passthrough} | Specifies the fax image resolution for TIFF files associated with this particular MMoIP dial peer. Note Only standard and fine fax resolutions are supported for this release. | ||
| Router(config-dial-)# image encoding {mh|mr|mmr|passthrough} | Specifies the type of encoding to be used for TIFF files associated with this MMoIP dial peer. |
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.
Once again, it is helpful, before configuring off-ramp POTS dial peers, to understand how the off-ramp gateway uses POTS dial peers in the course of call discrimination. 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.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)# dial-peer voice number pots | Defines the POTS dial peer tag number and enter the dial-peer configuration mode. | ||
| Router(config-dial-)# information-type fax | Identifies calls associated with this dial peer as being fax transmissions, as opposed to strictly being voice calls. | ||
| Router(config-dial-)# destination-pattern [+]string | Identifies the destination fax telephone number. | ||
| Router(config-dial-)# | (Optional) Specifies the prefix of the dialed digits associated with this dial peer. If you configure a prefix, when an outgoing call is initiated, the prefix string value is sent to the modem first, before the telephone number configured for this dial peer. |
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 to have 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 as well as 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.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)# fax send center-header {$a$|$d$|$p$|$s$|$t$|string} | Specifies the header information to be displayed in the center position. The wildcards used in this command are used to insert the following information:
You use the string variable in this command to insert personalized text string. | ||
| Router(config)# fax send right-header {$a$|$d$|$p$|$s$|$t$|string} | Specifies the header information to be displayed on the right. The wildcards used in this command are used to insert the following information:
You use the string variable in this command to insert personalized text string. | ||
| Router(config)# fax send left-header {$a$ | $d$ | $p$ | $s$ | $t$ | string} | Specifies the header information to be displayed on the left. The wildcards used in this command are used to insert the following information:
You use the string variable in this command to insert personalized text string. |
You can configure the off-ramp gateway to create fax cover pages for those faxes that originate from e-mail messages.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)# fax send coverpage enable | Enables the off-ramp gateway to send a cover sheet with faxes that originate from e-mail messages. | ||
| Router(config)# fax send coverpage comment string | (Optional) Adds personalized text in the title field of the fax cover sheet. | ||
| Router(config)# fax send coverpage show-detail | (Optional) Prints all of the e-mail header information as part of the fax cover sheet text. |
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 this 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.
| Example for To: Field Entries | Description |
|---|---|
FAX=+1-312-555-3260@fax.com | Fax sent to an E.164-compliant long distance telephone number in the United States. If the fax coverpage enable command has been configured, Store and Forward Fax will generate a fax cover page. |
FAX=+1-312-555-3260/cover=no@fax.com | Fax sent to an E.164-compliant long distance telephone number in the United States. In this example, the fax coverpage enable command is superseded by the cover=no statement. No cover page will be generated. |
FAX=+1-312-555-3260/cover=yes@fax.com | Fax sent to an E.164-compliant long distance telephone number in the United States. In this example, the fax coverpage enable command is superseded by the cover=yes statement. Store and Forward Fax will generate a fax cover page. |
FAX=+1-312-555-3260/T33S=123456@fax.com | Fax sent to an E.164-compliant long distance telephone number in the United States; this example has an attached T.33 substring. |
FAX=+49-515-555-5637@faxgateway.com | Fax sent to an E.164-compliant long distance telephone number in Germany. |
FAX=+61-2-555-8765@fax.host.com | Fax sent to an E.164-compliant long distance telephone number in Australia. |
FAX=+33-65-555-5555@fax.com | Fax sent to an E.164-compliant long distance telephone number in France. |
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)# fax send coverpage enable | Enables the off-ramp gateway to send a cover page with faxes that originate from e-mail messages. | ||
| Router(config)# fax send coverpage e-mail controllable | Configures the router to defer to the cover page setting in the e-mail header. For example, if the address has a parameter set to cover=no or cover=yes, it will override the setting for the fax send coverpage enable command. |
On-ramp security controls who is allowed to send Store and Forward faxes into the network. On-ramp security is facilitated by Cisco's authentication, authorization, and accounting (AAA) security services using either Remote Authentication Dial-In User Service (RADIUS) or Terminal Access Controller Access Control System (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. If a response is not received from the AAA server before the first page is received, the fax modem disconnects the call.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)# aaa new model | Enables AAA security services. | ||
| Router(config)# mmoip aaa method fax authentication method-list-name | Defines the name of the method list to be used for Store and Forward Fax AAA authentication. | ||
| Router(config)# | Defines the name of the method list to be used for Store and Forward Fax AAA accounting. | ||
| Router(config)# aaa authentication login {default|list-name} method1 [method2...] | Creates a local authentication method list and enables authentication. | ||
| Router(config)# | Creates an accounting method list and enables accounting. We recommend the following configuration: aaa accounting connection list-name stop-only. | ||
| Router(config)# mmoip aaa receive-id primary {ani|dnis|gateway|redialer-id|redialer-dnis} | Specifies the primary location where AAA retrieves its identifying information for on-ramp faxing. | ||
| Router(config)# | (Optional) Specifies the secondary location where AAA retrieves its identifying information for on-ramp faxing. | ||
| Router(config)# mmoip aaa receive-authentication enable | Enables on-ramp AAA authentication services. | ||
| Router(config)# | Enables on-ramp AAA accounting services. | ||
| Router(config)# radius-server host {hostname|ip-address} [auth-port port-number] [acct-port port-number] | Specifies the IP address or host name of the remote RADIUS server host and assigns authentication and accounting destination port numbers. (Typical authentication and accounting destination ports are 1645 and 1646.) | ||
| Router(config)# | Specifies the shared secret text string used between the router and the RADIUS server. | ||
| Router(config)# radius-server vsa send accounting | Enables the network access server to recognize and use accounting vendor-specific attributes (VSAs) as defined by RADIUS IETF attribute 26. | ||
| Router(config)# | Enables the network access server to recognize and use authentication VSAs as defined by RADIUS IETF attribute 26. |
Off-ramp security controls who is allowed to send outgoing Store and Forward faxes. Off-ramp security is facilitated by Cisco's 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.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)# aaa new model | Enables AAA security services. | ||
| Router(config)# mmoip aaa method fax authentication method-list-name | Defines the name of the method list to be used for Store and Forward Fax AAA authentication. | ||
| Router(config)# | Defines the name of the method list to be used for Store and Forward Fax AAA accounting. | ||
| Router(config)# aaa authentication login {default | list-name} method1 [method2...] | Creates a local authentication method list and enables authentication. | ||
| Router(config)# | Creates an accounting method list and enables accounting. We recommend the following configuration: aaa accounting connection list-name stop-only. | ||
| Router(config)# mmoip aaa send-id primary {account-id | envelope-from | envelope-to | gateway} | Specifies the primary location where AAA retrieves its identifying information for off-ramp faxing. | ||
| Router(config)# | (Optional) Specifies the secondary location where AAA retrieves its identifying information for off-ramp faxing. | ||
| Router(config)# mmoip aaa send-authentication enable | Enables off-ramp AAA authentication services. | ||
| Router(config)# | Enables off-ramp AAA accounting services. | ||
| Router(config)# radius-server host {hostname | ip-address} [auth-port port-number] [acct-port port-number] | Specifies the IP address or host name of the remote RADIUS server host and assign authentication and accounting destination port numbers. (Typical authentication and accounting destination ports are 1645 and 1646.) | ||
| Router(config)# | Specifies the shared secret text string used between the router and the RADIUS server. | ||
| Router(config)# radius-server vsa send accounting | Enables the network access server to recognize and use accounting vendor-specific attributes (VSAs) as defined by RADIUS IETF attribute 26. | ||
| Router(config)# | Enables the network access server to recognize and use authentication VSAs as defined by RADIUS IETF attribute 26. |
You can use incoming access control lists (ACLs) on Ethernet and/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 from which to begin.
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 smtp access-list 100 deny tcp any any eq smtp access-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 in
For complete information about configuring ACLs, refer to the relative chapters in the Cisco IOS Release 12.0 Security Configuration Guide.
RADIUS attributes are used to define specific authentication, authorization, and accounting (AAA) elements in a user profile, which is stored on the RADIUS daemon. Cisco's implementation of RADIUS supports both Internet Engineering Task Force (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. Cisco's vendor-ID company code is 9; the vendor-specific options are represented by sub-type numbers from 3 through 21.
Table 2 lists the Store and Forward vendor-specific options currently supported using vendor-specific IETF RADIUS attribute 26.
| IETF RADIUS Attribute | Vendor- Specific Company Code | Sub-Type Number | Attribute | Description |
|---|---|---|---|---|
26 | 9 | 3 | Cisco-Fax-Account-Id-Origin | Indicates the account ID origin as defined by system administrator for the mmoip aaa receive-id or the mmoip aaa send-id commands. |
26 | 9 | 4 | Cisco-Fax-Msg-Id= | Indicates a unique fax message identification number assigned by Store and Forward Fax. |
26 | 9 | 5 | Cisco-Fax-Pages | Indicates the number of pages transmitted or received during this fax session. This page count includes cover pages. |
26 | 9 | 6 | Cisco-Fax-Coverpage-Flag | Indicates whether or not a cover page was generated by the off-ramp gateway for this fax session. True indicates that a cover page was generated; false means that a cover page was not generated. |
26 | 9 | 7 | Cisco-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. For example, 10/15 means that the transfer time took 10 seconds, and the total fax session took 15 seconds. |
26 | 9 | 8 | Cisco-Fax-Connect-Speed | Indicates the modem speed at which this fax-mail was initially transmitted or received. Possible values are 1200, 4800, 9600, and 14400. |
26 | 9 | 9 | Cisco-Fax-Recipient-Count | Indicates the number of recipients for this fax transmission. Until e-mail servers support Session mode, the number should be 1. |
26 | 9 | 10 | Cisco-Fax-Process-Abort-Flag | Indicates that the fax session was aborted or successful. True means that the session was aborted; false means that the session was successful. |
26 | 9 | 11 | Cisco-Fax-Dsn-Address | Indicates the address to which DSNs will be sent. |
26 | 9 | 12 | Cisco-Fax-Dsn-Flag | Indicates whether or not DSN has been enabled. True indicates that DSN has been enabled; false means that DSN has not been enabled. |
26 | 9 | 13 | Cisco-Fax-Mdn-Address | Indicates the address to which MDNs will be sent. |
26 | 9 | 14 | Cisco-Fax-Mdn-Flag | Indicates whether or not message delivery notification (MDN) has been enabled. True indicates that MDN had been enabled; false means that MDN had not been enabled. |
26 | 9 | 15 | Cisco-Fax-Auth-Status | Indicates whether or not authentication for this fax session was successful. Possible values for this field are success, failed, bypassed, or unknown |
26 | 9 | 16 | Cisco-Email-Server-Address | Indicates the IP address of the e-mail server handling the on-ramp fax-mail message. |
26 | 9 | 17 | Cisco-Email-Server-Ack-Flag | Indicates that the on-ramp gateway has received a positive acknowledgment from the e-mail server accepting the fax-mail message. |
26 | 9 | 18 | Cisco-Gateway-Id | Indicates the name of the gateway that processed the fax session. The name appears in the following format: hostname.domain-name |
26 | 9 | 19 | Cisco-Call-Type | Describes the type of fax activity: fax receive or fax send. |
26 | 9 | 20 | Cisco-Port-Used | Indicates the slot/port number of the Cisco AS5300 used to either transmit or receive this fax-mail. |
26 | 9 | 21 | Cisco-Abort-Cause | If the fax session aborts, indicates the system component that signaled the abort. Examples of system components that could trigger an abort are FAP (Fax Application Process), TIFF (the TIFF reader or the TIFF writer), fax-mail client, fax-mail server, ESMTP client, or ESMTP server. |
For more information about using vendor-specific RADIUS attributes, refer to "RADIUS Attributes" chapter in the Cisco IOS Release 12.0 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.
One of the basic e-mail operations that Store and Forward Fax supports is message delivery notification (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's) 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 this, 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.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)# mta send return-receipt-to username string | Specifies the user name address where MDNs are sent. If this field is left blank, the on-ramp gateway inserts the postmaster address in this field as a default. | ||
| Router(config)# mta send return-receipt-to hostname string | Specifies the host name address where MDNs are sent. If this field is left blank, the on-ramp gateway inserts the postmaster address in this field as a default. | ||
| Router(config)# dial-peer voice number mmoip | Defines the MMoIP dial peer tag number and enters the dial-peer configuration mode. | ||
| Router(config-dial-)# mdn | Requests that an MDN be sent to the destination(s) defined by the mta send return-receipt-to command. |
| Command | Purpose |
|---|---|
Router# mta receive generate-mdn | Specifies that the Cisco AS5300 acting as the off-ramp gateway will respond to a request for an MDN. |
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. 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.
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,DELAY
Three different states can be reported back to the sender:
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.
| Step | Command | Purpose | ||
|---|---|---|---|---|
| Router(config)# mta send mail-from {hostname string} | Specifies the originator (hostname portion) of the e-mail fax message. This information appears in the RFC 822 "From:" field and the RFC 821 "MAIL FROM" field of the e-mail fax message. This information is also used for generating DSNs. When you configure the mta send mail-from hostname command, the host name configured is used with the mta send mail-from username command to form a complete e-mail address, like "faxuser@onramp-gateway.com." | ||
| Router(config)# mta send mail-from {username string|username $s$} | Specifies the originator (username portion) of the e-mail fax message. This information appears in the RFC 822 "From:" field and the RFC 821 "MAIL FROM" field of the e-mail fax message. If the wild card $s$ is used, a transmission report is sent to the originating fax machine. This information is also used for generating DSNs. When you configure the mta send mail-from username command, the user name configured is used with the mta send mail-from hostname command to form a complete e-mail address, like "faxuser@onramp-gateway.com." | ||
| Router(config)# dial-peer voice number mmoip | Defines the MMoIP dial peer tag number and enter the dial-peer configuration mode. | ||
| Router(config-dial-)# dsn {delay | success | failure} | Requests that an DSN be sent to the destination(s) defined by the mta send mail-from command. |
This section provides the following Store and Forward fax configuration examples:
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 alabama mta 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 peer incoming 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 peer session-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 smtp
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 fine
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 1646 radius-server key password ! Configure the RADIUS server to recognize and use vendor-specific attributes. radius-server vsa send accounting radius-server vsa send authentication
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 terminal modem-pool mica-inbound pool-range 25-84
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 configuration Building 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.0 service timestamps debug uptime service timestamps log uptime no service password-encryption service internal service udp-small-servers service tcp-small-servers ! hostname mmoip-b ! boot system tftp /auto/annex2/njoffe/c5300-is-mz 255.255.255.255 boot system flash c5300-is-mz aaa new-model aaa authentication login fax radius local aaa accounting connection fax stop-only radius ! username njoffe password 0 password username jfitzhug password 0 password username wooksong password 0 password username gmercuri password 0 password username faryaman password 0 password username ilyau password 0 password clock timezone PST -8 clock calendar-valid ! modem-pool mica-inbound modem poll time 2 ip subnet-zero ip host mail-server 10.14.116.1 ip host keyer 223.255.254.254 ip host mail-server.cisco.com 10.14.116.1 ip domain-name cisco.com ip name-server 10.14.116.1 ! isdn switch-type primary-5ess fax 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 enable fax send coverpage email-controllable fax send coverpage comment Cisco cover page comment mta send server mail-server.cisco.com mta send subject mmoip-b subject line here mta send origin-prefix Cisco Powered Fax System mta send postmaster gmercuri@mail-server.com mta send mail-from hostname mail-from-hostname.com mta send mail-from username $s$ mta send return-receipt-to hostname mmoip-b.cisco.com mta send return-receipt-to username $s$ mta receive aliases mmoip-b.cisco.com mta receive aliases [1.2.3.4] mta receive aliases cisco.com mta receive maximum-recipients 24 mta receive generate-mdn mmoip aaa send-id primary gateway mmoip aaa receive-id primary gateway mmoip aaa method fax authentication fax mmoip aaa method fax accounting fax mmoip aaa send-accounting enable mmoip aaa send-authentication enable mmoip aaa receive-accounting enable mmoip aaa receive-authentication enable ! ! controller T1 0 framing esf clock source line primary linecode b8zs cablelength short 133 pri-group timeslots 1-24 ! controller T1 1 shutdown framing esf clock source line secondary 1 linecode b8zs cablelength short 133 cas-group 0 timeslots 1-24 type e&m-fgb service fax ! controller T1 2 shutdown framing esf linecode b8zs cablelength short 133 cas-group 0 timeslots 1-24 type e&m-fgb ! controller T1 3 shutdown framing esf linecode b8zs cablelength short 133 pri-group timeslots 1-24 ! ! voice-port 0:D timeouts call-disconnect 0 ! voice-port 1:0 timeouts call-disconnect 0 ! voice-port 2:0 timeouts call-disconnect 0 ! voice-port 3:D timeouts call-disconnect 0 ! dial-peer voice 5 mmoip destination-pattern 55508.. information-type fax mdn dsn success dsn failure session target mailto:$d$@mail-server.cisco.com ! dial-peer voice 1001 pots incoming called-number 571.... port 0:D ! dial-peer voice 2 pots incoming called-number 5550839 information-type fax direct-inward-dial ! dial-peer voice 1 pots destination-pattern 5...... information-type fax prefix 5 ! num-exp 01133...... 33....... ! interface Loopback0 no ip address no ip directed-broadcast ! interface Tunnel1 no ip address no ip directed-broadcast ! interface Ethernet0 ip address 10.14.120.2 255.255.0.0 no ip directed-broadcast ! interface Serial0:23 no ip address no ip directed-broadcast encapsulation ppp no ip route-cache dialer rotary-group 1 dialer-group 1 isdn switch-type primary-5ess isdn tei-negotiation first-call isdn incoming-voice modem no fair-queue ! interface Serial3:23 no ip address no ip directed-broadcast shutdown isdn switch-type primary-5ess isdn tei-negotiation first-call no cdp enable ! interface FastEthernet0 no ip address no ip directed-broadcast shutdown ! interface Group-Async1 ip unnumbered Ethernet0 no ip directed-broadcast encapsulation ppp ip tcp header-compression dialer in-band dialer-group 1 async mode interactive peer default ip address pool default no fair-queue ppp multilink group-range 1 12 hold-queue 10 in ! interface Dialer1 ip unnumbered Loopback0 no ip directed-broadcast encapsulation ppp dialer in-band dialer-group 1 peer default ip address pool def no fair-queue ppp multilink ! ip default-gateway 10.14.0.1 no ip http server ip classless ip route 223.255.254.0 255.255.255.0 10.14.0.1 ! dialer-list 1 protocol ip permit snmp-server engineID local 00000009020000E01EA48784 snmp-server community public RW radius-server host 10.14.116.1 auth-port 1645 acct-port 1646 radius-server key password radius-server vsa send accounting radius-server vsa send authentication ! line con 0 exec-timeout 0 0 logging synchronous transport input none line 1 12 autobaud autoselect ppp modem InOut modem autoconfigure type microcom_hdms rotary 1 transport input all line aux 0 line vty 0 4 exec-timeout 0 0 password password ! exception core-file /auto/annex2/gmercuri/coredump exception dump 223.255.254.254 ntp source Ethernet0 ntp update-calendar ntp peer 223.255.254.254 scheduler heapcheck process scheduler interval 1000 end
Posted: Tue Jul 18 14:55:35 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.