Configuring and Troubleshooting V.92 Modems

Introduction

This document provides information on how to configure and troubleshoot V.92 and V.44 dial-up modems.

Prerequisites

Requirements

There are no specific requirements for this document.

Components Used

This document is not restricted to specific software and hardware versions.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Background Information

Here are some of the main features of the V.92 and V.44:

• Modem On Hold: You can suspend a data call, answer an inbound telephone call, and then re-establish the data call without losing the connection. This feature allows a better integration of voice and modem calls that share one phone line. This feature also eliminates the need for a second line, and dramatically reduces the time required to resume the connectivity to Internet after a voice call. You must subscribe to call waiting from your local phone company, in order to use this feature. If you also want to initiate outgoing calls with modem on hold, you need to activate three-way calling on your phone line.

• Quick Connect: Quick Connect allows the client modem to remember the connection quality parameters of the previous call to the ISP, and shortens the train-up time. This feature then uses these parameters to connect quickly. In order to do so, Quick Connect skips the normal line probing sequence. The connection can be re-established significantly faster than with the previous high speed standards. The gain in train-up speed depends on local line conditions.

  Note: The first time you call, the modems still need to perform the complete line probing. All further calls can train-up with Quick Connect eventually.

• V.PCM-Upstream: With the new standard, modems can allow faster upstream communication with upload speeds that reach 48 Kbps (V.90 supports up to 33.6 Kbps upstream, although in real life the upper limit of 31.2 Kbps is more common). This feature allows a faster and smoother transmission of large e-mail messages, documents, spreadsheets, presentations, or photos. Currently Cisco Systems products do not support this feature. Modem ISDN Channel Aggregation (MICA) modems do not support Pulse Code Modulation (PCM) upstream. The plans for PCM upstream support in NextPort modems are not defined yet.

• V.44 Data compression Protocol: V.44 is a new link-layer compression standard from the ITU, based on technology developed by Hughes Network Systems. You can use V.44 in conjunction with V.92 for a faster data transfer rate. Although common belief is that V.44 can replace the current V.42bis compression technology, V.42bis will continue to be used. V.44 and V.42bis are both available on V.92 modems, but do not require a V.92 connection. V.44 works with V.90-speed and below connections, as long as you dial into a V.92 ISP. V.44 offers up to a 6:1 compression ratio, compared to the 4:1 maximum compression from V.42bis.

Frequently Asked Questions

This section contains frequently asked questions and their answers.

Q. Is the client overall connect time the same as the Quick Connect time?

A. No, Quick Connect only represents the modem dialup time. The overall connect time also takes into account the time for call setup within the phone network, and for PPP negotiation.

Q. How much time do I have if I choose to take an incoming call?

A. The Cisco access server defines the hold time through the S62 register. The default of this register is 0 (Modem-on-Hold [MOH] disabled).

Q. Which client modems support various Call Waiting Tones used in Africa, Asia and Europe?

A. Today, the modem manufacturer decides on which of the various call waiting (CW) tones in the modem firmware to support. Please check with your modem manufacturer in case the documentation of your client modem does not list your country.

Q. Where can I get an MOH software application?

A. Most modem manufacturers supply an MOH utility together with the modem driver. Check with your modem manufacturer for details. Cisco does not supply any MOH software for client modems. A frequently-delivered program is NetMeeting from BVRP.

Q. Why does the connect standard in show port operational-status (or show modem operational-status) appear as V.90 and not V.92?

A. V.92 is an extension of V.90 with three new features, but the syntax of V.90 in show port operational-status has been retained. If you see V.90, this does not mean that the functionality of V.92 is not available within the current call.

Q. Do I have to redial to get back to the Internet after I drop the incoming call?

A. No. When you hang up the voice call, you can continue to browse after the modems train up. This time the modems are likely to use Quick Connect (QC) to make the connection faster. Be aware that you need to let the modems resume their connection before the MOH timer expires (as defined by S62 parameter in MICA and NextPort).

Q. Do the Cisco 3600 and 3700 routers support V.92?

A. MICA digital modem modules for 3600 and 3700 routers support the V.92 functionality. For release numbers, refer to the Cisco Feature Navigator.

Q. Does V.92 portware code work with older IOS versions of code?

A. Portware 2.9.1.0 is only supported for use with V.92-capable Cisco IOS® software versions. However, portware versions 2.9.1.1, 2.9.2.0, and later are supported for use with non-V.92 IOS, but only if V.92 and V.44 are disabled. This table provides information on the firmware versions that are supported:

	IOS Image Type
