Information Technology Reference
In-Depth Information
Modem Trainup
A successful trainup is indicated by the receiving modem raising DSR. Trainup failures can indicate a
circuit problem or modem incompatibility.
If you really want to get to the bottom of an individual modem problem, you'll want to get your hands
to the AT prompt at the originating modem, while it's attached to the POTS line of interest. If you're
calling into a digital modem in a Cisco access server, be prepared to record a .wav file of the trainup
“music,” or Digital Impairment Learning (DIL) sequence. The DIL is the musical score (PCM sequence)
that the originating V.90 analog modem tells the receiving digital modem to play back. The sequence
allows the analog modem to discern any digital impairment in the circuit (such as multiple D/A
conversions, a-law/u-law, robbed bits, and digital pads). If you don't hear the DIL, the modems did not
negotiate V.90 in V.8/V.8bis (that is, a modem compatibility issue has arisen). If you
do
hear the DIL,
but then you hear a retrain in V.34, the analog modem has decided, on the basis of the DIL playback, that
V.90 was infeasible.
Does the music have noise in it? If so, then clean up the circuit.
Does the client give up quickly, without running V.34 training? Perhaps it doesn't know what to do when
it hears V.8bis. Try disabling V.8bis (hence, 56K flex) on the server (if acceptable), getting new client
firmware, or swapping out the client modem. Alternately, the dialing end could insert five commas at the
end of the dial string. This delays the calling modem's listening and causes the V.8bis tone from the
receiving server to time out without affecting the client modem. Five commas in the dial string is a
ballpark estimate, though, so you might need to adjust this to allow for local conditions.
Session Establishment
At this point in the sequence, the modems are connected and trained up. Now it's time to find out whether
any traffic is coming across properly.
If the line receiving the call is configured with
autoselect ppp
and the async interface is configured with
async mode interactive
, use the command
debug modem
to verify the autoselect process. As traffic
comes in over the async link, the access server examines the traffic to determine whether the traffic is
character-based or packet-based. Depending on the determination, the access server then either starts a
PPP session or goes no farther than having an exec session on the line.
This is a normal autoselect sequence with inbound PPP LCP packets:
*Mar 1 21:34:56.958: TTY1: DSR came up
*Mar 1 21:34:56.962: tty1: Modem: IDLE->READY
*Mar 1 21:34:56.970: TTY1: EXEC creation
*Mar 1 21:34:56.978: TTY1: set timer type 10, 30 seconds
*Mar 1 21:34:59.722: TTY1: Autoselect(2) sample 7E Note 1
*Mar 1 21:34:59.726: TTY1: Autoselect(2) sample 7EFF
*Mar 1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D
*Mar 1 21:34:59.730: TTY1: Autoselect(2) sample 7EFF7D23
*Mar 1 21:34:59.734: TTY1 Autoselect cmd: ppp negotiate Note 2
*Mar 1 21:34:59.746: TTY1: EXEC creation
*Mar 1 21:34:59.746: TTY1: create timer type 1, 600 seconds
*Mar 1 21:34:59.794: TTY1: destroy timer type 1 (OK)
*Mar 1 21:34:59.794: TTY1: destroy timer type 0
*Mar 1 21:35:01.798: %LINK-3-UPDOWN: Interface Async1, changed state to up Note 3
Note 1
: The inbound traffic is displayed in hexadecimal format, based on the bits coming in over the
line, regardless of whether the bits are ASCII characters or elements of a packet. The bits represented in
this example are correct for an LCP packet. Anything different would be either a malformed packet or
character traffic.
