[asterisk-dev] Routing data modem calls

Andrew Kohlsmith akohlsmith-asterisk at benshaw.com
Fri Jul 28 06:08:01 MST 2006


On Friday 28 July 2006 05:27, Brian Candler wrote:
> Furthermore, a G.711 call uses a large bandwidth (up to ~120kbps), even for
> a low data rate modem, or when no data is being transmitted. A typical ADSL
> line has an uplink capacity of 288kbps, so 2 calls would eat all that up.

??  Most ADSL lines around here (southwestern Ontario, Canada) are 800kbps up, 
but yes, we can get pretty low depending on distance from CO.  My home, for 
example, has an uplink of 512kbps.

Also, a ulaw audio stream in RTP is about 80kbps.  Of course that is 80kbps 
upstream, 80kbps downstream, but you don't get to add them together and say 
it's 160kbps (or 120kbps in your example).

> 4. V.42 error correction is implemented using HDLC frames. If there was an
> RTP payload type for carrying HDLC frames, these could be exchanged
> end-to-end. It would have the advantage of performing end-to-end error
> correction, data compression and flow control between the endpoint modems,
> without the intervening network having to get involved.

This would be nifty.  I've also noted that most POS terminals use 2400 baud 
since there is no channel equalization or excessive training performed and 
this keeps call length to a bare minimum.  (Useful because they typically 
dial some 800# and the POS vendor likely has 1/1 billing on their 800 line.)  
I've not noticed much trouble with 2400-baud modem connections over stable IP 
networks, but then again I'm not willing to say it will always work, 
either.  :-)

Faxes are more of a problem because their lower-end connection rate is 
typically 9600 baud. Although some will "train down" (Mr. Underwood would be 
the authoritative source on these terms and implementation) to 2400 or even 
1200 baud, I have not seen this much in practice.

These points aside, you have put a lot of thought into this and I hope some 
decent conversation and even feasible goals come out of this.  I'll be 
watching this thread carefully.  :-)

-A.



More information about the asterisk-dev mailing list