VoIP over Dialup, Redux
Aswath Rao wrote to me to provide me some corrected facts about my VoIP over Dialup blog entry.
Grandstream reference you quote states that the overhead is 54 bytes per RTP packet. I don’t think they have included the 4 octets of CRC in the Ethernet frame. So the total bandwidth consumed needs to be appropriately increased.
You’re probably right there. I think most people forget that. I know they do in Nokia’s IPSO Operating System when you’re trying to set the MTU size of the interface.
In a dialup connection, we will be using PPP rather than Ethernet. So, we should be using the PPP header information. Also if we assume that we use header compression (meaning we will not transmit Address and Control octets), the PPP overhead is only 4 bytes (ending Flag will be the beginning Flag for the next frame). So the total overhead becomes 44 bytes, which translates to [(44+38)x8x50] 32.8 kbps, which is a just fit for 33.6 kbps modem, if we are using iLBC 20ms codec. The end-to-end delay then becomes 20+20+20=60 ms delay. I am not sure what would be the impact on the speech quality. Otherwise I will say we can use iLBC codec. What are your thoughts?
A couple of thoughts here:
- It’s quite possible your phone line is being served as part of a Digital Loop Carrier or similar device. While this does have an impact on DSL availability for some people, the other thing it has an impact on is the ability to use your analog line for data. At best, you can get about 28.8k in these conditions, even with a 56k modem. The only time I’ve gotten anywhere near 53k (which is the best you can do in the US due to power limits mandated by the FCC) is on an analog channel of an ISDN circuit–something I had maintained for a number of years.
- This doesn’t take into account the latency of the dialup connection itself, which from my experience is anywhere from 150-200ms in each direction, at least to US-based destinations from a US-based dialup account. So really, we’re looking at about 200+20+20+20+200 = 460ms, which is in the same ballpark as a satellite connection.
- At least for PSTN connectivity, I don’t know too many providers that actually support iLBC as a codec, though I’d like to see more providers support it, as well as hardware manufacturers like Sipura. Certainly you can use it peer-to-peer, but the only hardware I know of that supports iLBC is Grandstream.
- Certainly, iLBC sounds better than G.723, but it does have higher bandwidth requirements.
As I’m writing this, I am remembering a particular streaming audio tool that worked real well on dialup, though you could definately tell it was compressed. It was primarily for streaming voice, using an outstanding 53:1 compression ratio! You can see what this tool was at a 1996 version of the voxware.com site. While the codec they developed (RT29HQ) was proprietary, it was designed with dialup in mind. Pity Voxware isn’t supporting those tools anymore….
