Guest

Cisco BTS 10200 Softswitch

T38 FAX Relay Feature Module

  • Viewing Options

  • PDF (489.0 KB)
  • Feedback
Cisco BTS 10200 Softswitch T.38 Fax Relay

Table Of Contents

Cisco BTS 10200 Softswitch T.38 Fax Relay

Introduction

Fax Basics

Fax Relay Basics

Fax Modes

T.38 Benefits

Capability Negotiation

MGCP Gateway Capabilities

H.323 Network Capabilities

H.323 Adapter Enhancements

External Interfaces

Billing Interface

Alarms/Events

Measurements

Provisioning

Call Flow

Related Features

Related Documents

Supported Platforms

Determining Platform Support Through Cisco Feature Navigator

Availability of Cisco IOS Software Images for Media Gateways

Supported Standards

Prerequisites

Configuration Tasks

Command Reference

New Commands

Modified Commands

H.323 Gateway

H.323 Trunk Group Profile

Media Gateway Profile

Troubleshooting Fax Relay

Fax Analyzers

Opening a TAC Case

Glossary

Copyright Notice


Cisco BTS 10200 Softswitch T.38 Fax Relay


Feature History

Release
Modification

900.03.02.00

This feature was initially introduced on the Cisco BTS 10200 Softswitch in Release 3.2.


This Feature Module describes the support provided by the Cisco BTS 10200 Softswitch software in Release 3.2 and 3.3 for ITU-T recommendation T.38 Fax Relay, T.38 Fax Relay is used for transporting real-time Group 3 Fax documents over the Internet Protocol (IP), commonly used in packet networks.

This feature module includes the following sections:

Introduction

Fax Basics

Fax Relay Basics

Fax Modes

T.38 Benefits

External Interfaces

Billing Interface

Alarms/Events

Measurements

Provisioning

Related Features

Supported Platforms

Supported Standards

Prerequisites

Configuration Tasks

Command Reference

Troubleshooting Fax Relay

Glossary

Copyright Notice

Introduction

Group 3 fax devices were originally designed for use in the PSTN; however, the PSTN itself was designed for human speech (35 Hz to 3,500 Hz), so Group 3 fax devices use analog encoding or modulated signals. Fax machines are digital devices that use a modulated analog signal (audio tones) to pass digital information through the PSTN.

Gateways in packet networks initially treat voice and fax calls the same. Both types of calls cause the gateway to load a pre-configured voice compression codec in the digital signal processor (DSP). Voice compression codecs are usually high compression codecs, such as G729 and G723, so less bandwidth is used for voice calls. High compression codecs are optimized for voice and do a good job of conserving bandwidth while maintaining voice quality. However, G.729 and other high compression codecs are not optimized for fax transmissions. In fact, modulated fax signals usually do not pass correctly when high compression codecs are used, and fax calls fail as a result.

Faxes can be transmitted successfully when codecs with lower compression ratios or no compression are used, such as G.726 and G.711 with no echo cancellation or voice activity detection. This method of sending faxes through voice codecs is referred to as inband faxing or fax passthrough. The initial analog modulated signal is encoded and compressed by the codec on the originating gateway and passed across the packet network as if it were a voice sample. The terminating gateway uncompresses and decodes the sample and plays it out to the terminating fax machine.

Another technique, known as upspeeding, allows the originating gateway to initially load the configured voice compression codec into the DSP for voice calls, and changes to a low compression codec if fax tones are detected.

Fax Basics

Fax calls can be divided into two parts: fax negotiation and page transmission:

Half-duplex fax negotiation occurs at the beginning of a fax call. V.21 modulated high-level data link control (HDLC) data frames are passed at a speed of 300 bps. These data frames are sent in a standard sequence between the originating and terminating fax devices. During this exchange, the two fax devices exchange capabilities and both agree on the fax session characteristics before page transmission takes place.

Some capabilities that are exchanged and negotiated are page transmission speed (called "training"), error correction mode (ECM), resolution, page coding, and scan time. Page transmission speed is the speed at which the fax is going to send its information. Fax devices always try to "train" at the highest transmission speed possible based on the parameters initially exchanged. The fax devices retrain to a lower speed if training fails at a higher speed.

Page transmission occurs after the training part of the fax negotiation phase is complete using the previously agreed upon parameters. The page information is coded into scan lines with a standard resolution of 203 horizontal (H) dots per inch by 98 vertical (V) dots per inch. Fax images are typically compressed and encoded using Modified Huffman (MH) encoding or Modified Read (MR) encoding. MH encoding usually compresses fax transmission at a 20:1 ratio. MR encoding typically provides a 20 percent compression improvement over MH, but is slightly less resistant to error.

When page transmission occurs, a bit rate is used that is substantially higher than the initial 300 bps used in the call setup negotiation. The bit rate used for the page transmission is confirmed during training. Following are some of the common rates used in fax page transmission:

V.27ter - 2400/4800 bps

V.29 - 7200/9600 bps

V.17 - 14400 bps


Note The specifications used for page transmission (V.27ter, V.29, V.17) and fax negotiation (V.21) define how digital data is sent over analog telephone lines in the PSTN. Data modems are also able to use these specifications even though most data modems have migrated to much faster speeds.


Fax Relay Basics

Fax relay is an important toll-bypass capability that can produce significant cost savings to end users of packet telephony networks. As more services transition from the PSTN to packet networks, standards are emerging to ensure interoperability between different vendors' equipment. Support of ITU-T.38 Fax Relay in the Cisco BTS 10200 Softswitch is a move toward true voice-data convergence where the end user can use the same lines for voice and data (fax) in heterogeneous (multi-protocol) networks.

The ITU-T.38 Fax Relay recommendation specifies the messages and data exchanged for facsimile transmission in real-time between two Group 3 fax terminals communicating over Internet Protocol (IP) networks based on the H.323 protocol. The fax transmission method prescribed in the ITU T.38 recommendation can best be described as a demodulation/remodulation procedure (demod/remod).

Fax relay is a technique used to overcome the deficiency in high compression voice codecs, such as G729 or G723, when these codecs try to pass fax traffic. Since a fax call is treated as a regular speech call, the DSP in each gateway is put into voice mode after which human speech is expected to be received and processed. If a fax answer tone (CED) or calling tone (CNG) is heard during the call, the DSP does not interfere with speech processing. It simply allows the tone to continue across the packet network call leg as if it were a voice transmission.

A fax machine, after generating a CED or hearing a CNG, transmits a T.30 Digital Information Signal (DIS) as part of fax handshaking. DIS is the initial message stating the capabilities of the terminating fax machine. The terminating gateway's DSP detects the HDLC flag sequence at the start of the DIS message and initiates a fax relay switchover. It unloads the high compression voice codec and loads a lower compression fax codec to run the fax call.

