Enabling VoIP Fax and Modem Transmission


This section describes the implementation of fax and modem traffic over a VoIP network. It explores both Cisco Systems and standard implementations of faxing, as well as various methods used to transport modem traffic over VoIP.

Cisco Fax Relay

Figure 2-43 depicts a VoIP network set up for fax relay. Initially, fax calls are digitized representations of the contents on paper. The digitized bit stream is then converted to analog for transmission over voice circuits. If Cisco equipment treated fax calls like voice calls, the analog waveform would then be converted to G.711 PCM at 64 kbps and subsequently compressed before transmission across the VoIP network. Treating fax calls like voice calls is impractical because there are too many conversions and because the coding and compression schemes are designed to convey human speech, not fax modem tones.

Figure 2-43. Fax Relay


Using Cisco fax relay, as shown in Figure 2-44, the DSP (digital signal processor) chip first sets up the call as an end-to-end voice call. The DSP then recognizes the tones as those coming from a fax machine. The local DSP assumes the role of a fax modem, converting the analog data back to the original digitized bit stream. Acting as the fax modem, the DSP is downshifted in speed to 9.6 kbps to save bandwidth over the IP path. The bit stream is then packaged in VoIP packets and identified as a fax. The remote DSP assumes a similar role and converts the bit stream to analog for reception by the remote fax machine. Cisco fax relay is a proprietary protocol supported only on Cisco voice equipment. Cisco Systems pioneered this protocol in the early 1990s before standards were developed and ratified.

Figure 2-44. Cisco Fax Relay


T.38 Fax Relay

The T.38 approach to fax relay is similar to the Cisco approach, but represents the industry standard. Because T.38 is an open standard from the ITU, it is compatible between different vendors. A Cisco voice-enabled router can be configured as a T.38 gateway, and the transmission methodology is similar to the Cisco fax relay method. However, with T.38 it is possible to deliver documents to virtual fax machines, such as PCs and servers that are configured with software that is compatible with T.38 fax.

As illustrated in Figure 2-45, a T.38 gateway is required at both ends. The T.38 method uses DSP chips to intercept the fax signal at each end and convert the signal to its original digital format, for example, 9600 bps Group 3 fax. The resulting bit stream is then packetized into the T.38 packet format and sent across the IP network.

Figure 2-45. T.38 Fax Relay


T.37 Fax Store and Forward

The T.37 standard for fax store and forward, as depicted in Figure 2-46, is a way of delivering faxed documents as e-mail attachments. T.37 works by scanning a document, converting that document to tagged image file format (TIFF), and sending it to an e-mail address as an attachment using Simple Mail Transfer Protocol (SMTP). Cisco implements T.37 fax store and forward by using special gateways that are configured as on-ramps (transmitters of faxes) or off-ramps (receivers of faxes).

Figure 2-46. T.37 Fax Store and Forward


When configured on an on-ramp gateway, fax store and forward provides a way to transform standard fax messages into e-mail messages and TIFF attachments that travel to PCs on the network. When configured on an off-ramp gateway, e-mail with TIFF attachments transform into standard fax messages. These messages travel out of the packet network to standard Group 3 fax devices on the PSTN. When configured on both the on-ramp and off-ramp gateways of a network, fax store and forward allows temporary storage in the packet network for standard fax messages that cannot be delivered immediately.

Internet users are offered free store-and-forward faxes from various ISPs. Once subscribed, it is possible to send and receive fax messages using the service. If someone wants to send you a fax, they dial your assigned fax number from any standard fax machine. The store-and-forward on-ramp gateway at the service provider converts the fax back to its digital bit stream and then converts it into a graphics file (usually JPG). The completed graphics file is then e-mailed to you as an attachment.

Fax store and forward uses two different interactive voice response (IVR) applications for on-ramp and off-ramp functionality. The applications are implemented in two Tool Command Language (TCL) scripts that you can download from Cisco.com.

