Fax over IP T.37 Store and Forward Fax

Introduction

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.

Prerequisites

Requirements

Readers of this document must be knowledgeable of:

• Basic knowledge of Fax over IP (FoIP). For more information, refer to documents with this content:

  1. Fax Services

  2. Fax Applications over IP

• The basic functions of Simple Mail Transfer Protocol (SMTP) protocol. For more information, refer to RFC 821 .

Components

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:

1. Cisco 3660 with Cisco IOS® Software version 12.2(15)T9

2. Cisco AS5300 with Cisco IOS Software version 12.2(15)T9

3. Cisco AS5350 with Cisco IOS Software version 12.2(15)T9

4. SMTP server version 5.0.2195.4453

Conventions

For more information on document conventions, refer to the Cisco Technical Tips Conventions.

T.37 Technology

Architecture

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.

OnRamp Fax Related Applications and Features

OnRamp Features on the voice feature card (VFC) and on NextPort (NP) Digital Signal Processor (DSP) Modules

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

FMSP Features for OnRamp

• 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

DMSP Features for OnRamp

• 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

OffRamp Fax Related Applications and Features

FMSP Features for OffRamp

• 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

DMSP Features for OffRamp

• 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

Text-to-Fax Converter Features for OffRamp

• 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

OffRamp Features on the VFC and on NP DSP Modules

• 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

SMTP Primer

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.

SMTP Commands

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.

SMTP Replies

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 .

Sample Session

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#

Multipurpose Internet Mail Extensions (MIME)

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

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.

Topology

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:

1. OnRamp Gateway configuration and debugs

2. OffRamp Gateway configuration and debugs

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.

SMTP Reply Codes

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.

SMTP Common Reply Codes

• 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

Related Information

• RFC 821
• RFC 1651
• RFC 1893
• RFC 2034
• RFC 2301
• RFC 2302
• RFC 2303
• RFC 2304
• RFC 2305
• RFC 2532
• RFC 2045
• RFC 2046
• RFC 2047
• RFC 2048
• RFC 2049
• Voice Technology Support
• Voice and IP Communications Product Support
• Troubleshooting Cisco IP Telephony
• Technical Support - Cisco Systems