Some years ago, a technician told me to allocate 100kpbs per call for VOIP phone traffic. This baffled me because our phone service nominally runs at 64kbps.
I thought VOIP would be compressed. I guessed because IP runs over Ethernet, which is CSMA, you can’t control for latency, and once your data gets to the Internet, you don’t know traffic conditions.
Consumer Internet Phonts
Lately, folks around me have called me via Signal and Facebook Messenger phone, and the results are less than amazing. They sound good, but you get flanging (it sounds like plucking a wire) from the compression and, probably, error correction.
They’re almost as good as Skype… which sounds the best. Google Hangouts could use some work, but sounds okay over wired broadband. The traffic over wireless seems to be worse. Perhaps it drops out more than I notice.
Industrial Internet Phones
Plain old SIP-negotiated calls are generally better, but still have that weird sound. The sick fact about these calls, however, is that most of them end up going to a POTS line most of the time, or end up going over fiber links that are prioritized for phone calls.
Why so bad?
Partly, it’s a conspiracy. Ethernet and UDP or IP aren’t ideal for realtime traffic. A T1 line is better because the signaling uses *time division multiplexing* (TDM). The wire has a stream of bits at a constant speed. T1 divides its signal into frames, and each frame carries 24 phone calls. (In the case of T1 PRI, it’s 23 calls and one data channel.)
The frames are a fixed size. So it’s like an assembly line, where the products go by at a constant rate, and they are handled as they pass by.
If you are a phone call, your data dribbles into a frame, then you wait until the next moment when you can dribble in more data. That times comes, you dribble data, and then wait. It goes on until the call is over.
In contrast, ethernet originated as a single wire on which multiple computers signalled. There was no “assembly line”. The ether would be quiet until someone needed to transmit — then the transmitter would listen to the wire to see that it was quiet. If it was quiet, it would send the data, as fast as possible.
The ethernet interfaces would be listening for data all the time.
It worked like a party line, which meant it worked well until there were many computer on the wire sending a lot of data. Then it became untenable, and people started using ethernet switches, which would isolate the signal to just the sender and receiver, and also buffer the data to avoid collisions.
You still had the problem of one computer hogging up all the bandwidth – as we do with LANs today.
The same problem happens with WiFi, because it’s also CSMA. That is only going to multiply the problems when it’s connected to Ethernet.
What would work?
It would be nice if there were a way to reserve around 300kbps for phone calls. This would be a permanent allocation of bandwidth. The only way to do it is to implement something like time division multiplexing over Ethernet. Every 100th of a second, the calls would get 3kb of data.
Likewise, an identical amount of time would be reserved for phones over WiFi, and the systems would be able to synchronize.
This low-bandwidth channel would be a great benefit not only to phone calls, but also for delivering small amounts of time-sensitive data.
However, I don’t see the industry going in that direction. I did a search for TDM and Ethernet, and it turned up [TDM over IP](https://en.wikipedia.org/wiki/TDMoIP).
[TDM for 802.11 Mesh Networks](http://home.intekom.com/satnac/proceedings/2008/papers/progress/Duff%20No%20138.pdf)