In order to fax over IP networks, three mehods are used:
In-band Faxing—Fax tones are digitally encoded by the coder-decoder (codec) in the same way as voice.
T.38—Real-time Group3 Fax over IP networks
T.37—Store and Forward (S&F) fax on the Internet
In-band faxing is not very popular because this method is inefficient. This inefficiency is a result of low-bit rate codecs and the inability to accurately encode and decode fax (and modem) tones and any other non-speech sounds. Thus, in order to in-band fax efficiently, a higher bit-rate codec must be used (G.726r32 or G.711). This takes the bandwidth savings out of the equation and makes the option to fax over data networks less attractive.
T.38 eliminates the need for high-quality codecs when you fax over IP networks. Once the call is connected and fax negotiation starts, each gateway takes part in the T.30 signaling with the local fax machines, but negotiation is end-to-end. This is because the T.30 messages are encoded into packets and relayed over the IP network. Similarly, the page data is also encoded and forwarded over the data network. For more details on T.38 Fax relay, refer to Configuring Fax Relay T.38 with VoIP.
T.37 is an enhancement over T.38 because T.37 allows S&F capabilities. S&F fax has two modes of operation:
OnRamp—Receives faxes that are delivered as email attachments
OffRamp—Sends standard email messages that are delivered as faxes
Emails are received with a Tag Image File Format (TIFF) attachments only, but emails are sent as plain text, enriched text, or with TIFF attachments. S&F faxing has value because of this method's integration with email. You are able to configure email servers to retry continuously until successful and offer never busy fax service. The use of email aliases and distribution lists allow a single fax to be sent to multiple email addresses and conversely, for a single email to be sent to multiple fax machines.
Readers of this document must be knowledgeable of:
Basic knowledge of Fax over IP (FoIP). For more information, refer to documents with this content:
The basic functions of Simple Mail Transfer Protocol (SMTP) protocol. For more information, refer to RFC 821 .
For the most current fax features and hardware support, refer to the Cisco Fax Services over IP Application Guide and the Cisco IOS software release notes for the release in use. In general, supported platforms for T.37 include:
175x
26xx, 36xx
37x5
5300, 5350, 5400, 5800, 5850
This table provides performance numbers related to some of these platforms:
Platform | Restriction |
---|---|
1750 | 128M RAM minimum; 256M if you use Interactive Voice Response (IVR) 2.0 or a max of 192 S&F fax sessions |
5300 | 60 simultaneous S&F fax sessions (inbound or outbound) or up to 120 voice sessions (voice, IVR, or fax relay) (2 x S&F fax calls) + voice calls = 120 |
5850 | 120 S&F with 800 total sessions - 192 S&F with 750 total sessions |
For the purposes of this document, these components were used:
Cisco 3660 with Cisco IOS® Software version 12.2(15)T9
Cisco AS5300 with Cisco IOS Software version 12.2(15)T9
Cisco AS5350 with Cisco IOS Software version 12.2(15)T9
SMTP server version 5.0.2195.4453
For more information on document conventions, refer to the Cisco Technical Tips Conventions.
T.37 is an application that sits on top of a Call Control Application Programming Interface (CCAPI) just as the default application Voice over IP (VoIP) or IVR does. It is called by the application setting under the dial-peer (either Multimedia Mail over IP [MMoIP] or Plain Old Telephone Service [POTS]). T.37 uses the concept of an MMoIP dial-peer (dial-peer voice 1 MMoIP) for individual email session parameters such as Disposition and Message Notifications.
The S&F fax related applications extend to specific features on VFC modules for the AS5300 and on NP DSP modules on AS5400 and AS5350 (known also as the Libretto application). These are the main features:
Accepts new OnRamp calls from the IVR or directly if no authentication is required
Provides set-up, bridge, and transaction events with the Voice Telephony Service Provider (VTSP), the Fax Media Service Provider (FMSP), and the Document Media Service Provider (DMSP)
Creates the fax_record file in order to reference specific information on a fax
Provides fax modem training and negotiation
Demodulates T.30 fax signals from the Public Switched Telephone Network (PSTN)
Converts T.30 signals into T.38 packets
Encapsulated within User Datagram Protocol (UDP) data
Extracts T.4 data, incorporates packet header
Provides transparency byte stripping (Data-Link Encapsulation [DLE] DLE)
Generates end-of-page detection (DLE followed by ETX, which is end of stream denoting the end of a voice data stream.) for faxes
Copies data into buffers and enqueues the buffers into the DMSP
Converts T.4 fax data to TIFF images that use the TIFF or text libraries
Accepts buffers from FMSP for TIFF conversion by way of a Cisco IOS queue event
Performs all class two fax protocol operations
Receives T.38 packets from VTSP and modulates these packets back to T.30 signals
Extracts T.4 data from T.30 protocol and hands data to DMSP
Adds transparency bytes (DLE DLE)
Generates end-of-page indication (DLE ETX)
Inserts fill bits (for minimum scan line time)
Transmits data in the cover or payload queue
Processes data buffers from the FMSP
Makes calls to the TIFF engine to convert the TIFF or text (header) data to T.4 fax data format (passes lines per page, resolution, and encoding)
Handles buffer management for the TIFF engine
Processes data buffers from the DMSP
Makes calls to the Text to Fax engine in order to convert text data to fax data format (passes lines per page, resolution, and encoding)
Handles buffer management for the Text to Fax engine
Set-up, bridge, and transaction events with VTSP, FMSP, and the DMSP
Generates call active or history events with the MIB
Creates fax_payload and fax_records files
The objective of SMTP is to deliver email reliably and efficiently. SMTP addresses a mail request with this basic model:
A two-way transmission channel is set up between the sender and receiver.
The sender generates SMTP commands that are sent to the receiver.
The receiver responds with SMTP replies.
These are common SMTP commands:
Note: Commands are case insensitive (for example mail=MaiL). For an entire list, refer to section 4.1 of RFC 821 .
HELO—Identifies the sender-SMTP to the receiver-SMTP. The receiver-SMTP identifies itself in the OK reply. It must be the the first message in the SMTP exchange if service extensions are unsupported.
vdtl-5300-7a#telnet 172.18.106.36 25 Trying 172.18.106.36, 25 ... Open 220 testlab-smtp.testlab-t37.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.4453 ready at Tue, 5 Mar 2002 12:08:24 -0500 mail from:<tom@testlab-t37.com> 503 5.5.2 Send hello first
EHLO—Used instead of the HELO command to start a session from a client that supports SMTP service extensions. If the server does not support service extensions, the server generates an error response.
MAIL—Initiates a mail transaction. The argument field contains the address that the email is from (such as the sender's mailbox).
RCPT—Identifies the recipient of the email. Multiple recipients are specified by multiple commands (such as the To: field).
DATA—Mail data (such as the body of the email). A period on a line by itself (character sequence <CRLF>.<CRLF>) marks the end of the data.
SEND—Initiates the delivery of the mail message.
QUIT—Closes the SMTP session. An OK reply is necessary before the channel is closed.
Every SMTP command must generate exactly one reply. SMTP replies consist of a three-digit number followed by text. The numbers indicate what state to enter next, and the text is the decoded reply and meant for the user to debug. For a complete list of SMTP reply codes, see the SMTP Reply Codes section of this document. Enhanced system status codes to be used with Delivery Status Notifications (DSN) have been added with RFC 1893 For certain replies, these enhanced codes give more detailed information about the transaction. For more information on this, refer to the "SMTP Details" section in RFC 821 .
In this example, simply Telnet to the SMTP server and issue commands. No email clients are used to send the email. Familiarity with these commands and message flow is important when you debug S&F faxing on the gateways. This knowledge helps to eliminate pieces of the puzzle.
Sender commands are preceded with S:.
Receiver replies are preceded with R:.
Reply codes are in italics.
SMTP commands are in quotes.
System status codes are in bold.
vdtl-5300-7a#telnet 172.18.106.36 25 Trying 172.18.106.36, 25 ... Open R: 220 testlab-smtp.testlab-t37.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.4453 ready at Tue, 5 Mar 2002 12:10:01 -0500 S: "helo" testlab-t37.com R: 250 testlab-smtp.testlab-t37.com Hello [15.80.7.11] S: "mail" from:<tom@testlab-t37.com> R: 250 2.1.0 tom@testlab-t37.com....Sender OK S: "rcpt" to:<john@testlab-t37.com> R: 250 2.1.5 john@testlab-t37.com S: "data" R: 354 Start mail input; end with <CRLF>.<CRLF> Subject: This is a test email sent from telnetting to the SMTP server on port 25 From: Tom Jackson
This is an email sent from Tom to John on the testlab-smtp server by Telnetting to port 25 on the server, where only SMTP commands are used from the command line:
R: 250 2.6.0 <testlab-smtpeYrQz0ek6He00000002@testlab-smtp.testlab-t37.com> Queued mail for delivery S: "quit" R: 221 2.0.0 testlab-smtp.testlab-t37.com Service closing transmission channel [Connection to 172.18.106.36 closed by foreign host] vdtl-5300-7a#
RFC 821 defines SMTP, which is a protocol independent of the particular transmission subsystem and requires only a reliable ordered data stream channel. RFC 822 defines mail, standard for the format of Advanced Research Projects Agency (ARPA) Internet text messages. Both of these documents are excellent references to better famaliarize yourself with SMTP. MIME removes many restrictions that RFC 822 places on the body of emails. MIME allows these options:
Character sets other than US-ASCII
Enriched text
Images
Audio
Other messages (reliably encapsulated)
Tar files
PostScript
Pointers to FTP-able files
Cisco S&F fax can process emails with these content types:
Plain text
Enriched text
Image attachment (TIFF profile F [TIFF-F])
There are many ways to encode an email's body or attachment. Cisco S&F faxing can handle emails that are encoded with these options:
7 bit
8 bit
Base 64
Quotable-printable
TIFF was developed by Adobe to describe image data that typically comes from scanners, frame grabbers, and paint or photo-retouching programs. TIFF is a very feature-rich format, with these capabilities:
Describes bi-level, grayscale, palette-color, and full-color image data
Allows for several compression schemes
Allows for the inclusion of private or special-purpose information
There are many different options and ways to use TIFF in order to encode data. Cisco T.37 gateways take a TIFF attachment and convert that attachment to a fax for OffRamp applications. However, the TIFF format must conform to profile F, which is the extended black-and-white fax mode. TIFF-F is described in RFC 2301 . TIFF-F supports Modified Huffman (MH) , Modified Read (MR), and Modified Modified Read (MMR) encodings.
In this document, this network diagram is used as the topology of the network.
Note: The vdtl-5300-7a gateway acts as the OnRamp gateway, and vdtl-5350-8a acts as the OffRamp gateway.
For each gateway's configuration and debugs, refer to these links:
This section provides quick tips on how to use this Exchange email server. There are several options when you access the email server:
HTTP—Email accounts can be accessed with any web browser.
IMAP4 & POP3—Set up any email client to connect to testlab-smtp.cisco.com.
Everyone who wants to access the server needs an account, so the network administrator must create these accounts for the users. The default usernames and passwords for the SMTP server in this document, testlab-smtp, are each an individual's username (both username and password are the same). The domain is testlab-t37.com.
Email can be sent anywhere from this email account. Therefore, it is possible for any OnRamp recreates to have any valid address in the MMOIP dial peer:
! dial-peer voice 1 mmoip session target mail to:username@cisco.com !
OffRamp emails must be sent from this account due to the lab router's 15.x.x.x address. You can send emails from this account directly to a router with a To: field, such as in this example:
To: FAX=9-555-8354@15.80.7.107
Or the IP address can be replaced by the router's hostname:
To: FAX=9-555-8354@vdtl-5350-8a.testlab-t37.com
However, this second method requires a Domain Name System (DNS) entry in testlab-smtp.
For certain SMTP replies, more detailed information is available about the transaction if you better understand the format used for these reply codes. The three digits of the SMTP reply code have a special significance. The first digit denotes whether the response is good, bad, or incomplete:
1xx—Positive Preliminary reply
2xx—Positive Completion reply
3xx— Positive Intermediate reply
4xx—Transient Negative Completion reply
5xx— Permanent Negative Completion reply
The second digit encodes responses in different categories:
x0x—Syntax
x1x—Information
x2x—Connections
x3x—Unspecified as yet
x4x—Unspecified as yet
x5x—Mail system
The third digit gives more detail on the category specified by the second digit. Here is a complete list of the SMTP reply codes:
Note: The source of material for the reply codes here is the RFC documents, mentioned in the Reference section of this document.
211—System status, or system help reply
214— Help message (Information on how to use the receiver or the significance of a particular non-standard command; this reply is useful only to the human user.)
220 <domain>—Service ready
221 <domain>—Service closing transmission channel
250—Requested mail action okay, completed
251—User is not local; forwards to <forward-path>
354—Start mail input; end with <CRLF>.<CRLF>
421 <domain>—Service not available, closing transmission channel (This is possibly a reply to any command if the service must shut down.)
450—Requested mail action not taken, mailbox unavailable (for example, mailbox busy)
451—Requested action aborted, local error in the process
452—Requested action not taken, insufficient system storage
500—Syntax error, command unrecognized (This possibly includes errors such as command line too long.)
501—Syntax error in parameters or arguments
502—Command not implemented
503—Bad sequence of commands
504—Command parameter not implemented
550—Requested action not taken, mailbox unavailable (such as mailbox not found or no access)
551—User not local; try <forward-path>
552—Requested mail action aborted, exceeded storage allocation
553—Requested action not taken, mailbox name not allowed (such as mailbox syntax incorrect)
554—Transaction failed
Revision | Publish Date | Comments |
---|---|---|
1.0 |
02-Feb-2006 |
Initial Release |