This appendix explores the types of problems that might interrupt or prevent call transmission, and suggests some procedures for addressing those problems. This appendix covers these topics:
ISDN cause codes
Common problems and their solutions


This section describes the types of LEDs available on different MAX models, and explains the information they display.

MAX front panel

The MAX front panel includes this set of LEDs:

Figure A-1. MAX front panel LEDs

The front-panel LEDs report on the status of the system, the PRI interface, and the data transfer in active sessions.

Table A-1 lists and describes each LED.
Table A-1. MAX LEDs




This LED is on when the MAX power is on.


This LED is on in one of two cases-either a hardware self-test is in progress or there is a hardware failure.

When a hardware self-test is in progress, the LED is on. If any type of hardware failure occurs, the LED flashes. If the failure is isolated to a expansion card, the MAX may continue functioning without the expansion card.


This LED is on when calls are active.


This LED is on when there is a WAN alarm or a trunk is out of service, such as during line loopback diagnostics.

WAN alarms include Loss of Sync, Red Alarm, Yellow Alarm, and All Ones (or AIS).

Figure A-2. Location of LEDs on the Redundant MAX

Table A-2. Redundant MAX LEDs




This LED is on when the Redundant MAX power supply is on.

A Fail

This LED is on only when there is a failure on power supply A, (if one or more of the voltages on the A side has failed: +5, +3.3, +12, -12, -5.)

B Fail

This LED is on only when there is a failure on power supply B, (if one or more of the voltages on the B side has failed: +5, +3.3, +12, -12, -5.)


This LED is on when the fans are functioning properly (if +12 VDC from either A or B is good.) This LED is off when there is a fan failure.

Table A-2 lists and describes each LED.

MAX back panel

The MAX back panel includes the following LEDs that display the status of the Ethernet interface:

Figure A-3. Ethernet interface LEDs on MAX back panel