Firmware Version	V.92 Capable IOS (12.2XA/XB, 12.2 (11)T and higher)	Non-V.92 Capable IOS (12.1, 12.2 and so on)
MICA 2.7.x.x	Not supported	Supported (V.92 is not possible)
MICA 2.9.x.x before 2.9.1.1	Supported (V.92 is possible)	Not supported
MICA 2.9.x.x from 2.9.1.1	Supported (V.92 is possible)	Supported (V.92/V.44 must be disabled)

Configure and Install V.92

Cisco has two different modem solutions: MICA and NextPort. Both of them support QC, MOH and V.44. PCM upstream will later be added for Nextport.

Q. What firmware do I need to support V.92?

A. The firmware is bundled with the Cisco IOS software code. The versions are Portware 2.9.x.x and NextPort code 0.7.11.

Q. What S-register do I need to set, and how do I apply this to a modem?

A. The S-register is shown here:

   S29 Modulation Standards
   0 = V.34+ Automode, with terbo
   1 = V.34+ Automode, no terbo
   2 = V.32 terbo Automode
   3 = V.32bis Automode
   4 = V.22bis Automode
   5 = K56 Flex
   6 = V.90 Automode
   7 = <reserved>
   8 = V.110 Automode
   9 = <reserved>
   10 = V.120
   11 = Clear Channel
   12 = V.92 Automode
   S62 V.92 Maximum MOH Time
   0 = MOH Disabled
   1 = 10 Seconds
   2 = 20 Seconds
   3 = 30 Seconds
   4 = 40 Seconds
   5 = 1 Minute
   6 = 2 Minutes
   7 = 3 Minutes
   8 = 4 Minutes
   9 = 6 Minutes
   10 = 8 Minutes
   11 = 12 Minutes
   12 = 16 Minutes
   13 = no limit

For more information, refer to V.92 Modem on Hold for Cisco AS5300 Universal Access Servers.

   S63 V.92 QC Exchange
   Bit 0: Quick Connect Enable
   0 = Diabled
   1 = Enabled
   Bit 1-2: ANSpcm Level
   00 = -9dBm
   01 = -12dBm
   10 = -15dBm
   11 = -18dBm
   S21 Data Compression
   0 = Disabled
   1 = V.42bis
   2 = MNP5
   4 = V.44 Tx
   8 = V.44 Rx

For more information, refer to V.44 LZJH Compression for Cisco AS5350 and Cisco AS5400 Universal Gateways and V.92 Quick Connect for Cisco AS5350 and Cisco AS5400 Universal Gateways.

For test purposes, you can try these modemcaps to make V.92 and V.44 work.

Note: These modemcap statements appear over multiple lines so that they are easy to read.

• Modemap for MICA (2.9.4.0) with V.92 MoH, QC and V.44 enabled:

  modemcap edit cisco misc
   &F&D2S54=16584S0=0S29=12S21=15S62=8S63=3S34=18000S40=10S10=50

  For modemcap recommendations, refer to Recommended Modemcaps for Internal Digital and Analog Modems on Cisco Access Servers.

• Modemcap for NextPort with V.92 MoH, QC and V.44 enabled:

  modemcap edit cisco misc
   &FS62=8S63=3S29=12S21=15

Apply the modem cap under the lines:

   line x/x/x
    exec-timeout 0
    no flush-at-activation
    modem InOut
    modem autoconfigure type cisco
    transport input all

Here are the activated V.92 and V.44 parameters:

S-Register	Description
S21=15	Enable V.44 Data compression default S-register value in MICA 2910 or NP 7.5/0.7.11.
S29=12	Enable V.92 (default S-register value in 2910 or 7.5/0.7.11).
S62=8	V.92 Modem On Hold Exchange set to 4 minutes, so you can allow the client 4 minutes to talk before the primary line disconnects.
S63=3	V.92 Quick Connect QC Exchange - ANSPCM - 12 dbm.

Debug V.92

This section lists some commands to troubleshoot V.92.

Use these debug and show commands to troubleshoot V.92 connections:

• debug modem csm—debugs the Call Switching Module (CSM) that connects calls on the modem. The no form of this command disables debugging output.

• debug modem—enables you to observe modem line activity on an access server. The no form of this command disables debugging output.

• debug spe firmware statistics—displays SPE modem statistics. (Nextport implementation on AS5350, AS5400 and AS5850).

• debug modem oob—debugs the out-of-band port that polls modem events on the modem in privileged EXEC mode. (MICA Implementation on AS5800). In order to disable debugging output, use the no form of this command.

• debug isdn q931, or debug cas (as appropriate)—debugs problems at ISDN Layer 3 in privileged EXEC mode, or provides real-time traces of the CAS signaling bit status.

