Dial Peer Configuration for Onramp

Just like a passthrough or relay call through a Cisco IOS gateway, T.37 onramp must also match an inbound and outbound dial-peer. In the case of T.37 onramp, the inbound dial-peer will always be a POTS peer, and the outbound dial-peer will be an MMoIP peer.

From a configuration perspective, the inbound onramp POTS dial-peer is configured the same as any other inbound POTS dial-peer for a VoIP call with the addition of the service command. Table 11-4 covers this command and its function.

Table 11-4 service IOS Configuration Command for the POTS Dial-Peer



service service-name

Identifies the T.37 onramp application that is to be called when a call matches this incoming POTS dial-peer.

service-name is the name of the application that was defined in application configuration mode as the onramp store-and-forward fax application. For more detail about the script that this command is referencing, see "Loading the TCL Scripts."

Note: This command was introduced in Cisco IOS Software Release 12.3(14)T. Before this version, the command was application application-name.

Because the service command defined in Table 11-4 references the TCL script specified by the service command under the application configuration mode, the user-defined service name for each must match. For example, if the command service app_onramp flash:app_ faxmail_onramp. is configured under the Application menu, service app_ onramp must be configured under the onramp POTS dial-peer. The service name of app_onramp is the keyword that links the two service commands together.

The inclusion of the service command in Table 11-4 under the POTS dial-peer allows the gateway to properly process the incoming call as a T.37 onramp call. Therefore, it is critical that you make sure that incoming T.37 calls match this dial-peer. One common practice is to use the command incoming called-number number under the POTS dial-peer, where number represents the called party number or Dialed Number Identification Service (DNIS) as seen by the IOS gateway.

The T.37 onramp feature is designed for use with the command direct-inward-dial for correctly processing T.37 onramp calls on digital interfaces, such as T1 and E1. This command is commonly used on regular VoIP calls, too, and it instructs the gateway to make a routing decision based on incoming DNIS. The direct-inward-dial command does away with the need for the voice gateway to play dial tone and for the user to go through two-stage dialing. For an example of an onramp POTS dial-peer configuration using this command, see the section "Sample Onramp Configuration" in this chapter.

In addition to the inbound POTS dial-peer, T.37 onramp requires an outbound MMoIP dial-peer. This MMoIP dial-peer is responsible for routing the fax call to the mail server. Under the MMoIP dial-peer for onramp, there are a number of configuration commands, which are grouped and discussed in separate tables.

Table 11-5 defines the general configuration commands required for all onramp MMoIP dial-peers. If any of these configuration commands are not present for an onramp MMoIP dial-peer, onramp fax calls will fail.

Just like the onramp POTS dial-peer, the onramp MMoIP dial-peer needs an onramp specific script. However, this particular onramp script, fax_on_vfc_onramp_app, is bundled with IOS and does not need to be downloaded separately.

The presence of the fax_on_vfc_onramp_app script can be confirmed with the command show call application voice summary. If it is not shown in the list of applications in the output of show call application voice summary, it is likely that the command fax interface-type fax-mail has not been configured. Another possibility is that the fax interface-type fax-mail command has been configured but the gateway has not been reloaded after the command was added.

One command that is not T.37 specific but is just as critical as those highlighted in Table 11-5 is destination-pattern. This command is necessary for any outbound VoIP dial-peer, and it defines the digits that must be matched for this MMoIP dial-peer to handle the call.

Table 11-5 Required MMoIP Dial-peer Configuration Commands for Onramp Fax



service fax_on_vfc_onramp_app out-bound

Identifies the T.37 onramp application that is to be called when a call matches this MMoIP dial-peer. The out-bound keyword simply instructs the application that the calls it handles are outbound from the dial-peer.

Note: This command was introduced in Cisco IOS Software Release 12.3(14)T. Before this release, the command was application fax_on_ vfc_onramp_app out-bound.

information-type fax

Identifies the call information associated with this MMoIP dial-peer as being fax rather than voice.

Note: The default configuration for this command is information-type voice.

session protocol smtp

Specifies that the session protocol for calls between the onramp gateway and the remote mail server is to be SMTP.

session target mailto:{ username I $d$ I $m$ I $e$}[ @domain-name]

Designates the e-mail address to which fax mail messages will be sent by the MMoIP dial-peer.

• mailto: indicates that the argument that follows is an e-mail address.

• username is a string that contains the username portion of an e-mail address. This can be a single user or a mailing list alias made up of multiple users.

• $d$ is a wildcard that is replaced by the called party number (DNIS).

• @domain-name is a string that contains the domain name to be associated with the target address, preceded by the at sign (@). For example, @mycompany.com.

Note: The other options of $m$ and $e$ are not applicable to T.37 onramp and are for use with the fax detection application. For more information, see the section "Fax Detect Script" in Chapter 7, "Design Guide for Fax, Modem, and Text."

Onramp commands that configure fax image related parameters are also available under the MMoIP dial-peer. As defined in Table 11-6, these commands configure fax image attributes such as image encoding, image quality check, and image resolution.

