- Joined
- Jun 8, 2022
- Messages
- 5,543
I haven't had a land line in 15 years. Its cool to know some of these things still exist.
Most landlines these days are provided by cable companies and are VOIP.I haven't had a land line in 15 years. Its cool to know some of these things still exist.
So can I connect my 14.4 on VOIP to a ISP in North Dakota and post something on a message board?Most landlines these days are provided by cable companies and are VOIP.
If using G.711 it will probably work. You may or may not have an option to choose VoIP CODECs.So can I connect my 14.4 on VOIP to a ISP in North Dakota and post something on a message board?
That pre-dates me, I was born in '80.How many have used an acoustic coupler? I used them regularly.
View attachment 121355
If using G.711 it will probably work. You may or may not have an option to choose VoIP CODECs.
Yeah, fax works decently well over T38, I wonder if you could use that for dial-up? IIRC, you'd be limited to 14.4 but who cares if all you are doing is playing around.No, it probably won't work. The reason why is that there is no clock synchronization from end to end, which results in the occasional sample being dropped. You can't hear it, but your modem (or fax machine, if you are sending faxes) will absolutely not like it.
Even with G.711, when I did testing years ago, I couldn't get more than about half a page of a fax sent before it errored out. And that was with two ATAs connected together in the same network, nothing was going over the internet.
The issue, as far as I could determine, happens when one side is sampling at (for example) 8000.01 samples per second and the other is playing it back at 8000.02 samples per second. Because there is no clock synchronization, there is no way for both sides to sample at exactly the same rate. Sooner or later, the mismatch between the clock rates at both ends is going to result in a buffer overrun or underrun, and samples will be discarded or inserted to make up for it. When that happens, fax error. Or modem error.
This is why there is a standard for fax over VOIP where the ATA basically decodes the fax transmission (much like a fax modem would) and turns it into digital data, and the ATA at the receiving end encodes the digital data back into a fax transmission.
For PacketCable/DOCSIS cable modem ATAs, it's different. These do seem to be clock synchronized from end to end. Fax and modem works great over them. But you aren't going to be selecting the codec on these, I think they always default to a full-rate codec.
Yeah, fax works decently well over T38, I wonder if you could use that for dial-up? IIRC, you'd be limited to 14.4 but who cares if all you are doing is playing around.
Good point, I was thinking it could "image it" like it does with fax (analog tones -> encode -> image -> decode -> play analog tones) but I assume T38 is designed around those analog tones resulting in a valid "image" of the fax, which probably wouldn't work for just data that lacks fax content?I don't think a T38 device would know what to do with a V.32bis modem signal.
Good point, I was thinking it could "image it" like it does with fax (analog tones -> encode -> image -> decode -> play analog tones) but I assume T38 is designed around those analog tones resulting in a valid "image" of the fax, which probably wouldn't work for just data that lacks fax content?
T38 maximum baud is 14.4, so yeah, it can't use V.34As I recall, T38 actually demodulates the analog fax tones and turns them into the corresponding digital data just like a fax machine does. So when you send a fax through a T38 device, your fax machine is actually handshaking and communicating with the T38 device, not the fax machine on the other end.
Also, the modulation schemes used for fax are mostly different than those used for data modems. "Super Group III" faxes use V.34 and V.34bis at 28.8 and 33.6 speeds respectively, which are the same as used for modems, but all other Group III fax speeds are different protocols, incompatible with data modems.
(I remember having a faxmodem that could send faxes at 9600 baud, but data was limited to 2400 baud).
Me too. 1980!!!That pre-dates me, I was born in '80.
We have tested modems running at 14.4 over G.711 extensively at work and it mostly works. "Mostly" is the operative term. When it doesn't work, you're pretty much out of luck. The problem usually is lost packets, sometimes even one. G.711 does not have any mechanism to handle lost packets, nor should it. You just have to live with an occasional disconnect while using modem over SIP.No, it probably won't work. The reason why is that there is no clock synchronization from end to end, which results in the occasional sample being dropped. You can't hear it, but your modem (or fax machine, if you are sending faxes) will absolutely not like it.
Even with G.711, when I did testing years ago, I couldn't get more than about half a page of a fax sent before it errored out. And that was with two ATAs connected together in the same network, nothing was going over the internet.
The issue, as far as I could determine, happens when one side is sampling at (for example) 8000.01 samples per second and the other is playing it back at 8000.02 samples per second. Because there is no clock synchronization, there is no way for both sides to sample at exactly the same rate. Sooner or later, the mismatch between the clock rates at both ends is going to result in a buffer overrun or underrun, and samples will be discarded or inserted to make up for it. When that happens, fax error. Or modem error.
This is why there is a standard for fax over VOIP where the ATA basically decodes the fax transmission (much like a fax modem would) and turns it into digital data, and the ATA at the receiving end encodes the digital data back into a fax transmission.
For PacketCable/DOCSIS cable modem ATAs, it's different. These do seem to be clock synchronized from end to end. Fax and modem works great over them. But you cannot select the codec on these, I think they always default to a full-rate codec. In any case the codec used is controlled by the cable company.
BTW - POTS lines don't have time sync end-to-end either.
Yes, all TDM circuits have clock, they are either master or slave. If they have even one cycle that is off time, it's called a slip. When a circuit slips, then all bets are off until the circuit is resynced. POTS lines don't have master/slave clock, they just don't. The end station on a POTS line takes the timing that is given to them and they do not have the ability send any clock corrections or have the ability to act as master. While all other T1, PRI, DS0, etc can either listen to clock or provide clock. My point was the POTS line far end can never provide clock.Yes, they do. All of the TDM (traditional, prior to VOIP) digital circuits in the PSTN are (supposed to be) clock-synchronized. This includes T1, ISDN, DS3, OC3, all of it. That also means that the codec in the class 5 end-office that the POTS line is connected to is also clock-synchronized. I read that this clock is very, very accurate, and uses an atomic clock:
Ok, you are pretty seasoned for your age! Maybe you are the Canadian equivalent to Elon Musk ...That pre-dates me, I was born in '80.
POTS lines don't have master/slave clock, they just don't. The end station on a POTS line takes the timing that is given to them and they do not have the ability send any clock corrections or have the ability to act as master. While all other T1, PRI, DS0, etc can either listen to clock or provide clock. My point was the POTS line far end can never provide clock.
I'm so glad we are getting rid of all TDM.
All true.The POTS line is connected to a codec in a switch or a channel bank. That codec gets it's timing from somewhere, and it's the network. So when you make a call and both ends are POTS lines, the codecs at both ends are perfectly in sync because they are using the same clock.
Jus like how when you configure a T1 CSU/DSU, almost always you configure it for network timing, because your T1 line is coming from the phone company and they provide the clock.
The only time I've ever seen them configured for local timing is when they are connected back to back through dry copper, in that case one end is configured for local timing and the other for network timing. That's not a common configuration.
TDM won't go away for a long time, if ever.. Anything running over any OC type circuit is using TDM.
All true.
OCx is going away too. As soon as we get rid of the 4ESS and all the class five switches (5ESS, DMS, etc) the days of TDM are numbered. I'd give it another 25 years