• Please review our updated Terms and Rules here

MoIP: How do we make modem calls over IP? (and general chat about phone networks and modems, T1, E1, BRI 56k etc)

mR_Slug

mR_Slug

Veteran Member
Joined
Nov 28, 2006
Messages
1,075
Location
UK
As I understand it modems and VoIP don't really work. I assume most people have tried SIP is MGCP and h323 the same?

I had a look around for BRI 64K over IP and found TDM over IP, So, T1 or E1 over IP. For those that are not up-to-speed, Back in the '60s the telephone network was digitized using T1 or E1 (in Europe) to save on trunk lines. You take one pair, and run 24(23 usable) channels over it. Massive cost savings, however it also creates a maximum of 64Kb/s digital stream, or max 56Kb/s (analogue-to-digital) stream. As such all modem standards running on a dial up line can be represented in that 64Kb/s.

I'm interested in the later >33k standards too, that need to be terminated over T1/E1. whatever 56Kb/s standard you use, two 56k modems wont talk to each other at 56k, only 33k. The other end of a 56K modem needs a Digital Modem, that is on the end of the 64Kb/s data stream. As I (struggle to) understand this, the digital modem is kinda like a PC with a sound card input from S/PDIF, it reads and writes directly to the PCM signal.

Please tell me about your experiences with modems and VoIP.
 
I have been experimenting with using a dialup modem through an ATA 191. My findings so far:

Make sure you disable SIP ALG in your router. It is not necessary to manually forward the SIP or RTP ports to the ATA, in fact doing so will generate packet errors in the ATA debug log. Just make sure you enable the NAT keep-alive options in the ATA.

Latency and jitter are killer. You can mitigate the jitter by increasing the jitter buffer (set network jitter setting to "extremely high") but this comes at the cost of additional latency. Regardless of the buffer size, the option to dynamically adjust the buffer must be off in the ATA. The modem can't handle it being changed during a call. The effects of latency are most observed during the handshaking sequence.

The ATA is sensitive to anything that increases load on it during a modem call. Using the second line simultaneously can affect the performance of the modem call and lead to connection drops. Also viewing the voice status and refreshing the metrics during a modem call will lead to a connection drop.

Echo cancellation and fax detection will trip you up. You can either manually disable them in the line settings, or you can prefix your outgoing modem call with *99 to put the line in modem passthrough mode. This star code has the same effect as toggling the "modem line" option in the voice line settings, but it will only affect the specific outgoing call for which it is dialed.

With all this, I'm still only able to get reliable connections at 14.4k. 33.6k is possible with a particularly low latency path, but otherwise the latency will cause the handshaking to fail. The >33.6k modes will occasionally link with a low latency path, but I haven't been able to get them to work. This was tested using an old still operational dial-up access number.
 
maxtherabbit said:
I have been experimenting with using a dialup modem through an ATA 191. My findings so far:

Make sure you disable SIP ALG in your router. It is not necessary to manually forward the SIP or RTP ports to the ATA, in fact doing so will generate packet errors in the ATA debug log. Just make sure you enable the NAT keep-alive options in the ATA.

Latency and jitter are killer. You can mitigate the jitter by increasing the jitter buffer (set network jitter setting to "extremely high") but this comes at the cost of additional latency. Regardless of the buffer size, the option to dynamically adjust the buffer must be off in the ATA. The modem can't handle it being changed during a call. The effects of latency are most observed during the handshaking sequence.

The ATA is sensitive to anything that increases load on it during a modem call. Using the second line simultaneously can affect the performance of the modem call and lead to connection drops. Also viewing the voice status and refreshing the metrics during a modem call will lead to a connection drop.

Echo cancellation and fax detection will trip you up. You can either manually disable them in the line settings, or you can prefix your outgoing modem call with *99 to put the line in modem passthrough mode. This star code has the same effect as toggling the "modem line" option in the voice line settings, but it will only affect the specific outgoing call for which it is dialed.

With all this, I'm still only able to get reliable connections at 14.4k. 33.6k is possible with a particularly low latency path, but otherwise the latency will cause the handshaking to fail. The >33.6k modes will occasionally link with a low latency path, but I haven't been able to get them to work. This was tested using an old still operational dial-up access number.
Click to expand...
Ah yes, the stuff of nightmares!

I supported a network of 350 locations. Every one had a FAX machine or two. Fax over IP (using an ATA) was always unstable.
We were constantly changing settings trying to keep it all running. Nothing ever worked for more than a couple of weeks.
Finally bought an expensive FAX server and replaced every FAX with a printer/scanner. The trouble calls stopped.

I never liked faxing over IP.
 
To follow up on the "ATA is sensitive to anything that increases load on it during a modem call" thing:

I've been experimenting with this further. It seems that making/sustaining a call on the second line doesn't cause problems, but that in fact hanging it up does. I believe this may be attributable to the "call statistics" settings in the ATA configuration. This enabled it to collect statistics on the active call(s) and send them to the other party at the end of the call. I suspect this may be increasing processing load slightly. I have disabled it and will continue to test. For now consider use of the second line to be experimental.
 
I had a respectable experience with analog modem connectivity through a NetTalk Duo WiFi device over a decade ago, some of the details for which I'd posted about on this forum.

I configured a Linksys SPA2102 several months back, hoping to replicate or even better the same success, but found the experience to be comparatively worse, and despite the additional configurability options of the SPA/ATA models. A glaring issue is the abnormally high and performance-impacting ~100ms of G.711 decode latency reported by the unit. Thinking that a current-model ATA192 might have a more-performant chipset, potentially addressing the codec latency, I also bought and tested one of those. Alas, no; the deficiency persists. It's worth mentioning that the same, ~100ms decode latency is present even just dialing between the two FXS ports, sans any network involvement.

So, unless or until some new information is forthcoming - configuration tweaking or otherwise - my experience with, and opinion of, pairing a Linksys/Cisco ATA with a modem is not the greatest.
 
Cloudschatze said:
I had a respectable experience with analog modem connectivity through a NetTalk Duo WiFi device over a decade ago, some of the details for which I'd posted about on this forum.

I configured a Linksys SPA2102 several months back, hoping to replicate or even better the same success, but found the experience to be comparatively worse, and despite the additional configurability options of the SPA/ATA models. A glaring issue is the abnormally high and performance-impacting ~100ms of G.711 decode latency reported by the unit. Thinking that a current-model ATA192 might have a more-performant chipset, potentially addressing the codec latency, I also bought and tested one of those. Alas, no; the deficiency persists. It's worth mentioning that the same, ~100ms decode latency is present even just dialing between the two FXS ports, sans any network involvement.

So, unless or until some new information is forthcoming - configuration tweaking or otherwise - my experience with, and opinion of, pairing a Linksys/Cisco ATA with a modem is not the greatest.
Click to expand...
I have noticed the same issue with the decode latency, although occasionally it will report as low as 50ms.

Do you think a grandstream device may fair better?
 
I found little note in the cisco manual which recommends a jitter buffer size of "very high" for fax passthrough. It seems like this is also the sweet spot for modem calls, I'm now able to sustain reliable connections, and even error-free zmodem downloads at 26.4k and sometimes 33.6k
 
maxtherabbit said:
Do you think a grandstream device may fair better?
Click to expand...
I couldn't say. I'm hoping to hear of others' experiences with Grandstream devices as well.

maxtherabbit said:
I found little note in the cisco manual which recommends a jitter buffer size of "very high" for fax passthrough. It seems like this is also the sweet spot for modem calls, I'm now able to sustain reliable connections, and even error-free zmodem downloads at 26.4k and sometimes 33.6k
Click to expand...
That's great news. My use-case for VoIP sort-of evaporated as a result of other solutions, but your results are making me want to give the Cisco ATA another go.

Are you able to sustain a connection to The Hidden Reef BBS (718-448-9402)? That had been particularly troublesome for me over the ATA.
 
maxtherabbit said:
I found little note in the cisco manual which recommends a jitter buffer size of "very high" for fax passthrough. It seems like this is also the sweet spot for modem calls, I'm now able to sustain reliable connections, and even error-free zmodem downloads at 26.4k and sometimes 33.6k
Click to expand...
This is pretty impressive, is this in the lab or over the internet?

Cloudschatze said:
Are you able to sustain a connection to The Hidden Reef BBS
Click to expand...
What kinda speeds are you getting on an average BBS

I'm assuming you are all talking SIP. Are any of the other protocols better/worse?
 
Is the goal to use VOIP for modems across the internet, or is the goal to use physical modems for your vintage computer setup to communicate with other things (local or distant)?

Asking this as if the goal is just to use modems for your vintage computers then you could use a PBX that is known to have no latency problems or whatnot, perhaps even an older one that does the switching fully analogue. Or a less realistic setup would be to just simulate a line using a small DC power supply (wall wart) in series with two modems. The PBX option is more attractive as it does ringing, dialing and whatnot just like regular phone lines did.
 
mR_Slug said:
This is pretty impressive, is this in the lab or over the internet?


What kinda speeds are you getting on an average BBS

I'm assuming you are all talking SIP. Are any of the other protocols better/worse?
Click to expand...
Internet, and yes using SIP

The worst part of it is the input lag. It is somewhere between 0.5-1 second between keypress and seeing the character echo when connected to a BBS
 
Ah I was just reading about Telebit TrailBlazer modem. It's multi-channel implementation caused problems with lag. I've had ssh connections worse than 1 second lag before though.

Im assuming this is SIP>POTS>receiving modem. Though I guess the connection may be SIP>POTS>SIP>modem.

I'm interested about the viability of a SIP/other connected BBS. And the results are better than I thought.


Yes I have a PBX, which is fine for 33k or less, though for 56K you need a PBX with a T1/E1 connection to a RAS that has Digital modems. This is how you got a v.90/92 connection. Typically this would provide a TCP/IP internet connection, don't think many BBS's were on a RAS. You can emulate the POTS in a lab*, but it's connecting it to other places, you are limited to your network, (unless you still have a landline). Does anyone know anything about TDMoverIP? As I understand it, it solved some of the lag issue.

*Here's my POTS setup:
8xFXS----Cisco 3825----T1---Cisco AS5350
2xBRI-------^

I don't quite have all the parts yet But I will have just enough of the POTS to finally get 56k, locally.
 
Cloudschatze said:
I couldn't say. I'm hoping to hear of others' experiences with Grandstream devices as well.


That's great news. My use-case for VoIP sort-of evaporated as a result of other solutions, but your results are making me want to give the Cisco ATA another go.

Are you able to sustain a connection to The Hidden Reef BBS (718-448-9402)? That had been particularly troublesome for me over the ATA.
Click to expand...
Yes I made it through and was connected for 20min. I sent you a message there
 
mR_Slug said:
You can emulate the POTS in a lab*, but it's connecting it to other places, you are limited to your network, (unless you still have a landline).
Click to expand...

Yes and no. Even with just a basic telephone line simulator or direct modem-to-modem connection, the "target" modem can be connected to a DTE that provides external network access, sans landline. So, for example, I have a Raspberry Pi Zero W with a USB attached modem as part of my "POTS-in-a-lab" setup. Dialing into that gets me Telnet and PPP access beyond my network (an enhanced "ISP in a box," basically). Further, given modem sharing over Telnet, a static WAN IP, and port-forwarding, anyone over the internet can also hit my setup.

PSTN.png
 
Last edited:
Oh yes I'm aware you can do a local modem setup to an IP server, then telnet to a BBS. This is probably preferable over a SIP connection due to the lag mentioned above. However the telephone network ends at your Pi.

Im on a vintage phone forum and they have 2 networks you can join, and everyone is linking PBXs and all sorts of telephone exchanges. As the POTS network disappears It would be interesting if we had something like this with modems in mind. It does look possible with SIP.

BTW, If you needed to dial a BBS in 1988, but you are at a large corp. Did you typically have a modem on your desk connected via a PBX? Or would you connect to a terminal server over a network, that had modems to dial out on?
 
mR_Slug said:
Yes I have a PBX, which is fine for 33k or less, though for 56K you need a PBX with a T1/E1 connection to a RAS that has Digital modems. This is how you got a v.90/92 connection. Typically this would provide a TCP/IP internet connection, don't think many BBS's were on a RAS.
Click to expand...
I have to admit that I'm more interested in the voice than modem aspect of this, but...
My general impression is that at least a while ago T1/E1 interfaces for a PC were still considered an "expensive" item for "professional" use and you never found any cheap one for next to nothing that would work with Asterisk, or where documentation were available to write your own driver for Asterisk.

I haven't looked into it but unless it already exists it seems like a project for someone way more skilled (in digital signal processing and whatnot) to implement 56k modems in software for connecting to for example Asterisk.

Going off on a tangent, I remember that Ken Shiriff created a bridge to the old Xerox 3Mbps Ethernet thing. This makes me think that it's most likely possible to use similar hardware to build a T1/E1 interface thing.
https://www.righto.com/2018/01/xerox-altos-3-mbs-ethernet-building.html
(I've been quite reluctant of getting any E1 stuff myself as although I have E1 cards for my PBX (Ericsson ASB 150/02, also known as BusinessPhone), I'm not sure if they actually work. Many years ago I tried connecting two such PBX'es to each other with the E1 cards but I couldn't get anything to happen. Maybe this PBX always assumes that whatever it's connected to has a higher spec clock and thus can't generate the clock itself, only sync up to the other end?)
 
As I understand it there is something like a network end and terminal end, I think the network end usually provides the timing signal, so perhaps the PBX just doesn't support that?

As I understand it, the digital modems receive a PCM waveform in the 64Kb/s stream, then mixes in responses etc. I think if you had code (or a spec) of what sound does what, you could probably get a soundcard talking to a 56k modem. Though I'd imagine it would be a lot of work.

Interesting xerox project.
 
You must log in or register to reply here.
Back
Top