Inspired by my previous post made merely an hour ago, I set to work seeing if I could acquire a recording of a K56flex dial-up modem connection before it is too late. After all, both X2 and K56flex are more “at risk” of extinction (if not already) compared to the ITU standards-ratified V.90/V.92. Sadly, while I had three Australian points-of-presence to dial into, only one persists today.
The K56flex Camp
If you haven’t read the previous posting about X2, it’s probably a good idea as it is quite relevant to this post as well. The K56flex camp was basically the only competition to X2, which launched almost simultaneously in February 1997. The K56flex camp was made of Rockwell (holding a large majority share of consumer chipsets) as well as Lucent and Motorola (who dropped out of the modem business soon afterwards). The standard itself served to cut USR’s hopes of becoming a de-facto standard for 56k modems and resulted in USR’s collaboration in coming together with the joint ITU V.90 standard, although not without some annoyances from the parties as to USR’s majority control.
Adoption of 56k modems were somewhat hampered by incompatible modulations – it seems that Rockwell chipsets dominated the low end of the market and by extension, K56flex was more widely adopted at the consumer end. However, when it came to ISPs in the USA, it seems that X2 had a firm lead, judging by “The Need For Speed And The Copper Wire” by Lisa A. Phifer in June 1997.
Very few user devices supported both standards –
However, in “Coordination vs. differentiation in a standards war: 56K modems“, a working paper by Angelique Augereau et.al in 2004 has the table below:
While only covering the early days, this particular table seems to suggest that while X2 enjoyed some early popularity, K56flex did take the upper hand only a few months later. It also acknowledges the general lack of industry data availability.
Of the protocols, K56flex was rather unique in having only speeds divisible by 2kbps, which include 32, 34, 36, 38, 40, 42, 44, 48, 50, 52, 54, 56kbit/s. Upstream remains V.34 and the system by which it works is the same as X2 in exploiting the digital nature of the server modems. If the speed limiting commands of certain K56flex modems are to be believed, a provision for 58 and 60kbit/s is also made.
The K56flex Handshake
In order to capture a K56flex handshake, I needed to identify a K56flex capable modem. For the most common Rockwell/Conexant chipsets, the AT+MS command is used to select modulations. Querying it for its settings with AT+MS=? should provide a list of supported values. Only modems which accept 56 or K56 claim to support K56flex. Many upgraded modems with smaller flash chips will only support 12 which is V.90, or may fail to negotiate flex despite accepting 56.
The particular modem I chose was my Netcomm Roadster II 56k Ultra SVD which supports both modes in its firmware. By forcing the unit to use modulation 56, I can ensure a K56flex connection is established.
ati3 V2.210-K56_2M_DLS OK ati4 NetComm RoadsterII 56 V.90 F02_V1.56 (C) NetComm Ltd. 1999 OK ati6 RCV56DPF L8570A Rev 47.32/47.32 OK at+ms=? (0,1,2,3,9,10,11,12,56,64,69),(0,1),(300-56000),(300-56000),(0,1),(0,1),(300-33600) OK at+ms? 56,1,34000,56000,1,0,33600
I tried calling my last remaining point of presence that can be reached on my Australian VSP and possibly the last actually operating. Using my Grandstream HT702 was fruitless, as a V.34 connection was always negotiated. Only when I moved back to my venerable Linksys PAP2T was I greeted with a glorious result – a pretty speedy K56flex connection.
Make no mistake – this is no V.34 connection. The sound of a K56flex connection is different. As with my convention, the digital modem is on the left channel, the analog calling modem is on the right. The standard ranging signals are used and scrambled data is sent right after, but the frequency and “scratchiness” of it is different. It sounds as if someone’s cutting in and out a few different high-pass filters. There’s no obvious digital impairment learning sequence as with V.90.
at&v1 TERMINATION REASON.......... LOCAL REQUEST LAST TX rate................ 28800 BPS HIGHEST TX rate............. 28800 BPS LAST RX rate................ 48000 BPS HIGHEST RX rate............. 48000 BPS PROTOCOL.................... LAPM COMPRESSION................. V42Bis Line QUALITY................ 025 Rx LEVEL.................... 013 Highest Rx State............ B3 Highest TX State............ 67 EQM Sum..................... 00BB RBS Pattern................. 00 Rate Drop................... 00 Digital Loss................ None Local Rtrn Count............ 00 Remote Rtrn Count........... 00 Flex 9481834246E0 OK at&v2 BEGINaa14ab14ac14ad14ba25bb25bc25bd25ca77cb67cc153da4ea0eb0fa110fb110fc110ga10gb4ha25hb21hc25hd0he9hf187hg0hh0hi0hj23hk21hl0hm255hn255ho255hp255hq255hr255hs255ia26ib26ic26ja0jb0jc0jd0je0ka0kb1kc0kd0ke0kf0kg0kh1ki38kj0kk2kl81km33kn255la103lb179lc103ld104ma0mb0mc6na2nb0oa0ob0oc0od18oe34of0og235pa1pb0qa0qb1qc255ra43rb148rc129rd131re66rf70rg224sa255sb255sc255END OK at#ud DIAG <2A4D3263 0=10> DIAG <2A4D3263 1=07> DIAG <2A4D3263 2=00> DIAG <2A4D3263 3=00> DIAG <2A4D3263 10=0D> DIAG <2A4D3263 11=0A> DIAG <2A4D3263 12=1A> DIAG <2A4D3263 20=81> DIAG <2A4D3263 21=81> DIAG <2A4D3263 22=0C80> DIAG <2A4D3263 23=1F40> DIAG <2A4D3263 24=0725> DIAG <2A4D3263 25=00> DIAG <2A4D3263 26=7080> DIAG <2A4D3263 27=BB80> DIAG <2A4D3263 30=00> DIAG <2A4D3263 31=00> DIAG <2A4D3263 32=00> DIAG <2A4D3263 33=00> DIAG <2A4D3263 34=7080> DIAG <2A4D3263 35=BB80> DIAG <2A4D3263 40=01> DIAG <2A4D3263 41=80> DIAG <2A4D3263 42=00> DIAG <2A4D3263 43=00> DIAG <2A4D3263 44=01> DIAG <2A4D3263 50=02> DIAG <2A4D3263 51=02> DIAG <2A4D3263 52=00000005> DIAG <2A4D3263 53=0000003F> DIAG <2A4D3263 54=0000> DIAG <2A4D3263 55=0000> DIAG <2A4D3263 56=00000003> DIAG <2A4D3263 57=00000004> DIAG <2A4D3263 58=0000> DIAG <2A4D3263 59=0000> DIAG <2A4D3263 60=51> OK
While the diagnostics available on the modem aren’t good enough to say clearly that it is a K56flex connection, it almost certainly is. For one, the connect rate is divisible by 2kbps. Secondly, there was no DIL sequence in the call – the modem defaults to V.90 and produces the two-tone crescendo as per my V.90 collection of sounds. Finally, the speed is above 33.6kbit/s, therefore cannot be V.34.
What is more surprising is that it was able to get a 48000/28800bps connection reliably on a VoIP connection terminated to my local VSP via LTE mobile broadband going through a triple-NAT. It’s a case of all the stars aligning to make it happen.
Conclusion
These pre-standards 56k modem technologies are a little more difficult to catch “in the wild” primarily because they were not that popular and because many of the modems were upgraded to later V.90 standard firmware which often removed support for older pre-standard modulation due to lack of flash memory storage. I remember having a pair of disks I could use to switch a Rockwell ACF modem between its K56flex and V.90 firmwares. Rather luckily, I was able to find a more “premium” modem with simultaneous dual-standard support and a point-of-presence that still supported the protocol. Count that as curiosity satisfied!
This might be a bit primitive, but I’d still like to challenge you to connect to a dialup provider via the standard means of PPP (possibly generating some traffic to their captive portal using a browser) while forcing the modem to use Bell 103 signalling and recording the audio.
It’s be pretty interesting to see how long would pages take to load at such a speed and also what do the modems actually communicate to each other in process.
That would be rather interesting but also rather difficult.
For one – in Australia, my list of over 160 dial-in access numbers have been whittled down to just one that still works from my VSP. The one that still works was never a public point-of-presence for internet access and instead was an intranet access server for a prepaid dial-up service belonging to a major telco that has long vanished. There were some fixed credentials to login to this server, but I’ve since lost them and don’t have any record to go on. There are still commercial dial-in providers, but the access numbers they use cannot be terminated from a VSP due to their special area code which makes it impossible to reach without a traditional land-line which I don’t have access to.
Bell 103 is outlawed in Australia, and indeed, its ITU relative V.21 is also frowned upon from memory due to the use of “solid” tones during idle periods resulting in potential audible cross-talk to adjacent lines. While it’s not as big of an issue today as it was back in the analog days, it’s definitely one consideration amongst many.
The other is that the size of webpages have grown and at the default MTU of 576 bytes for dial-up modems, could mean lengthy delays for retransmission as most modems operating in Bell 103/V.21 do so without any of the later benefits of V.42bis compression and error detection/correction (ARQ/SREJ) methods. A 300bps modem operating in a “pure” aynchronous serial mode would offer just 30-bytes (assuming 8N1) per second transfer rate, so a single fully laden MTU would take 19.2 seconds to traverse the link and probably time-out. That would be without any error correction, so just a click of line noise and we’d be screwing the whole MTU over. I suspect it’s not really possible to run PPP with the “default” settings on a link so slow – such slow links are normally used for terminal display output and even then, 30 bytes/second is about 6 words per second. A full 80×25 character “DOS” mode screen would take around 67 seconds to send.
Given that, taking the result of stuffing google.com into Pingdom’s Full Page Test tells me that the search page needs a whole 835.5kB to download with almost 39% being scripts and 33% being HTML. Even on a 48kbit/s link, that’s almost 140 seconds assuming no overheads or gains from compression. At 300bps, that would be 7.736 hours. Even ignoring the lack of error correction and the issue with MTU sizes, there’s absolutely no way, given that commercial ISPs all time out links at 6 hours, that it would happen. Nor would my VSP let that happen – they time out calls at 2 hours.
In fact, just having this thought experiment is probably enough. Actually doing it? I doubt it. Maybe if I run my own PPP server internally and dial-in to my own PPP server using my own VoIP PBX internally, then it could be tried … but it’s definitely not fast enough for anything useful.
Thanks for the thought experiment though.
– Gough