• show modem operational-status x/x or show port operational-status x/x—displays the operational status of the modem or port, based on the command you use.

• show call calltracker x/x—displays information stored within the Call Tracker active database for all active calls, or the information stored within the Call Tracker history database table for the most recent historical calls, based on the command you use.

Troubleshoot QC

This section deals with commands that you can use to troubleshoot QC.

Configure these lines in order to troubleshoot QC:

service timestamps debug datetime msec  
service timestamps log  datetime msec

Enable these commands:

• debug csm modem or debug modem csm (based on your Cisco IOS software version and platform).

• debug spe firmware statistics

• debug modem oob

• debug modem

• debug isdn q931

QC works properly if:

• V.90 calls are functional. If not, refer to Configuring Client Modems to Work with Cisco Access Servers.

• The selection of the country type is correct.

• You see ranging short in the Content Switching Module (CSM) debugs.

• The average connect time for QC is 9 to 20 seconds (depending on line conditions).

• The calculated time between link and steady-state is 9 to 20 seconds.

QC does not work if:

• You do not get QC with different country types. Contact the modem vendor.

• You see ranging instead of ranging short.

Here is an example of a full range compared with a short range:

1. Check the time between Link Initiate and Steady state. In this example, for a full range call with No QC ~ 21 seconds, and for a short range call with QC, trainup takes around 12 seconds.

2. Enable the csm debugging command that is appropriate for your platform:

      17:06:07.679: Mica Modem(1/12): Link Initiate 
      17:06:08.771: Mica Modem(1/12): State Transition to Connect 
      17:06:08.787: Mica Modem(1/12): State Transition to V8bis Exchange 
      17:06:11.351: Mica Modem(1/12): State Transition to Quick Connect 
      17:06:12.931: Mica Modem(1/12): State Transition to Ranging 
      17:06:15.451: Mica Modem(1/12): State Transition to Half Duplex Train 
      17:06:21.335: Mica Modem(1/12): State Transition to Trainup 
      17:06:27.459: Mica Modem(1/12): State Transition to EC negotiating 
      17:06:27.879: Mica Modem(1/12): State Transition to Steady State
   

   You can see a QC train up with the state transition short range (in a regular V.90 train up, you see ranging instead of ranging short).

      17:20:46.207: Mica Modem(1/14): Link Initiate 
      17:20:47.295: Mica Modem(1/14): State Transition to Connect 
      17:20:47.311: Mica Modem(1/14): State Transition to V8bis Exchange 
      17:20:50.135: Mica Modem(1/14): State Transition to Quick Connect 
      17:20:51.695: Mica Modem(1/14): State Transition to Ranging Short 
      17:20:51.995: Mica Modem(1/14): State Transition to Half Duplex Train 
      17:20:54.695: Mica Modem(1/14): State Transition to Trainup 
      17:20:58.359: Mica Modem(1/14): State Transition to EC Negotiating 
      17:20:58.839: Mica Modem(1/14): State Transition to Steady State

   You can also troubleshoot QC through calltracker with the show call calltracker x/x command.

   Note: Call Tracker is currently available only on the AS5xxx series platforms.

      Router#show call calltracker active 
      -------------------------- call handle= 458 --------------------------
      status=Active, service=PPP, origin=Answer, category=Modem
      DS0 slot/port/ds1/chan=0/0/0/26, called=xxxxx, calling=xxxxx
      protocol: last=LAP-M, attempted=LAP-M
      compression: last=V.44-Both, attempted= V.42bis-RX V.42bis-TX
      standard: last=V.90, attempted=V.21, initial=V.90
   
      v90: status=Success, client=Unknown, failure=None
   
      rx/tx: max neg I frame=256/256, neg window=15/15
      v44 size: dictionary=2048, rx/tx string=255/255
      qc exchange: QC Short Train Success
      moh status: Modem is Not on Hold
      moh count: 0, moh request count: 0
      total moh time: 0, cur moh time: 0
      call waiting retrains: 0
      rx/tx codewords: 2048/2048, rx/tx string: 255/255
      rx/tx history size: 6144/6144
      encoder/decoder state: 0/0
      rx/tx compression ratio: 313/154, rx/tx dictionary reset count: 0/0
      diagnostic code: 0x0000000000000000

Troubleshoot MOH

This section outlines the requirements, and possible issues that relate to MOH.

Requirements

• Activate call waiting type CID II.

• Select the correct country type.

• Caller ID is not mandatory, but works better with some MOH applets.

Possible Line Problems

If you have activated call waiting, but the client modem does not pick up the incoming call, you need to make an outgoing call with a regular handset, and get somebody dial your number. If you do not hear the call-waiting tone with the regular handset, please check the line with your Telco.

