Fun fact: Hayes had a patent on the one-second pause before and after the “+++”, so if you had a cheaper modem that didn’t pay the patent or implement the requirement for the pause, seeing “+++ATH” in a TCP/IP packet or a text file you’re viewing on a BBS could disconnect you. https://twitter.com/gravislizard/status/1340757262588018688

Apparently Dennis Hayes’s company used to send out press releases with “+++ATH” embedded in them, to taunt their rivals. https://en.wikipedia.org/wiki/Hayes_command_set

Another fun fact is that most smartphones before about 2012 or so were using AT commands for all phone functions: calls, SMS, etc..

With the AT command interpreter in a cell modem, you usually never enter the “connected” mode that you would have to “+++” your way out of. There are a couple of ways that is avoided. For voice calls, you put a “;” after the “ATD” (not “ATDT” because GSM uses digital signaling).

The “;” at the end of ATD means you get the “OK” prompt immediately and then you (meaning the telephony subsystem on Android, iOS, BlackBerry, Sidekick, etc.) can monitor the call status changes either by polling or by enabling “unsolicited responses”, which arrive at any time.

All of the extended AT commands for telephony in the GSM/UMTS/LTE/5G world are described in 3GPP TS 27.007, except for the SMS stuff, which is in TS 27.005 (with additional specs for the character set encodings and other layers of the stack).

You also have data connectivity.

Today’s smartphones usually use some proprietary API, and Android has an abstraction layer around all the radio calls so that it doesn’t ever touch AT commands itself, but I think AT command interpreters are still used in tablets/laptops.

You can have multiple data connections.

There may be some new details in 5G, but for GSM all the way up to LTE, there’s an APN (Access Point Name) that connects you to a data network. It often looks like a DNS address, but it’s not looked up in DNS. https://en.wikipedia.org/wiki/Access_Point_Name

The Sidekick phones used a private APN.

You can’t really use a vintage Sidekick phone for data these days because the software is hardcoded to want to use a private APN to route to the Danger cloud, neither of which exist any more.

Todays phones may still use multiple APNs to get MMS content, or carrier provisioning.

Long story short, there’ll be an AT command (or equivalent) to connect and disconnect from the APN, and then once you’re connected, you may have to further authenticate yourself. In the LTE world, it’s all done in a VoIP style, but with a challenge-response using the SIM card.

The actual data packets will have to flow through a separate channel from the AT command/response channel, which can be done in a variety of different ways depending on whether the cell modem is connected via shared memory, high-speed serial, USB interface, etc..

In the really olden days (circa 2005), 3GPP defines a CMUX protocol (TS 27.010) that your modem may support to let you tunnel multiple serial connections, including flow control and other features, within a single serial connection, for your AT command and APN data convenience.

For further amusement, you might even see the PPP protocol used to actually negotiate the data connection once the APN has been “dialed up”, so to speak.

There’s a big difference between LTE and earlier (2G, 3G, 3.5G) standards designed for circuit-switched voice calls first.

With all the radio protocols prior to LTE, those AT commands are doing all sorts of complex things on the radio layer to set up and tear down circuits for voice calls, or to send SMS data, with Internet access bolted onto the side. With 4G/5G, it’s the reverse: packet data only.

With LTE and 5G, you establish your TCP/IP tunnel, set up your IMS connection to your carrier (IP Multimedia Subsystem), and then all of the telephony services are handled in an Internet style instead of something archaic that you should be glad your radio vendor hid from you.

For further insight into just how complex the *new* system is, check out the Wiki page for IMS: https://en.wikipedia.org/wiki/IP_Multimedia_Subsystem

It’s basically an extraordinarily complicated SIP stack, with features for roaming, “lawful intercept”, and other features that you may or may not want.

“Lawful intercept” is when the government gets a search warrant to spy on your communications, preventing traditional telephony services from ever providing true “end-to-end encryption” that can’t be decrypted by the carriers.

I think it’s a reason RCS hasn’t been more popular.

Rich Communication Services (RCS) is an initiative that’s been around since 2007, if you can believe that: https://en.wikipedia.org/wiki/Rich_Communication_Services

Google has made some attempts to support it in Android, while Apple doesn’t have any interest in it, and it’s confusing to configure and provision.

Since I’ve been working on Firefox code, I have to say that there’s not much reason to care about the mobile operators as more than an untrustworthy pipe for Internet data that you should be encrypting at all times so they don’t tamper with your headers. If you desire privacy.

The more interesting set of protocols to support, which are very similar to what the carriers did with VoLTE, but embedded completely in the Web paradigm is WebRTC: https://en.wikipedia.org/wiki/WebRTC 

It’s supported by Google, Apple, Microsoft, Mozilla, and others, for video & voice chat.

With WebRTC, anyone can build a soft phone that runs entirely in the browser and should offer reasonable latency and audio quality guarantees for voice and video calls. I will definitely be testing this feature on my Power Mac once I fix the pixel format and alpha blending bugs.

…once I fix the pixel format and alpha blending bugs *in Firefox*. Still waiting for the latest compile to finish. I suspect I may need to fix a few additional code paths in Skia and/or gfx/ycbcr.