Project: THE DEFINITIVE COLLECTION of V.90/V.92 Modem Sounds

Just recently, there was a surge in traffic to my old legacy dial-up sounds pages. While I did my best with the equipment I had at the time to capture the sound of dial-up modems, I always knew that my job was only half done. As we approach the consumer POTS-line apocalypse, and ISP upon ISP are starting to disable their modem banks, the V.90/V.92 handshake sound is seriously under threat. Anything from V.34bis and down is still safe, since having modems “back to back” will allow for this type of connection to occur, but since V.90/V.92 are digital modulations on the downstream, the digital modems are rare, expensive and require special digital (ISDN or better) connectivity to function. There’s no way most home users can afford to have them. As a result, in this post, I finish the job I started (before it’s too late) to present the definitive collection of V.90/V.92 modem sounds at a quality never previously presented before.

A Two-Paragraph Introduction to Modem History

Early modems used simple modulations involving FSK/PSK modulations and separate carrier frequencies for receive and transmit. When that became spectrally impractical, interim protocols featuring “turn-around” which were half-duplex and various non-standard optimizations started to appear (e.g. Trailblazer, USRobotics HST, Hayes Ping-Pong/Express96). Over time, developments were made which increased the data rate by using more sophisticated Trellis-code modulation, and full-echo cancelling to allow for the full voice-band frequency to be used in both ways simultaneously. This increased the complexity of the modems, which also increased their handshaking times due to the requirement for training, a process whereby the modems assess the qualities of the phone line and set optimal parameters to maximise the transmission rate within a given set of line conditions.

A good introduction to the various sounds of dial-up modems was done in a relatively viral image by Oona Räisänen on her blog, reproduced here under CC:

dialup-final

This image, however, depicts a V.34-type connection, as it has no high speed sound.

The High Speed Sound

This is not the correct technical term for it, but it’s a term which I’ve heard amongst my less technically proficient group of friends. They realized that by listening to the modem’s handshake, there was a particular sound towards the end of the handshake which signalled a high speed connection. They were right.

This sound is of the Digital Impairment Learning (DIL) sequence. This is only applicable for V.90/V.92 connections, as V.34-type (analog, up to 33.6k) connections do not have it. If you heard this “sound”, you would be fairly certain that you were attempting a V.90 (up to 56k) connection.

For those who want a headache, they can go and try to digest the ITU-T’s V.90 recommendation here, specifically the section about DIL (8.4.1) and the section about Signal Ja (8.3.1).

While the document is technical, I will try to explain the concept in a progressively more difficult way. Basically, the standard dictates that the analog modem (customer side) sends a Ja sequence which tells the digital modem (ISP side) what signals to generate for the DIL segment and send back. This allows the analog modem to understand the line parameters better – namely, is there robbed bit signalling (i.e. where one-bit of every six 8-bit frames, or more in case of multiple RBS links, is altered by the signalling equipment), or are there digital pads (i.e. a DSP algorithm based scaler which reduces the maximum level on the phone line). This allows for the modem to adapt and compensate for these impairments.

The signal itself is rather complicated in specifications, consisting of up to 255 segments, 8 codes per segment, with the length in 6-symbol blocks determined by the associated H-value. Further to this, the specifications also define a sign-pattern and training-pattern, which are up to 128 bits long, and specify whether a symbol transmitted is a training symbol or a reference symbol, and whether the symbol has positive amplitude or negative amplitude. This sequence is repeated completely until it is aborted by the analog modem, or the sending modem times out. Further to this, throughout the DIL procedure, the analog modem is also permitted to send scrambled data (SCR), but is not required to do so.

Because of this analog modem defined nature of the DIL signal (i.e. the high speed sound), different modem manufacturers were at liberty to use a different DIL training pattern optimized for their algorithms. This resulted in a case where people would notice that my modem didn’t quite sound like that recording!

As to why this flexibility is in the V.90 standard (and not found in earlier standards) may have to do with the compromise nature of V.90 which came about to end the war between K56flex and X2 by producing an incompatible but similar modulation that modems from both camps could be upgraded to. This flexibility may have been necessary to appease both parties and reduce the engineering effort required to redesign their digital impairment learning algorithms, but that’s just a hunch.

Methodology

In order to capture the best quality handshakes, I had to resort to a necessary evil of VoIP. While generally not optimized for data, I was careful to configure the transmit/receive amplitudes, disable echo cancellation, reduce packetization to 10ms increments, use G.711a codec, disable fax pass-through detections and lock the jitter buffer at its minimum value of 30ms. This made it much more suitable. I terminated my test calls through the Linksys/Sipura PAP2T ATA to a local VSP which has digital terminations I know are capable of returning the exact digital codes and permit a V.90 connection, which is very difficult. Additional V.92 testing was performed using an overseas VSP termination, as local V.92 modem banks that were reachable through VoIP terminations were not known.

The VoIP ATA was connected through a Ethernet bridge where all the packets in both directions were collected and reconstructed into call audio using Wireshark (as PCM 16-bit samples, rather than the native a-law 8-bits). This allowed me to separate digital and analog modems into separate channels. Some echo is heard due to impedance mismatches at the analog end, which is expected behaviour.

This method is much better than recording the audio output from the modem’s speaker jack (as I did previously) as it eliminates power supply and digital hash noise from the recordings, and allows for separation of the two ends of the call. It’s also obviously miles better than recording the audio using a microphone, as the tinny piezo buzzers on many internal modems do a pretty bad rendition of the actual call audio.

Of course, getting the drivers and getting the modems installed was not necessarily trivial especially with some of the less popular and less supported winmodems. This required computers spanning Windows 7 x64, down to Windows 98SE to ensure the functionality of the collection of modems.

The Samples

This is the section you’ve all been waiting for. In this section, we will look at the actual recorded sounds. Before we begin, here’s a few things to look out for (spectrograms generated with Spek):

handshake-differences

Some modems perform the V.8bis and escape to V.8 at the beginning of the call, with some of them getting the timings wrong and mucking that up. Others don’t bother at all, and just respond only to V.8, which is possibly slightly faster. Some modems send a guard tone with the data sequences before and after the line probing signal, while others do not, resulting in a slightly brighter sound. The DIL sequences vary between the chipsets, but some have scrambled data being sent back and others do not – so keep an ear out for that as well.

V.90 Handshakes

These will be presented, grouped by chipset. Click on the link text for the audio. Waveform images shown, with green indicating analog modem, and blue indicating digital modem. If you would like to hear just the DILs cut-together into one audio file, here it is. It probably makes an ideal nerdy ringtone, for those who still use a ringtone.

Rockwell/Conexant HCF/ACF/ACF2 Modems

Conexant-HCF-[smooth-crescendo]Rockwell/Conexant were the most popular chipset as they were relatively low cost solid performers. These could be found in various brands of external and early internal modems. The sound that these produce is arguably the most typical V.90 sound that most people remember, having a smooth crescendo as the DIL. It does not perform V.8bis.

Rockwell/Conexant ACF2 Modems

Netcomm-RoadsterIIUltraSVD-[two-tone-cres]By all means, this was not the case with all ACF2 modems, but my Netcomm Roadster II 56k UltraSVD (AM5690) and Roadster II USB (AM5050R3) both make this two toned crescendo, which might easily be mistaken for the first. It also has some difficulty during the INFO sequence which causes it to be prolonged. It performs V.8bis.

Conexant HSF/HSFi Modems

Conexant-HSFi-[stuttering-crescendo]These were fairly popular internal soft modems and instead use a stuttering crescendo rather than a smooth one. It seems to get the V.8bis timing wrong, and misses the first capabilities request message consistently, which may be a driver bug.

 

Lucent Technologies WinModem (later known as Agere)

Agere-Mars1648C-[bipbipbipbip]Arguably one of the best softmodems I have used, and one that had kept me online for almost half of my dial-up career. This one uses a “bipping” noise with scrambled data sent during DIL. No V.8bis negotiation takes place. This used the Netcomm IN5699_5 with the latest V8.36 driver, although many products used the 1648C chipset, the last hardware-DSP based generation.

Lucent Technologies WinModem (later known as Agere)

Agere-Mars-HV90-[bipbipbipbip]This one was recorded using the 1646 HV90 chipset modem running (deliberately) V5.44 driver under Windows 98SE (the things I go to for this). This validated the observation made by Richard Gamburg of Modemsite of DIL changes. The differences can be seen in the tone pattern and scrambled data during the DIL.

Agere Softmodem (later known as LSI)

Agere-Venus-SV92PP-[echo-blip]A relatively unrelated cousin of the LT winmodem, also went through a name change due to a series of acquisitions. It is seen that this modem does not do V.8bis negotiation and does not send scrambled data during the DIL, with a DIL that sounds like an echoing blip. The Broadcom modems also sound identical.

Texas Instruments DSP based Modems

USR-Sportster-[bong-bong]This particular chipset was considered a premium chipset and was part of most of USRobotics’ extremely reliable range of modems, such as the Sportster Flash, Courier, Message Modem etc. I also found the same chipset in an Aztech EM6800U/A and the same line frequency diagnostic command also works (ATY11). The DIL is known affectionately as the “bong”.

Ambient Technologies (later Intel) Modems

Swann-SpeedDemon-[crackly-buzz]This chipset was found in the Swann Speed Demon as well as the Amigo Intel Host-Accelerated Modem. This one makes a crackly buzzing noise, which on tinny piezo speakers, is hard to distinguish from the regular noise of scrambled data. The modem also does not participate in V.8bis negotiations. Not very commonly encountered.

Motorola Hardware/External Modems

Acer-AcermodemSurf56-[laserbeam]This sample was recorded from an Acer Acermodem Surf 56, the only Motorola hardware external modem I have come across. The modem has a very particular DIL sound which I have dubbed the laserbeam and has the honour of being the shortest DIL sequence recorded.

Motorola SM56 Softmodem

Motorola-SM56-[laserbeam]The SM56 soft-modem, while also a Motorola chipset, differs from their hardware chipsets in the pace of the DIL. For their soft modems, the DIL sequence is slower and more prolonged. A subtle, but noteworthy difference.

ESS Teledrive

ESS-Teledrive-[stuttering-bip]A relatively uncommon, low cost soft-modem which had some good opinions from time to time. I’ve never used it, however, its DIL is distinctive with a staccato bipping that makes it sound like someone’s having a seizure or something. It was nice to hear this one as I had never heard this one prior to this investigation.

Smartlink/Modio Softmodem

Smartlink-SL2800-[smooth-crescendo]This modem was an SL2800 modem, but it sounds practically identical to every Smartlink/Modio product I have used. At a time, these were quite popular as a softmodem driver for AMR/CNR based modems in cheaper computers and laptops, and they worked with many integrated audio chipsets. Their crescendo is easily mistaken for a Rockwell/Conexant but is slower.

V.92 Handshakes

V.92 was the last dial-up modem standard, and bought along with it features such as quick connect which at least, in theory claimed to reduce handshaking times by remembering line performance parameters, support for call-waiting modem-on-hold to suspend and resume data connections (although this was rarely allowed by ISPs), PCM upstream for increased upload rates up to 48k at the cost of limiting downstream rate to 48k as well (again, rarely used). It was accompanied by V.44, an improved data compression standard, which was commonly used to improve throughput.

In the course of testing, I also made calls overseas, terminating via a u-law gateway in the USA to their V.92 modem banks. The increased latency makes the connection both difficult, and prolonged, with the handshake signals almost artificially prolonged to lengths not often heard. However, this gave me a chance to capture the quick-connect behaviour of the V.92 capable modems that did successfully exhibit quick connect within the 10-30 test calls I made per modem.

Agere Softmodem Normal V.92 Connect

Agere Softmodem Normal V.92 ConnectThere’s nothing too flashy about this one, and it doesn’t differ very much to the V.90 connection reported earlier with the exception of increased latency and the ulaw/alaw conversion or mismatch. Regardless, the arrangement was sufficient to demonstrate V.92 connection in normal mode.

