Hello Mychaela, Am 29.02.24 um 11:19 schrieb Mychaela Falconia: 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

Sarah wrote: Christoph wrote: 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~

Hi Christoph, 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: the icE1usb is strictly E1 only. T1 is significantly different, it's not just a different clock / bit rate. -- - Harald Welte <laforge(a)gnumonks.org> https://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

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:

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: