by SteveF, April 5, 2026
Modem technology originated in the 1950s and was among the earliest communication technologies for connecting computers. In 1958, AT&T released the Bell 103 modem, which achieved a transmission rate of 300 bps, paving the way for data transmission over the PSTN network and enabling remote computer communications for the first time.
In the 1960s–1980s, modem technology rapidly became widespread in commercial and industrial applications. At that time, computers were all equipped with RS232 serial ports—just as today’s computers are all equipped with WiFi. The DTE/DCE interface and the standard AT command set were also standardized during this period. Even today, we still refer to networked devices that use 4G/5G technology as cellular modems, and these devices continue to rely on the AT command set.
Today’s young people can hardly imagine that, 30 years ago, people mainly accessed the internet through a device called a “modem” (as shown in the image above). With the internet boom of the 1990s, modem speeds rapidly increased—from early rates of 9.6 Kbps and 14.4 Kbps to 33.6 Kbps (the V.34 standard), eventually evolving to the theoretical limit of 56 Kbps over analog lines (the V.90/V.92 standards).
56 Kbps represents the theoretical limit of PCM lines, but this rate clearly falls short of meeting the demands of Internet development. Consequently, as we entered the year 2000, modems were quickly replaced by xDSL and subsequently by PON technology. Today, the mainstream wired internet technology is Giga PON, and it is currently evolving toward 10G PON.
However, the application of modem technology extends far beyond just internet connectivity. Even before the advent of the internet age, modems were already widely used in various scenarios requiring remote communication—for example, cash register POS systems, SCADA applications, alarm panels, or the remote programming of emergency phones. These applications remain prevalent today as well.
1. Challenges Posed to Modem Applications by PSTN Switch Of
The PSTN is a clock-synchronized network. Although the PSTN network may experience transmission errors due to environmental interference (such as lightning strikes), it has only a very small, fixed latency and no jitter. In contrast, IP networks are characterized by asynchrony; jitter on the order of tens or even hundreds of milliseconds is quite common, and communication interruptions lasting several seconds can even occur.
Modem protocols are highly dependent on the synchronization features of the PSTN network. As an example, let’s take the SIA FSK Format F2, which is a Bell 103-like modem protocol.
As shown in the figure above, the SIA FSK Format F2 requires recognition of the Start Bit and then proceeds to receive 8 data bits at a baud rate of 42.7. This protocol can tolerate a certain amount of jitter, but clearly, the maximum jitter duration must not exceed 23.42 ms (1000 ms / 42.7); otherwise, data recognition will become “misaligned,” leading to communication errors.
The SIA FSK Format F2 is a very slow-speed modem communication protocol. Although it also uses FSK, its baud rate is only 42.7, significantly lower than the 300 bps defined by Bell103. Even so, SIA FSK Format F2 can tolerate jitter of only 23.42 ms—a requirement that is clearly too stringent for IP networks. This is precisely why most UC platforms designed for voice communications cannot directly support modem communications.
2. ITU’s standards for developing Modem Over IP solutions
《ITU V.152 Procedures for Supporting Voice-Band Data over IP Networks》aims to provide a generic transmission method for Voice Band Data (VBD) based on G.711. It defines a basic approach for the automatic recognition of voice codecs such as G.729 and for switching between Voice and VBD modes. At the same time, V.152 also specifies an Assure VBD mode that supports RED and FEC.
As for the Non-assure VBD mode defined in V.152, it generally cannot function either due to the aforementioned sensitivity of modem communication to jitter. On the other hand, the Assure VBD mode performs exceptionally well in environments where jitter is not severe. Unfortunately, however, most UC platforms do not directly support RED or FEC.
When jitter is significant, V.152 also experiences a substantial increase in failure rates. In such cases, it becomes necessary to use another standard defined by the ITU—V.150.
The main content of the V.150 specification is defined in “V.150.1 Modem-over-IP networks: Procedures for the end-to-end connection of V-series DCEs,” which defines a relay communication model.
V.150.1 also defines the SPRT (Simple Packet Relay Transport) protocol, which implements reliable transmission based on UDP. V.150.1 addresses the issue of modem transmission relay by decoding the modem protocol on the gateway device (e.g., Flyingvoice’s PR12 or PR18) and converting it into IP packets, which are then transmitted via the SPRT protocol to the called party (typically another gateway device that also supports V.150.1) and reconverted back into modem signals. Since the modem protocol is decoded locally into IP packets, the effects of IP network jitter are naturally avoided, enabling reliable modem transmission.
3. How does Flyingvoice POTS Replacement help MSPs build a reliable modem communication platform?
MSPs can leverage Flyingvoice’s POTS Media SBC to enable the V.152 Assure VBD mode, or they can directly deploy Flyingvoice POTS terminals at both ends and use the V.150 protocol to implement Modem Relay Transport.
3.1. Implement V.152 Assure VBD mode using Flyingvoice Media SBC
As shown in the figure above, the Flyingvoice POTS Media SBC is a cloud server deployed on AWS. It is responsible for converting data in V.152 Assure Mode—where the RED/FEC method is enabled—into standard G.711 data and forwarding it to the UC platform already deployed by the MSP. Without needing to make any modifications to the existing network, the MSP can leverage the Flyingvoice POTS device to provide reliable modem transmission services.
V.152 + SBC mode is suitable for scenarios with relatively good network conditions. According to Flyingvoice Lab’s assessment, the end-to-end total latency (fixed delay + jitter) of such a network generally needs to be less than 300 ms, and the packet loss rate should be below 3%.
3.2. Deploy Flyingvoice POTS devices at both ends to achieve a direct V.150 connection.
For installation locations with poor network conditions—such as those experiencing frequent jitter exceeding 500 ms, packet loss rates greater than 5%, or frequent network outages—the V.150 protocol is a better choice.
However, this requires that both CPEs support V.150. Although Flyingvoice does not mandate that both ends must use Flyingvoice devices, for ease of management and maintenance, we recommend using Flyingvoice POTS devices (such as PR12 or PR18) at both ends .
4. Summary
In the U.S. today, modems are still widely used in legacy devices such as alarm panels, emergency phones (elevators and blue boxes), inbound programming, SCADA systems, point-of-sale terminals, and more. With the impending shutdown of the PSTN, communication issues with these devices urgently need to be addressed.
MSP can leverage Flyingvoice’s CPE devices (such as PR12 and PR18) and POTS Media SBCs to quickly integrate with their existing UC platforms and provide customers with reliable modem transmission services.
Back to list
