How are people making the case for IPv6 with [VOIP]? With G.711 and 20ms voice samples, with IPv4 you get:
If you're running G.711, you've decided that network bandwidth isn't a problem for your application. Percentage of overhead doesn't really matter - it's total overhead bandwidth compared to available bandwidth that sometimes matters. There are several different usage scenarios where there are different tools available for managing bandwidth consumption * LANs - you generally don't care * Single point-to-point calls between general-purpose Internet endpoints - bandwidth might matter, depending on the pipe size at each end, and compression can be useful, but usually the more important problems on small connections are MTU size (because of the latency of a 1500 byte packet on a 128kbps upstream) and to some extent prioritization. * Multiple simultaneous calls between endpoints on a Layer 1 or Layer 2 network - Voice over Layer 2 Frame or ATM has largely fallen out of fashion, though it worked well for its day. IP header compression from vendors starting with C is generally intended for this environment - some of the versions also support fragmentation to work around the MTU size problem, but many of them don't work well for Frame/ATM interworking. * Multiple simultaneous calls between a pair of Internet endpoints - there are trunking-style VOIP protocols such as some of the IAX versions that let you use one set of IP+Layer4 headers to carry multiple voice channels, and these can eliminate most of the per-call overhead (at least when you have most of your channels active, which is when it matters.) There are some other VOIP-call-stacking protocol approaches that at least let you use one set of IP headers to carry a bunch of {Layer 4 header + Payload} tuples that reduces some overhead. * Multiple simultaneous calls at one endpoint to a bunch of single-call or few-call endpoints across a general IP network. At the big end, the easy approach is to just buy fat pipes, but there are carriers or applications that use header compression on the access line, either with PPP headers to an access router or frame relay to an Internet or MPLS edge router. Unfortunately, we've mostly found it's difficult to make those solutions scalable - typically the access cards that are scalable for carrier-sized networks don't do that in ASICs, and the router doesn't have enough CPU horsepower to support a significant number of compression sessions in the main CPU at a reasonable price (where "reasonable" is defined as "cheaper than adding another access line and a couple more router cards".) * Encrypted Voice Sessions - the popular approach is to use IPSEC, which often requires adding a layer or two of NAT traversal UDP headers as well, so any complaints about the overhead of IPv4 or IPv6 headers on an 8kbps voice session just get multiplied. It's much more efficient to do the encryption at the voice layer (at least for Internet VOIP, as opposed to enterprise VPNs where all the bits are getting wrapped in IPSEC anyway.) SIP supports it, and even some H.323 versions have it tacked on, but I've found it very frustrating how much carrier-scale and large-enterprise VOIP equipment doesn't support payload encryption, so VOIP carriers either don't encrypt (leaving VOIP wide open to wiretapping without even the grudging pretense of protection of some of the CALEA rules), even on the media connection which is between callers, or it's an option that the carriers didn't buy/provision/activate/whatever. Skype at least gets some credit here (though they're using proprietary protocols and closed source, so it's impossible to tell whether they've done a secure implementation that doesn't leak keying material all over the place), and the Asterisk PBXs are capable of encrypting voice and signalling channels for many choices of endpoints. ---- Thanks; Bill