Modem Issues Related to Lack of CW Tone Support

If you hear the call-waiting tone, and the modem does not pick up the call, call the modem vendor for an updated code, because the CW tone at that stage is not supported. Another side affect is that the client modem can wrongly interpret the CW tone.

Here is an example where we see a Q.931 disconnect when the client modem comes out of hold state. This example is a switch-related issue.

   17:15:33.395: Mica Modem(1/13): State Transition to Modem On Hold
   17:16:44.779: Mica Modem(1/13): State Transition to Steady QC
   17:16:53.243: Mica Modem(1/13): State Transition to Steady State
   17:17:14.495: Mica Modem(1/13): State Transition to Steady State Speedshifting
   17:17:16.599: Mica Modem(1/13): State Transition to Steady State
   17:18:01.503: Mica Modem(1/13): State Transition to Steady State Retraining
   17:18:02.043: Mica Modem(1/13): State Transition to Modem On Hold
   17:18:27.183: ISDN Se0:15: RX <- DISCONNECT pd = 8 callref = 0x476B
   17:18:27.183: Cause i = 0x81FF - Interworking error; unspecified
   17:18:27.187: %ISDN-6-DISCONNECT: Interface Serial0:3 disconnected from
   unknown , call lasted 667 seconds

Here is another example of a client modem disconnect: The client gives up, and drops the first line to accept the incoming call. This is a client modem problem.

   17:22:02.834: Mica Modem(1/14): State Transition to Modem On Hold
   17:22:10.226: ISDN Se0:15: RX <- DISCONNECT pd = 8 callref = 0x4BE8
   17:22:10.226: Cause i = 0x8190 - Normal call clearing
   17:22:10.226: %ISDN-6-DISCONNECT: Interface Serial0:4 disconnected 
   from unknown, call lasted 84 seconds.

Troubleshoot V.44

This section contains some frequently asked questions that relate to V.44.

Q. How do I know if V.44 negotiation is complete?

A. The show port operational-status x/x command shows you whether V.44 negotiation is complete.

Q. What is the relationship between the ftp download speed and the DC TX RX compression ratio in show port operational-status? Does it map?

A. In order to obtain an answer to this question, look at this example:

This example involves the download of a binary file at a speed of 18.7 KBps. The show port operational-status x/x DC TX RX compression ratio displays 3.48:1/2.57:1. The correlation between 18.7 KBps and 3.48:1/2.57:1 is not obvious.

The modem counter keeps track of up to 4,194,304 bytes, then resets. The ratios are calculated between the numbers of bytes of decompressed and compressed data that the V.44 code processes. Based on the other details, given the compression ratio in the downstream direction 3.48, file size 50'000 B, and a link rate of 43.989 Kbps, you can calculate the correlation as:

(50'000 bytes * 8 bits/byte) / (3.48 * 43'989 bps) = 2.61 s

and

50'000 B / 2.61 s = 19'200 Bps (or 18.7 KBps, when you assume that 1 KB = 1024 B)

However, consider these two additional factors:

• Protocol overhead (V42, PPP, TCP and IP) and delays.

• Compression speed. If the modem processor compresses slower than the link rate, a bottleneck occurs, and the overall performance degrades.

These two factors make the correlation difficult to calculate. The aggregate compression ratio is just one aspect of the download speed. The upstream compression ratio has limited impact on the downstream performace, because it transmits only TCK acknowledgements (if the application uses TCP).

The compression ratios do not apply if no data traverses the network. Congested network nodes can adversely impact the data transfer rate, but the compression ratio remains the same, as if there is no congestion. When there is congestion, the server also experiences underruns more often, but this is just the result of a bigger problem. A slow client PC can affect the download data rate. In this case, the compression ratio can be even better, because the processor of the server modem can flush compression less often (a flush occurs in an underrun situation).

Use the show port operational-status x/x command, and check these parameters:

Connect Standard                : 52000/28800 
Connect Protocol                : LAP-M 
Compression                     : V.44 
Call Timer                      : 140 secs 
Link Signal Quality             : 7 
Total MOH Time                  : 0 secs 
Current MOH Time                : 0 secs 
MOH Status                      : Modem is Not on Hold 
MOH Count                       : 0 
MOH Request Count               : 0 
Retrains due to Call Waiting    : 0 
DC Encoder,Decoder State        : compressed/compressed 
DC TX,RX Compression Ratio      : 1.85:1/3.47:1 
DC TX,RX Dictionary Reset Count : 0/0

Related Information

• Access Technology Support Pages
• Technical Support & Documentation - Cisco Systems