Notification is also sent to the DSP on the other side of the packet network so that both DSPs on the fax call are using the same fax codec. Notification mechanisms differ depending on the fax relay protocol used. With the lower compression fax codecs loaded, the DSPs demodulate the T.30 HDLC frames, extract the fax information, and pass it between the gateways using the standard T.38 fax relay protocol.

It is important to note that unlike inband faxing or fax passthrough, fax relay breaks down (demodulates) the T.30 fax tones into specific HDLC frames, transmits the information across the packet network using the T.38 fax relay protocol, then converts (re-modulates) the bits back into tones at the far side. The fax machines on either end simply send and receive tones; neither terminal is aware that the fax relay process is occurring or that part of the transmission is over the PSTN and part is over a packet network.

The information that follows can be difficult to understand if you aren't familiar with the messaging that occurs during a typical fax transmission.

Fax Modes

Existing H.323-based VoIP networks cannot interoperate with MGCP-controlled media gateways. Starting in this release, the Cisco BTS 10200 Softswitch software provides a gateway interface that supports the H.323 protocol. This allows MGCP-controlled gateways to interwork with H.323 VoIP ports.

In the Call Agent (CA)-controlled mode the Cisco BTS 10200 Softswitch can mediate fax control signaling using T.38 fax relay attributes between two dissimilar gateways; one an MGCP-controlled gateway, the other an H.323-controlled gateway. The CA drives T.38 media changes through MGCP command interaction with the gateways involved in the call. This requires that the CA be upgraded with the functionality provided in this release to support the T.38 media change protocol inherent in the T.38 fax relay feature.

For the CA-controlled mode of operation, the following approach applies:

The call is initially established as a voice call.

When a V.21 preamble is detected at the terminating fax machine the CA receives an MGCP NTFY message:

if both gateways support T.38, the CA initiates an H.323 Mode Request procedure to switch both of the media gateways to T.38 fax relay mode for the connection.

To minimize additional delay in switching to T.38, the existing voice port is reused instead of establishing a new connection through the network. The process of switching from voice to T.38 fax relay includes shutting down RTCP and using the RTP port for the UDP transport of T.38.

if both gateways do not support T.38, or an attempt to switch modes fails, the connection is lost and the call is cleared.

On completion of the fax image transfer, the connection remains established until one of the two endpoints goes on-hook, then the call is cleared.

The following assumptions are made for the CA-controlled mode of operation:

When a V.21 preamble is detected, the T.30 protocol is persistent enough to handle the delays added by the MGCP messaging necessary to accomplish the fax switchover.

Detection of V.25 ANS or V.8 ANSam indicates the presence of a non-voice call.

A modem call is assumed and an attempt is made to enable modem passthrough. If a V.21 preamble is then detected on the terminating fax, an attempt is made to enable T.38 processing, provided both endpoints involved support T.38 fax relay.

Because the T.38 Fax Relay protocol is standards based, Cisco media gateways and gatekeepers can also interoperate with third-party T.38-enabled gateways and gatekeepers in mixed vendor networks where real time fax relay capabilities are required.

H.323 is just one of several native signaling protocols supported by the Cisco BTS 10200 Softswitch. The H.323 interface allows the Cisco BTS 10200 Softswitch to function as a switching platform for heterogeneous networks. The Cisco BTS 10200 Softswitch can be used without restricting the network to any single protocol, such as MGCP, SIP, or H.323.

T.38 Benefits

The Call Agent-controlled mode for T.38 fax relay provided in Release 3.3 also offers several benefits:

Support of sending Empty Capability Set (ECS)—Cisco BTS 10200 Softswitch deployment in heterogeneous networks mandates that various CA features, like Call Forwarding No Answer (CFNA), work seamlessly in H.323 networks. Most of these features require that H3A modify the connection parameters on the remote H.323 gateway after the logical channels are established. For modifying the connection parameters, H3A implements a mechanism called "sending Empty Capability Set (ECS)." In prior releases of the Cisco BTS 10200 Softswitch software, H3A supported this capability only for IVR applications.


Note Any gateway that requires closure of both logical channels after sending ECS is not supported by the Cisco BTS 10200 Softswitch.


Clearing the call once the T.38 fax relay is completed—after the fax image transfer, the connection remains established until one of the endpoints goes onhook, then the call is cleared.

Clearing the call if an H245 request mode rejection is received—if an H245 request mode rejection is received from the remote media gateway, the call is cleared.

Seamless integration of various features—connection parameters on the remote H.323 gateway can be modified after the connection is established by sending empty capability set (ECS).

The CA-controlled mode for T.38 fax relay provided by this feature also imposes several restrictions:

Only partial support of MGCP fax package (fax start, fax stop, fax failure events only).

No voice fall back is supported—

when the fax call completes the call is cleared.

if the T.38 fax invocation fails, the call is cleared.

CA-controlled mode feature cannot function for H.323-to-H.323 calls transiting the CA.

Capability Negotiation

For the CA-controlled media change, capabilities supported by the gateway are advertised in the SDP exchange during connection establishment. This provides knowledge early and prevents unnecessary messaging to switch to a media or voice format that is not supported by both gateways.

During the initial bearer path setup, the Cisco BTS 10200 Softswitch negotiates the T.38 Fax Relay capabilities of both the originating and terminatinggateways (endpoints).

If there are no common T.38 Fax Relay capabilities, the inband method is chosen.

If both sides have more than one capability in common, the common preferred T.38 mode is used.

If there is a common preferred mode, which is also present among the common capabilities, that mode is chosen.

If no common preferred T.38 mode is available, then one of the common T.38 mode capabilities is chosen.

Since the H.323 stack in the version 3.2 software does not support T.38 capability exchange during Fast-start information exchanges, the Cisco BTS 10200 Softswitch initiates a Terminal Capability Set (TCS) procedure to exchange T.38 Fax Relay capabilities along with DTMF capabilities.

MGCP Gateway Capabilities

The Cisco BTS 10200 Softswitch provides default provisioning parameters in the MGW-PROFILE table for MGCP-controlled media gateways. The MGWs are also provisioned with static capabilities showing the types of T.38 Fax Relay supported by the MGW.

The negotiated fax mode is provided in an extension to the LocalConnectionOption (LCO) parameter of the CRCX message that the CA sends to MGCP-controlled gateways, which allows the CA to give the gateway up front instructions on how to handle fax for any given connection. This reduces the number of messages required between the CA and the gateway, which reduces the time to switch to the T.38 media format.

