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. _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev