Dial-up over VoIP service ISP

Annotation: Telecommunications laboratory (telco lab) is the next step in the old hardware collection’s further usage and analysis. About 10+ various [mainly U.S.Robotics (USR) branded] voice 56kbit (fax)modems for dial-up Internet connection had been collected. This article gives a Prove of Concept (PoC) to the modem-modem link establishment over the VoIP RTP stream with aim to build a dial-in ISP service. Various VoIP technology’s underlying parameters, and modem configurations had been tuned with batch dial-up connection testing being executed, and then commented. Tests were performed with the usage of remote SIP operator’s circuit, and local PBX SIP circuit.

ŠARA, Kryštof. “Dial-up over VoIP service ISP.” Krusty’s Space, Jan 14, 2024, https://krusty.space/projects/dialup_over_voip.

introduction

This article gives a verbose introduction to the dial-up modem-related paradigm, its problems, and practical usage. Next section provides used hardware and software configuration settings examples. Various modem’s outputs are present and commented there too. In the end, a batch modem-to-modem connection testing is executed while numerous parameters being tuned and scraped. Basic GNU/Linux shell knowledge is required as well as some understanding of the VoIP technology.

The main inspiration source could be seen in the Doge Microsystems blog post [4] about making the dial-up/dial-in ISP (Internet Service Provider) over VoIP (Voice over IP).

interconnection idea

For faxmodem feasible operation, a working telephone circuit/loop is required side by side with a compatible serial port having terminal. PSTN (Public Switched Telephone Network) is being emulated using (mainly) software PBXs (Private Branch eXchange) supporting SIP (Session Initiation Protocol) and VoIP RTP (Real-time Transport Protocol) packet flow. For the classic telephone cables (RJ11 6P2C/6P4C) being used by modems, an independent VoIP SIP hardware gateway with analogue FXS (Foreign eXchange Station) ports for POTS (Plain Old Telephone System) devices is deployed too in the networking. [2] [3]

The target dial-in server consists of:

• a software PBX (local circuit),
• a PPP (Point-to-Point Protocol) link daemon with PAP authentication,
• an IPTables-powered GNU/Linux kernel packet router/forwarder.

The server is connected to the Internet (upstream ISP) using a basic coaxial cable modem CPE (Customer Premises Equipment). A voice faxmodem pool for multiple concurrent client dials is connected to the server using serial-to-USB adapters and cables.

As the basic telephone call bandwidth (0,3–3,4 kHz) is used, the supporting VoIP RTP stream has to be established and stable for the whole time. This stream (with its signalling too) is carried (mostly) between the VoIP SIP gateway and some SIP server as a normal IP Internet traffic. [2] [46]

As soon as the telephone circuit is ready for a reqular voice call, the faxmodems are ready for the dialing. The server’s modem(s) acts like an answering modem, the client’s modem is used as a dialing modem. During the initial part of the call, modems are analyzing the call quality, interchanging supported protocols, and negotiating possible connection speeds. When a handshake by modems is made, a PAP authentication takes place. After a successful access to the server, a PPP link is established. This link is then used for various diagnostic tests described further. Also, this link can be used by a customer/client to access the Internet.

Simplified interconnection schemes are shown and commented in Figg. 1 and 2 (see more below).

remote provider circuit

In the first case, the SIP server is located at the remote operator/provider’s network with the corresponding remote PBX. A client (and client’s modem) uses PSTN and POTS socket to dial the dial-in server’s modem.

Fig. 1: Hardware and software lab parts interconnection scheme showing the local labolatory setup, local and remote SIP servers/PBXs used by the lab’s VoIP gateway, and a client (terminal workstation) connected to the server’s modem via PSTN and remote telephone company SIP trunk — Odorik.cz VoIP operator providing the public telephone number for the server’s dial-in modem.

local lab circuit

In the second case, the SIP server is located locally, as a part of the dial-in server software equipment. Thus the labolatory’s VoIP SIP gateway is connected directly to the dial-in server’s SIP service. The client’s modem uses FXS port of the same VoIP SIP gateway.

Note: the client’s modem using the same VoIP SIP gateway model can be used for dialing using the remote SIP server too.

Fig. 2: Hardware and software lab parts interconnection scheme using local SIP Asterisk service (shared VoIP gateway providing FXS ports for the server’s and client’s modems).

link media stack

As already described and shown, many hardware and software technologies are used for the actual labolatory interconnetion. Table 1 sorts used technologies according to the ISO/OSI layers stack model.

Tab. 1: Used medium, protocols and technologies as ’layers’ according to the ISO/OSI stack. [3]

Fig. 3 is to model the underlying technologies stack used for the supporting SIP session and RTP stream (upstream ISP backbone and telephone operator’s backbone), modem-to-modem handshake (drawn as arrows) and established PPP link with TCP/IP implementation.

Fig. 3: Network media stack with ISP and PSTN telecom company backbone model (bottom), and modem-to-modem-established PPP link and further TCP/IP implementation (top).

hardware and software

In this section, used hardware and software parts are to be described in more detail. Some personal notes/commentaries are present too. Those come from the practical experiences with the devices, and are shown in italics.

modems

• USR 56K Faxmodem (type TBR21 External, ID 24-5631-00, model 5631A) as dial-in server (also as client) modem
  • options: V32bis (V.32B), V.80, V.34+, V.90, V.92
  • data sheet

Seems to be the most reliable modem series owned (according to tests). Mostly used for testing.

• USR Courier V.Everything 56K Voice Faxmodem (type Czech/Slovakia External) as dial-in server, and client modem
  • options: HST, V.32B, V.34+, x2
  • data sheet

Modem has troubles making a PPP link (sends gibberish data after the analogue handshake). Electrolytic capacitors have been changed/soldered in, but the troubles are still present.

• USR 56K Voice Faxmodem (type Czech External, model ID 18-5663-00) as client modem
  • options: V32bis, V.34+, x2, V.90

Typical USR modem in the CZ/SK region, in my honest opinion. Advertised more than other series/brands. Has to be hard restarted (power off/on) quite often when batch testing. Sometimes it has troubles going off hook after a just-ended dial.

• Microcom DeskPorte Pocket (type Czech External, version 3.02) as client modem
  • options: V.90, V.34, V.32bis, MNP5, V.42bis [7]

Tiny blue external modem, reproductors are failable, thus the negotiation(s) are tough to follow. Has a DB9 serial interface as the only modem used.

VoIP gateway

• Well ATA172 plus as VoIP SIP gateway
  • data sheet

dial-in server

• Raspberry Pi 4B 8 GB RAM as dial-in server, network access server (NAS)
• Raspbian GNU/Linux 11 (bullseye) as server OS
• asterisk (16.28.0~dfsg-0+deb11u1) as NAS software PBX
• mgetty (1.2.1-1.1) as server modem controller
• pppd (version 2.4.9) as PPP link daemon

client

• terminal workstation aka client
• Fedora GNU/Linux 34 as client OS
• wvdial (1.61-26) as client dialer software
• screen (4.08.00 GNU)
• iperf3 (3.9) as link performance evaluation tool
• wireshark (3.6.2) as frame/packet analysis tool

DTE, DCE and interface transmission speeds

The main system components regarding local loop include [9] [40]:

• DTE – Data Termination (Terminal) Equipment – computer, terminal,
• interface cable [e.g. RS232 (DB25, DB9) modem cable],
• DCE – Data Circuit-terminating (Communication) Equipment – modem + RJ11 cable.

Fig. 4: DTE and DCE depiction. RS232 plugs being drawn as modem’s model interface cable. [9]

In relation to those components mentioned above, two important speeds are present [9] [40]:

• DTE–DCE (DTE, computer–modem) speed – set by mgetty, wvdial and screen commands/tools,
• DCE–DCE (DCE, modem–modem) speed – to be negotiated between two modems during the dial.

For 56 Kbps bitrate to be achieveable, it is vital for both modem-ends (especially for the dial-in server) to support V.90/V.92 ITU-T recommendations. In case of multiple analogue-to-digital signal conversions in the path of modems, the bitrate defaults to V.34 (33.6 Kbps) or lower speeds. On poor line quality, “a bad line” experience could be present, resulting in slow DCE–DCE speeds. The serial port speed (DTE speed) has to be equal or higher than the expected maximum bitrate. [1] [10] [11] [12]

Furthermore, it is better to completely disable V.90/V.92 standards for modem calls over VoIP. Enabling T.38 standard for faxing service is also recommended (direct data pass-through) as it should increase the line’s quality. It should be better to carry RTP call stream directly between peers, rather than using RTP proxy over the top. Using G.711 (A-law/mu-law) is preferred as non-compressing VoIP codec. Also, stable and of-very-good-quality internet connection is needed (sensitivity to QoS problem) for the RTP stream integrity. Due to PSTN/GSTN call multiplexing, another analogue-to-digital process is present in the way (may possibly lead to lower speeds). [31] [32] [33] [34]

Note: Speed of 33,6 Kbps is achievable on direct telephone line connection using a nullmodem cable. For modem to dial, one has to disable dial tone recognition/checking by ATX0 (ignore all tones) command. Server’s mgetty.conf has to be reconfigured to use direct yes (direct line, on nullmodem cable, see #server-nas-configuration). Any telephone number can be used for the direct call. [38]

modem indicators and signal controllers

Common modem’s hardware usually provides an user with a simple LED diode indicators bar describing its operational status. Those indicators are labeled by their meaning as abbreaviations — see Tab. 2. Front diode panel examples can be seen in Figg. 5–8.

Tab. 2: Shortcuts and their meanings (have been read off used faxmodems’ plastic covers).

Fig. 5: USR 56K Voice Faxmodem (5663 series) diode indicators (active connection).

Fig. 6: USR Courier V.Everything front panel with indiators (powered off).

Fig. 7: Microcom DeskPorte Pocket faxmodem (powered off)

Fig. 8: USR 56K Faxmodem (5631 series) with dial-in Network Access Server (NAS); active connection.

signal controllers

The diode indicators above are controlled by signal(s) being set between the hardware modem, and a terminal computer software equipment. Those signals are usually set by the terminal, thus allowing user to take control over the line and modem’s running configuration. The most used signals are listed in Tab. 3.

Tab. 3: Shortened list of common modem signals carried over the serial line. [6] [13] [41]

EIA232/RS232 pin assignments

All modems used in labolatory are equipped with EIA232/RS232 standard serial port. On the other end, there is a serial-to-USB converting cable. This cable has DB9 (9-pinned serial interface), while most modems carrying DB25 (25-pinned serial interface). This means there must be some other serial-to-serial converting wiring, which is already included by the modem manufacturers in a DB9-to-DB25 serial cable. Table 4 shows, which pins are used by both interface models.

Note: For Tab. 4, Courier’s bottom desk with verbose RS232 pins description has been used one source (transcribed).

Tab. 4: Complete list of DB25’s pins with their according meaning. To be compared with DB9 interface. [40] [41]

Hayes (AT) command set

AT command set is used to directly communicate with modem’s internal firmware and hardware. Originally, it was introduced by the Hayes company manufacturing earlier modem models, but is used till the contemporal times (e.g. GSM modems implement Hayes command set as well). [13] [14] [15] [16] [30] [43]

USR configuration settings fingerprint using ATI4 command string (ommited command output, to be compared with its meaning):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

ATI4
U.S. Robotics 56K Voice EXT Settings...

   B0  E1  F1  L2  M1  Q0  V1  X4  Y0
   BAUD=115200  PARITY=N  WORDLEN=8
   DIAL=TONE    ON HOOK

   &A3  &B1  &C1  &D2  &H1  &I0  &K1
   &M4  &N0  &R2  &S0  &T5  &U0  &Y1

[...]

basic command list

Tab. 5: Incomplete list of common so-called basic (Hayes originally) command set.

extended command list

Tab. 6: Incomplete list of common extended command set. [30]

S-registers (shortened)

Tab. 7: List of common (mostly USR-related) S-register list used by USR modems (see #hardware-and-software). To be completed later. [15] [30]

modem standards and modulation protocols

Tab. 8: Selected important modem standards and modulation protocols list, with a short summary, symbol rate and bitrate. [3] [7] [12] [18] [40]

error correction, and data compression

Tab. 9: Selected ITU-T recommendations for error correction and data compression. [18]

CRC (Cyclic Redundancy Check)

CRC detects errors in the data transmission. As the PPP protocol relies on connected nodes to take care of those errors, thus PPP implements CRC. CRC mostly implements checksums as FCS (Frame Check Sequence). Error recovery must be implemented by a different protocol, as the recovery often needs lost/corrupted frames retransmission (ARQ, see below). [3]

ARQ (Automatic Repeat Request)

ARQ is a method using acknowledgements (ACK) for the data transmission. This method is used to ensure reliablity of the transmission data link. [19]

MNP (Microcom Networking Protocol)

Proprietary protocol group by Microcom company, used as recommendations for signal modulation rates (MNP2–MNP4), and for data compression (MNP5). [7]

LAPM/LAPM-SREJ (Link Access Protocol for Modems)

Part of the V.42 error correction protocol. CRC, and ARQ is used for corrupted data retransmission. Frames sent upon LAPM protocol are of a various length, each ending with tail containing CRC information. Received packets are to be ACKed, other packets has to be retransmitted (ARQ). [20]

Special funtionality called Selective Reject (SREJ) allows resending of corrupted packets only to optimize modem-modem speed and for faster error recovery. V.42bis recommendation introduces better compression option, allowing higher throughput for data flow. [20]

modem flow control

Flow control (FC) ensures fluent data transmission from modem to modem. It uses modem’s data buffers for transmitted and received data (congestion control). Flow control operates on those buffers and controls their utilization by stopping and starting data flow. Basically, there is hardware (highly recommended) and software modem flow control. It is very common, that lower ISO/OSI levels utilize hardware FC, while software FC is carried out above those (mostly). [3] [30]

hardware flow control

Hardware FC controls (drops) CTS (clear to send) signal when buffer is about to be filled, and raises it back when buffer is ready (about to be emptied) again. [30]

software flow control

Software FC adds special characters to the data flow to indicate filling buffers. Those special characters are unfortunately part of normal data flow, so it can interfere with software FC special character recognition and therefore can lead to data loss. Those characters are called XON (transmission on) and XOFF (transmission stop), the actual ASCII codes are stored in registers S22 and S23. [30]

transmission modes

Basically, data can be transmitted using asynchronous and synchronous transmission modes. The core difference is the final connection speed: asynchronous mode is usually way slower, and thus less effective than synchronous mode. [3]

asynchronous mode

In this mode, only one character is transmitted over the link at a time: only one node transmits at any given moment. Usually, the connection bitrate is set up to 1800 bps. Asynchronous modems use Frequency Shift Keying (FSK) modulation for the communication itself. [3] [39]

synchronous mode

This mode introduces whole data blocks transmission as a coherent data flow in both directions (mostly). As far as the modulation is concerned, phase shift keying is very common at bitrates up to 28.8 Kbps. [3] [39]

Synchronous modems are equipped with so-called equalizers, that are used for telephone line quality tuning. Equalizers watch the line attenuation and other telephone signal parameters to optimize their quality compensation effect. [39]

In 4-wire (6P4C) telephone line configuration, one pair can be used for data transmission, while the other for data reception. [2] [39]

point-to-point protocol (PPP) link

PPP is an ISO/OSI layer 2 protocol group — so-called two-point protocol — preceded by SLIP, supports multiprotocol environments [IP/IPX/AppleTalk via NCP (Network Control Protocol)], supports voluntary compression, and periodically checks for link quality and dynamically configures link parameters. [3]

Also, PPP can be used to create link bonds as MP (Multilink PPP), combining multiple serial links/lines to one bonding interface, while adding up to the total interface speed (described as RFC 1990). The (multi)link itself is controlled via LCP (Link Control Protocol) part of the PPP frame. [3]

VoIP parameters

Call data are usually transported using RTP (real-time transport protocol) stream with SIP (session initiation protocol) signaling. [2]

SIP proxy

RTP stream usually flows to-and-from so-called SIP proxy at the VoIP provider’s endpoint. This may add up some latency and delay of the RTP stream itself. SIP proxy acts like SIP signaling router/gateway. As far as the RTP stream is concerned, using SIP proxy (direct RTP stream between peers) might be a better option than implementing B2BUA (back-to-back user agent). [2]

In the Asterisk configuration, a direct media flow is recommended for such setup (sip.conf) [2] [4]:

1
2

[sip_account]
directmedia=yes

codecs

Tab. 10: Codecs supported by some ISP’s network components list (mainly the VoIP gateway). G.719 is listed due to its fullband characteristics. [2] [3]

Note: no handshake has been completed when using g729 codec (in testing).

packetization

Sending an analogue signal through the IP network requires its packetization. Usually, packetization is defined as milisecond per packet, ms/pkt. Default packetization is 20 ms/pkt for G.711 (used VoIP gateway offers range of 10 to 90 ms/pkt, sometimes even up to 120 ms/pkt). [8] [28] [35] [36]

Note: Tuning packetization value up may link to the overall stream delay — lower packetization leads to lower ICMP RTT on the other hand.

Packetization of 10 ms/packet could be used for faxes sending (g711 with 10 ms/packet). [28]

configuration

As already mentioned in the very introduction, the next part deals with the whole lab configuration setup.

server (NAS) configuration

mgetty configuration (/etc/mgetty/mgetty.config) for the specific port [4] [33] [38]:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

port ttyUSB0
 # maximum debugging
 debug 9

 # port ownership (to be inspected)
 port-owner root
 port-group dialout
 # port chmod permissions, relatively secure options are 0660 or even 0600
 port-mode 0660

 # do not run on direct line (nullmodem), 
 direct no
 # watch DCD signal
 ignore-carrier no
 # do not do faxing
 data-only yes
 fax-only no

 # modem init string; the syntax is chained 'expect-send' string array
 init-chat "" ATQ0V1E1L1M1 OK AT&D2 OK

 # lower DTR signal to reset the modem
 toggle-dtr yes
 # hold DTR low for X miliseconds
 toggle-dtr-waittime 500
 # wait X miliseconds after modem reset (some modems send 'OK' string on startup)
 open-delay 1000
 # check if modem is alive (a simple AT OK expect-send) each X seconds
 modem-check-time 120

 # ring count before call answer; should be different than the contents 
 # of S0 register, otherwise the modem may hangup during autoanswering
 rings 1
 # modem port access speed (computer-modem speed, 
 # should be higher to allow the compression to be negotiated)
 speed 115200
 # lock modem's DTE speed
 autobauding no

mgetty issue file (/etc/mgetty.issue):

1

caller \Y --- modem \P \S (\I)

Explanation of the so-called string ’tokens’ from mgetty manpages [21]:

1
2
3
4

\Y - caller ID
\P - expand the tty name
\S - port speed in bps
\I - print "CONNECT foobar" string returned by modem

To ensure computer-modem connection to be enabled, restart and check the systemd service [4] [33]:

1
2

systemctl restart [email protected]
systemctl status [email protected]

Server MOTD (/etc/motd) contents:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

.
.                 _     _ _
.                (_)   | (_)
.  ___  _ __  ___ _  __| |_  __ _ _ __
. / _ \| '_ \/ __| |/ _` | |/ _` | '_ \
.| (_) | |_) \__ \ | (_| | | (_| | | | |
. \___/| .__/|___/_|\__,_|_|\__,_|_| |_|
.      | |
.      |_|
.
.
[ savla Network Access Server --- welcome on-line! ]
.
[ opsidian.savla.net ]
[ 10.4.7.0/27, 10.4.7.0/30, 10.4.7.1/32 ]
[ https://docs.savla.su/nodes/opsidian ]
.
.

Note: savla.net and savla.su domains cannot be accessed from the Internet as those are advertised by an internal authoritative DNS server in savla.dev infrastructure — VPN access only. Domains cannot be resolved even when connected to the dial-in server via modem, because that traffic is not routed to the intranet networks. Some domain may be available on the Internet, but is not connected to savla.dev organization, thus has been purchased by someone else (public vs. private DNS).

client configuration

To dial from linux system, the wvdial tool has been used. It has got its own config on how to connect to the dial-in counterpart. It is also possible to use pppclient, that has more potent configuration options (ppp client for debian docs). [22] [37]

Example of wvdial configuration file (/etc/wvdial.conf) [23]:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

[Dialer lab]
Init = ATI6
Init1 = ATZ0
Init2 = ATQ0 V1 E1 L1 M1 S0=0 X4 Y0 &C1 &D2 +FCLASS=0
Modem Type = Analog Modem
FlowControl = Hardware (CRTSCTS)
Baud = 115200
ISDN = 0
Phone = 881***
Modem = /dev/ttyUSB0
Stupid = mo
Carrier = yes
Dial = 1
Username = ***
Login = ***
Password = ***

Baud (DTE–DCE speed) shown above is set to the highest possible serial link speed, as this setting should be the default one. [37].

server modem configuration

1

screen /dev/ttyUSB0 38400

1
2
3
4
5
6
7
8
9

ati4
U.S. Robotics 56K FAX EXT Settings...

B1 E1 L1 M1 Q0 T V1 X4 Y0 &A3 &B1 &C1 &D2 &H1 &I0 &K1 &M4 &R2 &S0 &Y0
S00:000 S01:000 S02:043 S03:013 S04:010 S05:008 S06:003 S07:090 S08:002 S09:006
S10:014 S11:085 S12:050 S27:000 S32:000

LAST DIALED #:
OK

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

ati6
U.S. Robotics 56K FAX EXT Link Diagnostics...

TERMINATION REASON.......... RETRAIN FAILURE
LAST TX rate................ 4800 BPS
HIGHEST TX rate............. 14400 BPS
LAST RX rate................ 4800 BPS
HIGHEST RX rate............. 14400 BPS
PROTOCOL.................... LAPM-SREJ
COMPRESSION................. V42Bis
Line QUALITY................ 127
Rx LEVEL.................... 026
Highest Rx State............ 00
Highest TX State............ 00
EQM Sum..................... 0000
RBS Pattern................. FF
Rate Drop................... FF
Digital Loss................ None
Local Rtrn Count............ 02
Remote Rtrn Count........... 01

OK

In the output above, we can see a serious modem-modem speed fluctuation (e.g. abs({"LAST TX rate"} - {"HIGHEST TX rate"})).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

ati7
Configuration Profile...

Product type         TBR21 External
Product ID:          24563100
Options              V32bis,V.80,V.34+,V.90,V.92
Fax Options          Class 1/Class 2
Line Options         Caller ID, Distinctive Ring
Clock Freq           28.2MHz
EPROM                256k
RAM                  32k

FLASH date           05/27/2004
FLASH rev            1.915M
DSP rev              79.00
OK

client modem configuration

1

screhen /dev/ttyUSB0 115200

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

ATI0
5601

OK
ATI1
299D

OK
ATI2
OK

OK
ATI3
U.S. Robotics 56K Voice EXT Rev. 11.1.17

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

ATI4
U.S. Robotics 56K Voice EXT Settings...

   B0  E1  F1  L2  M1  Q0  V1  X4  Y0
   BAUD=115200  PARITY=N  WORDLEN=8
   DIAL=PULSE   ON HOOK

   &A3  &B1  &C1  &D2  &H1  &I0  &K1
   &M4  &N0  &R2  &S0  &T5  &U0  &Y1

   S00=000  S01=000  S02=043  S03=013  S04=010  S05=008  S06=003
   S07=055  S08=003  S09=006  S10=014  S11=070  S12=050  S13=000
   S15=000  S16=000  S18=000  S19=000  S21=010  S22=017  S23=019
   S25=005  S27=001  S28=008  S29=020  S30=000  S31=128  S32=002
   S33=000  S34=000  S35=000  S36=014  S38=000  S39=012  S40=000
   S41=004  S42=000

   LAST DIALED #:

OK

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

ATI5
U.S. Robotics 56K Voice EXT NVRAM Settings...

 Template Y0

   DIAL=PULSE  B0  E1  F1  L2  M1  Q0  V1  X4
   BAUD=57600  PARITY=N  WORDLEN=8

   &A3  &B1  &C1  &D2  &H1  &I0  &K1  &M4  &N0
   &P0  &R2  &S0  &T5  &U0  &Y1

   S00=000  S02=043  S03=013  S04=010  S05=008  S06=003  S07=055
   S08=003  S09=006  S10=014  S11=070  S12=050  S13=000  S15=000
   S19=000  S21=010  S22=017  S23=019  S25=005  S27=001  S28=008
   S29=020  S30=000  S31=128  S32=002  S33=000  S34=000  S35=000
   S36=014  S38=000  S39=012  S40=000  S41=004  S42=000


Strike a key when ready . . .


 Template Y1

   DIAL=PULSE  B0  E1  F1  L2  M1  Q0  V1  X4
   BAUD=57600  PARITY=N  WORDLEN=8

   &A3  &B1  &C1  &D2  &H2  &I2  &K1  &M4  &N0
   &P0  &R1  &S0  &T5  &U0  &Y1

   S00=000  S02=043  S03=013  S04=010  S05=008  S06=003  S07=055
   S08=003  S09=006  S10=014  S11=070  S12=050  S13=000  S15=000
   S19=000  S21=010  S22=017  S23=019  S25=005  S27=001  S28=008
   S29=020  S30=000  S31=128  S32=002  S33=000  S34=000  S35=000
   S36=014  S38=000  S39=012  S40=000  S41=004  S42=000


   STORED PHONE #0:
                #1:
                #2:
                #3:

OK

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

ATI7
Configuration Profile...

Product type           Czech External
Product ID:            18566300
Options                V32bis,V.34+,x2,V.90
Fax Options            Class 1/Class 2.0
Voice Options          Speakerphone, TAD
Clock Freq             92.0Mhz
EPROM                  256k
RAM                    32k

FLASH date             3/2/98
FLASH rev              11.1.17

DSP date               3/2/98
DSP rev                11.1.17

OK

1
2
3
4
5
6
7

ATI8
Blacklist
Time: 01:58:36
Dialed Numbers: Empty
Dial Attempts:  000 of 012

OK

1
2
3
4

ATI9
(1.0USR9180\\Modem\PNPC107\U.S. Robotics 56K Voice EXT)FF

OK

asterisk PBX configuration

sip.conf

1
2
3
4
5
6
7
8
9

[ata-servermodem]
context=public
type=friend
secret=***
qualify=200
host=dynamic
directmedia=yes
nat=no
allow=alaw

1
2
3
4
5
6
7
8
9

[ata-clientmodem]
context=public
type=friend
secret=***
qualify=200
host=dynamic
directmedia=yes
nat=no
allow=alaw

The important rule here (as mentioned in #sip-proxy paragraph) is

1

directmedia=yes

allowing both modems to communicate without using SIP proxy. This should theoretically improve connetion speeds and VoIP call parameters in general.

implementation

ansible role

For changes (dial-in server) deployment and for configuration versioning an Ansible role repository was created (to be published soon). Role ensures pppd, mgetty, asterisk and screen tools are present on the repomote system. Next, it configures tty ports for pppd amd mgetty, configures SIP accounts for local asterisk instance, reloads system daemons and configuration settings. Client has to apply changes manually.

Repository usage is even more simplified by using Makefile (GNU make). So one can just edit port settings (as described above), and then deploy to server specified by --limit flag of the ansible-playbook command.

1
2
3
4
5
6

# alias for
# ansible-playbook dialin-playbook.yml \
#	--limit opsidian.savla.net \
#	-i dialin.list \
#	--ask-become-pass
make deploy_dial_in_server

dialing up

To dial the remote conterpart — specified by ’lab’ configuration section above — type:

1

sudo wvdial lab

wvdial output when dialing, redacted:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

--> WvDial: Internet dialer version 1.61
--> Initializing modem.
--> Sending: ATZ
ATZ
OK
--> Sending: ATQ0 V1 E1 L1 S0=0 &C1 &D2 +FCLASS=0
ATQ0 V1 E1 L1 S0=0 &C1 &D2 +FCLASS=0
OK
--> Modem initialized.
--> Sending: ATDT881***
--> Waiting for carrier.
ATDT881***
CONNECT 14400/ARQ/V32/LAPM/V42BIS
--> Carrier detected.  Waiting for prompt.
caller none --- modem ttyUSB0 57600 (14400/ARQ/V32B/LAPM-SREJ/V42BIS)
**EMSI_REQA77E
[11]
opsidian.savla.net login:
--> Looks like a login prompt.
--> Sending: ***
caller none --- modem ttyUSB0 57600 (14400/ARQ/V32B/LAPM-SREJ/V42BIS)
**EMSI_REQA77E
[11]
opsidian.savla.net login:
--> Looks like a login prompt.
--> Sending: ***
***
Password:
--> Looks like a password prompt.
--> Sending: (password)
Linux opsidian.savla.net 5.15.84-v7l+ #1613 SMP Thu Jan 5 12:01:26 GMT 2023 armv7l
.
.                 _     _ _
.                (_)   | (_)
.  ___  _ __  ___ _  __| |_  __ _ _ __
. / _ \| '_ \/ __| |/ _` | |/ _` | '_ \
.| (_) | |_) \__ \ | (_| | | (_| | | | |
. \___/| .__/|___/_|\__,_|_|\__,_|_| |_|
.      | |
.      |_|
.
.
[ savla Network Access Server --- welcome on-line! ]
.
[ opsidian.savla.net ]
[ 10.4.7.0/27, 10.4.7.0/30, 10.4.7.1/32 ]
[ https://docs.savla.su/nodes/opsidian ]
.
.
Last login: Sun Jan 15 20:43:43 GMT 2023 on ttyUSB0
--> PPP negotiation detected.
--> Starting pppd at Mon Jan 16 18:50:46 2023
--> Pid of pppd: 33690
--> Using interface ppp0
--> local  IP address 10.4.7.2
--> remote IP address 10.4.7.1
--> primary   DNS address 1.1.1.2
--> secondary DNS address 1.1.1.2
--> Script /etc/ppp/ip-up run successful
--> Default route Ok.
--> Nameserver (DNS) Ok.
--> Connected... Press Ctrl-C to disconnect

spectral analysis of modem-modem negotiation procedure

Fig. 9: Negotiation spectral analysis with annotations ( see original ). [ reference ]

Note: EMSI_REQA77E string is sent by mgetty server’s daemon, used to negotiate EMSI Request for FIDO. [24]

PPP routing and DNS resolving issue

Sometimes it is necessary to manually add nameserver for ppp0 network interface and to reset default IP route:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# manually add DNS server for interface
sudo resolvectl dns ppp0 1.1.1.1

# manually add route and assign IP to the interface
sudo ip route add 10.4.7.1 dev ppp0
sudo ip address add 10.4.7.2/30 dev ppp0

# or
# delete and re-add default gateway to be used via ppp0 interface
sudo ip route del default
sudo ip route add default ppp0

# alternatively, we can set explicit routes to be routed through ppp0 interface
sudo ip route add 89.31.40.0/21 dev ppp0

browsing

Using HTTP/S protocols for browsing can clog the connection, so it is better to use simpler protocols like gopher and text-based browsers.

1

lynx gopher://kocourovo.eu

link and data analysis

wvdial handshake readings analysis

Sample connection handshake(s):

1
2
3
4
5
6
7

CONNECT 14400/ARQ/V32/LAPM/V42BIS
--> Carrier detected.  Waiting for prompt.
caller none --- modem ttyUSB0 57600 (14400/ARQ/V32B/LAPM-SREJ/V42BIS)

CONNECT 26400/ARQ/V34/LAPM-SREJ/V44
--> Carrier detected.  Waiting for prompt.
caller none --- modem ttyUSB0 115200 (31200/ARQ/V34/LAPM-SREJ/V44)

Text output (the very first 3 lines) analysis using chapters above. Another handshake(s) examples are to show possible link speed differences (to be discussed further).

First line

• client modem CONNECT response
• modem-modem connection speed
• use ARQ error correction
• use V.32/V.32bis modulation
• use LAPM/LAPM-SREJ protocol
• use V.42bis data compression.

Second line

• wvdial program debug message
• carrier signal ready
• check for PPP link negotiation initialization.

Third line

• no CLIP (caller ID) sent by client
• server tty name used
• NAS-modem (DTE–DCE connection) link speed
• (in parentheses) remote modem’s connection string (set by mgetty).

iperf link performance

The client-server constallation respects modem-modem connection relation.

Fig. x: Connection between client and server with corresponding IP addresses. CIDR for the network is /30.

Handshake and carrier details:

1
2
3

CONNECT 14400/ARQ/V32/LAPM/V42BIS
--> Carrier detected.  Waiting for prompt.
caller none --- modem ttyUSB0 57600 (14400/ARQ/V32B/LAPM-SREJ/V42BIS)

server side settings

At first, it is mandatory to setup the server side, namely firewall. Then it is possible to start the iperf tool in server mode.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

# allow incomming traffic
iptables -I INPUT -p udp -m udp --dport 5001 -s 10.4.7.0/30 \
         -m comment --comment "iperf3 server-side UDP ingress" -j ACCEPT

# start the server
iperf3 -p 5001 -s

# delete the iperf3 dedicated UDP port rule
iptables -D INPUT -p udp -m udp --dport 5001 -s 10.4.7.0/30 \
         -m comment --comment "iperf3 server-side UDP ingress" -j ACCEPT

UDP stream

Down below, there is a sample 10s measurement of the UDP bitrate (should be much longer).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

[  5] local 10.4.7.1 port 5001 connected to 10.4.7.2 port 54320
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-1.00   sec  0.00 Bytes  0.00 bits/sec  0.000 ms  0/0 (0%)
[  5]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec  0.000 ms  0/0 (0%)
[  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec  0.000 ms  0/0 (0%)
[  5]   3.00-4.00   sec  14.1 KBytes   116 Kbits/sec  7.893 ms  0/10 (0%)
[  5]   4.00-5.00   sec  90.5 KBytes   741 Kbits/sec  12.634 ms  0/64 (0%)
[  5]   5.00-6.00   sec  74.9 KBytes   614 Kbits/sec  20.064 ms  0/53 (0%)
[  5]   6.00-7.00   sec  80.6 KBytes   660 Kbits/sec  39.078 ms  0/57 (0%)
[  5]   7.00-8.00   sec   106 KBytes   869 Kbits/sec  23.034 ms  0/75 (0%)
[  5]   8.00-9.00   sec  80.6 KBytes   660 Kbits/sec  18.761 ms  0/57 (0%)
[  5]   9.00-10.00  sec  77.8 KBytes   637 Kbits/sec  32.303 ms  0/55 (0%)
[  5]  10.00-11.00  sec  90.5 KBytes   741 Kbits/sec  20.381 ms  0/64 (0%)
[  5]  11.00-12.00  sec  96.2 KBytes   788 Kbits/sec  28.922 ms  0/68 (0%)
[  5]  12.00-13.00  sec  80.6 KBytes   660 Kbits/sec  20.925 ms  0/57 (0%)
[  5]  13.00-13.41  sec  42.4 KBytes   854 Kbits/sec  31.447 ms  0/30 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-13.41  sec   834 KBytes   510 Kbits/sec  31.447 ms  0/590 (0%)  receiver

TCP stream

Next, there is a sample TCP server-side output of iperf. The bitrate here should be understood as the rate of received bytes from the client side. Therefore this value should be more exact in terms of the link speed measurement.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

Accepted connection from 10.4.7.2, port 36190
[  5] local 10.4.7.1 port 5001 connected to 10.4.7.2 port 38998
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  0.00 Bytes  0.00 bits/sec
[  5]   1.00-2.00   sec  0.00 Bytes  0.00 bits/sec
[  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec
[  5]   3.00-4.00   sec   560 Bytes  4.48 Kbits/sec
[  5]   4.00-5.00   sec   560 Bytes  4.48 Kbits/sec
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec
[  5]   6.00-7.00   sec   560 Bytes  4.48 Kbits/sec
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec
[  5]   8.00-9.00   sec   560 Bytes  4.48 Kbits/sec
[  5]   9.00-10.00  sec   560 Bytes  4.48 Kbits/sec
[  5]  10.00-11.00  sec   560 Bytes  4.48 Kbits/sec
[  5]  11.00-11.41  sec  0.00 Bytes  0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-11.41  sec  3.28 KBytes  2.36 Kbits/sec                  receiver

Therefore one could say. that the link fluctuated a lot, tuning the link speed negotiated by modems. The bitrate is close to 2400 modem bitrate. [45]

client side

On the client side though, it is not needed to configure anything. Just open the client side end to establish a connection to the remote machine (server).

1
2

# UDP stream
iperf3 -c 10.4.7.1 -p 5001 -w 5 -4 -u -V

Down below, sample UDP, and TCP stats are listed.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

iperf 3.9
Linux krustyboks *** #1 SMP PREEMPT Mon May 30 17:47:02 UTC 2022 x86_64
Control connection MSS 1448
Setting UDP block size to 1448
Time: Sat, 11 Feb 2023 19:32:36 GMT
Connecting to host 10.4.7.1, port 5001
      Cookie: ***
      Target Bitrate: 1048576
[  5] local 10.4.7.2 port 54320 connected to 10.4.7.1 port 5001
Starting Test: protocol: UDP, 1 streams, 1448 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval           Transfer     Bitrate         Total Datagrams
[  5]   0.00-1.38   sec  1.41 KBytes  8.38 Kbits/sec  1  
[  5]   1.38-2.00   sec   216 KBytes  2.87 Mbits/sec  153  
[  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec  0  
[  5]   3.00-4.00   sec   113 KBytes   927 Kbits/sec  80  
[  5]   4.00-5.00   sec  79.2 KBytes   649 Kbits/sec  56  
[  5]   5.00-6.00   sec  87.7 KBytes   718 Kbits/sec  62  
[  5]   6.00-7.00   sec  72.1 KBytes   591 Kbits/sec  51  
[  5]   7.00-8.00   sec   120 KBytes   985 Kbits/sec  85  
[  5]   8.00-9.00   sec  65.0 KBytes   533 Kbits/sec  46  
[  5]   9.00-10.00  sec  79.2 KBytes   649 Kbits/sec  56  
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-10.00  sec   834 KBytes   683 Kbits/sec  0.000 ms  0/590 (0%)  sender
[  5]   0.00-13.41  sec   834 KBytes   510 Kbits/sec  31.447 ms  0/590 (0%)  receiver
CPU Utilization: local/sender 10.6% (4.1%u/6.4%s), remote/receiver 0.1% (0.0%u/0.0%s)

iperf Done.

1
2

# TCP stream
iperf3 -c 10.4.7.1 -p 5001 -w 5 -4 -V

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

iperf 3.9
Linux krustyboks *** #1 SMP PREEMPT Mon May 30 17:47:02 UTC 2022 x86_64
Control connection MSS 1448
Time: Sat, 11 Feb 2023 19:36:14 GMT
Connecting to host 10.4.7.1, port 5001
      Cookie: ***
      TCP MSS: 1448 (default)
[  5] local 10.4.7.2 port 38998 connected to 10.4.7.1 port 5001
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test, tos 0
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.39   sec  1.64 KBytes  9.70 Kbits/sec    1   5.47 KBytes
[  5]   1.39-2.00   sec  0.00 Bytes  0.00 bits/sec    0   5.47 KBytes
[  5]   2.00-3.00   sec  0.00 Bytes  0.00 bits/sec    0   5.47 KBytes
[  5]   3.00-4.00   sec  0.00 Bytes  0.00 bits/sec    0   5.47 KBytes
[  5]   4.00-5.00   sec  1.09 KBytes  8.97 Kbits/sec    0   5.47 KBytes
[  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec    0   5.47 KBytes
[  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec    0   5.47 KBytes
[  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec    0   5.47 KBytes
[  5]   8.00-9.00   sec  1.09 KBytes  8.96 Kbits/sec    0   5.47 KBytes
[  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec    0   5.47 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  3.83 KBytes  3.14 Kbits/sec    1             sender
[  5]   0.00-11.41  sec  3.28 KBytes  2.36 Kbits/sec                  receiver
CPU Utilization: local/sender 16.3% (5.4%u/11.0%s), remote/receiver 0.0% (0.0%u/0.0%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic

iperf Done.

These TCP bitrates on average are quite low, meaning the connection was very poor.

modem diagnostics

Naks and BLERs

Naks are not-acknowledgments meninging the remoze modem did not confirmed (ACKed) some of set data. BLERs are BLock ERrors — meaning some frames had to be resent. [44]

diagnostics

Dial existing number for data link (make a handshake).

1
2
3
4
5

ATDT7*****
CONNECT 14400/ARQ/V32/LAPM/V42BIS
--> Carrier detected.  Waiting for prompt.
caller none --- modem ttyUSB0 38400 (14400/ARQ/V32B/LAPM-SREJ/V42BIS)
**EMSI_REQA77E

Let us now compare this trimmed output (above) after wvdial executed.

After any call attach screen to just used modem: [25]

1

screen /dev/ttyUSB0 115200

U.S. Robotics connection stats (ATI6)

Both connections/calls in the following tho outputs were tested with iperf TCP mode on.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

ATI6
U.S. Robotics 56K Voice EXT Link Diagnostics...

Chars sent             15998842      Chars Received         15273626
Chars lost                    0
Octets sent            16100000      Octets Received        15430775
Blocks sent              126015      Blocks Received          121540
Blocks resent                31

Retrains Requested            2      Retrains Granted              0
Line Reversals                0      Blers                         7
Link Timeouts                 1      Link Naks                    23

Data Compression       V42BIS 2048/32
Equalization           Long
Fallback               Enabled
Protocol               LAPM/SREJ
Speed                  14400
Last Call              02:52:25

Disconnect Reason is DTR dropped

OK

From the output above we could get an average link throughput \(R_{thru}\) and bitrate \(R_{bitrate}\):

$$ N_{chars} = 15,998,842~\text{chars}\\ T_{call} = 10,345~\text{seconds} $$

$$ R_{thru} = \frac{N_{chars}}{T_{call}} \approx 1,546.53~\text{bytes/second} $$

$$ R_{birate} = R_{thru} * 8 \approx 12,372.23~\text{bits/second} $$

This bitrate/throughput is around 86% of the link speed (in the output as “Speed” bitrate).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

ATI6
U.S. Robotics 56K Voice EXT Link Diagnostics...

Chars sent            151249108      Chars Received        138913986
Chars lost                    0
Octets sent           152199836      Octets Received       140359787
Blocks sent             1191742      Blocks Received         1105818
Blocks resent               286

Retrains Requested            0      Retrains Granted             14
Line Reversals                0      Blers                       250
Link Timeouts                14      Link Naks                    91

Data Compression       V42BIS 2048/32
Equalization           Long
Fallback               Enabled
Protocol               LAPM/SREJ
Speed                  28800/31200 
Last Call              13:49:56

Disconnect Reason is DTR dropped

OK

Again, from the output above we could get an average link throughput \(R_{thru}\) and bitrate \(R_{bitrate}\):

$$ N_{chars} = 151,240,108~\text{chars}\\ T_{call} = 49,796~\text{seconds} $$

$$ R_{thru} = \frac{N_{chars}}{T_{call}} \approx 3,037.19~\text{bytes/second} $$

$$ R_{birate} = R_{thru} * 8 \approx 24,297.55~\text{bits/second} $$

This througput/bitrate is around 84% of the link speed (in the output as “Speed” bitrate).

U.S. Robotics connection stats (ATI11)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

ati11
U.S. Robotics 56K Voice EXT Link Diagnostics...


Modulation                  V.34
Carrier Freq     (Hz)       1829/1920
Symbol Rate                 3200/3200
Trellis Code                64S-4D/64S-4D
Nonlinear Encoding          ON/ON
Precoding                   ON/ON
Shaping                     OFF/ON
Preemphasis      (-dB)      6/4
Recv/Xmit Level  (-dBm)     19/17
Near Echo Loss   (dB)       32
Far Echo Loss    (dB)       57
Carrier Offset   (Hz)       -4720
Round Trip Delay (msec)     250
Timing Offset    (ppm)      -6656
SNR              (dB)       35
Speed Shifts Up/Down        0/1
Status :                    

OK

Microcom DeskPorte Pocket

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

ati11

    Description                         Status
    ---------------                     ------------
    Last Connection                     V.32
    Initial Transmit Carrier Rate       14400
    Initial Receive  Carrier Rate       14400
    Final   Transmit Carrier Rate       14400
    Final   Receive  Carrier Rate       14400
    Protocol Negotiation Result         LAPM
    Data Compression Result             V42bis
    Estimated Noise Level               50
    Receive  Signal Power Level  (-dBm) 4
    Transmit Signal Power Level  (-dBm) 12
    Round Trip Delay             (msec) 632
Press any key to continue; ESC to quit.

    Description                         Status
    ---------------                     ------------
    Near Echo Level              (-dBm) 0
    Far  Echo Level              (-dBm) 0
    Transmit Frame Count                1632
    Transmit Frame Error Count          0
    Receive  Frame Count                652
    Receive  Frame Error Count          2
    Retrain by Local  Modem             0
    Retrain by Remote Modem             0
    Rate Renegotiation by Local Modem   0
    Rate Renegotiation by Remote Modem  0
    Call Termination Cause              0
    Robbed-Bit Signaling                NA
    Digital Loss                   (dB) NA
    Remote Server ID                    NA
    Last PCM S PTR                      237F

OK

frequent disconnection reasons

Next, there are some sample error codes from ATI6 AT command diagnostics.

1

Disconnect Reason is No Reversal Detected

The explanation No Reversal Detected code is that modem is not receiving any signal reversals – those are vital for phase modulation. [26]

1

Disconnect Reason is Loss of Carrier

USR Faxmodem series 5663 has troubles with carrier detection pretty often.

Note: To reproduce the one above:

• packetization {20, 30} ms,
• jitter buffer 32 pcts,
• codec alaw,
• EC enabled,
• VAD enabled,
• wvdial’s ‘Baud = 57600’

1

Disconnect Reason is DTR dropped

The remote counterpart (NAS) hangs up the connection. Also, user line disconnection using CTRL-C in terminal with wvdial session up. DTR signal can be easily dropped by serial cable physical disconnection.

1

Disconnect Reason is GSTN Cleardown

GSTN stands for General Switched Telephone Network. The background of this phoenomena is not quite understood yet; seen both on remote (odorik.cz) SIP provider loop, as well on local Asterisk PBX loop while testing. [27]

This error should carry a message that the other side dropped the DTR signal, or the disc frame was corrupted. Thi phoenomenta can be seen on non-error correcting connections. [44]

link medium debugging

Note: Statistical test idea: compare dial-up connection/handshake on 10-ms and 20-ms signal packetization (10 means less loss and prolly less noise too). [28]

Problems getting the handshake over 10-ms packetization setting.

Tab. 11: ATA VoIP gateway settings, with VAD being Voice Activity Detection (VAD) and EC being Echo Cancellation (EC). [2] [29]

1
2
3
4
5

codec  		|   g711alaw/pcma/A-law
packetization	|   10 ms/pkt
jitter buffer   |   3 packets
VAD		|   disabled
EC		|   disabled

Silence supression (VAD being enabled) can disrupt the carrier signal.

provider call stats

Odorik.cz in-network call trimmed log (translated) and statistics (stats).

Tab. 12: Sample VoIP call statistics provided by Odorik.cz SIP ISP (translated).

1
2
3
4
5
6
7

direction			    |   client->Odorik    |   Odorik->client
------------------------------------------------------------------------------
registered packets count	    |	125624 	          |   126058
packetization (sound lenght/packet) |	20ms		  |   20ms
sound length sum 		    |	2512.48 s 	  |   2521.16 s
codec				    |	pcma/alaw	  |   pcma/alaw
lost packets count		    |	0 (0%)		  |   0 (0%)

provider call length limit

SIP ISP may cancel the circuit carrier link after 180 minutes.

Tab. 13: 180-minute VoIP call stats via Odorik.cz SIP ISP (translated, outgoing call).

1
2
3
4
5
6
7

direction			    |   client->Odorik     |   Odorik->client
------------------------------------------------------------------------------
registered packets count	    |	540042 	           |	539583
packetization (sound lenght/packet) |	20ms		   |	20ms
sound length sum 		    |	10800.84 s 	   |	10791.66 s
codec				    |	pcma/alaw	   |	pcma/alaw
lost packets count		    |	0 (0%)		   |	1 (0%)

Tab. 14: 180-minute VoIP call stats via Odorik.cz SIP ISP (translated, incoming call).

1
2
3
4
5
6
7

direction		            |   client->Odorik      | 	Odorik->client
------------------------------------------------------------------------------
registered packets count	    |	539590 	            |	540028
packetization (sound lenght/packet) |	20ms		    |	20ms
sound length sum 		    |	10791.80000000001 s |	10800.56 s
codec				    |	pcma/alaw	    |	pcma/alaw
lost packets count		    |	1 (0%)		    |	0 (0%)

link handshake

1
2
3

CONNECT 14400/ARQ/V32/LAPM/V42BIS
--> Carrier detected.  Waiting for prompt.
caller none --- modem ttyUSB0 57600 (14400/ARQ/V32B/LAPM-SREJ/V42BIS)

modem-side call diagnostics

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

ATI6
U.S. Robotics 56K Voice EXT Link Diagnostics...

Chars sent                55873      Chars Received            12514
Chars lost                    0
Octets sent               52851      Octets Received            8778
Blocks sent                1407      Blocks Received            1497
Blocks resent                 0
Retrains Requested            0      Retrains Granted              1
Line Reversals                0      Blers                         0
Link Timeouts                 0      Link Naks                     0
Data Compression       V42BIS 2048/32
Equalization           Long
Fallback               Enabled
Protocol               LAPM/SREJ
Speed                  14400
Last Call              02:59:25

Disconnect Reason is Unable to Retrain

OK

server-side mgetty verbose output

/var/log/mgetty/mg_ttyUSB0.log

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

--
01/31 20:57:34 SB0  mgetty: stable release 1.2.1
01/31 20:57:34 SB0   increasing modem_check_time to 900 sec.
01/31 20:57:34 SB0  check for lockfiles
01/31 20:57:34 SB0   checklock: stat failed, no file
01/31 20:57:34 SB0  locking the line
01/31 20:57:34 SB0   makelock(ttyUSB0) called
01/31 20:57:34 SB0   do_makelock: lock='/var/lock/LCK..ttyUSB0'
01/31 20:57:34 SB0   lock made
01/31 20:57:34 SB0   tio_get_rs232_lines: status: RTS CTS DSR DTR
01/31 20:57:34 SB0  lowering DTR to reset Modem
01/31 20:57:35 SB0   tss: set speed to 57600 (10001)
01/31 20:57:35 SB0   tio_set_flow_control( HARD )
01/31 20:57:35 SB0   waiting for line to clear (VTIME=1), read: [0d][0a]OK[0d][0a]
01/31 20:57:35 SB0  send: \dATQ0V1H0[0d]
01/31 20:57:35 SB0  waiting for ``OK''
01/31 20:57:35 SB0   got: ATQ0V1H0[0d]
01/31 20:57:35 SB0    CND: ATQ0V1H0[0d][0a]OK ** found **
01/31 20:57:35 SB0  send: AT[0d]
01/31 20:57:35 SB0  waiting for ``OK''
01/31 20:57:35 SB0   got: [0d]
01/31 20:57:35 SB0    CND: OK[0a]AT[0d]
01/31 20:57:35 SB0    CND: AT[0d][0a]OK ** found **
01/31 20:57:35 SB0   waiting for line to clear (VTIME=3), read: [0d][0a]
01/31 20:57:36 SB0   removing lock file
01/31 20:57:36 SB0  waiting...
01/31 21:00:45 SB0    select returned 1
01/31 21:00:45 SB0   checking lockfiles, locking the line
01/31 21:00:45 SB0   makelock(ttyUSB0) called
01/31 21:00:45 SB0   do_makelock: lock='/var/lock/LCK..ttyUSB0'
01/31 21:00:45 SB0   lock made
01/31 21:00:45 SB0  wfr: waiting for ``RING''
01/31 21:00:45 SB0   got: [0d][0a]RING[0d]
01/31 21:00:45 SB0    CND: RING
01/31 21:00:45 SB0   wfr: rc=0, drn=0
01/31 21:00:45 SB0    CND: check no: 'none'
01/31 21:00:45 SB0  send: ATA[0d]
01/31 21:00:45 SB0  waiting for ``CONNECT''
01/31 21:00:45 SB0   got: [0a]
01/31 21:00:45 SB0    CND: OKATA[0d]
01/31 21:00:45 SB0    CND: ATA[0d][0a]CONNECT ** found **
01/31 21:01:21 SB0  send:
01/31 21:01:21 SB0  waiting for ``_''
01/31 21:01:21 SB0   got:  14400/ARQ/V32B/LAPM-SREJ/V42BIS[0d]
01/31 21:01:21 SB0    CND: CONNECT 14400/ARQ/V32B/LAPM-SREJ/V42BIS
01/31 21:01:21 SB0   CND: found: 14400/ARQ/V32B/LAPM-SREJ/V42BIS[0a] ** found **
01/31 21:01:21 SB0   waiting for line to clear (VTIME=3), read:
01/31 21:01:21 SB0    looking for utmp entry... (PID: 29012)
01/31 21:01:21 SB0  no utmp/wtmp entry, expect issues
01/31 21:01:21 SB0   tio_set_flow_control( HARD )
01/31 21:01:21 SB0   print welcome banner (/etc/issue.mgetty)
01/31 21:01:21 SB0   getlogname (FIDO AUTO_PPP), read:
01/31 21:01:23 SB0    select returned 1[0d]
01/31 21:01:23 SB0   input finished with '\r', setting ICRNL ONLCR
01/31 21:01:23 SB0   tio_set_flow_control( HARD )
01/31 21:01:23 SB0   print welcome banner (/etc/issue.mgetty)
01/31 21:01:23 SB0   getlogname (FIDO AUTO_PPP), read:
01/31 21:01:23 SB0    select returned 1d
01/31 21:01:23 SB0    select returned 1i
01/31 21:01:23 SB0    select returned 1a
01/31 21:01:23 SB0    select returned 1l
01/31 21:01:23 SB0    select returned 1[0d]
01/31 21:01:23 SB0   input finished with '\r', setting ICRNL ONLCR
01/31 21:01:23 SB0   tio_get_rs232_lines: status: RTS CTS DSR DTR DCD
01/31 21:01:23 SB0    login: use login config file /etc/mgetty/login.config
01/31 21:01:23 SB0   match: user='***', key=''
01/31 21:01:23 SB0   match: user='***', key=''
01/31 21:01:23 SB0   match: user='***', key='/AutoPPP/'
01/31 21:01:23 SB0   match: user='***', key=''
01/31 21:01:23 SB0   match: user='***', key='*'*** hit!
01/31 21:01:23 SB0   calling login: cmd='/bin/login', argv[]='login ***'
01/31 21:01:23 SB0   setenv: 'CALLER_ID=none'
01/31 21:01:23 SB0   setenv: 'CONNECT=14400/ARQ/V32B/LAPM-SREJ/V42BIS'
01/31 21:01:23 SB0   setenv: 'DEVICE=ttyUSB0'
01/31 21:01:23 ##### data dev=ttyUSB0, pid=29012, caller='none', conn='14400/ARQ/V32B/LAPM-SREJ/V42BIS', name='', cmd='/bin/login', user='***'

VoIP gateway log

The hardware (ATA SIP gateway) needs to be restarted/rebooted quite often to work in more stable way.

Tab. 15: ATA gateway status log, trimmed.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

Index 	 Content
----------------------------------------------------
0 	 <2023-01-31 21:37>Reg Status: REGISTERED
1 	 <2023-01-31 21:37>REG MSG: 200 is received
2 	 <2023-01-31 21:37>REG MSG: REGISTER is sent

3 	 <2023-01-31 21:37>REG MSG: 401 is received

4 	 <2023-01-31 21:37>Reg Status: REGISTERED
5 	 <2023-01-31 21:37>REG MSG: 200 is received
6 	 <2023-01-31 21:37>REG MSG: REGISTER is sent

7 	 <2023-01-31 21:37>REG MSG: 401 is received

8 	 <2023-01-31 21:36>Reg Status: REGISTERED
9 	 <2023-01-31 21:36>REG MSG: 200 is received
10 	 <2023-01-31 21:36>Reg Status: REGISTERED
11 	 <2023-01-31 21:36>REG MSG: 200 is received

discussion

Nothing interesting or weird found in logs above. May lead to conclusion, that the carrier medium is stable in terms of SIP and RTP stream. Or, those 401 messages (impulses, flap) could lead to the carrier signal to be lost.

A possible solution could be an increase in jitter buffer packet count on the VoIP gateway.

batch connection testing

A special batch heuristic testing of modem-modem connection to fetch various performance variables, statistics. For packet transmission metrics acquirance, a program called wireshark is used, meanwhile iperf3 link performance tests are to be executed (UDP and TCP streams + ICMP stats).

Testing methodology is based on heuristic modem-,link-,medium-variable tuning. Different hardware is tested too (against fixed USR5631 server modem, mostly). Tests are performed on:

• the actual SIP provider’s network (odorik.cz) with RTP proxy,
• local Asterisk SIP PBX with direct data (RTP stream) pass-through between peers.

For both configurations, Well ATA172 is used as SIP gateway. Scraped data are stored in digitalized spreadsheet, with just-changed parameters emphazing (to see testing-time changes).

scraped variables

• dialing modem
  • DTE (DTE–DCE) speed [Bd]
  • DCE-DCE speed [kbit/s]
  • Error Correction (EC)
  • modulation and Baud speed [Bd]
  • EC protocol
  • Data Compression (DC)
  • Hardware flow control
• answering modem
  • DTE (DTE–DCE) speed [Bd]
  • DCE-DCE speed [kbit/s]
  • Error Correction (EC)
  • modulation and Baud speed [Bd]
  • EC protocol
  • Data Compression (DC)
  • hardware flow control
• VoIP gateway
  • packetization [ms/pkt]
  • SIP codecs
  • silence supression (VAD)
  • Echo Cancellation (EC)
  • jitter buffer [pkt]
  • VoIP provider SIP codecs
• iperf3 stats
  • UDP upstream speed [kbit/s]
  • UDP downstream speed [kbit/s]
  • UDP loss rate [%]
  • UDP jitter [ms]
  • TCP upstream speed [kbit/s]
  • TCP downstream speed [kbit/s]
  • TCP MSS [bytes]
• wireshark stats
  • UDP thoughput [b/s]
  • TCP throughput [b/s]
  • TCP RTT peak [ms]
• misc
  • ICMP time average, seq 50 [ms]
  • ICMP loss rate [%]
  • Registered Jack 11 cable used (2-wire/4-wire)
  • Disconnection Reason
  • Dialing/Answering modem series
  • Connection Time [min]
  • Line Quality (ATI6 to answering modem, USER5631 only)
  • Retrain Count (Local/Remote)
  • Attempts to Connect + gateway restart needed?
  • Dialing Setting AT string

Fig. 10: Cropped spreadsheet thumbnail with speed values heatmapping. (see the screenshot)

• Google spreadsheet link

testing results

Final statistics:

Tab. 16: Final statistics from remote and local circuit dial-up connection (conn) testing. \(\text{ca}\) stands for circa.

\(^{*}\)Remote SIP provider limits the connection time (call duration) to 180 minutes.

discussion and conclusion

During the testing part, more than 840 calls had been executed to establish a dial-up handshake. On average, it took 6 and 3 attempts to get a handshake — to establish a successful connection for remote and local circuits respectively.

Comparion of Tab. 16 shows that local SIP circuit gives better results than when remote SIP provider’s circuit used. This could lead to a conclusion that bypassing SIP proxy is important for modem’s sensitive information exchange during the negotiation phase and thus leads to a better call quality.

connection speeds

• Why is the UDP downstream bitrate 70–80 times the TCP downstream bitrate? How can the UDP downstream speed be higher than the connection bitrate?

The main difference between UDP and TCP connection speeds are that UDP tests are provided using a continuous datagram stream from client to server, while TCP requires 3-way handshakes to reliably send packets.

The reliability of UDP stream can be qualified by the UDP loss rate, which is quite high for both circuits (above 15 %).

The other important part here is software/hardware flow control in action on both modems. It is not quite known now (to be further inspected), if both modems are in sync with the flow control. According to the configuration of both modems, software flow control should be disabled (mostly by default) as it could lead to data loss via its control characters used for the flow control itself.

Let \(R_{UDP}\) be the average UDP downstream bitrate, let \(L_{UDP}\) be the average UDP loss rate, and let \(R_{clr}\) be a cleared UDP bitrate from lost traffic. Then:

$$R_{clr} = R_{UDP} \times (1 - L_{UDP})~[\text{kbps}]$$

For both remote and local circuits respectively then:

$$R_{clr} = 588.53 \times (1 - 0.2151) \land R_{clr} = 645.23 \times (1 - 0.1718)$$ $$R_{clr} = 461.94~\text{kbps} \land R_{clr} = 534.38~\text{kbps}$$

Even when cleared by loss rate, the bitrate is still quite high (way above average connection bitrate). It is also important to consider, that average values are biased by extremes (extreme top and bottom values). However, this problem should be minimized by the batch size (678 and 174 callings for remote and local circuit respectively).

Errors could also possibly be in the used iperf default settings — TCP window being disabled in sysctl [42]:

1

net.ipv4.tcp_window_scaling = 0

Moreover, it has been discovered, that the methodic of iperf usage for link speed testing was not used properly. See the next chapter of the new testing round.

link revision (Jan 2024)

Tab. x: Selected parameters and configurations of modems and ATA.

second test round

references

printed

online

Cited using scribbr.com.

further telco lab ideas

• xDSL service
  • superuser inspiration post
• LoRa P2P link