Where to find free numbers for dialup access?

If using G.711 it will probably work. You may or may not have an option to choose VoIP CODECs.

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.
 
Last edited:
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.
 
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?
 
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?

As 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).
 
As 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).
T38 maximum baud is 14.4, so yeah, it can't use V.34

And that's right, the fax machine sends the analog tones to the T38 ATA, which then encodes it as an image, transmits that image as data to the corresponding T38 device on the other end, which decodes it back to the analog tones, which get sent to the fax machine. This eliminates the issues with latency but obviously does not tolerate packet loss.
 
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.
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.

If you are sending fax over SIP, then it's T.38 or nothing. I tell customers we only support fax over T.38 and if you must use G.711 or G.729, then you are on your own.

BTW - POTS lines don't have time sync end-to-end either.
 
BTW - POTS lines don't have time sync end-to-end either.

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:


Years ago there was some sort of problem where Contel/GTE in this area (Contel was a real "hillbilly" sort of phone company) had a clock slip on some of their interoffice trunks. The result was that, at 2400 baud, you'd get repeating characters of garbage coming across the screen. It was the same garbage characters repeated endlessly, over and over. Hanging up and redialing may or may not get a working connection, depending on whether your call went through a trunk that was configured correctly. (The problem NEVER happened on intraoffice calls, calls originating and ending in the same central office).

This was happening at about the time they were moving their interoffice trunks from T1 lines to fiber.

By the time I got a 14.4 modem, they had corrected the problem.
 
Last edited:
I remember when I worked a Safeway we would write up a stock order and then the manager would adjust it for sales or promotions and print the order using a machine that prints out a punch paper tape then down load the tapes information finally to a device like the above.
 
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:
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.

I'm so glad we are getting rid of all TDM.

Ethernet brings another problem, because it cannot provide clock. When you have Ethernet on the street side and terminate PRIs to a PBX on the customer side, accurate clock is a problem as are slips. Routers don't tend to have very accurate clocks, so we have to set our routers to slave from the customer PBX that's terminating the PRIs. Someone has to have a good clock for the PRIs to work. Generally PBXs have a much better clock than routers.
 
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.

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.

I'm so glad we are getting rid of all TDM.

TDM won't go away for a long time, if ever.. Anything running over any OC type circuit is using TDM.
 
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 :)

I don't have a single customer with OC-x, they have gotten rid of all of it. POS interfaces are too expensive compared to Ethernet and Ethernet is taking over the world.

How did we get here by talking about where to find a dial-up number? LOL
 
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 :)

It might take that long for "Happy Valley Telephone Company and Golf Cart Repair" to upgrade their equipment. Small independent telephone companies in rural areas without the deep pockets of AT&T and Verizon. Even Contel, which was at one time the 3rd largest phone company in the USA, ran on a shoestring budget compared to the big two (Bell and GTE).
 
Back
Top