The syntax of the fx: option is a preferenced list. The possible values for the fx: option are:

t38—The gateway is to use CA-controlled T.38 media change for fax relay on the connection. The gateway should use this option if both gateways involved in the connection support T.38. This is the only mode supported if the gateway needs to interoperate with H.323-based gateways.

pt—Use the existing MGCP fax passthrough functionality to process the fax transmission. Fax passthrough is used if T.38 is not supported by both of the involved gateways, but fax passthrough is. The manner in which fax passthrough functions for MGCP is not altered by this feature.

off—This option means that no special handling for fax is performed at the MGW. This involves no upspeeding, no alteration of silence suppression or echo cancellation settings for the connection. The fax payload is transported using an inband bearer path.

If the CA does not provide an fx: LCO for the connection, the gateway provisioning makes the decision on the fax transmission method to use, the default being the CA-controlled mode. This setting for fx: remains in place for the duration of the connection unless explicitly altered by another fx: setting transmitted to the gateway.

H.323 Network Capabilities

In the absence of dynamic capability exchange, capabilities are provided by current H.323 networks during the call setup time. Due to protocol complexities, the Cisco BTS 10200 Softswitch currently has static provisioning per logical H.323 network cloud. They are provisioned in the H.323-TG-PROFILE table that can be associated with certain H.323-GW (or H.323-endpoint) entries.

Should the Cisco BTS 10200 Softswitch have to provide an interface to H.323 networks that have H.323 gateways (or endpoints) with different capabilities, multiple H.323-TG-PROFILEs can be provisioned and all of them can use the same H.323-GW entry.

The only capability of H.323-TG-PROFILE that is currently supported is the T.38 CA-controlled mode. The H.323-TG-PROFILE can also be provisioned with a preferred mode, the default value being the CA-controlled mode.

H.323 Adapter Enhancements

The enhancements made to implement T.38 Fax Relay and the "modify connection" feature in the H.323 adapter (H3A) in Release 3.3 include the following:

Implementation of H.245 request mode procedures (refer to the call flowdiagram, Figure 1).

Handling of the ModifyCx command from the basic call module (BCM) when the channels are already established required implementation of the H.245 sending Empty Capability Set (ECS) messages.

State machine changes required in H3A for H.245 OLC/CAPs for T.38 fax relay and sending ECS messages.

Implementation of the pass through media case for H.323 to H.323 calls, where any H.245 message results in "media/connection pass through" messages on the other H.323 side.

Addition of new fields in existing data structures, specifically the new parameters added to the H323_TRUNK_GRP_PROFILE table.

External Interfaces

This section contains information about the external operational, management, and administrative interfaces for the T.38 Fax Relay feature, which include the following:

Billing Interface

Alarms/Events

Measurements

Provisioning

Billing Interface

Three new fields have been added to the Call Data Blocks (CDBs) to support the T.38 fax relay feature:

Fax Indicator—The value of this indicator is dependent on whether or not the call involved any fax transmissions. This indicator can have one of the following values:

Not Fax = 1

Fax Only = 2

Voice & Fax = 3

Not Fax (1) indicates that no fax transmissions occurred, the other two values (2 or 3) indicate that faxes were sent or received. If faxes were sent, the number of pages is indicated by the next field. If faxes were received, the number of pages is indicated by the third field.

Fax Pages Sent—The number of fax pages that were sent during this call (0 through 999).

Fax Pages Received—The number of fax pages that were received during this call (0 through 999).

Alarms/Events

Table 1 details the alarms and events that can be generated by the T.38 Fax Relay feature.

For detailed information about Cisco BTS 10200 Softswitch alarms and events refer to the Cisco BTS 10200 Softswitch Event Messages Reference.

Table 1 T.38 Fax Relay Alarms and Events 

Alarm or Event

FAX_T38_START

FAX_T38_STOP

FAX_FAILURE


Measurements

Table 2 lists the T.38 specific traffic counter values reported by the Cisco BTS 10200 Softswitch.

For detailed information about Cisco BTS 10200 Softswitch measurements refer to the Cisco BTS 10200 Softswitch Operations Guide.

Table 2 T.38 Fax Relay Traffic Counters 

Measurement Name
Measurement Description

FAX_PAGES_SENT

Number of fax pages sent.

FAX_PAGES_RECV

Number of fax pages received.


Provisioning

This section describes provisioning changes that resulted from the addition of the T.38 Fax Relay feature to the Cisco BTS 10200 Softswitch software. For more information on provisioning commands, refer to the "Command Reference" section.

H323_GW—This table defines the capabilities of each H.323 protocol gateway. The parameters added for T.38 fax relay include:

FAX-RELAY-CAP—the T38 fax relay option for this gateway. The value is one of the following:

T38_CA_FAX—CA-controlled fax mode. This is the default value.

INBAND—Inband fax mode.

H323_TRUNK_GRP_PROFILE—This table is responsible for providing information that is used on a per-call basis for any H.323 trunk group. The parameters added for T.38 fax relay include:

FAX_T38_CAMODE_SUPP—if set to "Y." CA-controlled mode is supported for T38 fax relay

FAX_INBAND_SUPP—if set to "Y," the inband mode is supported for T38 fax relay

FAX_PREF_MODE—this is the preferred mode for T38 fax relay. The value is one of the following:

FAX_T38_CAMODE—CA-controlled mode is the preferred mode (This is the default value.)

FAX_INBAND—Inband mode is the preferred mode

MGW_PROFILE—This table provides templates for defining a Media Gateway by hardware vendor. It identifies the specifications and settings necessary for communications between the Call Agent and each type of Media Gateway. The parameters added for T.38 fax relay include:

FAX_T38_CAMODE_SUPP—if set to "Y" (the default value), the CA-controlled mode is supported for T38 fax relay

FAX_INBAND_SUPP—if set to "Y" (the default value), the inband mode is supported for T38 fax relay

FAX_PREF_MODE—this is the preferred mode for T38 fax relay. The value is one of the following:

FAX_T38_CAMODE—CA-controlled mode is the preferred mode (This is the default value.)

FAX_INBAND—Inband mode is the preferred mode

Call Flow

The following call flow diagram (Figure 1) illustrates the interactions between the Cisco BTS 10200 Softswitch software modules for the CA-controlled T.38 Fax Relay implementation.

Figure 1 CA-Controlled T.38 Fax Relay

The following steps describe in detail the T.38 Fax Relay functionality:


Step 1 The BCM checks the gateway profiles for their T.38 fax relay capabilites. It selects a common/preferred capability supported by both the gateways.

Prior to establishing a connection, the BCM encodes the T.38 fax Local Connection Option (LCO) in the SAI_CreateCxData_t . The t38fax LCO information is transmitted by the MGA in the CRCX.

Step 2 The BCM performs a check to ensure that the gateways are, in fact, MGA and H3A. The BCM initiates an RQNT to the gateway by sending SAI_CCM_OOBINFO_REQ.

Based on these additional attributes in the RQNT, the MGA determines whether it can allow T.38 fax calls. In order to detect whether T.38 fax calls are supported on the H3A, the BCM checks the trunk group profile. In addition, the BCM checks the MGA static profile to ensure T.38fax is supported.

Step 3 The gateway detects fax transmission. It notifies the originating Signaling Adapter of the reception of fax information. The Signaling Adapter in turn informs the BCM about the fax-start event in the SAI_CCM_SVCFEATURE_IND primitive.

Step 4 The BCM upon reception of the SAI_CCM_SVCFEATURE_IND primitive looks for the SAI_EI_FAX_START event. Then BCM checks to make sure that the passive_leg is in the LEG_JOINED state; the remote BCSM state machine is in the active state. It then relays the T.38fax information to the remote Signaling Adapter in the SAI_CCM_SVCFEATURE_REQ primitive. In the case, where the passive_leg is not in the LEG_JOINED state, a FAX_FAILURE event is sent in the SAI_CCM_SVCFEATURE_REQ towards the gateway.


Note Since T.38 fax is handled only in the ACTIVE state, the passive legs are in the LEG_JOINED state and a valid bcsm_id exists for the remote end.


Step 5 The Signaling Adapter upon receipt of the T.38 fax_start information, invokes the CNM API RemoteModifyCL_ex inorder to initiate a ModifyConnection request to the other Signaling Adapter with the new SDP information. Two consecutive RemoteModifyCL_ex is sent to the peer Signaling Adapter; one of them initiates the MDCX in the inactive mode while the other initiates an MDCX with modified codec.

Step 6 The Signaling Adapter's CNM upon receipt of the RemoteModifyCL_ex from the remote CNM modifies the SDP information. The codec information is also modified.The ACK/NACK that is received from the originating gateway is then sent all the way back to the CNM of the terminating Signaling Adapter. This is accomplished by retaining a copy of the remote Signaling Adapters identification.

Step 7 The gateway detects an end of fax and transmits it to the other Signaling Adapter. The Signaling Adapter in turn transmits the fax stop information in the SAI_CCM_SVCFEATURE_IND primitive to the BCM.

Step 8 The BCM upon reception of the SAI_CCM_SVCFEATURE_IND primitive looks for the SAI_EI_FAX_STOP event. It then relays the fax information to the other Signaling Adapter in the SAI_CCM_SVCFEATURE_REQ. Following this, the call is cleared in a normal manner upon the receipt of SAI_REL_IND from the H3A.

Related Features

The T.38 Fax Relay feature is directly related to the H.323 features introduced in Release 3.1 and 3.2.


Note For more information on the H.323 features, refer to the Cisco BTS 10200 Softswitch System Description.


Related Documents

This Release 3.2 T.38 Fax Relay Feature Module should be used in conjunction with the following Cisco BTS 10200 Softswitch Release 3.1 and 3.2 documents:

Cisco BTS 10200 Softswitch Physical and Network Site Surveys and Data Sheets

Cisco BTS 10200 Softswitch Cabling Procedures

Cisco BTS 10200 Softswitch Release Notes for Release 3.2

Cisco BTS 10200 Softswitch System Description

Cisco BTS 10200 Softswitch Application Installation Procedures

Cisco BTS 10200 Softswitch Command Line Interface Reference Guide

Cisco BTS 10200 Softswitch CORBA Installation and Programmer's Guides

Cisco BTS 10200 Softswitch Operations Manual

Cisco BTS 10200 Softswitch Billing Interface Guide

Supported Platforms

The T.38 Fax Relay features provided in Release 3.3 of the Cisco BTS 10200 Softswitch are available on a wide variety of Cisco platforms, including the following:

Cisco AS5300

Cisco AS5350

Cisco AS5400

Cisco AS5800

Cisco AS5850


