[retronet-discuss] Re: Software to emulate V.xxx modulations in PCM sample stream?

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~