After my posting of the definitive collection of V.90 modem sounds, a number of people got in touch with me with a few of them requesting the same to be done with V.34 connections. At first, I didn’t see the point, as I had some samples of V.34 connects scattered in my legacy page, and to me, they don’t have anywhere near as much character and distinction as the V.90 handshake. They all just sound the same.
That was, until one very observant reader pointed out to me that they don’t. After seeing for myself and confirming that was the case, I couldn’t help but examine this for myself.
The Signal in Question
While the V.34 protocol is standardized by the ITU-T, just like V.90, this does not mean that the handshaking sequences are necessarily fixed. In the case of V.34, the signal in question is termed MD for “Manufacturer Defined”.
Both answer and originating modems have the option to use an MD sequence of their choosing, provided they’ve noted this in the INFO sequence. The purpose of it is for better echo canceller training, especially where a chipset manufacturer may wish to implement their own algorithms which may work better with different signals from the standard TRN sequence.
The length of this signal is limited since the total time from beginning of MD to end of TRN must not exceed two round-trip times + 2000ms. As a result, it’s not going to realistically be more than 2 seconds of difference in a handshake for each modem. As V.90 calls made before use V.34 in the upstream direction, if the modem has an MD sequence, it is likely also heard on the V.90 calls.
Methodology
Seeing as it might well be heard on V.90 calls, why did I bother doing this whole investigation? Well, one thought was that it would be nice to get some pure V.34 action going using local back-to-back VoIP SIP ATAs as the lines, and secondly, to placate the readers who absolutely demand V.34 action.
As a result, I used my trusty Linksys PAP2T with my Asterisk server set to copy media. Interception of the call occured through a network bridge where Wireshark recorded packets and reconstructed calls. With the optimum line gain tuning based on previous experiments and minimal jitter buffer, a round-trip delay of 170ms was consistently achieved.
Calling modems were varied, however, the answering modem was always a Netcomm Roadster II 56k USB (Conexant-chipset, hardware modem). It was configured with ATS0=1 as to auto-answer calls, and ATS30=1 to auto-terminate calls after 10 seconds of idle connection to produce a controlled calling environment. By having this set-up, multiple calls could be attempted with no cost incurred, in a network that simulated an analog-to-analog via DAC/ADC situation similar to using a real phone line. Connect rates of 31.2kbit/s both ways were regularly achievable under this condition.
Results
The Families
By excerpting just the S-to-J sequences, three different families can be identified. The first family is the Conexant Software modems (HSF and HSFi) which form the top two traces with practically identical timing. The Conexant Software Modem sequence sounds like this. Note the databurst followed by regular training.
The second family of signals belongs to the Intel/Ambient chipset modems, which are the middle two traces (one from an Intel HaM, the other from a Swann Speed Demon). The Intel/Ambient Chipset sequence sounds like this. Note the rough blipping noise followed by the training sequence.
The final family of signals represents a regular V.34 connection with no MD sequence. This example comes from the Agere (Lucent) Win Modem (1648C and HV90 DSPs). The standard V.34 sequence sounds like this. Note the lack of a second “blip” S-sequence within the noise.
Sadly, no other variants were detected within my farm of modems (note the spectrograms above), however, there are a variety of answer-modems used by ISPs which may well have different results. I also didn’t manage to find my SmartLink modem, thus I am not sure, but likely it is the “same” as the others.
Due to the allowed variation in the length of the TRN signal, some modems send it for longer than others. Other variation is also expected, as these real calls result in different carrier frequency and symbol rate combinations, resulting in a different time necessary to send the same number of TRN symbols.
All Samples
While it’s a bit of a downer to see so little variation, since the calls were made, I might as well post the samples here. Naming convention is normally make-model-originating modem download rate-originating modem upload rate. The recordings are stereo, with left channel being originating modem and right channel being answer modem.
3Com (TI) Chipsets
- 3com-messagemodem-31200-31200
- 3com-promessagemodem-28800-31200
- 3com-sportsterflash-28800-28800
- 3com-mpcie-28800-31200
Rockwell Conexant Hardware Chipsets
- conexant-rh56sp-33600-33600
- netcomm-roadsteriiser-31200-31200
- ktx-33600fm-24000-24000
- maestro-woomera-28800-33600
- spirit-336l-31200-33600
- banksia-wavesp336-33600-33600
- dynalink-v1456vqe-31200-31200
Conexant Software Chipsets
Agere/Lucent Win Modem Chipset
Motorola Chipset
Ambient/Intel Chipset
Others/Unknown
Things to look out for – different carrier frequencies which can make a certain handshake sound “brighter” or higher toned than normal. More noticeable across distinctly different speeds/brands. An unusual INFO sequence on the KTX “no brand” modem which seems to repeat very rapidly. The success/failure of V.8/V.8bis negotiation at the beginning – some modems don’t have it, others do.
Bonus Handshakes
Because I didn’t have the Xircom Creditcard LAN + Modem and a working laptop to use it with before, I didn’t have a chance to record its V.90 handshake until now. It seems to be a variant of the old Lucent Win Modem DIL – xircom-creditcardlan-v90.
Someone wanted some V.32bis 14.4k action, so I took out my Banksia MyModem 144, and made a connection with it – banksia-mymodem144-14400-14400. Note the restricted bandwidth used by TCM.
I also had the chance to witness possible compatibility/timing issues with certain modems, especially the Motorola SM56, resulting in retrain death-spirals – motorola-sm56-problematic1 and motorola-sm56-problematic2. In both instances, the call fails due to the 60 second connection timer expiring on the answer modem, resulting in a call hang-up.
Conclusion
On the one hand, running an analog back-to-back style call at home with an ATA and a software SIP PBX proved viable and reliable enough to perform these experiments with. On the other hand, after scouring through my piles of modems, it’s sad to see that there are only two MD sequences observed within the fleet, one of which I was made aware of by a reader. At least it’s been done – so now I can sleep soundly.
Bonus – ATA Differences
At the beginning of the investigation, I wanted to perform the testing using the Grandstream HT802 which I received for review. Unfortunately, running the latest firmware, I encountered V.8/V.8bis timeouts and strange behaviour. When testing with the ATI11 command on the LT Win Modem, the reason became apparent –
Description Status --------------- ------------ Last Connection V.34 Initial Transmit Carrier Rate 31200 Initial Receive Carrier Rate 31200 Final Transmit Carrier Rate 31200 Final Receive Carrier Rate 31200 Protocol Negotiation Result LAPM Data Compression Result V42bis Estimated Noise Level 27 Receive Signal Power Level (-dBm) 32 Transmit Signal Power Level (-dBm) 9 Round Trip Delay (msec) 460 Press any key to continue; ESC to quit. Description Status --------------- ------------ Near Echo Level (-dBm) 24 Far Echo Level (-dBm) 66 Transmit Frame Count 0 Transmit Frame Error Count 0 Receive Frame Count 0 Receive Frame Error Count 0 Retrain by Local Modem 0 Retrain by Remote Modem 1 Call Termination Cause 0 Robbed-Bit Signaling NA Digital Loss (dB) NA Remote Server ID NA OK
It seems that for some reason, the round trip latency is above 400ms even though everything is local and the jitter buffer is set to fixed/minimum. It may well be a firmware limitation or design issue, but the HT802 does have superior frequency response and was my first pick. After seeing what my venerable (and now discontinued) PAP2T could do … there was no option.
Description Status --------------- ------------ Last Connection V.34 Initial Transmit Carrier Rate 31200 Initial Receive Carrier Rate 31200 Final Transmit Carrier Rate 31200 Final Receive Carrier Rate 31200 Protocol Negotiation Result LAPM Data Compression Result V42bis Estimated Noise Level 24 Receive Signal Power Level (-dBm) 30 Transmit Signal Power Level (-dBm) 9 Round Trip Delay (msec) 170 Press any key to continue; ESC to quit. Description Status --------------- ------------ Near Echo Level (-dBm) 22 Far Echo Level (-dBm) 64 Transmit Frame Count 0 Transmit Frame Error Count 0 Receive Frame Count 0 Receive Frame Error Count 0 Retrain by Local Modem 0 Retrain by Remote Modem 1 Call Termination Cause 0 Robbed-Bit Signaling NA Digital Loss (dB) NA Remote Server ID NA OK
Even 170ms RTT was a little higher than I expected, but reasonable enough. Real PSTN operation to a local POP often had only about 7ms. The reason boils down to codec packetization (10ms chunks minimum, as I set, commonly larger), jitter buffering (40ms or so is common minimum) at the ATA, at the PBX set to copy media, PBX processing and network traversal time. I can only do my best, I suppose, or go the non-SIP route using a loop current simulator but then result in poorer recording quality without separation of each modem.