• 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)

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.
T1/E1 may be expensive still, but I don't think they are necessarily impossible to get going with Asterisk should you get your hands on one. The Dialogic cards at least seem to be well enough documented with drivers available for download, though its possible some driver features may come with a licensing fee.

If you don't specifically need T1/E1, then going with ISDN BRI is probably cheaper. My PBX (a Pansonic KX-TD1232) has six ISDN BRI lines that can be configured as CO or extension lines, so I picked up a pair of Dialogic Diva BRI-2 cards (the ones with two DSP chips each) pretty cheap on ebay. These should be able to terminate two V.90 calls each, but I've not had the time since they arrived to properly have a go at getting it all working. Last I was working on it, I was having trouble getting the Linux drivers to load (CPU too old/driver too new?), and I'm not sure I've got the PBX end configured correctly (the documentation is a bit light on details).

For making data calls over the internet, V.150.1 and V.152 have relevant sounding titles though last time I looked into it nothing free implements either of these standards. I'd guess you probably need noisy Cisco widgets or similar at either end.
 
T1/E1 may be expensive still, but I don't think they are necessarily impossible to get going with Asterisk should you get your hands on one. The Dialogic cards at least seem to be well enough documented with drivers available for download, though its possible some driver features may come with a licensing fee.

If you don't specifically need T1/E1, then going with ISDN BRI is probably cheaper. My PBX (a Pansonic KX-TD1232) has six ISDN BRI lines that can be configured as CO or extension lines, so I picked up a pair of Dialogic Diva BRI-2 cards (the ones with two DSP chips each) pretty cheap on ebay. These should be able to terminate two V.90 calls each, but I've not had the time since they arrived to properly have a go at getting it all working. Last I was working on it, I was having trouble getting the Linux drivers to load (CPU too old/driver too new?), and I'm not sure I've got the PBX end configured correctly (the documentation is a bit light on details).

For making data calls over the internet, V.150.1 and V.152 have relevant sounding titles though last time I looked into it nothing free implements either of these standards. I'd guess you probably need noisy Cisco widgets or similar at either end.
That's a very cool looking PBX. If I hadn't just picked up a KX-TA824 a couple of weeks ago I would look into one myself. Didn't even know ones with BRI extensions were available on the surplus market. Does it still maintain a fully analog path for regular calls and allow full usage of SLTs like the TA series hybrids?

Would something like an adtran total access allow you to bridge some of those BRI CO lines to a VoIP trunk for a fully digital path upstream of the PBX?

As for me, I received an offer from an ebay seller on a grandstream HT802 in my watch list and couldn't resist. So I'll have some more data to report soon.
 
I'm getting 26400 on outbound calls from FiOS voice service to real phone lines, and can fax over it too.
 
That's a very cool looking PBX. If I hadn't just picked up a KX-TA824 a couple of weeks ago I would look into one myself. Didn't even know ones with BRI extensions were available on the surplus market. Does it still maintain a fully analog path for regular calls and allow full usage of SLTs like the TA series hybrids?

Would something like an adtran total access allow you to bridge some of those BRI CO lines to a VoIP trunk for a fully digital path upstream of the PBX?

As for me, I received an offer from an ebay seller on a grandstream HT802 in my watch list and couldn't resist. So I'll have some more data to report soon.
AFAIK it fully supports SLTs including pulse dialing on any line, and I've not had any trouble getting modems to talk through it. Its own digital proprietary phones seem to communicate with the PBX digitally though - you can plug an SLT or modem into some of them, and the SLT/modem will have its own extension number and work independently of the digital phone its plugged into:
1750634122561.png
The manual does mention ISDN phones, and CO lines could of course be digital too. So given either end of a call could be digital or analog it seems like it would make the most sense for it to convert analog calls to digital as soon as possible rather than trying to maintain a fully analog path, but I've not seen any technical description anywhere for how these things actually work so who knows.

For a fully digital upstream path, I guess I could probably use one of the Dialogic Diva cards with Asterisk. Currently I'm just using some old Cisco ATA connected to one of the analog CO lines, but I don't really have anywhere useful to VoIP to - outbound calls are kind of expensive. Mostly I just use the PBX as an intercom and for making modem calls within the house. If I can get the ISDN Extensions working properly and can get two of them hooked up to the Dialogic cards then maybe V.90 dialup, and perhaps if it supports ISDN data calls between extensions then maybe I might even be able to make that ISDN port on the SGI Indy do something.
 
