This document provides information on how to configure and troubleshoot V.92 and V.44 dial-up modems.
There are no specific requirements for this document.
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.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
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.
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 22.214.171.124 is only supported for use with V.92-capable Cisco IOS® software versions. However, portware versions 126.96.36.199, 188.8.131.52, 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 184.108.40.206
|| Supported (V.92 is possible)
|| Not supported
| MICA 2.9.x.x from 220.127.116.11
|| Supported (V.92 is possible)
|| Supported (V.92/V.44 must be disabled)
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.
Apply the modem cap under the lines:
modem autoconfigure type cisco
transport input all
Here are the activated V.92 and V.44 parameters:
|| Enable V.44 Data compression default S-register value in MICA 2910 or NP 7.5/0.7.11.
|| Enable V.92 (default S-register value in 2910 or 7.5/0.7.11).
|| 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.
|| V.92 Quick Connect QC Exchange - ANSPCM - 12 dbm.
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.
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:
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:
Here is an example of a full range compared with a short range:
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.
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
This section outlines the requirements, and possible issues that relate to MOH.
Activate call waiting type CID II.
Select the correct country type.
Caller ID is not mandatory, but works better with some MOH applets.
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.
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.
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
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