Hello fellow retrotechnologists,
I am looking for any existing software implementations of V.xxx modulations, those used by analog modems over POTS. Specifically, I am looking for software that can grok and generate streams of G.711 PCMU or PCMA samples, whether it be ISDN/T1/E1 or RTP, and thereby digitally grok and generate voiceband modem waveforms that can interoperate with a real V.xxx modem on the other end of the link. I was previously given an impression that some free sw offerings already exist that do what I just described, but I don't remember any specific names, nor do I recall ever being given any direct links. Would anyone here happen to know about such software?
In my corner of USA I still have a real POTS landline, served out of a real 5ESS switch. That switch turns this POTS line into a 64 kbit/s G.711 PCMU sample stream, and using SIP trunk providers like BulkVS, I can access those PCMU sample streams (which were, once upon a time, telco-internal, unless you had ISDN which was super-rare in USA) when making and receiving calls on USA PSTN. I have a US Robotics Courier "V.Everything" modem connected to this POTS line, and my idea is to run some modem-emulating software on G.711 PCMU RTP streams on the SIP end - and aim for working interoperation between the real POTS modem on one end and a software emulation of modem waveforms in G.711 PCMU on the other end.
In this lovely country of USA we also still have some public (govt-operated) service numbers where an analog modem answers when you call:
https://www.nist.gov/pml/time-and-frequency-division/time-distribution/autom...
I can call that NIST ACTS number from any voice phone and hear the answering modem screeching at me. Back when GSM/2G service of T-Mobile USA was in much better condition (as recently as 2018), I was able to make CSD calls to that ACTS number from my FreeCalypso GSM MS devices, and I used to get reliable connections, receiving the time code in ASCII each time - thus T-Mobile must have had a working IWF gateway that turned CSD into analog modem emulation, the exact same emulation I am currently after. That sweet CSD IWF seems to be broken now, but last night I tried a long-distance call from my POTS line (with my USR Courier modem) to that ACTS number in Colorado, and on the second try I got a successful connection at 9600 baud. Thus NIST ACTS itself appears to still be up and functional, and if I can find some working modem emulation software, I want to try connecting to ACTS with a modem-emulating G.711 PCMU RTP stream.
Given that I operate my own Osmocom-based GSM network, my eventual goal is to build my own interworking gateway from GSM CSD to analog modem emulation, replicating the functionality that was wrongfully taken away by T-Mobile. However, before I bring GSM CSD into the mix, I seek to test the PSTN side of the equation by itself, just the leg between a software modem emulator in G.711 RTP and a real POTS modem on the other end. Toward that end, I would appreciate any pointers to suitable software implementations of V.xxx modulation standards.
M~
2cts...
spandsp
Christoph
Am 28. Februar 2024 19:12:43 GMT-07:00 schrieb Mychaela Falconia falcon@freecalypso.org:
Hello fellow retrotechnologists,
I am looking for any existing software implementations of V.xxx modulations, those used by analog modems over POTS. Specifically, I am looking for software that can grok and generate streams of G.711 PCMU or PCMA samples, whether it be ISDN/T1/E1 or RTP, and thereby digitally grok and generate voiceband modem waveforms that can interoperate with a real V.xxx modem on the other end of the link. I was previously given an impression that some free sw offerings already exist that do what I just described, but I don't remember any specific names, nor do I recall ever being given any direct links. Would anyone here happen to know about such software?
In my corner of USA I still have a real POTS landline, served out of a real 5ESS switch. That switch turns this POTS line into a 64 kbit/s G.711 PCMU sample stream, and using SIP trunk providers like BulkVS, I can access those PCMU sample streams (which were, once upon a time, telco-internal, unless you had ISDN which was super-rare in USA) when making and receiving calls on USA PSTN. I have a US Robotics Courier "V.Everything" modem connected to this POTS line, and my idea is to run some modem-emulating software on G.711 PCMU RTP streams on the SIP end - and aim for working interoperation between the real POTS modem on one end and a software emulation of modem waveforms in G.711 PCMU on the other end.
In this lovely country of USA we also still have some public (govt-operated) service numbers where an analog modem answers when you call:
https://www.nist.gov/pml/time-and-frequency-division/time-distribution/autom...
I can call that NIST ACTS number from any voice phone and hear the answering modem screeching at me. Back when GSM/2G service of T-Mobile USA was in much better condition (as recently as 2018), I was able to make CSD calls to that ACTS number from my FreeCalypso GSM MS devices, and I used to get reliable connections, receiving the time code in ASCII each time - thus T-Mobile must have had a working IWF gateway that turned CSD into analog modem emulation, the exact same emulation I am currently after. That sweet CSD IWF seems to be broken now, but last night I tried a long-distance call from my POTS line (with my USR Courier modem) to that ACTS number in Colorado, and on the second try I got a successful connection at 9600 baud. Thus NIST ACTS itself appears to still be up and functional, and if I can find some working modem emulation software, I want to try connecting to ACTS with a modem-emulating G.711 PCMU RTP stream.
Given that I operate my own Osmocom-based GSM network, my eventual goal is to build my own interworking gateway from GSM CSD to analog modem emulation, replicating the functionality that was wrongfully taken away by T-Mobile. However, before I bring GSM CSD into the mix, I seek to test the PSTN side of the equation by itself, just the leg between a software modem emulator in G.711 RTP and a real POTS modem on the other end. Toward that end, I would appreciate any pointers to suitable software implementations of V.xxx modulation standards.
M~ _______________________________________________ retronet-discuss mailing list -- discussion@lists.retronetworking.org To unsubscribe send an email to discussion-leave@lists.retronetworking.org
Hello Mychaela,
there's no really good option for this right now (especially at higher speeds), but supersat wrote this yate module to run an old "Winmodem" driver binary (sl-modem) from a PBX. It's not very polished, but it will work up to 33.6k (or even 56k in outgoing calls). There are some problems/concerns regarding reliability of the connection, I still haven't gotten it to be fully stable.
https://github.com/Shadytel/shadysoftmodem
Good luck!
Best regards Sarah / manawyrm
Hi Sarah,
there's no really good option for this right now (especially at higher speeds), but supersat wrote this yate module to run an old "Winmodem" driver binary (sl-modem) from a PBX. [...] https://github.com/Shadytel/shadysoftmodem
I looked at the source tree at that link, and - please correct me if I got it wrong - it seems to me that it uses some binary-only *.o code pieces, i.e., blobs. If this solution is indeed blobware, then it is very UNattractive...
However, prior to your reply, Christoph Lauter pointed me to spandsp - seeing that name in Chris' response jogged my memory, I now recall someone else (perhaps it was you?) mentioning spandsp to me earlier, in some OsmoDevCall or RetroNetCall chat.
I cloned spandsp from github and started looking at it. At first glance the code looks very complete, and appears to have all of the pieces I am looking for. However, the giant red flag I see there is almost complete absence of documentation. Sure, there are some sprinkled doxygen comments, but no REAL documentation. I wonder if perhaps Steve U (the author of spandsp) follows a business model where the code is released under GPL, but instead of proper documentation that would allow anyone to self-support, he offers paid support to those who need it badly enough...
When I have more time (always the big uncertainty), I will try digging through that spandsp code a bit harder, with a goal of figuring out how to exercise V.21 modem functions for a start, and try building a SIP+RTP 300 baud modem on top of the lib - and I may also try emailing Steve U and asking him about his support offerings...
M~
Hello Mychaela,
Am 29.02.24 um 11:19 schrieb Mychaela Falconia:
If this solution is indeed blobware, then it is very UNattractive...
Agreed, 100%. Especially because it's a 32bit/i386 blob, which is getting harder and harder to run on modern systems.
I was thinking about building some weird setup with qemu-i386 and just let the binary run in there. The other downside of the blob is that it's designed to be used with a Winmodem via AMR, so that means 16bit linear 9600 Hz samples, while we're using 8bit G.711 at 8000 Hz of course. The resampling and format conversion probably isn't ideal for that either (also introduces additional latency, etc.).
Sadly, right now, it's the only way to do V.34 (or even V.90) in software. The free implementations like linmodem, spandsp, etc. all have some parts of the code, but they don't work in pratice / are missing pieces.
libspandsp can do 14400 baud under ideal conditions, but it was basically only tested against fax modems (as it's mostly used for fax). In my testing, I was only able to establish a data call in a single direction (iirc inbound) and with an Acer V.90 modem. Both of my softphones failed to connect, as did my 14400 hardware modem.
So yeah, please do test around, if you'd like share your findings here (or the forum), I'm very interested in the topic and sad that there's no good solution.
Best regards Sarah / manawyrm
Hello,
For V.21 speeds, spandsp works fine. I wrote a couple of Asterisk bindings for spandsp modems, to do 50baud 5bit tty, 300baud Bell, 1200/75 V.23 Minitel/BTX. That was no issue at all. I should have these lines open to CNET, if someone wants to try.
Christoph
Am 29. Februar 2024 03:19:55 GMT-07:00 schrieb Mychaela Falconia falcon@freecalypso.org:
Hi Sarah,
there's no really good option for this right now (especially at higher speeds), but supersat wrote this yate module to run an old "Winmodem" driver binary (sl-modem) from a PBX. [...] https://github.com/Shadytel/shadysoftmodem
I looked at the source tree at that link, and - please correct me if I got it wrong - it seems to me that it uses some binary-only *.o code pieces, i.e., blobs. If this solution is indeed blobware, then it is very UNattractive...
However, prior to your reply, Christoph Lauter pointed me to spandsp - seeing that name in Chris' response jogged my memory, I now recall someone else (perhaps it was you?) mentioning spandsp to me earlier, in some OsmoDevCall or RetroNetCall chat.
I cloned spandsp from github and started looking at it. At first glance the code looks very complete, and appears to have all of the pieces I am looking for. However, the giant red flag I see there is almost complete absence of documentation. Sure, there are some sprinkled doxygen comments, but no REAL documentation. I wonder if perhaps Steve U (the author of spandsp) follows a business model where the code is released under GPL, but instead of proper documentation that would allow anyone to self-support, he offers paid support to those who need it badly enough...
When I have more time (always the big uncertainty), I will try digging through that spandsp code a bit harder, with a goal of figuring out how to exercise V.21 modem functions for a start, and try building a SIP+RTP 300 baud modem on top of the lib - and I may also try emailing Steve U and asking him about his support offerings...
M~ _______________________________________________ retronet-discuss mailing list -- discussion@lists.retronetworking.org To unsubscribe send an email to discussion-leave@lists.retronetworking.org
Sarah wrote:
Sadly, right now, it's the only way to do V.34 (or even V.90) in software. The free implementations like linmodem, spandsp, etc. all have some parts of the code, but they don't work in pratice / are missing pieces.
libspandsp can do 14400 baud under ideal conditions, but it was basically only tested against fax modems (as it's mostly used for fax). In my testing, I was only able to establish a data call in a single direction (iirc inbound) and with an Acer V.90 modem. Both of my softphones failed to connect, as did my 14400 hardware modem.
Christoph wrote:
For V.21 speeds, spandsp works fine.
My idea is to _start_ with V.21 in my bring-up journey, and then go up from there. Assuming that V.21 300 baud works, try V.22 1200 bps next, and then V.22bis 2400 bps. And if the latter also works, then start playing with modulations that are supported by V.32bis module in spandsp, beginning with 4800 bps. The overall idea is to see how high I can climb before the rig stops working.
Also please note the test setup I intend to use: my plan is to speak SIP+RTP (PCMU of course, no compressed codecs) to my SIP trunk interconnection point (bulkvs.com), either sending a call to or receiving a call from a POTS line (public phone number) on real USA PSTN. I *hope* that I can at least get 300 baud to work this way, to prove the most basic concept, but when I reach the speed at which this setup breaks, whatever bps number and modulation standard it will be, I won't have an easy way of knowing if it breaks because spandsp isn't quite there, or because VoIP-land parties who stand between me and legacy TDM PSTN are rearing an ugly head.
When I make or receive calls to or from PSTN phone numbers via BulkVS, here is what I see so far:
* On incoming calls, the SIP INVITE I get lists PCMU, PCMA and G729 in this order of preference; I then select PCMU in my SDP answer.
* On outbound calls, I send SIP INVITE offering only PCMU and PCMA in this order of preference (no compressed codecs), and BulkVS's SBC selects PCMU in its SDP answer.
* With PCMU selected by either of the above two paths, the RTP stream I receive has no dropouts, I get an RTP packet every 20 ms without fail, and the largest jitter I get is usually on the order of 1 ms.
* The very first RTP packet I receive has both sequence number and timestamp equal to 0 (not randomized), M bit set; all subsequent RTP packets have M bit clear, while sequence and timestamp increment in perfect cadence. Thus the incoming RTP stream truly look pristine.
But what I don't know is whether this pristine RTP stream I receive from BulkVS (or the bigger VoIP carrier just behind them) is the genuine truth or only an illusion. It would be most awesome if there is only one TDM-to-RTP conversion point somewhere, if the RTP stream I receive comes directly from that from-TDM converter, and if the TDM path between that conversion point and the 5ESS switch serving my home POTS line is pure and unbroken. But what if the pristine-looking RTP stream I receive is only an illusion? What if there are some compressed codecs, packet loss concealment, elastic jitter buffers or other badness deployed somewhere along the path invisibly to me, and the carrier VoIP switch closest to me merely reconstructs a pristine- looking PCMU RTP stream to "make the customer happy"?
At some point I will need to build a test setup that will allow me to exercise spandsp (or other candidate soft modem implementations) in a 100% controlled environment, without uncertainties of commercial VoIP-to-PSTN carrier environment muddying the waters. But that path will require acquiring a piece of hardware which I currently don't know where to look for: a real telco-grade channel bank or SLC (subscriber loop carrier) terminal, going from a T1 carrier to POTS FXS lines. A typical consumer-grade ATA, or even a "high-end" one, won't be good enough: if it converts POTS to SIP, it is too high-level and has too many unwanted smarts. Instead I want a traditional telco- style channel bank that turns POTS lines into a T1 carrier, then hook up that carrier to an icE1usb (I hope the latter can do T1 too, not just E1) with GPS timing, and have my own software be responsible for dialtone generation, DTMF decoding etc. But I don't know where to look for the necessary hardware...
M~
Hello,
The proof of the pudding is in the eating.
This is Bellmodem @1200 over an ATA over SIP over IAX to spandsp:
https://photos.app.goo.gl/8Lp3DJMaoWyK1iVm9
It just works.
Christoph
Hi Christoph,
The proof of the pudding is in the eating.
This is Bellmodem @1200 over an ATA over SIP over IAX to spandsp:
OK, so you have proof (of the pudding) that 1200 bps Just Works - very good to hear! Now can you do the same thing at 9600 bps? Back when T-Mobile USA had beautifully working CSD, I could make CSD calls from a GSM MS to servers with POTS modems, and it would connect at 9600 bps. I would like to replicate that feat, if possible - and I have a suspicion that this area is one where spandsp will need some further work, and/or there may be issues with the commercial SIP-to-PSTN path being not as pristine and transparent as it appears.
I still need to figure out how to build spandsp correctly (there are compilation options where I am not certain of the "right" choice, such as fixed point or not), and how to actually use spandsp library from my own programs. Would you happen to have an example of your own from-scratch C program using spandsp functions for that 1200 bps modem?
M~
The code is attachment. It's for an old version of asterisk, incorrectly linted, not very well written, comes with no warranties. You can consider it GPL.
Christoph
Mychaela Falconia wrote on 29.02.24 at 14:30:
Hi Christoph,
The proof of the pudding is in the eating.
This is Bellmodem @1200 over an ATA over SIP over IAX to spandsp:
OK, so you have proof (of the pudding) that 1200 bps Just Works - very good to hear! Now can you do the same thing at 9600 bps? Back when T-Mobile USA had beautifully working CSD, I could make CSD calls from a GSM MS to servers with POTS modems, and it would connect at 9600 bps. I would like to replicate that feat, if possible - and I have a suspicion that this area is one where spandsp will need some further work, and/or there may be issues with the commercial SIP-to-PSTN path being not as pristine and transparent as it appears.
I still need to figure out how to build spandsp correctly (there are compilation options where I am not certain of the "right" choice, such as fixed point or not), and how to actually use spandsp library from my own programs. Would you happen to have an example of your own from-scratch C program using spandsp functions for that 1200 bps modem?
M~
On Thu, Feb 29, 2024 at 12:34:16PM -0800, Mychaela Falconia wrote:
[...] Instead I want a traditional telco- style channel bank that turns POTS lines into a T1 carrier, then hook up that carrier to an icE1usb (I hope the latter can do T1 too, not just E1) with GPS timing, [...]
the icE1usb is strictly E1 only. T1 is significantly different, it's not just a different clock / bit rate.
RAD used to make converters (RAD SPD-T1/802) that glue the 24 T1 timeslots into an E1 and undo that on the other side. I guess DAHDI DACSing capabilities would be enough to achieve the same thing in software. They also made devices to put one E1 into 2 B8ZS-coded T1s; but that is another story. Adit 600s came with E1 controller cards and can, in combination with a T1 controller card, achieve the same. You need to be careful as I just recently discovered that ice1usb (with today's firmware) cannot do CAS, as even RBB CAS requires to know a frame's position in a superframe.
Christoph
Harald Welte wrote on 29.02.24 at 14:14:
On Thu, Feb 29, 2024 at 12:34:16PM -0800, Mychaela Falconia wrote:
[...] Instead I want a traditional telco- style channel bank that turns POTS lines into a T1 carrier, then hook up that carrier to an icE1usb (I hope the latter can do T1 too, not just E1) with GPS timing, [...]
the icE1usb is strictly E1 only. T1 is significantly different, it's not just a different clock / bit rate.
I forgot:
I am amazed that a Digium E1/T1 card has no problem with generating a T1 clock off a E1 clock. I had expected issues as T1 has a bitrate of 8000 * 193 bits/second and 193 is a prime number. It probably uses some hardware PLLs or the jitter on a digital is too low to be noticeable.
I am using OCTOI as an etalon at home, feeding the E1 into a 4 span card. 2 spans are in E1 mode, 2 spans are in T1 mode.
Christoph
Harald Welte wrote on 29.02.24 at 14:14:
On Thu, Feb 29, 2024 at 12:34:16PM -0800, Mychaela Falconia wrote:
[...] Instead I want a traditional telco- style channel bank that turns POTS lines into a T1 carrier, then hook up that carrier to an icE1usb (I hope the latter can do T1 too, not just E1) with GPS timing, [...]
the icE1usb is strictly E1 only. T1 is significantly different, it's not just a different clock / bit rate.
Hi Christoph,
I am amazed that a Digium E1/T1 card has no problem with generating a T1 clock off a E1 clock. I had expected issues as T1 has a bitrate of 8000
- 193 bits/second and 193 is a prime number. It probably uses some
hardware PLLs or the jitter on a digital is too low to be noticeable.
I am using OCTOI as an etalon at home, feeding the E1 into a 4 span card. 2 spans are in E1 mode, 2 spans are in T1 mode.
So it appears then that I should be able to use one of those Digium cards as my T1 interface, and in the interim use an icE1usb as a GPS-to-E1 timing path, until I build my own hw that would generate a timing-only T1 from a GPSDO?
Such is life: despite being Russian by birth and in many cultural ways, I see myself as an American in terms of telecom culture specifically, which is why I want T1 and not E1 even in my own self-contained lab environment.
M~
Yes, you can do that: ice1usb to drive an E1 input of a E1/T1 card, T1 off that card with the same timing stability.
GPSDO-ing a card should be easy as well, the same way as manawyrm has done it in the past with HFC BRI cards.
Christoph, a German, married to a French/Russian living in the US (well a human being, right?)
Mychaela Falconia wrote on 29.02.24 at 14:48:
Hi Christoph,
I am amazed that a Digium E1/T1 card has no problem with generating a T1 clock off a E1 clock. I had expected issues as T1 has a bitrate of 8000
- 193 bits/second and 193 is a prime number. It probably uses some
hardware PLLs or the jitter on a digital is too low to be noticeable.
I am using OCTOI as an etalon at home, feeding the E1 into a 4 span card. 2 spans are in E1 mode, 2 spans are in T1 mode.
So it appears then that I should be able to use one of those Digium cards as my T1 interface, and in the interim use an icE1usb as a GPS-to-E1 timing path, until I build my own hw that would generate a timing-only T1 from a GPSDO?
Such is life: despite being Russian by birth and in many cultural ways, I see myself as an American in terms of telecom culture specifically, which is why I want T1 and not E1 even in my own self-contained lab environment.
M~ _______________________________________________ retronet-discuss mailing list -- discussion@lists.retronetworking.org To unsubscribe send an email to discussion-leave@lists.retronetworking.org
Hi Mychaela,
aside from spandsp, there's also the long-abandoned linmodem project by Fabrice Bellard. I made it build under [then] current linux/gcc a few years back, see https://gitea.osmocom.org/retronetworking/linmodem and there's also some related issues in our redmine at https://osmocom.org/projects/linmodem/issues
linmodem is probably less complete or even field-proven than spandsp. However, it does have some nice bits like visualization (via X11) as well as a channel simulator for the telephone line so you can simulate the performance of modems via that channel simulator.
discussion@lists.retronetworking.org
-
Christoph Lauter -
Christoph Quirin Lauter
-
Harald Welte -
Manawyrm -
Mychaela Falconia