SMTP facilitates the basic functionality of fax store and forward, with additional functionality that provides confirmation of delivery using existing SMTP mechanisms such as Extended Simple Mail Transfer Protocol (ESMTP). Fax store and forward requires that you configure gateway dial peers and the following types of parameters:

  • IVR application parameters and IVR security and accounting parameters Load the applications on the router and enable accounting and authorization for the application.

  • Fax parameters Specify the cover sheet and header information for faxes that are generated in the packet network.

  • Message Transfer Agent (MTA) parameters Define delivery parameters for the e-mail messages that accompany fax TIFF images.

  • Message disposition notification (MDN) parameters Specify the generation of messages to notify e-mail originators when their fax e-mail messages are delivered.

  • Delivery status notification (DSN) parameters Instruct the SMTP server to send messages to e-mail originators to inform them of the status of their e-mail messages.

  • Gateway security and accounting parameters Define authentication, authorization, and accounting (AAA) for faxes that enter or exit the packet network.

Fax Pass-Through

Fax pass-through occurs when incoming T.30 fax data is not demodulated or compressed for its transit through the packet network, as shown in Figure 2-47. The two fax machines communicate directly with each other over a transparent IP connection.

Figure 2-47. Fax Pass-Through


When a gateway detects a fax tone, it switches the call to a high-bandwidth CODEC. The fax traffic, still in PCM form, travels in band over VoIP using G.711 with no VAD. This method of transporting fax traffic takes a constant 64-kbps (payload) stream end to end for the duration of the call. It is very sensitive to packet loss, jitter, and latency in the IP network, although packet redundancy can be used to mitigate the effects of packet loss.

Fax pass-through is applicable when connecting to a third-party voice gateway that does not support T.38 fax relay. Fax pass-through treats the fax call as a simple G.711 voice call with no special handling for fax. When connecting a Cisco fax-enabled router to a third-party voice-enabled router that does not support fax, you should use fax pass-through. The originating Cisco router will treat the call as a G.711 voice call and will not compress, thus preserving the analog properties of the waveshape for the receiving fax machine.

Fax pass-through is supported under the following call control protocols:

  • H.323

  • Session initiation protocol (SIP)

  • Media Gateway Control Protocol (MGCP)

Note

Echo cancellation is enabled and preferred for pass-through using Cisco IOS Release 12.0(3) T and later. Earlier versions of Cisco IOS software required that you disable echo cancellation.


Modem Pass-Through

Modem pass-through, as illustrated in Figure 2-48, is similar to fax pass-through, except that there is a computer modem at each end of the connection. The two modems communicate directly with each other over a transparent IP connection.

Figure 2-48. Modem Pass-Through


When a gateway detects a modem tone, it switches the call to a high-bandwidth CODEC. The modem traffic, still in PCM form, travels in band over VoIP using G.711 with no VAD. This method of transporting modem traffic takes a constant 64-kbps (payload) stream end to end for the duration of the call. It is highly sensitive to packet loss, jitter, and latency in the IP network, although packet redundancy can be used to mitigate the effects of packet loss. Packet redundancy is defined in RFC 2198 and describes a way in which RTP carries the modem audio essentially twice. The redundant packets are sent in case there is packet loss. This scheme produces significant overhead, therefore, and may not be acceptable in all applications. You can enable or disable packet redundancy when configuring modem pass-through.

The following call control protocols support modem pass-through:

  • H.323

  • SIP

  • MGCP

Modem pass-through is utilized when the gateways serve as a dial-up application for terminals or alarm systems. If your company utilizes alarm systems in multiple buildings throughout a WAN application and the alarm system requires modems to dial in to a central server, you can use modem pass-through on your VoIP network. This application will eliminate the cost of separate long-distance dial telephone lines for the modems.

Modem Relay

When using modem relay, which is illustrated in Figure 2-49, computer modem signals are demodulated at one gateway, converted to digital form, and carried in Simple Packet Relay Transport (SPRT) protocol packets to the other gateway. When it reaches the other gateway, the modem signal is recreated and remodulated and then passed to the receiving computer modem. SPRT is a protocol running over User Datagram Protocol (UDP). At the end of the modem session, the voice ports revert to the previous configuration and the DSPs switch back to the original voice CODEC. This method uses less bandwidth (Real-Time Transport Protocol [RTP] is not required) and is much less sensitive to jitter and clocking mismatches than modem pass-through.

Figure 2-49. Modem Relay


The following call control protocols support modem relay:

  • H.323

  • SIP

  • MGCP




Cisco Voice over IP Cvoice (c) Authorized Self-study Guide
Cisco Voice over IP (CVoice) (Authorized Self-Study Guide) (2nd Edition)
ISBN: 1587052628
EAN: 2147483647
Year: 2006
Pages: 111
Authors: Kevin Wallace

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net