Modem over IP Problems and Solutions:
The Advent of V.150
The Modem over IP problem
Since the advent of widespread Voice over IP (VoIP) networks, the original data networking equipment, Voice Band Modems no longer have the reliability needed to perform their jobs. Unfortunately, there are surprisingly many industries and problem spaces where these data modems are still in use, and to replace them would impose an unacceptable cost. These areas include, but are far from limited to: utility meters, point of sale devices, elevators, secure communications, and remote radio and weather equipment. These modems are most difficult to replace when they are in hard to reach locations that require a technician to make the change, embedded in expensive equipment, or located where alternative methods such as cellular are not available.
The analog copper phone lines for which these systems were designed, known as the PSTN or POTS, have often been replaced, on one or both ends of the connection. If the new connection uses something like LTE voice, the modulation would then be passed over a speech coder (lossy compression / decompression) channel such as GSM-AMR or G.729, which would damage the modulation so that it would be unusable.
If these new connection used VoIP and ran over G.711, which is more likely for a fixed endpoint like a modem would typically be, things are a bit better. G.711, which comes in two different but very similar forms around the world – ulaw and alaw – to pass voice band modulations. In fact, the PSTN has used T1 and E1 Time Division Multiplexed (TDM) channels for many decades. The problem is not the same as it was with LTE voice, where the compression/decompression cycle damages the signals – but rather other issues are introduced that voice band modems were not designed to handle. The primary issues are jitter, packet loss, and clock skew but further problems can arise due to latency, or even abrupt changes in latency. A packet network can even possibly create duplicate packets, such that the same packet arrives twice at the receiver.
A packet network is not a constant clocked stream of bits like a TDM, but rather packets that are sent at an approximately constant rate. A TDM bus such as T1 is analogous to a train in that the relative timing of cars is constant, and all cars will take the same time, and travel in the same order going from point A to point B. No cars will be added or removed while the train is moving. A packet network is more like a highway, cars come and go, traffic gets faster and slower regularly and unpredictably, and the order of the cars can change. If 10 packages are put on 10 different cars of a train to ship somewhere, they will arrive in the same order they were when the train left. If 10 packages are put in 10 automobiles to ship them somewhere, they may arrive out of order, and not at very predictable times. Maybe a car even breaks down and doesn’t arrive, but the others still do.
Because of this difference, modems work well on a nearly perfect packet network, where all the packets are basically guaranteed to arrive, only once, in the order they were sent, and at very close to the rate they were sent. In the internals of a datacenter, in the primary network of the PSTN, or on the IP backbone – this is possible. Unfortunately, closer to the edges of the Internet – homes, businesses and places where equipment is deployed – this is rarely the case; even if it is the case every so often, it is likely not often enough. Packet loss will leave gaps in the audio that will break a demodulator. Jitter can cause packets to be discarded or skipped, because they will not be at the receiver at the right time. For voice, a jitter buffer – and specifically an adaptive jitter buffer with changing depth – can help this. But for a modulation, even a small number of samples lost can cause issues. There will be failed calls that are unexplained, even amongst some successful calls.
Additionally, even with no loss, duplication, or jitter – there will almost certainly be clock skew. Skew happens because the transmit end and the receive end of a connection have DAC and ADC conversions respectively, sampling the modem’s signal when converting between analog and digital. it is most common to sample at 8000 samples per second for this type of application, but unfortunately each endpoint samples based on its own internal clock. In TDM on the PSTN, they share a clock, but when they have their own clocks, they will run at slightly different rates and slowly drift apart like when two people count to 1000 in different rooms. They may start out seemingly synchronous, but they are very likely not going to be when they get to 1000. In the case of digitizing, the clocks are very accurate – maybe 50 or 100 parts per million accurate – but they will still drift. And eventually that drift will break a modulation. On an analog copper line – the transmitter sends analog signals, and the receiver tracks them using a phase locked loop (PLL), and so they actively synchronize to each other. With the analog to digital conversion for the packet network this cannot be done, as the data is already quantized, and most hardware would not have the ability to slow or speed the driving clock.
The MoIP Solution: V.150
So there needs to be a different method to connect these voice band modems across IP networks. This method is commonly called Modem over IP (MoIP), and while there are many ways that MoIP can be and is implemented, the specifications/standards most commonly intended when referring to MoIP, is ITU-T V.150.1 and related specs – usually referred to generally as V.150. V.150 was originally intended to implement two gateways that stand on each side of an IP network that split what would ideally be a single analog network.
Since then, V.150 has also been implemented directly in endpoints, essentially pulling a modem and a V.150 gateway into the endpoint so that it can be directly connected to an IP network and communicate through a far end V.150 gateway, to a voiceband data modem on an analog PSTN connection. One such case is the vIPer secure telephone, which is made to connect to other secure phones through the PSTN, but can use an internal V.150 to connect directly to the IP network and use a far end V.150 gateway to reconnect to the PTSN and the far end data modem.
The way a V.150 gateway works and gets around the limitations of data modems when running over IP, is that the V.150 gateway terminates the analog modulation on the PTSN side, and takes the data from that modulation, and transmits it in packets to the far end gateway, which then remodulates it and sends it over an analog connection to the far end data modem. In a dual gateway configuration there are actually 4 modems: two endpoints, and two gateways. The reason this works so much better is that the two endpoint modems each are connected over analog, as designed, to the two gateways and so those two independent modem connections do not go across IP, and therefore do not have the clock skew, packet loss and other issues that occur over IP networks. Only the user data the modems were transporting is sent over the IP link. It is almost always the case that this data has less stringent timing constraints on it, and often has retransmission logic – even two modems passing data over an analog connection could have data loss due to noise etc. So, when the data is packetized, and sent with possible redundancy, or retransmission mechanisms, or guaranteed delivery transports like TCP, the application will likely be able to deal with it. When passing modulated data over that same IP network – those solutions would cause the modulation to break, and thus the whole connection to fail.
VOCAL's V.150 MoIP Solutions
The V.150 MoIP solution works, and works well. Unfortunately, the VoIP and IP based service providers rarely implement V.150 – because few manufacturers have built equipment that supports it, and although there are a lot of important data modems in use, there are relatively few when compared with the total call volume of the phone networks. So there is little incentive to implement it. VOCAL has multiple solutions to help with this. We have AMA devices that allow modems to have a small V.150 gateway collocated with it, on premises. We also have V.150 to T1/E1 gateways that scale to multiple TDM spans. VOCAL also offers our SPRAG service, which puts a V.150 in the cloud, directly connected to the telephone network, so that endpoints like the vIPer phone can connect to our SPRAG service over an imperfect IP connection, and then the SPRAG V.150 gateway converts to analog modulation and connects over the PSTN to the far end (or back to another registered SPRAG client). VOCAL has other complimentary solutions, such as our SAMS server, which is a pure software modem bank that can replace modem banks that require T1/E1 connections with a drop-in pure IP solution. With these, along with related Fax modem offerings, VOCAL has solutions for every data modulation problem.