I'm getting 26400 on outbound calls from FiOS voice service to real phone lines, and can fax over it too.
According to an old post I found on the verizon community forums, the fios voice ports on the ONT don't use VoIP per-se - they encode the voice calls and send them via circuit-switched ATM to the local digital phone switch. You should be able to do better than 26.4k on it. @vwestlife demonstrated a V.90 connection at 48k over fios voice in an old youtube video. I messed around with it a little at my dad's house a few years back when he still had the fios voice service but my memory of the exact link speeds is a bit foggy now. I'm pretty sure I was getting at least 33.6k
 
I figured it was something like that. In this world of 4K streaming video and 100GB video game patches, why is aggressive lossy compression of calls even a thing?
 
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.
Not exactly. It sort of takes a detour in the above diagram. That is, I'm able to dial into either the Pi or Patton setup locally from either the Tandy or Dell systems, Telnet to the MA100, and then dial-out from its modem across the Comcast landline. Granted, it's an overly roundabout mechanism, but it further permits me to share the landline-connected modem to anyone across the internet.

@mR_Slug the Empire of the Dragon BBS may be of interest to you
https://bbs.fandom.com/wiki/Empire_of_the_Dragon

They offer true 56k dial-in but I'm not exactly sure of the hardware they use to support it. I assume ISDN modems
I'm left wondering how I would go about something similar with my setup. I have 56k (V.90) dial-up connectivity locally through the Virtual Console and Patton combination, but to offer 56k dial-up externally... I'm unsure of what would/could replace the need for an actual, provider-based T1/PRI.
 
Good point! A sound card obviously have a high enough quality to be able to act as a "56k server".

Wasn't there sound cards that also doubled up as "voice modems", or am I mixing things up? I.E. it might had been the case that some internal "voice modems" looked like sound cards as they had jacks for mic/headphones, but maybe those jacks only had 8-bit 8kHz quality at best.

Either way it should be fairly easy to interface line in+out of a sound card to a modem/phone line. Either just use the classic transformer setup found in telephones from before semiconductors started replacing the transformer, or use a circuit with OP amps and whatnot.

My gut feeling is that if someone starts out with a simple circuit that people who don't have that much electronics skills can build, someone who is good at software might come in and improve a started project. I.E. start out with the simplest possible code for echo cancellation and emulating the early 300bps modems, and build from that.

Thinking about it, you could even just use a series resistor from line out to the other end = modem, and connect line in directly to the other end, and run a fairly heavy echo cancellation in software. That way the likelihood of a "software person" taking on the project might increase.

Or for that sake somehow configure an ATA to use non compressed audio.

P.S. I wonder why 56k modems never were made in a way that they can connect at 56k to each other over a pure analogue line? I get why they can't do that through a digital exchange/pbx, but still.
 
T1/E1 may be expensive still, but I don't think they are necessarily impossible to get going with Asterisk should you get your hands on one. The Dialogic cards at least seem to be well enough documented with drivers available for download, though its possible some driver features may come with a licensing fee.

If you don't specifically need T1/E1, then going with ISDN BRI is probably cheaper. My PBX (a Pansonic KX-TD1232) has six ISDN BRI lines that can be configured as CO or extension lines, so I picked up a pair of Dialogic Diva BRI-2 cards (the ones with two DSP chips each) pretty cheap on ebay.
Ideally I would find a newer CPU card for my PBX, with built in IP telephony capabilities, but I don't know how good/bad that would work with modem calls. Unfortunately it seems like the only source for things like this at decent prices is at electronics surplus auctions and whatnot, as on eBay and at other online sellers things are priced for making money off of those who keep legacy systems alive in actual commercial use. IIRC there were cards for my PBX that allows it co connect to BRI lines but I assume those cards also are at least as expensive as a Dialogic card, or a new CPU card for the PBX that supports IP telephony. And in comparison both a Dialogic card or a new CPU card for the PBX seems like a better option than a BRI card for the PBX.

I used to have some "phone line simulator" boxes but for ISDN, IIRC one had like three PRI ports and one had a PRI and two BRI ports or something like that, but unfortunately I've either given them to someone else or they have ended up unterneath-behind [tm] somewhere. If I could find these I could use a BRI card in a PC. Somewhere I have or at least used to have some PCI card with a BRI interface, but I can't remember the details about what it was supposed to do or if there were any generic use drivers available for it.
 
Here's my .02 which may be controversial - don't use hardware PBX unless you have one with builtin ATA clearly supporting fax solution.

 
Here's my .02 which may be controversial - don't use hardware PBX unless you have one with builtin ATA clearly supporting fax solution.

That thread is about software PBX, not hardware. Did you mean to say "don't use software PBX" ?
 
Good point! A sound card obviously have a high enough quality to be able to act as a "56k server".

Wasn't there sound cards that also doubled up as "voice modems", or am I mixing things up? I.E. it might had been the case that some internal "voice modems" looked like sound cards as they had jacks for mic/headphones, but maybe those jacks only had 8-bit 8kHz quality at best.

Either way it should be fairly easy to interface line in+out of a sound card to a modem/phone line. Either just use the classic transformer setup found in telephones from before semiconductors started replacing the transformer, or use a circuit with OP amps and whatnot.

My gut feeling is that if someone starts out with a simple circuit that people who don't have that much electronics skills can build, someone who is good at software might come in and improve a started project. I.E. start out with the simplest possible code for echo cancellation and emulating the early 300bps modems, and build from that.

Thinking about it, you could even just use a series resistor from line out to the other end = modem, and connect line in directly to the other end, and run a fairly heavy echo cancellation in software. That way the likelihood of a "software person" taking on the project might increase.

Or for that sake somehow configure an ATA to use non compressed audio.

P.S. I wonder why 56k modems never were made in a way that they can connect at 56k to each other over a pure analogue line? I get why they can't do that through a digital exchange/pbx, but still.
There is some software modem implementations at the bottom of this page, though none of it 56K: https://osmocom.org/projects/retronetworking/wiki/Software_Modems
 
I've heard nothing but praise for grandstream ATAs.

Most of my actual phones are pulse dial, the Panasonic KX-TA824 and the like of analog PBXs are sought after as they do pulse to tone conversion & in call pulse to tone conversion. My Cisco routers support pulse to tone conversion for dialing, but not in call. So you can't use a menu system. Do you know if the Panasonic KX-TD1232 support in call pulse to dtmf?

the fios voice ports on the ONT don't use VoIP per-se - they encode the voice calls and send them via circuit-switched ATM to the local digital phone switch.
Now this is interesting, kinda ATM over IP, from what I understand. No?
Not exactly. It sort of takes a detour in the above diagram. That is, I'm able to dial into either the Pi or Patton setup locally from either the Tandy or Dell systems, Telnet to the MA100, and then dial-out from its modem across the Comcast landline. Granted, it's an overly roundabout mechanism, but it further permits me to share the landline-connected modem to anyone across the internet.
This is cool. I'm looking at terminal/console servers at the moment, and hope to have a similar setup. Anyone have any recommendations?
I'm unsure of what would/could replace the need for an actual, provider-based T1/PRI.
The only thing I know of is TDM over IP, The fios thing may work too, Unless I've misunderstood it.
Wasn't there sound cards that also doubled up as "voice modems", or am I mixing things up?
Yes software modems, all the call DSP functions run on your main CPU. If the DAC/ADC has the resolution, you may be able to reprogram a software modem. However I suspect they don't.
P.S. I wonder why 56k modems never were made in a way that they can connect at 56k to each other over a pure analogue line? I get why they can't do that through a digital exchange/pbx, but still

This is due to the state of the telephone network at the time it was introduced. If you take a completely analogue PBX/tel. Exchange, over a short distance you may be able to run Ethernet on it. Problem is by 1995 most of the network was T1 or E1, that encode each call in a 64kb/s format. As this was the current state of the network, the standard had to work with T1/E1. They couldn't get it to work with the additional A-to-D conversions.

A: Modem---analog---Modem at 56k (or perhaps more) would work. However most calls would have looked like this:

B: Modem---analog--AtoD-----64kb/s T1/E1 stream-----DtoA---analog---Modem
They couldn't get it to work, so they did this:
C: Modem---analog--AtoD-----64kb/s T1/E1 stream-----Digital Modem (speaking PCM)

As a result of this, a 56k connection never had an analog modem at the other end. They speak the same protocol, but they are different. The digital modem can transmit faster to the 56k modem, than the 56k can to the digital modem.

Now I'm a bit unsure of the low-level details, but I think the digital modem requires more processing power than the analogue 56k modem. So a standard 56k modem never had the signaling or hardware required for this. It saved on cost at the consumer end. Adding the additional hardware to each modem, would only allowed for local calls, it won't work over T1/E1 (well, not circuit B:, A: and C: would work).

I think there is a leased line analogue 56k standard, but I don't know much about it
 
Now this is interesting, kinda ATM over IP, from what I understand. No?
ATM over Ethernet, not IP. The ATM cells are wrapped in Ethernet frames.
Unfortunately I don't think this is a DIY option unless you pay for it from the service provider. But if you're willing to pony up for the monthly cost of the "landline" it would undoubtedly be the most performant option.