Agere Softmodem Quick V.92 Connect

Agere Softmodem Quick V.92 ConnectThis is where things get interesting. The quick connect recognizes V.92 upfront and skips the line probing sequence entirely. The DIL is still used, but an accelerated version of it is used. This is the first time I have exhibited the one modem using two different DIL sequences. The connect is indeed quicker by a few seconds, although its robustness may be affected.

USR Message Modem Normal V.92 Connect

USR-Message-V92NC-[bong-bong-bong]Because of the latency, the DIL has “looped” around resulting in two-and-a-half bongs in the DIL segment. Normally, hearing four bongs indicates a time-out of the DIL and a retrain occurs, but in this case, the connection is successful as V.92 and the extra partial bong is due to latency of the “abort sending DIL” command.

USR Message Modem Quick V.92 Connect

USR-Message-V92QC-[bong-bong-bong]Again, the line-probing sequence is skipped in the quick connect, as V.92 capabilities are quickly identified, but the DIL in this case remains the normal regular DIL as this modem only has the one DIL sequence.

 

 

Motorola SM56 Softmodem Normal V.92 Connect

Motorola SM56 Softmodem Normal V.92 ConnectIn the case of the Motorola, the increased latency of the trans-pacific connection gives us an unusual glimpse into its extended DIL sequence. In the case of the USR above, its termination was merely delayed by latency, but in the Motorola, it was delayed more than just by latency revealing more of the DIL which is not normally heard.

Motorola SM56 Softmodem Quick V.92 Connect

Motorola-SM56-V92QC-extDIL[laserbeam]The extended DIL is also used on the quick connect with the high latency, but the line probing phase was skipped. I suspect there may be different levels of quick connect, but achieving the fastest quick connect, especially under VoIP conditions where the impairments are different to POTS, is rather difficult.

Conclusion

A lot of calls were made, and some ISPs were probably annoyed. Variations on the V.90/V.92 handshake were examined, with differences in V.8bis negotiation, guard tone, DIL, scrambled data and INFO sequence length shown. It seems that certain chipsets (e.g. Rockwell/Conexant) have a habit of not sending scrambled data during DIL, whereas some others do.

With this posting, I think I am ready to farewell V.90 and V.92, and I think I won’t be too sad when the last V.90/V.92 modem banks are turned off and unplugged from the network for good. I’ll always be able to hear the comforting high-speed sound, and remember the various chipsets who were part of making internet connectivity faster and more affordable to the world.

While I wasn’t able to test every variation of V.90/V.92 chipset, the DILs recorded cover every chipset I know of (as most vendors use the same DIL for their whole family of chipsets), possibly with the exception of the IC-Plus/Topic chipset which I haven’t seen for sale or encountered personally.

I hope this post is enjoyed by those who enjoyed my legacy pages, and I hope it goes some way to helping you find your dial-up modem sound.

About lui_gough

I'm a bit of a nut for electronics, computing, photography, radio, satellite and other technical hobbies. Click for more about me!
This entry was posted in Audio, Computing, Tech Flashback, Telecommunications and tagged , , , . Bookmark the permalink.

22 Responses to Project: THE DEFINITIVE COLLECTION of V.90/V.92 Modem Sounds

  1. Mark says:

    Nice work. I had no idea the old dialup modem was so complicated.
    Mark

  2. yuhong says:

    I think you should do Trumpet Winsock next. This should include version 1.0, 2.0 (first version with PPP support), 2.1 (first timelocked version), 3.0 (an attempt at Win95 support), …. This should also include Trumpet vs OzEmail lawsuits, and http://thanksfortrumpetwinsock.com/

  3. yuhong says:

    I wonder if VoIP can be used to simulate a digital modem answering V.90/V.92 connections.

    • lui_gough says:

      In theory, you can implement a digital modem that way, namely that your answering modem has its samples encapsulated into RTP instead of as digital (ISDN/DS*) signals. In fact, if you have a digital answer bank, and you connect it to a ISDN/DS* card of some sort that’s Asterisk capable, it may well be possible to have your own digital modem bank.

      Unfortunately, as the V.90/V.92 standard is quite complex, especially in regards to training and echo cancellation, that even though you have “soft” V.90/V.92 originating modems (all those nasty PCI cards), there isn’t any VoIP-native software that will do such standards or even V.34 for that matter. V.17 (14.4k fax) does have several VoIP-native alternatives, namely t38modem and Digium Fax for Asterisk to name a few, which leverages both T.38 and “regular” audio passthrough methods. Unfortunately, because of a lack of market, I suspect a VoIP V.90/V.92 answer modem will never eventuate – also because VoIP is horrid at transporting such signals for long periods/over longer internet paths.

      – Gough

  4. Chris says:

    This is so cool 🙂 But I cannot find the sound that I distinctly remember. My memory starts out like the contextant, and then instead of “white noise” there are more rapidly changing tones. I suspect that you recorded links at the max negotiable speed, and my memories are of hardware that is capable of faster speed, but negotiating to a lower speed? Anyways, still pretty cool.

  5. Excellent resource! I’m building a hobbyist project which involves mimicking a modem connection. These sounds will really add authenticity. Thank you!

  6. Phil says:

    This is really awesome. I would love to see this done for X2 and K56flex, but finding a compatible termination point would be a real challenge. Same for Telebit PEP.

    • L. Capitan says:

      And v.32terbo! 🙂 That was quite a cool sound. I remember calling certain BBSes just to hear the connect sequence.

  7. mubd1234 says:

    This is great! Hearing the modem noises with the outgoing/incoming channels separated into their own stereo channels puts a whole new dimension on things.

    I remember the computer I used as a kid (a Toshiba laptop) made a noise like a machine gun going off during the DIL sequence, and I’ve been looking for it ever since. It’s not on here but listening to all the variations are very interesting.

  8. Bob says:

    What’s the one that made the sonar sound at the end?

  9. Alo alp says:

    I have a cisco spa122 ATA. I am unable to dial anything that starts with 019. I get a busy signal immediately. Any fix?

    • lui_gough says:

      Does it give a busy tone mid-dialling? If so, could be dial-plan. Perhaps change it to (xxx.) which means 3 or more digits for a number.

      Lots of VoIP providers do not terminate calls to 01xxxxxxxx at all, so you could well be getting a busy because your VSP is refusing to terminate to those numbers. Also check if the number is active – many older ISPs using Telstra’s modem banks have been turned off and their numbers are no longer active.

      – Gough

      • alo alp says:

        im using the active dialup numbers. i can hear the dialup tone on mobile but the ata gives a busy signal once i enter 019

        • lui_gough says:

          Then the number is active, but your ATA dial plan may not be allowing the number through. For 10 digits, you could replace your dial plan with (xxxxxxxxxx) which will accept 10 numbers only then put out the SIP INVITE request, or as I suggested, something like (x.) or (xxx.) if you can dial really quickly (like a modem does).

          Best to have a Wireshark trace of the data going into the ATA as well, because your VSP may not be terminating the number correctly and giving you a reply of 4xx or 5xx.

          – Gough

          • alo alp says:

            ill try that when i go home this evning.

            Got another question relating to dial-up, to create a 33.6k DIY dial-in connection, that is as easy as connecting 2 modems together with line volatge and a way to ring one of them. but to make a 56k diy dial-in server, digital modems are required. i found a cisco router and the digital modem that attches to the router. it outputs to T1 line. problem is what happens next? were does the T1 line go and what equipment do i need to convert the t1 to analogue?

          • lui_gough says:

            Your digital modem expects to be plugged into a digital line, so that’s what you’ll need. Perhaps consider plugging the T1 line into a T1 line interface on an Asterisk server and then accepting SIP connections from ATAs as a way of connecting analog FXS lines to it, although not ideal because there will be a fair amount of jitter buffering and packetization delays involved.

            Perhaps you might need to buy some more equipment – maybe something like a second interface on the asterisk server that produces an FXS interface so you can basically route the call directly through the PBX or perhaps another interface that you might have the equipment to convert to an FXS interface – e.g. perhaps ISDN/BRI although I’ve never tried.

            Good luck with your endeavours.

            – Gough

          • alo alp says:

            ive tried the the various dial plans. i am using the (x.) as it works the best but this time, i dont get busy signal anymore, i get a voice sayng i dialed the wrong number.

          • lui_gough says:

            Check with your VSP about the number format they expect – perhaps they need a full IDD+Country+Area+Number for out of area calling. However, I suspect they just can’t terminate calls to those numbers.

            I’ve not used a single VoIP provider that can call 0198xxxxxx numbers at all, some of them return busy, unavailable, etc. This is one reason why I was very concerned about the loss of access to digital modems for these kinds of experiments. This is why you’ll have to find a non-01-virtual-area-code number if you’d like to hear your own V.90/92 handshake. There are not many remaining.

            Otherwise, dialling overseas is a possibility but the likelihood of a V.90 handshake is even lower in part due to latency/packet loss but also due to the potential for a codec mismatch (i.e. USA uses G.711u, rest of world uses G.711a “in general”).

            – Gough

          • alo alp says:

            Cant get the 01xx… numbers to work so ill just pass by. The 56K dial-in server i am planing to make is going to be used in a private system, in other words, the dial-in server goes straight to a computer and not to VOIP or landline, exactly like connecting 2 modems together for PPP conection. Ill use the ATA to ring the server. I currently dont have the parts to make the 56k dial-in server but when i figure out what items i need, ill order them. ive done alot of research but despite being new into this i kind of have an idea on how this might work. the connection starts from the router with the digi modem. it sends the signal out using T2. A second router takes the T1 and interfaces it to a ISDN/BRI network module card, producing the FXS signal. is that right? i probaly got something very wrong as i have no experience with this equipment.

          • lui_gough says:

            To be honest, you’ll need to consult with an expert as frankly, while I have some idea of how it might look, I’ve never had the chance to own or play with the equipment. But basically you have a digital modem with a digital line – you need to interface an analog line to “eventually” for the client modem. How you make the transition is really up to you – it could be via an Asterisk PBX machine you set up with a T1 interface card on one end, and an FXS capable card on the other, bridging the calls together. Or you could possibly have a different interface, say ISDN-BRI and use some external equipment that takes ISDN and creates an FXS port or two out of it. Telecomms gear can be configured in a bewildering array of topologies – you’ll need to see what is available to you and what you really want.
            I mean, it is possible to interface the analog modem to the FXS port of a consumer grade ATA and have it go over SIP to Asterisk with a T1 card to the digital modem – but I can’t guarantee this would work too well especially for longer connections due to the asynchronous nature of SIP. In fact, I’m not sure how accurate the sample clocks would be on “prosumer” gear such as the interfaces you might get for an Asterisk box. Desynchronization leads to burst errors and potential retrains/disconnections, so best to be avoided if at all possible.

            While your dial-in server is for your own intranet – you’ll need to think about how you provide the inbound phone trunks to this digital modem bank. That’s probably where you might get stuck in some ways as the world is very much VoIP now unless you can get an T1/ISDN/etc digital trunk line from your Telco.

            – Gough

          • alo alp says:

            ive been doing alot more research into making my own 56K dial-in server. I found 4 seperate cisco parts that can be asembled together to make the server and it is the cisco router, ISDN BRI interface card, digital modem card and the ethernet card. when asembled and programed, this allows a client to connect directly to the router using an analogue connection with real 56K v.92 speeds. i said in the past that i found a router with a digital modem that outputs T1. ive passed by this innitial config and the recent configuration eliminates the T1 interface and makes it ALOT easier to set up the server. i found the parts for very cheap, but i am in the process of saving up to get this amazing equipment.

          • lui_gough says:

            Well, if you’re thinking what I’m thinking, then perhaps something like a Cisco 36xx/38xx with a digital modem module and an analog FXS module? Not being familiar with the gear, while I would like to build one of my own, I don’t think I can justify the investment as yet.

            – Gough

Error: Comment is Missing!