Table 11-6 Optional MMoIP Dial-peer Configuration Commands for Onramp Fax



image encoding {mh 1 mr I mmr 1 passthrough}

Sets the encoding method used for the fax mail TIFF images for calls that match the MMoIP dial-peer:

• mh—Uses the Modified Huffman algorithm for image encoding.

• mr—Uses the Modified READ algorithm for image encoding.

• mmr—Uses the Modified Modified READ algorithm for image encoding.

• passthrough—Image is not modified by the gateway with any image encoding method. Therefore, the image is encoded by whatever encoding method is used by the originating fax machine.

For more detailed information on these three image-encoding schemes, see the section "Page Encoding" in Chapter 2 "How Fax Works."

Note: The default configuration setting for this command is image encoding passthrough.

image quality check

This command enables/disables image quality checking. There is an image quality error rate threshold of 15 percent for the IOS gateway's built-in TIFF writer. If this command is enabled and the error rate threshold is exceeded, the fax image is not sent to the mail server.

Note: The default behavior is for image quality check to be enabled. The default setting for this command should always be used unless problems are encountered.

image resolution {fine I standard I super-fine I passthrough}

Sets the resolution of the fax TIFF images that are forwarded by the specific MMoIP dial:

• fine—Fax TIFF image resolution setting of 204 x 196 pixels per inch.

• standard—Fax TIFF image resolution setting of 204 x 98 pixels per inch.

• super-fine—Fax TIFF image resolution setting of 204 x 391 pixels per inch.

• passthrough—Resolution of the Fax TIFF image is not to be altered by the gateway.

Note: The default configuration setting for this command is image resolution passthrough.

The commands image encoding and image resolution provide a means for the onramp gateway to control how the TIFF image is created from the incoming fax call. Even though these same image encoding and resolution parameters also exist for regular T.30 fax calls, these commands applied to an onramp gateway function only with regard to the creation of the fax mail TIFF image.

The last group of configuration commands for the onramp MMoIP dial-peer includes the e-mail message notifications of delivery status notification (DSN) and message disposition notification (MDN). The DSN and MDN configuration commands provide for status messages about the fax e-mail to be relayed back to a user. Table 11-7 details the DSN and MDN configuration commands for an onramp MMoIP dial-peer.

Table 11-7 DSN and MDN MMoIP Dial-Peer Configuration Commands for Onramp Fax



dsn {delayed 1 failure 1


This command requests in the header of the e-mail fax message that the next-hop mailer notify the sender of the e-mail status via a DSN. The following DSN types are supported:

• delayed specifies that a DSN is sent when the fax e-mail experiences a delayed condition. The determination of whether the e-mail message is delayed is made independently by each mailer along the path and cannot be controlled by the sender.

• failure requests that a DSN be sent if the fax e-mail has a delivery failure.

• success specifies that a DSN message be sent when the fax e-mail has been successfully delivered.

Note: DSN must be supported by the remote mail server to acquiesce to the notification request.

Note: The delayed, failure, and success options for the dsn command are not mutually exclusive, and each one can be enabled individually. By default, all DSN commands are disabled.


This command requests in the e-mail fax message header forwarded by the matching MMoIP dial-peer that the remote mail server send an MDN to the sender when the recipient has opened the e-mail message with the TIFF fax attachment.

Note: This command is disabled by default.

For the dsn command and each of its three options in Table 11-7, the DSN message generated by a remote mail server is sent to the e-mail address specified in the command mta send mail-from. This command is covered in detail in Table 11-9 in the section "MTA Configuration Commands For Onramp Fax."

As mentioned for the dsn command in Table 11-7, mail servers used in the transport and delivery of the fax mail message may not offer support for DSNs. This can cause DSN messages to not be sent even though they were requested with the appropriate dsn command under the MMoIP dial-peer. In the case of the command dsn failure, nonsupport of DSNs by remote mail servers might not be as big of a problem because a mail delivery failure always generates a nondeliverable or undeliverable message called a bounce.

Whereas DSN messages depend on mail servers to support the DSN extension, the MDN is handled by the receiving mail user agent. However, the mail user agent or client may not support MDNs, just like some mail servers may not support DSNs. When MDNs are sent by the mail client, the message is transmitted to the address defined in the mta send return-receipt-to command. For more information on the mta send return-receipt-to command, see the section "MTA Configuration Commands for Onramp Fax." If you need to review DSNs and MDNs, see the section "DSN and MDN" in Chapter 6, "T.37 Store-and-Forward Fax."

Was this article helpful?

0 0
Code Of Success

Code Of Success

Now You Can STOP Failing In Your Business And Become A Success Even If You’ve Tried Everything Before! I Easily Put An END To My Lack Of Success And Learned How To Develop Rules Of Conduct That Transform Organizations And Businesses And I'll Show You How YOU Can, Too! Are you sick to death of your business efforts going nowhere?

Get My Free Ebook

Post a comment