VoIPv6

[Greg Maxwell]

Not really for this task.. 

IPv6 = 40byte header
ATM = 5byte header, 48byte payload

Now,  for data due to the MUCH large allowed payload, IP wins out, but for
telephony
applications where latency is important (anything more then 300ms you need
echo canceling, more 100ms your users start wondering if you switched
their phone for a CB)

So lets assume a 1 way path latency of 25ms, and audio codec that outputs
16kbit/sec (perhaps adpcm with silencing, double-rate GSM, or others), and
lets calculate the maximum data packet to achieve 140ms one-way latency
(note: much less is desirable due to the complexity of echo canceling).

Okay, we lose 25 ms to network latency so that leaves 75ms for codec
delay and framing delay. Assuming that there is no codec delay (HA!), we
can only put 150bytes per packet. (75ms of 16kbit/sec is 150bytes).

That means we will emit 190 bytes per 75ms with IPv6 (20266.6kbit/sec),
giving a one way delay of 100ms ignoring all codec delays. Reality would
probably be a lot worse due to the codec delays.

For ATM we would emit 165.625 bytes per 75ms (17666.66kbit/sec).

ATM overhead: 10.4%
IPv6 overhead: 26.6%

It gets worse for better compression algorithms, and if you put in more
realistic delay numbers (codec delay, etc).. (8kbit/sec ABR is quite
realistic for better then toll quality voice). 

Of course, you can improve the solution quite a bit by multiplexing
multiple calls into one IP packet for transversal of longer delay links.

(BTW- My numbers may be a bit off as I'm not a telephony expert, I'm just
aware of the issues, nor is this an endorsement of ATM (yuch))

On Tue, 4 Jul 2000, Todd T. Fries wrote:

> This is very funny considering the atm networks upon which most phone
> systems reside have a 53 byte packet .. not all of which is for data ..
> so the data / header ratio is much worse in native telco land ..