Alex Barnes wrote:
Overhead is not really the issue. The problem has to do with the internals of TCP an UDP. In general if you run UDP over TCP you will have issues due to the acknowledgement, state handling, etc and the fact that this can introduce delays when packets get dropped (a TCP connection will wait for the missing packet and let the retry happen, while UDP just goes on to the next packet, which is important for streaming audio such as VOIP).Just my 2p.
But might it not be a better idea to push for proper secure SIP support. However this requires a number of steps in the * dev:
- TCP Support for SIP - TLS Support for SIP - SIPS Support - Secure codec support via * (SRTP - http://www.voip-info.org/wiki-SRTP) tho transcoding is probably not needed as that would defeat the object.
Else would VPN's with IPSec or whatever incur less overhead????
What happens then is that a dropped packet will not cause "jitter" but rather a delay in the audio. This is the problem.
IPSec will probably introduce more overhead than a simple UDP over TCP, it will create far better sound quality. I am not sure whether SSH has more or less overhead than IPSec (I suspect less, but I am not sure), but the important issue is that IPSec allows Udp to be run over IP like it was designed to be run rather than over a TCP tunnel, so you have better performance.
UDP over TCP is not always so bad-- something like DNS or NetBIOS is going to do very little other than add potential delay and a little overhead. But for streaming applications, it is disasterous.
Best Wishes, Chris Travers
begin:vcard fn:Chris Travers n:Travers;Chris email;internet:[EMAIL PROTECTED] x-mozilla-html:FALSE version:2.1 end:vcard
_______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