I didn't even know about the pulse-to-tone in call of the KX-TA824 until I got it setup. It is very cool because almost all my voice phones are rotary as well.
 
Yeah if it is over Ethernet, then you need the other end on that Ethernet connection. Also need to simulate the server, unless you are actually using the service. There is EoIP on mikrotik routers, so I guess you could do ATM-over-Ethernet over Ethernet-over-IP. But It's quite a lot of specific hardware. Don't think Linux can help here?

 
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.
How interested are you in knowing the reason? How in depth do you want to know?

The short answer is that there were issues with the ADCs the Bell network was using that severely limited the frequency (and thus baud rate) of signals passing through them. By the end of the 70s, that hardware was all but universal. Modem manufacturers figured out that the DACs Bell used had much less loss, and so you could successfully pass much more data through them. Where the ADCs sampled at "about" 4KHz, the DACs ran at 8KHz. This meant that with half a digital call path, you could send digital signals with reasonable success over an analog line. If you've ever handshook X2/K56Flex/v.90/v.92 with a USR modem and looked at the call statistics, you might have noticed that your "uplink" baud rate (going to the telco, through an ADC, to the other modem) was at most 3429, and that your "downlink" baud rate (coming from the telco through a DAC) was 8000. Your upload, still going through the ADC, was limited to v.34bis Trellis Code, but you could download over PCM (digital). Later, it was found that the ADCs *could* pass slightly higher bitrates if you were super careful about the ordering of your bits and had a pristine line. This was included as an option in v.92 as "PCM uplink," which allowed you an 8000hz carrier on an analog line, though only at 6 bits, leaving you 48K upload. It is my understanding that this was largely unsuccessful for basically all implementations, USR/3Com never implemented it at all and Patton disabled it after a few firmware updates. Interestingly, I've actually seen evidence that the maximum v.34bis Trellis code uplink was actually 33800, rather than 33600, but that this was never used because of FCC power limits. I wonder if you could eek out those extra 200 bits with a custom firmware, or even get 48K both ways on an analog circuit by attempting to use v.92 PCM uplink in both directions. Someday I might take a crack at this.

Interestingly, the DACs were all 8-bit. 8 bits x 8000hz = 64,000 bits per second, which is the capacity of a full fat ISDN bearer. There's a problem, though! Many telcos at the time were not fully ISDN, and only terminated CT1, no PRIs! This meant that they used RBS, Robbed Bit Signalling. It does exactly what it says on the tin, something like every 8 frames the telco would "rob" the least significant bit from the digital signal for their own equipment signalling. This comes up because there's no particularly good way to predict this behaviour, and it was so widespread in 1997 (and later) that rather than fight it and lose a bit randomly, the least signficant bit is simply unused. This leaves you with a maximum bandwidth of 7 bits x 8000hz = 56,000 bits per second. In reality, FCC and ITU restrictions prevented users from ever connecting faster than 54666 bits per second, but provisions were always made for 56000, both in ITU recommendations and in the receiving hardware. Again, it could probably be enabled with a creative firmware, if someone knew what they were doing.
 
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.
Getting a sound card to do telephony is fairly trivial and this is almost exactly what HCF (Host Control Function) modems are doing. They're just a DSP hanging off the PCI bus and your CPU hands off a waveform. This probably wouldn't work on the digital side, though.
 
Interesting back story about the ADCs and DACs in the Bell network.

However I would think that there must had taken place some work on modem standards elsewhere too.

Sure, Europe was way more split with different countries having different telecom monopolies, and later different competing telecom companies, using different hardware suppliers and whatnot. But I would think that many of these would had used better "sound" quality ADCs than those you mention, simply due to the switch to digital taking place later on.
 
Patton also makes a couple series of ATAs - they call them SmartNode. If the grandstream doesn't produce favorable results I might give one of them a try. They are in a higher price tier which 1) sucks but 2) means they might be better?

Unlike the offerings from cisco and grandstream they also have "modern" models with gig-e too.
 
This was included as an option in v.92 as "PCM uplink," which allowed you an 8000hz carrier on an analog line, though only at 6 bits, leaving you 48K upload. It is my understanding that this was largely unsuccessful for basically all implementations, USR/3Com never implemented it at all and Patton disabled it after a few firmware updates.
I assume you mean they never implemented it/disabled in their RAS?

What about connecting two v.92 modems together on a local analog PBX? Was the PCM uplink feature deprecated in the modems as well or just the RAS?
 
Back
Top