Note Not all features provided in Releases 3.2 and 3.3 are available on all Cisco platforms. Consult the Cisco Feature Navigator web site (http://www.cisco.com/go/fn) to determine what platforms and IOS software images can accommodate the Cisco BTS 10200 Softswitch features that you require.


Determining Platform Support Through Cisco Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Cisco Feature Navigator is a web-based tool that enables you to determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

To access Cisco Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to cco-locksmith@cisco.com. An automatic check verifies that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password is e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions at http://www.cisco.com/register.

Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:

http://www.cisco.com/go/fn

Availability of Cisco IOS Software Images for Media Gateways

Support for the features available in the Cisco BTS 10200 Softswitch Release 3.3 software is dependent on the availability of the appropriate Cisco IOS software images for the supported platforms (media gateways). IOS software images for some Cisco platforms may be deferred, delayed, or changed without notice. For updated information about platform support and availability of software images for each Cisco IOS software release, refer to the online release notes or, if supported, Cisco Feature Navigator.

Supported Standards

The T.38 Fax Relay feature is compliant with the following ITU standards:

Standards

ITU-T.4 Standardization of Group 3 facsimile terminals for document transmission

ITU-T.30 Procedures for document facsimile transmission in the general switched telephone network

ITU-T.38 Procedures for real-time Group 3 facsimile communication over IP networks

The T.38 Fax Relay feature utilizes the following Management Interface Bases (MIBs):

MIBs

SNMP MIB v2c

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

RFCs

(to be determined)

Prerequisites

The T.38 Fax Relay feature requires that the following prerequisites be completed prior to sending or receiving fax transmissions:

(to be supplied)

Configuration Tasks

The T.38 Fax Relay feature requires that the following configuration tasks be completed prior to sending or receiving fax transmissions. Each task in the list is identified as either required or optional.

Configure the H.323 Gateway

Configure the H.323 Trunk Group profile

Configure the Media Gateway profile

See the "Command Reference" section for configuration examples.

Command Reference

This section documents new or modified Cisco BTS 10200 Softswitch commands associated with the T.38 Fax Relay feature. All other commands used with this feature are documented in the Cisco BTS 10200 Softswitch Release 3.2/3.3 Command Reference Guide or in the Cisco user documentation for the gateway(s) you are using.

New Commands

There are no new commands associated with the T.38 Fax Relay feature.

Modified Commands

This section documents modified commands associated with the T.38 Fax Relay feature.

H.323 Gateway

The H.323 Gateway (h323-gw) table defines the capabilities of each H.323 protocol gateway. There can be four instances of an H.323 gateway running on the Call Agent at any one time.

Table Name: H323-GW

Table Containment Area: Call Agent

Command Types

Show, add, change, and delete

Examples

show h323-gw id=gw1@cisco.com;

add h323-gw id=gw1@cisco.com; fax-relay-cap=t38-ca-fax;

change h323-gw id=gw1@cisco.com; fax-relay-cap=t38-ca-fax;

delete h323-gw id=gw1@cisco.com;

Usage Guidelines

Primary Key Token(s): id;

Add Rule: status=OOS

Change Rule: status=OOS

Delete Rules: FK constraints, status must be OOS.

Token Properties

Table 3 lists the token properties that were added to this command for T.38 Fax Relay.

Table 3 T.38 Fax Relay Tokens

Token
Values

FAX-RELAY-CAP

Specifies FAX Relay Option for this gateway.

INBAND—Possible only for G.711 and G.726, supported by MGX 8260.

T38-CA-FAX—CA-controlled issuing RequestMode relay in real time.
This is the default value.


H.323 Trunk Group Profile

The H.323 Trunk Group Profile (h323-tg-profile) table defines the characteristics of each H.323 trunk. A h323-tg-profile id must be created in this table before H.323 trunk group entries can be added.

Table Name: H323-TG-PROFILE

Table Containment Area: Call Agent

Command Types

Show, add, change, and delete

Examples

show h323-tg-profile id=gw1@cisco.com

add h323-tg-profile id= ras-tg; ras=n;

change h323-tg-profile id= ras-tg; ras=y;

delete h323-tg-profile id= ras-tg;

Usage Guidelines

Primary Key Token(s): id

Add Rules: FK constraints.

If fax-pref-mode=FAX-T38-CAMODE, then fax-t38-camode-supp=Y;

If fax-pref-mode=FAX-INBAND, then fax-inband-supp=Y;

Change Rules: FK constraints.

Delete Rules: FK constraints.

Token Properties

Table 3 lists the token properties that were added to this command for T.38 Fax Relay.

Table 4 T.38 Fax Relay Tokens

Token
Values

FAX-T38-CAMODE-SUPP

CA-controlled T.38 fax relay in real time (CA instructs GW when to switch to T.38 mode).

Y/N (Default = Y)

FAX-INBAND-SUPP

Y/N (Default = N)

FAX-PREF-MODE

Designates preferred mode of T.38 fax relay for this gateway.

FAX-T38-CAMODE—This is the default value.

FAX-INBAND—Possible only for G.711 and G.726. supported by MGX 8260.


Media Gateway Profile

The Media Gateway Profile (mgw-profile) table provides templates for defining a Media Gateway by hardware vendor. It identifies the specifications and settings necessary for communications between the Call Agent and each type of Media Gateway. An ID must be created in this table before entries can be added to the Media Gateway table.

Several tokens have values that can be overwritten after the Call Agent queries the Media Gateway for supported capabilities. If the Media Gateway returns a value different from the value originally provisioned, the returned value automatically replaces the originally provisioned value.

Table Name: MGW-PROFILE

Table Containment Area: Call Agent

Command Types

Show, add, change, and delete

Examples

show h323-mgw-profile id=resgw2000;

add h323-mgw-profile id= resgw2000; fax-inband-supp=N; fax-pref-mode=fax-t38-camode

change h323-mgw-profile id= resgw2000; fax-inband-supp=N;

delete h323-wgw-profile id= resgw2000;

Usage Guidelines

Primary Key Token(s): id

Add Rules:

If fax-pref-mode=FAX-T38-CAMODE, then fax-t38-camode-supp=Y;

If fax-pref-mode=FAX-INBAND, then fax-inband-supp=Y;

Change Rules: none

Delete Rules: id does not exist in any mgw::mgw-profile-id.

Token Properties

Table 3 lists the token properties that were added to this command for T.38 Fax Relay.

Table 5 T.38 Fax Relay Tokens

Token
Values

FAX-T38-CAMODE-SUPP

CA-controlled T.38 fax relay in real time (CA instructs GW when to switch to T.38 mode).

Y/N (Default = Y)

FAX-INBAND-SUPP

Specifies whether inband mode of fax relay is supported.

Y/N (Default = Y)

FAX-PREF-MODE

Designates preferred mode of T.38 fax relay for this gateway.

FAX-T38-CAMODE—This is the default value.

FAX-INBAND—Possible only for G.711 and G.726,
supported by MGX 8260.


Troubleshooting Fax Relay

The purpose of this section is to provide basic troubleshooting procedures for anyone trying to resolve Cisco BTS 10200 Softswitch T.38 fax relay issues. The technical intricacies of faxing and fax relay are not covered in detail, but you will get a basic understanding and be able to perform troubleshooting for a majority of common fax relay issues.

It is important to know the following information:

Phase in which the fax transmission error occurred.

Whether the gateways or fax machines terminated the connection, and if it was a fax machine, which one.

What fax protocol events took place prior to the connection being terminated.

The following steps have been shown to resolve the majority of issues involving T.38 fax relay over packet networks.


Step 1 Identify and isolate the problem.

The first step to take when you troubleshoot any fax relay issue is to reduce the problem to its simplest form. Many issues arise in situations where multiple fax machines are not able to pass fax traffic. It is easier to isolate two fax machines that are having problems and concentrate on a simple topology. First, determine how these two machines are connected to one another and resolve the issue between this pair. In addition, you should draw a complete picture of the network topology and determine how all the fax machines are interconnected.

Troubleshooting one issue at a time minimizes confusion and allows for methodical troubleshooting. It is also possible that the solution for this problem will resolve other fax relay problems in the network. Most fax relay problems result from poor packet network configuration or network design. These lead to basic connectivity problems and physical line or packet loss and jitter problems.

After you have identified and isolated the problem, the next steps relate to verifying the basic voice over packet network configuration and monitoring the health of the network.

Step 2 Check basic network connectivity.

Basic fax connectivity issues can be the result of the following factors:

Normal voice connectivity problems—Confirm that normal voice calls can be completed before investigating fax connectivity. If there is no telephone attached to the fax machine, unplug it and connect a regular telephone. If normal voice calls do not connect, the issue may be network-related and you should troubleshoot the problem as a connectivity issue before fax troubleshooting.

Configuration problems related to dial peers, such as:

Wrong dial peer being matched—

After ensuring that voice calls can be successfully completed in both directions through the network, issue the show call active voice brief command and note the dial peers that are being matched with each voice call.

When you have VoIP trunks, you should be able to see all the call legs with the show call active voice brief command. Ensure that the configured dial peer is the peer that is being matched.

A common cause of fax relay problems is that the correctly configured dial peer is not the one being matched. It is also common that there is no particular incoming VoIP dial-peer configured on the terminating gateway and the Cisco IOS software selects the first appropriate (including default) VoIP dial peer as the incoming dial peer. Hence the parameters for this incoming dial peer may not match those of the outbound dial peer on the originating gateway.

It is not always required that you have identical configurations on the outgoing and incoming VoIP dial-peers. When you have a fax relay problem though, make sure you have a dedicated incoming VoIP dial-peer on the terminating gateway and that its configuration matches the configuration of the outgoing VoIP dial-peer on the originating gateway.

Another method you can use to check dial peer matching is to issue the debug voip ccapi inout command. The debug output from this command will show an ssaSetupPeer message that lists all the dial-peers matching the called number. A ccCallSetupRequest message follows with the outbound peer option indicating the outgoing VoIP dial-peer selected. When multiple VoIP dial peers are configured for the same destination, it is possible that the initial call setup could fail and another dial peer tried. In this case another ccCallSetupRequest will appear in the debug.

On the terminating voice gateway the first line of the debug voip ccapi inout call trace will be a cc_api_call_Setup_ind message with a peer_tag option that refers to the incoming VoIP dial peer on the terminating gateway.

Incorrectly configured dial peers on one or both sides—

After you confirm that the correct dial peer is being matched (in this case dial-peer 100 for the originating gateway and dial peer 400 for the terminating router), confirm in the configuration that the dial-peer is configured correctly for fax. Some common errors to check for on both sides of the call are:

Fax relay is disabled (that is, the fax rate disable command has been issued on the dial peer) while a low bandwidth codec has been in use.

The dial peer on one gateway is configured for T.38 fax relay but the other gateway is configured for Cisco proprietary fax relay, so the negotiation will fail.

The default dial peer is used inbound on the terminating gateway and these parameters do not match with the parameters set for the outbound dial peer on the originating gateway.

Incorrect compand type—

The companding type for the US is µ-law, for EMEA it is a-law. The show voice call command dispolays which value is currently configured. If, on a BRI or E1 port, the companding type on the gateway does not match the one on the connected device, calls will sometimes fail and sometimes connect. When a connection is made the voice becomes heavily distorted, the person becomes unrecognizable, and a high volume low-pitch noise level is heard.

Other basic connectivity problems not relating to dial peers, including:

Cisco IOS Software incompatibilities on gateway pairs.

It is not always required that Cisco IOS Software releases on the gateways match, but it is recommended to check releases for compatability when fax relay problems occur.

Compressed Real-Time Transport Protocol (cRTP) problems.

There are several known problems associated with cRTP. Fixes are available for these problems and it makes sense to disable cRTP when fax relay problems occur and to check whether a Cisco IOS Software upgrade is an appropriate course of action.

Ensure that the VCWare and Cisco IOS Software are compatible.

On Cisco AS5300 series voice gateways, the Cisco IOS software might be incompatible with the VCWare software.

Fax connectivity problems across the PSTN—

If voice calls work in both directions, but fax calls are failing in at least one direction, check that normal faxing between these two machines works across the PSTN. In other words, ensure the fax machines successfully transmit faxes to each other using the PSTN without traversing the packet network. If they do not, one or both fax machines may have problems that need to be addressed before you consider fax relay problems.

Step 3 Check for slips and other errors on the interfaces.

If any T1 (or E1) digital connections are used by the gateways performing T.38 fax relay, make sure that they are error free. T.38 fax relay is very sensitive to errors on digital interfaces, especially slips. The errors may not be noticeable on voice calls, but they can cause fax calls to fail.

The T1 (or E1) controllers at both the originating and terminating gateways should be error free. If errors occur, repeat the show controller (T1, E1, and 1/0 will vary) command several times during a fax call to see if the number of errors increases. The most common problem with slips is timing synchronization resulting in clocking errors.

In packet voice networks, confirming that the router is clocking from the line is usually sufficient. If it isn't, ensure that the clock source line command is entered at the controller level. However, in VoATM or TDM networks where a clocking hierarchy is established and the gateways might need to pass clock signals through the network, additional considerations need to be made.

Step 4 Check fax interface type.

On some Cisco media gateways, including the Cisco 3660, 5300, 5350, 5400, and 5800, the gateway defaults to fax interface-type modem. The fax interface-type modem global configuration command forces fax calls to a modem (usually for T.37 Store and Forward fax) and not to a DSP. For T.38 fax relay to work, the fax call must be sent to a DSP, which means it must be configured by issuing the fax interface-type t38 command.

Make sure you reload the Cisco media gateway; otherwise the fax interface-type t38 command won't take effect. Fax calls will fail on some Cisco media gateways with T.38 fax relay, so this is an important command to check. This problem is seen when a gateway is upgraded to Cisco IOS Release 12.2 or later.

Step 5 Make sure that the fax codec is loaded during the fax call.

Each fax machine displays the remote fax machine ID on its LCD screen at the completion of the fax negotiation phase. It is unlikely that the fax machines could complete negotiation if the fax codec had not been successfully downloaded. On the other hand, if no remote fax machine ID is displayed, further debugging in this area is appropriate.

There are two ways to ensure the gateways detect the fax transmission and successfully load the fax codec.

Issue the debug vtsp all command and the debug voip ccapi inout call trace.

Voice Telephony Service Provider (VTSP) is an architecture that defines the interface between the Cisco call control and a DSP end point connected to standard telephony equipment such as a PBX, fax or central office via analog or digital interfaces.

The debug vtsp all output does not contain a lot of information from a T.30 protocol perspective, but it does provide useful state information from the router such as:

Confirmation that the gateway entered fax mode

Fax rate and codec used

Confirmation that the terminating gateway received a fax tone from the terminating fax machine

Issue the show voice trace command.

Show commands use less resources than debug commands and are preferable in production networks.

Step 6 Disable T.38 fax relay and change codec for passthrough.

In the previous troubleshooting steps you established that voice calls work, faxes work through PSTN, and all digital interfaces in the fax relay path are free from errors. This step determines whether faxes can go through with T.38 fax relay disabled.

Under the dial-peers, enter the following commands on both media gateways:

gateway-name(config)#voice-port 2/0:15
gateway-name(config-voiceport)#no echo-cancel enable
gateway-name(config)#dial-p voice 3
gateway-name(config-dial-peer)#fax rate disable
gateway-name(config-dial-peer)#codec g711ulaw
gateway-name(config-dial-peer)#no vad

These commands disable fax relay, disable echo cancellation, and force the call to use a high bandwidth codec without voice activity detection (VAD). The gateway samples the fax tones like a normal voice call. With the high bandwidth codec (G.711), the most precise sample possible is captured and the tone replayed on the other side is as accurate as possible. Be aware that the G.711 is a 64 kbps bandwidth codec, so each call consumes up to 80 kbps when the additional transport protocol overhead is added.

If this test is positive, two things have been accomplished:

First, if per call bandwidth consumption is not a major issue for the network, there is now a potential fax passthrough workaround for the fax relay problem.

Secondly, and more significantly if bandwidth consumption is an issue, the problem has been isolated to the T.38 fax relay software and you should open a case with the Cisco TAC.

If this test fails, it is very likely that whatever is causing the fax calls to fail with T.38 fax relay is also causing the failures with this test. The network may have a large amount of jitter or packet loss.

Step 7 Check for packet loss on the network.

The easiest and most accurate way to determine if there is packet loss is to do the following:

a. Disable VAD on the packet network dial-peers.

b. Make a voice call between the same ports where the fax machines are connected. (Fax machines may be able to serve as ordinary phones or you might need to connect handsets to the fax ports).

c. When the call is connected:

Issue the show voice dsp command. You can see in the output that one of the DSP channels has the configured codec loaded. Usually the column "TX/RX-PAK CNT" shows that the transmit and receive packet counters are equal, meaning no packets are being lost.

If the counters are not equal, packets might be getting lost. Type the show voice dsp command several times at 30-second intervals to determine if the difference increases. If so, then packets are being lost.

Issue the show voice call summary command to see which port (and timeslot if applicable) is allocated to the voice call. Type terminal monitor then issue the show voice call command with the voice port (and timeslot if applicable) specified to get the detailed DSP statistics. In the "***DSP VOICE VP_ERROR STATISTICS***" section of the output, look for the counters. They are usually 0 or below 20. If the counter(s) is higher than 20, investigate the packet loss.

If the network appears to be lossy, it is not reasonable to expect T.38 fax relay to work reliably. Further investigation is probably needed to ensure that QoS is provisioned end-to-end so that the voice and T.38 fax relay traffic has priority and is never lost during congestion.

Step 8 Enable T.38 Packet Redundancy.

The T.38 fax relay packet redundancy feature can be turned on by configuring the following command under the appropriate dial peers on both gateways:

gateway-name (config-dial-peer)#fax protocol t38 Ls-redundancy X Hs-redundancy Y

where X> 0 and Y= 0 (only make changes to Ls-redundancy).

This feature can alleviate T.38 fax relay failures due to packet loss. However, T.38 packet redundancy significantly increases bandwidth usage and it is preferable to eliminate packet loss where possible.

Step 9 Set the fax NSF command to all zeroes.

The fax NSF command can be helpful in troubleshooting the brands of fax machines that alter the NSF field during fax negotiation for proprietary encodings. This command allows the gateway doing T.38 fax relay to override the settings made by fax machines that are trying to implement proprietary encodings. Before the fax NSF command was available, fax relay would fail for these brands of fax machines. Typically the fax NSF command is used to set the NSF field to all zeroes, which forces a standard fax negotiation from both sides. Using this command has been successful with certain brands such as Harris and Lanier, and it is recommended when T.38 fax relay is failing.

Step 10 When all else fails ...

If the preceding troubleshooting steps did not resolve the T.38 fax relay issue, the problem may require more advanced troubleshooting. Listed below are additional steps to try before you open a case with the Cisco Technical Assistance Center (TAC).

Learn the brands and models of the fax machines that are failing, and investigate those brands and models for known issues.

Sometimes there are defect reports that address known problems for certain brands of fax machines. These defects are not in the Cisco IOS Software; they are known incompatibilities with the fax machines' proprietary fax signaling protocol when these fax devices are used on each side of a connection. The workaround is to disable the proprietary protocol on the fax machines or to disable T.38 fax relay and use a higher bandwidth codec.

Use search tools to look for known fax problems in the Cisco IOS Software release where the problem is occurring.

In the previous step, searches were made for a specific fax brand in the hope of identifying a known issue between a certain fax brand and the Cisco T.38 fax relay code. The next step is to perform a generic search since there could be a fax relay defect in the Cisco IOS Software release installed.

For example, if T.38 fax relay is not working in a particular Cisco IOS Software release, you can search for defects using the Bug Toolkit on CCO. If a defect in a particular release causes all T.38 fax relay to fail, then an upgrade is needed to a release in which this defect is no longer present.

Eliminate hardware faults.

In some cases it is easier to isolate the problem by excluding potential problem sources one by one. You can do this by replacing different hardware parts and using alternative IP connections between the gateways.

When extra hardware is available, the following steps can help.

Use different ports on the gateways—

If your configuration involves two gateways connected to PBXs or the PSTN with T1 (or E1) and if you have the FXS ports available, try to connect the fax machines directly to the FXS ports on the voice gateways. This procedure will help further isolate the problem by excluding the possibility of the T1 (or E1) cards failing, problems on the telephony side, or T1 (or E1) clock synchronization or cable problems.

Try different hardware—

If you have another voice gateway with FXS ports available to you, try to connect it directly with the Ethernet crossover cable to each of the voice gateways and send a fax using the fax machine connected to the FXS port. This procedure will help determine if there are problems in the packet network such as queuing, fragmentation, or prioritization.

Use debug commands on the gateways to determine what is happening.

Describing the details of debug outputs is beyond the scope of this document, but described below are the basic transactions that are commonly seen when debugging T.38 fax relay. For more in-depth information on T.30 messaging or for information on messages that are not listed below, see the T.30 specification.

1. The fax transmission starts with the exchange of DIS/DCS (CSI,DIS / TSI,DCS) messages:

DIS is the initial message stating the capabilities of the answering end. The accompanying CSI frame has the phone number.

DCS defines the transmit parameters and starts an image transfer sequence. The accompanying TSI frame has the phone number.

2. The fax machines go into training mode and can make several attempts to agree on a transmission speed. For instance, the fax machines may first train to a speed of 9600 bps, fail, and then train to a speed of 7200 bps.

3. Successful training is followed by a CFR message.

4. Transmission starts following the CFR message.

5. If there is a high number of errors, a good fax analyzer will detect them.

If the terminating fax machine considers the error rate too high, it will terminate the connection.

6. MCF is the normal response to an end-of-image message sequence by the receiving end. It indicates that the image was received with less than five percent of lines in error. It is normally followed by the DCN (disconnect) message.

7. If there is no MCF message, the transmission was not completed successfully. It may suggest a high error rate caused by one of the following:

Digital line errors (clocking, cabling)

VoIP packet loss (queueing, prioritization, fragmentation, compression)

Hardware fault

Cisco IOS/DSPW incompatibility (rarely occurs) ¨

8. If the DIS or DCS messages are retransmitted several times, it may be that they are not passed across the VoX connection correctly or only passed in one direction—a software or configuration problem.

9. If training repeats multiple times, each time at a lower speed and then the transmission fails, it may be that the fax codec was not loaded and the voice gateways handle the fax transmission as a normal voice conversation, again a configuration or software issue.

Trace information may look different in different versions of Cisco BTS 10200 Softswitch software, but you should be able to understand whether the fax codec was loaded correctly and which fax protocol was used by the output following the "FAX" keyword.

If the fax codecs were not loaded correctly, there is probably a software problem. Make sure that the latest release is used and, if there is still a problem, open a case with the Cisco TAC.


Fax Analyzers

Sometimes it is necessary to go beyond the debugging capabilities of the Cisco voice gateways to resolve fax relay problems. Tools such as protocol analyzers and fax analyzers are used to see what is occurring during fax relay operation. Fax analyzers such as the Genoa ChannelProbe/FaxProbe by QualityLogic or the HP Telegra can be positioned between the fax device and the gateway to capture what is occurring.

Protocol analyzers such as Sniffer and Domino can also be helpful when you need to view the fax relay packets that are being exchanged between the gateways.

The ability to resolve a complex problem sometimes requires using a combination of test equipment—an analyzer to capture the fax traffic at each fax machine and a protocol analyzer to capture the fax relay packets. A single fax call is placed to reproduce the problem, and then the information is captured from the attached devices for analysis.

Most fax analyzers have adequate help screens and documentation to help you determine what is happening. The T.30 specification is also very helpful. For the protocol analyzers, decoding can be a little more difficult since sometimes the encodings are proprietary or the analyzer software does not have the specific decode needed. If the protocol analyzer is not able to decode the frame, the frame can be manually decoded using the specification. With T.38 fax relay, a Cisco proprietary format is used for the fax relay packets.

With fax analyzer and protocol analyzer information, you should be able to resolve most T.38 fax relay problems. Few fax relay problems reach this point, and when they do, escalation and other resources should already be involved for further assistance.

Opening a TAC Case

If this document has not enabled you to isolate and resolve the problem, open a case with the Cisco Technical Assistance Center (TAC) and provide the following information:

Network topology description (PDF, Visio, or Microsoft PowerPoint format).

The fax machines used, including vendor and model information.

The history of the problem.

Useful information includes whether the implementation is new or an established network that worked well and then failed.

If the network was established, what changed before the problem occurred? Is the problem intermittent? Can the problem be reproduced and, if so, what are the steps to reproduce the problem?

Output of the show tech command from both fax gateways and all the routers on the IP path, and relevant information for the active non-Cisco network equipment.

A pair of the call traces with the following debug flags enabled:

debug voip ccapi inout

debug vtsp all

debug isdn q931 (if the ISDN or Q.Sig is involved)

A pair of the show voice call and show voice dsp outputs. ·

A pair of the fax analyzer traces connected in the monitor mode to the originating and terminating fax machines, if available.

Results of the troubleshooting and debugs already performed, if available.

Glossary

AIN—Advanced Intelligent Networking.

ANI—Automatic Number Identification (ANI) is a service that provides the receiver of a telephone call with the number of the calling phone. The service is often provided by sending the digital tone multi frequency (DTMF) tones with the call. Users of ANI can screen callers with this information.

ANM—Announcement.

API—Application Programming Interface

ATM—Asynchronous Transfer Mode

BCM—Basic Call Module

CA—Call Agent

CALLP—Call Processing

CAS—Channel Associated Signaling

CDB—Call Detail Block

CFNA—Call Forwarding No Answer

CLC—Close Logical Channel

CLCA—Close Logical Channel Acknowledge

CNAM—Calling Name

CNM—Connection Manager

CTX—Centrex

DA—Directory Assistance

DAS—Data Acquisition System

DSP—digital signal processor.

ECS—Empty Capability Set

EDP—Event Detection Point

EMG—Emergency (911) Call

EMS—Element Management System

EPOM—Extensible Provisioning and Operations Manager

FCP—Feature Control Protocol

FS—Feature Server

FTP—File Transfer Protocol

GUI—Graphical User Interface

H.235—H.235 provides security for the RAS signaling between H.323 endpoints and gatekeepers so that only duly authenticated and authorized endpoints are able to use Gatekeeper resources.

H.323—ITU-T Recommendation for "Visual Telephony System" and equipment for local area networks which provide a non-guaranteed quality of service.

H3A—H.323 Gateway Adapter

HCM—High-density Compression Module.

HNPA—Home Numbering Plan Area

INTRALATA—Calls that occur within a single LATA

INTERLATA—Calls that cross LATA boundaries

IP—Internet Protocol

ISDN—Integrated Services Digital Network

ISUP—ISDN User Part (SS7)

LATA—Local Access Transport Area

LNP—Local Number Portability

LRN—Local Routing Number

MCM—Multimedia Conference Manager.

MGA—Media Gateway Adapter

MGCP—Media Gateway Control Protocol

MIB—Management Information Base

NANP—North American Numbering Plan

NPA—Numbering Plan Area (area code)

OLC—Open Logical Channel.

OLCA—Open Logical Channel Acknowledge

PCS—Personal Communications Service

PIN—Personal Identification Number

POTS—Plain Old Telephone Service

PSTN—Public Switched Telephone Network

QOS—Quality of Service

RSVP—Resource Reservation Protocol.

SAI—Signaling Adapter Interface

SCP—Service Control Point

SDP—Session Description Protocol

SIA—Signaling Interface Adapter

SIM—Service Interaction Manager

SIP—Session Initiation Protocol

SNMP—Simple Network Management Protocol

SQL—Structured Query Language

SS7—Signaling System #7

SSTSS—Slow Start To Slow Start Calls

T.30—ITU-T Recommendation for analog phone line Group 3 facsimile terminals.

T.38 Fax—ITU-T Recommendation T.38 describes the features necessary to transfer facsimile documents in real-time between two standard Group 3 facsimile terminals over the Internet or other networks using IP protocols. The recommendation allows the use of either TCP or UDP depending on the service environment.

TCS—Terminal Capability Set

TDM—Time Division Multiplexing

TDP—Trigger Detection Point

TG—Trunk Group

VCM—Voice Compression Module.

Copyright Notice