Note: The Classic MAX back panel shows similar LEDs on the Ethernet expansion card if one is installed. On the Classic MAX, there is one LED for each possible Ethernet interface (10BaseT, and COAX (10Base2), which are lit when the interface is in use. The ACT and COL LEDs are the same as those on the MAX 6000 (Table A-3).

Table A-3. Ethernet interface LEDs on back panel



ACT (Activity)

This LED is on when the MAX is detecting activity (network traffic) on its Ethernet interface.

COL (Collisions)

This LED is on when the MAX detects packet collisions on the Ethernet.


When this LED is on it indicates full duplex on the Ethernet.


When this LED is on, it indicates 100BT; when it is off, it indicates 10BT.

LINK (Link integrity)

This LED is on when the Ethernet interface is functional.

The Ethernet interface LEDs are described in
Table A-3.

ISDN cause codes

ISDN cause codes are numerical diagnostic codes sent from an ISDN switch to a DTE; these codes provide an indication of why a call failed to be established or why a call terminated. The cause codes are part of the ISDN D-channel signaling communications supported by the Signaling System 7 supervisory network (WAN). When you dial a call from the MAX using ISDN access, the MAX reports the cause codes in the Message Log status menu. When the MAX clears the call, a cause code is reported even when inband signaling is in use. If the PRI or BRI switch type is 1TR6 (Germany), see Table A-5.

Table A-4 lists the numerical cause codes and provides a description of each.
Table A-4. ISDN cause codes




Valid cause code not yet received


Unallocated (unassigned) number


No route to specified transit network (WAN)


No route to destination


Send special information tone


Misdialed trunk prefix


Channel unacceptable


Call awarded and being delivered in an established channel


Prefix 0 dialed but not allowed


Prefix 1 dialed but not allowed


Prefix 1 dialed but not required


More digits received than allowed, but the call is proceeding


Normal clearing


User busy


No user responding


No answer from user (user alerted)


Call rejected


Number changed


Reverse charging rejected


Call suspended


Call resumed


Non-selected user clearing


Destination out of order


Invalid number format (incomplete number)


Facility rejected




Normal, unspecified


Circuit out of order


No circuit/channel available


Destination unattainable


Degraded service


Network (WAN) out of order


Transit delay range cannot be achieved


Throughput range cannot be achieved


Temporary failure


Switching equipment congestion


Access information discarded


Requested circuit channel not available




Precedence call blocked


Resource unavailable, unspecified


Quality of service unavailable


Requested facility not subscribed


Reverse charging not allowed


Outgoing calls barred


Outgoing calls barred within CUG


Incoming calls barred


Incoming calls barred within CUG


Call waiting not subscribed


Bearer capability not authorized


Bearer capability not presently available


Service or option not available, unspecified


Bearer service not implemented


Channel type not implemented


Transit network selection not implemented


Message not implemented


Requested facility not implemented


Only restricted digital information bearer capability is available


Service or option not implemented, unspecified


Invalid call reference value


Identified channel does not exist


A suspended call exists, but this call identity does not


Call identity in use


No call suspended


Call having the requested call identity has been cleared


Called user not member of CUG


Incompatible destination


Nonexistent abbreviated address entry


Destination address missing, and direct call not subscribed


Invalid transit network selection (national use)


Invalid facility parameter


Mandatory information element is missing


Invalid message, unspecified


Mandatory information element is missing


Message type non-existent or not implemented


Message not compatible with call state or message type non-existent or not implemented


Information element nonexistent or not implemented


Invalid information element contents


Message not compatible with call state


Recovery on timer expiry


Parameter nonexistent or not implemented, passed on?


Protocol error, unspecified


Internetworking, unspecified

Table A-5. ISDN cause codes for 1TR6 switch type

1TR6 Code



Invalid call reference value


Bearer service not implemented. (Service not available in the A-exchange or at another position in the network, or no application has been made for the specified service.)


Call identity does not exist. (Unknown call identity)


Call identity in use. (Call identity has already been assigned to a suspended link.)


No channel available. (No useful channel available on the subscriber access line-only local significance.)


Requested facility not implemented. (The specified FAC code is unknown in the A-exchange or at another point in the network.)


Request facility no subscribed. (Request facility rejected because the initiating or remote user does not have appropriate authorization.)


Outgoing calls barred. (Outgoing call not possible due to access restriction which has been installed.)


User access busy . (If the total made up of the number of free B-channels and the number of calling procedures without any defined B-channel is equal to four, then any new incoming calls will be cleared down from within the network. The calling party receives a DISC with cause "user access busy" (= 1st busy instance) and engaged tone.)


Negative CUG comparison. (Link not possible due to negative CUG comparison.)


Communication as semi-permanent link not permitted

48 - 50

Not used. (Link not possible, e.g. because RFNR check is negative.)


Destination not obtainable. (Link cannot be established in the network due to incorrect destination address, services or facilities)


Number changed. (Number of B-subscriber has changed.)


Out of order. (Remote TE not ready)


No user responding. (No TE has responded to the incoming SETUP or call has been interrupted, absence assumed-expiry of call timeout T3AA.)


User busy. (B-subscriber busy)


Incoming calls barred. (B-subscriber has installed restricted access against incoming link or the service which has been requested is not supported by the B-subscriber)


Call rejected. (To A-subscriber: Link request actively rejected by B-subscriber -by sending a DISC in response to an incoming SETUP. To a TE during the phase in which an incoming call is being established: The call has already been accepted by another TE on the bus.)


Network congestion. (Bottleneck situation in the network; e.g. all-trunks-busy, no conference set free)


Remote user initiated. (Rejected or cleared down by remote user or exchange.)


Local procedure error. (In REL: Call cleared down due to local errors; e.g. invalid messages or parameters, expiry of timeout, etc. In SUS REJ: The link must not be suspended because another facility is already active. In RES REJ: No suspended call available. In FAC REJ: No further facility can be requested because one facility is already being processed, or the specified facility may not be requested in the present call status.)


Remote procedure error. (Call cleared down due to error at remote end.)


Remote user suspended. (The call has been placed on hold or suspended at the remote end.)


Remote user resumed. (Call at remote end is no longer on hold, suspended or in the conference status.)


User Info discarded locally. (The USER INFO message is rejected locally. This cause is specified in the CON message.)


Non existent CUG. (This CUG does not exist.)

Table A-5 lists the cause codes for the 1TR6 switch type.

Common problems and their solutions

This section lists problems you might encounter and describes ways to resolve them.

General problems

Calls fail between AIM ports

.The following first-level diagnostic commands can help in troubleshooting calls between AIM ports:

You must be in a profile or status window specific to an AIM port with a call online to use each DO command. For information on the Local LB command and on each DO command, see the MAX Reference Guide

DO menus do not allow most operations

When the list of DO commands appears, many operations may not be not available if the right profile is not selected. Because the MAX can manage a number of calls simultaneously, you might need to select a specific Connection profile, Port profile, or a Call profile in order to see certain DO commands. For example, to dial a Call profile or a Connection profile, you must move to the Call profile (Host/6>Port N Menu > Directory) or the Connection profile, and then type Ctrl-D 1.

Note that you cannot dial if Operations=No for the control port. If a call is already active, DO 2 (Hang Up) appears instead of DO 1 (Dial). If the T1 or E1 line is not available, Trunk Down appears in the message log and you cannot dial.

POST takes more than 30 seconds to complete

The MAX downloads 12MOD modem code, waits for the modems to checksum the downloaded code, and then verifies the checksum matches before continuing with AT POST. Previously, the MAX downloaded the modem code and immediately commence with AT POST. This feature helps to reduce the POST failure rates for the MOD12 cards.

The 12MOD digital modem slot card boots every time the MAX power-cycles, and requires boot-up configuration data from the MAX. This means the MAX makes two further attempts to download the code for the MAX unit's MOD12 digital 12-modem slot card if the first boot-up fails.

Previously, the MAX downloaded the required code and immediately commenced with AT POST (which sends the string AT to each modem and waits for the modem to respond with "OK"). Now the MAX downloads the modem code, waits for the modems to checksum the downloaded code, and then verifies that the checksum matches before continuing. If the checksum does not match, the MAX will download the code again, up to 2 more times. If the checksum still doesn't match after three download attempts, the MAX will fail the entire slot card.

Configuration problems

The most common problems result from improperly configured profiles.

The MAX cannot dial out on a T1 or E1 line

To verify that the configured profile is correctly configured:

  1. Make certain that you have entered the correct phone number to dial.

  2. Check that the Data Svc parameter specifies a WAN service available on your line.

    If you request a WAN service that is not available on your line, the WAN rejects your request to place a call.

  3. Check whether the channels using the requested WAN service are busy.

    If these channels are busy, an outgoing call might be routed to channels for which you did not request the specified WAN service. Check the Data Svc, Call-by-Call, and PRI # Type parameter values in the profile.

  4. Determine whether you have correctly set the parameters controlling Dynamic Bandwidth Allocation.

    For detailed information, see Chapter 2, Configuring the MAX for WAN Access, and Chapter 3, Configuring WAN Links.

Some channels do not connect

You may encounter a problem where the Line Status menu shows that the MAX is calling multiple channels simultaneously, but only some of the channels connect.

An international MAX placed the call or the call was from the U.S. to another country. In some countries, setting the Parallel Dial parameter in the System profile above 1 or 2 violates certain dialing rules, and only some of the channels can connect during call setup. Try reducing the Parallel Dial parameter to the value 2. If the problem persists, try reducing it to 1.

Data is corrupted on some international calls

You may notice that the data appears to be corrupted on single- or multichannel calls dialed in the U.S. to another country. On some international calls, the data service per channel is not conveyed by the WAN to the MAX answering the call. You must therefore set Force 56=Yes in the Call profile. If you do not, the MAX incorrectly thinks that the call uses 64-kbps channels.

Only the base channel connects

You may encounter a problem where the first channel of an inverse multiplexing or MP+ call connects, but then the call clears or does not connect on the remaining channels.

The most common error in defining Line profiles is specifying incorrect phone numbers. The MAX cannot successfully build inverse multiplexing or MP+ calls if the phone numbers in the Line profile of the called unit are incorrect. The phone numbers that you specify in the Line profile are the numbers local to your unit. Do not enter the phone numbers of the MAX you are calling in the Line profile. The numbers you are calling belong in the Call profile, Destination profile, or Connection profile.

In addition, when you are using E1 or T1 lines, any phone numbers you specify must correspond to those channels within the circuit that are available for data transmission. For example, if channels 13-21 are allocated to a particular slot, you must specify the phone numbers for channels 13-21 in the Line profile. Switched data channels do not have to be contiguous within the circuit.

No Channel Avail error message

When the MAX tries to place a call, if the error message No Channel Avail appears in the Message Log display, check the Line profile configuration. This message can also indicate that the lines' cables have been disconnected or were installed incorrectly.

Restored configuration has incorrect RADIUS parameters

The RADIUS Server submenu used to consist of 3 clients (specific host addresses) and 1 Server Key for all 3 clients. If the MAX supports the new RADIUS Server, the restoration of the MAX configuration will cause a problem because the new RADIUS Server allows up to 9 addresses (host or net) and a Server Key for each address. When you restore configurations with the old Client Address list, the netmask assigned to the clients will be the default netmask of the address type given (for example, will get a netmask of 16) and not the previous 32-bit (single host) address. In addition, the Server Key will not automatically be set. You must set the Server Key manually for each client in the RADIUS Server submenu.

Hardware configuration problems

If you cannot communicate with the MAX through the vt100 control terminal, you might have a terminal configuration, control port cable, or MAX hardware problem.

Cannot access the vt100

If no data is displayed on the vt100, verify that the unit completes all of the power-on self tests successfully by following these steps:

  1. Verify that the MAX and your terminal are set at the same speed.

  2. Locate the LED labeled FAULT.

  3. Switch on the MAX.

The FAULT LED should remain off except during the power-on self tests. If you are using the vt100 interface, type Ctrl-L to refresh the screen.

If the FAULT LED remains on longer than a minute, there is a MAX hardware failure. A blinking FAULT LED also indicates a hardware failure. Should these situations arise, contact Ascend Customer Support.

FAULT LED is off but no menus are displayed

If the unit passed its power-on self tests and you still cannot communicate with the vt100 interface, type Ctrl-L to refresh the screen. If you still do not see any data, check the cabling between the MAX and your terminal as follows:

  1. Check the pin-out carefully on the 9-pin cable.

    The control terminal plugs into the HHT-vt100 cable or 9-pin connector labeled Control on the back of the MAX. If you are connecting to an IBM PC-like 9-pin serial connector, a straight-through cable is appropriate. Otherwise, you might need a 9-to-25 pin conversion cable.

  2. Check the flow control settings on your vt100 terminal.

    If you are not communicating at all with the MAX, see whether you can establish communications after you have turned off all transmit and receive flow control at your terminal or terminal emulator.

  3. Determine whether you need a null-modem cable converter.

    In general, these are not required for communications to the MAX. However, so many different cable and terminal configurations are available that occasionally a null-modem cable converter might be required.

Random characters appear in the vt100 interface

If random or illegible characters appear on your display, there is probably a communications settings problem. You must make these settings:

If you have changed the data rate through the Port profile, make certain that your vt100 terminal matches that rate.

A power-on self test fails

If the start-up display indicates a failure in any of its tests, an internal hardware failure has occurred with the unit. In this case, contact Ascend Customer Support.

AIM port interface problems

There are two ways to test the AIM port interface:

Many codecs or other AIM devices support some knowledge of loopback. For example, when the MAX is in loopback mode and is connected to a codec, users see their own images through the codec. Likewise, most bridge/router devices recognize and report a diagnostic message when a packet is sent out and received by the same module. More often than not, the codec must be configured explicitly to accept the loopback from the communications device.

Local loopback testing is the best aid when troubleshooting the AIM port interface-the interface between the codec and the MAX. All of the symptoms and operations described in this section assume you are working from the local loopback diagnostics menu. Unless otherwise specified, the AIM port interfaces in this section can include the Ascend Remote Port Modules (RPMs).

The first and most critical aspect of the AIM port interface is the cable or cables connecting the codec to the MAX. If you are unsure about the cabling required, contact Ascend Customer Support.

The MAX reports data errors on all calls

This problem can indicate that you have installed faulty host interface cables or cables not suited to the application. Information on host interface cabling requirements is found in MAX Getting Started

Calls cannot be made, answered, or cleared using control leads

If you have purchased or built your own cables, verify the pin-out against the MAX pin-out for compatibility. MAX Getting Started lists the host interface pin-outs.

Frequently, a DB-25 breakout box is useful for monitoring control leads and for making quick changes to the cabling. However, because the host interface is running V.35 or RS-422 signal levels, you must verify that the breakout box is passive; that is, you must verify that the breakout box is not regenerating RS-232 level signals.

The codec indicates that there is no connection

The codec expects one or more of its control lines to be active. If no lines are active, toggle the various outputs available on the local loopback diagnostics menu. If there is still no connection, verify that you have installed the host cables correctly as described in MAX Getting Started. If the cabling is installed correctly, examine the host interface cable pin-outs as described in MAX Getting Started.

The codec does not receive data

To resolve this problem:

  1. Verify that the codec is configured to accept a loopback at the communications device. Frequently, a codec requires certain control lines to be active during data transfer. Therefore, you might want to toggle the various host interface output lines, especially DSR and CD, to ensure that they are active.

  2. If there is still no data transfer, your cable might not provide one or more control lines required by the host; refer to the documentation of your equipment for a description of what pins it requires to be active. These control lines are generally the most important ones:

  3. If you are convinced that the control lines are in their correct states, but there is still no data transfer, you might have a clocking problem. The MAX provides both the transmit data clocks and the receive data clocks to your equipment through the host interface.The codec must be configured to accept the clocks from the MAX.

  4. Check your cable length.

    If the cable length exceeds the recommended distances, you should be using terminal timing. Alternately, you might need to install RPMs.

  5. Check the data rate.

    You can adjust the data rate from the local loopback diagnostics menu by choosing the number of channels. Some applications cannot work above or below a certain data rate; for example, some high performance codecs cannot operate at data rates less than 384 kbps. In such cases, adjust the number of channels of data being looped back.

The codec cannot establish a call when DTR is active

You may notice that the Port profile is set to establish calls when DTR is active, but the codec cannot establish a call. If the codec is going to originate the calls directly by using control-lead dialing, the call origination and clearing mechanisms must be configured for compatibility between the MAX and the codec. To verify a compatible configuration from the local loopback diagnostics menu:

  1. Disable each of the MAX output control lines except DSR.

    To disable an output control line, toggle it to be Inactive (-). At this time, the codec should indicate that there is no connection.

  2. Request an outgoing call from your equipment and monitor the Port Leads status menu of the ports active in the call.

    One or more of the control line inputs should go active and remain active for some period of time. If the DTR input is not one of the leads that changes state, your cable is not properly configured. In this case, you must change the cable to route the appropriate host output signal to the DTR input of the MAX. The MAX must use the DTR lead to establish outgoing calls.

  3. Once you have made any changes required to verify that the DTR lead becomes active when the MAX requests the call, configure the Port profile to expect the DTR input.

    In the Port profile, set the Dial Call = DTR Active.

Calls initiated by control-lead toggling are cleared too soon

You may encounter a problem where the MAX clears a call initiated by control-lead toggling before it completely establishes the call. If the call is cleared almost immediately, the Port profile most likely has a configuration error. To find the source of the problem:

  1. Place an outgoing call from the codec while monitoring the Port Leads status menu of the AIM ports used in the call.

  2. Watch the DTR input carefully while the MAX is establishing the call.

    If the DTR input indicates Active (+) and then shortly thereafter returns to Inactive (-), the MAX is using DTR as a pulse to place the call. Make sure that the Clear parameter in the Port profile does not have the value DTR Inactive. (DTR Inactive should be selected for Clear only when the application maintains DTR positive during the call.)

  3. While your equipment is still dialing the call, toggle the value of the CD output to indicate to your equipment that the call completed. At this time, watch the control leads very carefully. Make certain that any control leads that toggle while the call is being established are not used in the Clear parameter to clear the call. This type of configuration error is the most likely cause of a call being cleared almost immediately.

The codec cannot clear a call

You may encounter a problem where a codec-initiated call cannot be cleared. If the call cannot be cleared from the codec, the Port profile most likely has a configuration error. To verify the source of the problem:

  1. Place an outgoing call from your equipment while monitoring the Port Leads status menu of the AIM ports used in the call.

  2. Toggle the CD output to Active (+) once the host has requested the outgoing call. The codec should recognize that the call is online.

  3. Make a request to clear the call from the codec.

  4. Watch the control leads very carefully as one or more of the input control lines toggle. Generally, either DTR or RTS is the line that toggles. Record whether the control lead input goes to Active (+) or Inactive (-) when the call is cleared; then, check that the value of the Clear parameter in the Port profile matches the action that the codec takes when the call is cleared.

ISDN PRI and BRI interface problems

Calls are not dialed or answered reliably

To resolve this problem:

  1. Check your cabling.

    The first and most critical aspect of the interface is the physical cable connecting the MAX to the line or terminating equipment. Typically, WAN interface cabling problems appear immediately after installation. If you are unsure about the cabling required, contact Ascend Customer Support. MAX Getting Started describes the general PRI and BRI interface requirements, and lists cabling pin-outs.

  2. If the cabling is not the problem and the MAX is a T1 unit, check that the value of the Buildout parameter or the Length parameter in the Line profile matches the actual distance in your configuration.

Note: T1 PRI ports not equipped with internal CSUs require an external CSU or other equipment approved for the metallic interface between the MAX and the WAN facility.

The Net/BRI lines do not dial or answer calls

Do not connect the MAX unit's Net/BRI ports directly to U-interface BRI lines. The MAX unit's Net/BRI ports require carrier-approved NT1 (network terminating 1) equipment between the MAX and BRI lines. Note that Net/BRI outbound calls require the use of trunk groups.

No Logical Link status

You may notice that the status of a Net/BRI line in the Line Status display is No Logical Link.

In some countries outside the U.S., it is common for no logical link to exist before the MAX places a call. In the U.S., when you first plug a line into the MAX or switch power on, the central office switch can take as long as 15 minutes to recognize that the line is now available. You might have to wait that long for the line state to change to Active (A). The physical link can exist without a logical link up on the line.

If you wait longer than 15 minutes and the line is still not available:

  1. Check whether all the ISDN telephone cables are wired straight through.

    If you are running multipoint (passive bus) on your switch, all of the ISDN telephone cables must be wired straight through. If any of the cables are wired to cross over, you will not be able to place calls.

  2. Check that 100% termination is provided on each ISDN line.

  3. Check whether you have correctly specified the SPIDs (Service profile Identifiers) in the Line profile for each line. If the SPIDs are not correctly specified, the line status might indicate No Logical Link. Check with your system manager or carrier representative to obtain the SPID or SPIDs for your line. You specify your SPIDs using the Pri SPID and Sec SPID parameters in the Line profile.

WAN calling errors occur in outbound Net/BRI calls

You may encounter a problem where the Call Status window immediately indicates a WAN calling error when the MAX places a call on a Net/BRI module. To resolve the problem:

  1. Check the value of the Data Svc parameter in the Call or Connection profile.

    Try both the 64K and 56K options for Data Svc to see whether using a different value solves the problem.

  2. Check whether you are using the correct dialing plan.

    Depending on how the BRI lines are configured, you might need to type four, seven, or ten digits to communicate with the remote end.

    Four-digit dialing involves the last four digits of your phone number. For example, if your phone number is (415) 555-9015, four-digit dialing requires that you type only the last four digits-9015. Seven-digit dialing specifies that you dial the digits 5559015, and ten-digit dialing requires 4155559015.

    If you are sending the incorrect number of digits, the MAX cannot route the call. Ask your carrier representative for the correct dialing plan, or simply try all of the possibilities.

  3. Verify explicitly with your carrier representative that the line is capable of supporting the call types you are requesting.

ISDN PRI and BRI circuit-quality problems

Excessive data errors on calls to AIM ports

You may encounter a problem where the MAX reports excessive data errors on some calls to AIM ports. The MAX provides a BERT (byte error test) that counts data errors that occur on each channel during a call to a AIM port. The BERT checks the data integrity from the MAX at one end of the call to the MAX at the other end.

If you have verified that the MAX is correctly installed and configured, and you have previously placed calls without excessive errors, run the BERT using the command DO Beg/End BERT. Do not clear the call before running the BERT. You can run a BERT only under these conditions:

You can also configure the Auto BERT parameter in the Call profile to run an automatic BERT. If the BERT indicates very high errors on some of the channels, clear the call and redial. When redialed, the call might take a different path, correcting the excessive error problem.

Excessive handshaking on calls to AIM ports

Handshaking is a normal and momentary occurrence during call setup and when the MAX increases or decreases bandwidth. If there is trouble in the circuits that carry the call, frequent handshaking can occur. If the trouble is serious enough to degrade the quality of the call, the MAX disconnects. If handshaking is continuous for over a minute, the problem is probably not due to the quality of the line, and you should call Ascend Customer Support.

Inbound data is scrambled during an AIM Static call

Because an AIM Static call does not have a management channel, it is possible for data scrambling to occur because of WAN slips, a type of timing error. Slips are a very infrequent occurrence. If you encounter such problems, clear the call and redial.

Problems indicated in LEDs

LEDs are not lit for the secondary E1 or T1 line

If no LEDs relating to the secondary line are lit, the line is disabled in the Line profile. You can enable the secondary line by modifying the Line profile.

The E1 or T1 line is in a Red Alarm state

If the ALARM LED and the Line Status menu indicate that the line is in a Red Alarm state, the MAX cannot establish proper synchronization and frame alignment with the WAN. This behavior is normal for as long as 30 seconds when an PRI line is first plugged into the MAX.

If the Red Alarm condition persists for longer than 30 seconds:

  1. Check the value of the Framing Mode parameter in the Line profile.

    Change the value to the other available option and check to see whether the Red Alarm condition goes away within 30 seconds.

  2. If the Red Alarm state still persists, check the cabling.

    You might have a crossover cable installed when a straight-through cable is required, or vice versa. If the MAX is connected through bantam plugs, reverse the transmit and receive plugs. Then, allow the MAX to attempt to establish synchronization for an additional 30 seconds.

  3. You can eliminate the cabling as a possible cause by replacing the connection with a loopback plug. The LS LED should go off immediately, followed by the RA LED in about 30 seconds.

A PRI line is in use and the ALARM LED blinks

A blinking ALARM LED means that the physical configuration of the E1 or T1 line is correct, but that the D channel is not communicating with the WAN. To resolve this problem:

  1. Verify with your carrier representative that the D channel is channel 16 (E1) or 24 (T1).

  2. If the D channel number is correct, check the value of the Line Encoding parameter in the Line profile. When B8ZS encoding is in use, a non-inverted D channel is established. If AMI encoding is selected, an inverted D channel is established. Check the line translations provided by your carrier representative and set the line encoding to match the inversion requirements.

  3. Determine whether your WAN interface or the MAX T1 unit is equipped with a CSU.

    If the WAN interface or the MAX is not equipped with a CSU, the ALARM LED blinks. Check whether you have specified the proper Length or Buildout value in the Line profile.

  4. Check whether the D channel is in service.

    If no equipment has been plugged into the line for a short period of time (five to ten minutes), the D channel is taken out of service. You might need to contact your carrier to put the D channel back into service.

Problems accessing the WAN

Only some channels are dialed for AIM or BONDING calls

You may encounter a problem where whenever the MAX makes an AIM or BONDING call, it dials only some of the channels. To resolve this problem:

  1. Verify that there are enough channels enabled for switched services in the Line profile to meet the requirements of the Parallel Dial parameter in the System profile.

    Most WAN providers can place a limited number of calls simultaneously from a single E1 or T1 line. If more concurrent attempts are made than the WAN can support, the WAN applies a congestion tone-a fast busy signal.

  2. Try adding bandwidth once the call is up.

    If you can add bandwidth, the solution is to adjust the Parallel Dial parameter in the System profile. A value of 5 works for almost all WAN providers, while some support substantially more. If adding bandwidth does not work, the problem is most likely within the individual channel translations. In this case, call your carrier representative.

The MAX never uses some channels

To resolve this problem:

  1. If you are making AIM or BONDING calls, verify that the affected channels are enabled for switched services in the Line profile.

  2. If you have an E1 unit, check whether it has been connected recently to a device that does not support the full 31 channels. If so, the switch might take the unused channels out of service. This situation can arise on either the local or the remote end.

  3. If you have a T1 unit, check whether it has been connected recently to a device that does not support the full 23 channels. If so, the switch might take the unused channels out of service. This situation can arise on either the local or the remote end.

  4. Check whether the channels enabled in your Line profile correspond to the channels enabled in the circuit. If only some of the channels in the circuit are available for data calls, you must specifically enable those channels in your Line profile.

  5. If you place a call and some channels are always skipped, call your carrier representative.

An outgoing call using fails to connect to the remote end

If the T1 or E1 line is configured for inband singaling and outbound calls fail to connect:

  1. Make sure that your Line profile is properly configured for wink-start or idle-start.

    The Rob Ctl parameter in the Line profile determines which of these call-control mechanisms the MAX uses. Check with your carrier representative to find out which inband signaling your line supports.

  2. If the Line profile is configured correctly and you still cannot place an outgoing call, check the service state of the line.

    Frequently, if a T1 or E1 line has been unplugged for an extended duration, the switched services available on the line are taken out of service. Once you install the MAX, you might need to call your carrier representative to have the line reactivated. If this is the case, leave the MAX on all the time, even when you are not using it; otherwise, you will have to call your carrier to reactivate the line each time the unit is switched off and on.

  3. Ask your carrier representative whether the line is configured for DTMF dialing; the line must support this type of dialing in order to recognize digits being dialed.

Incoming call routing problems

Routing problems occur when a call is connected to the answering MAX but cannot be routed to one of its slots.

Call status drops back to IDLE

You may see a condition where after the Call Status window reports ANSWERING and HANDSHAKING, it drops back to IDLE. This condition might not indicate a problem. It can indicate that the call was initially answered and that when its routing was checked, the target AIM port was busy or disabled. Handshaking does not occur on calls to the MAX unit's internal router, but calls can initially be answered and then quickly cleared during normal operation, such as during the receipt of an incorrect password.

Dual-port call status drops back to IDLE

If when trying to make a dual-port call, the Call Status menu reports ANSWERING and HANDSHAKING, and then drops back to IDLE, check the status of both ports specified in the Dual Ports, Port 1/2 Dual, Port 3/4 Dual, or Port 5/6 Dual parameter of the answering MAX. If either port in the pair is busy, the call cannot be routed to that pair.

AIM or BONDING call status drops back to IDLE

If when trying to make an AIM or BONDING call, the Call Status window reports ANSWERING and HANDSHAKING, and then drops back to IDLE, check that the routing parameters are configured correctly. If the routing parameters are configured incorrectly, an AIM, BONDING, or AIM/DBA call might be routed to ports that cannot support these types of calls.

Bridge/router problems

The link is of uncertain quality

When running FTP (File Transfer Protocol), the data transfer rate appears in bytes per second. Multiply this rate times 8 to get the bits per second. For example, suppose that you are connected to Detroit on a 56-kbps B channel and that FTP indicates a 5.8 kbyte/s data rate; in this case, the link is running at 5.8x8=46.8 kbps, or approximately 83% efficiency. Many factors can affect efficiency, including the load on the FTP server, the round-trip delay, the overall traffic between endpoints, and the link quality.

You can check link quality in the WAN Stat status window, or by running a ping between the same endpoints. Dropped packets hurt the link's efficiency, as does round-trip delay. Random round-trip delay indicates heavy traffic, a condition that also drops the efficiency of the link.

The MAX hangs up after answering an IP call

To resolve this problem:

  1. If you are running PPP, check that you have entered the proper passwords.

  2. Check that Auth is set to PAP or CHAP.

  3. If you are routing IP over PPP, check that the calling device gives its IP address

    Some calling devices supply their names, but not their IP addresses. However, you can derive an IP address if the calling device is listed in a local Connection profile or on a RADIUS authentication server. Try enabling PAP or CHAP for the Recv Auth parameter so that the MAX matches the caller's name to the Station parameter in a Connection profile and gets the corresponding LAN Adrs.



Copyright © 1998, Ascend Communications, Inc. All rights reserved.