For signalling maybe, but not for RTP media streams and RCTP, read on down to section 7.6.2.1 of PKT-SP-SEC-I05-020116.
At 08:41 AM 1/29/02 +0800, Enzo Michelangeli wrote: >> > There are other problems with using IPsec for VoIP.. In many cases >> > you are sending a large number of rather small packets of data. In >> > this case, the extra overhead of ESP can potentially double the size >> > of your data. >> >> HOW small? You'd already be adding IP+UDP+RTP headers (20 [or 40] + >> 8 + 12 = 40 [or 60] bytes). Using ESP with authentication would add >> another 22, plus possible explicit IV and padding, if needed -- call >> it 30? >> >> 20ms of uncompressed telephone quality data is 160 bytes ... > >True, but VoIP uses pretty efficient codecs, typically compressing by a >factor of 8 (G.729) to 10-12 (G.723.1). On the other hand, the payload of an >RTP packet may contain more than one frame (increasing the latency, of >course: see e.g. http://www.openh323.org/docs/bandwidth.html ). > >Anyway, IPSEC (plus Kerberos/PKINIT) is the security mechanism chosen by the >PacketCable initiative: > >http://www.packetcable.com/ >http://www.packetcable.com/specs/PKT-SP-SEC-I05-020116.pdf > >Enzo > > > > > >--------------------------------------------------------------------- >The Cryptography Mailing List >Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED] > --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]