[beardoc]

Originally Posted by Mal

Still, it is a good idea as long as VOIP is sufficiently neutered or blocked.

There are ways around that - it will depend on how good the service is and what sort of latency people can expect as to whether it is usable for VoIP or gaming inflight.

[NM]

Originally Posted by beardoc

There are ways around that - it will depend on how good the service is and what sort of latency people can expect as to whether it is usable for VoIP or gaming inflight.

How much latency would you expect? And how much (little) is ok for VoIP? What do you consider the upper limit for latency for usable VoIP?

[beardoc]

Originally Posted by NM

How much latency would you expect? And how much (little) is ok for VoIP? What do you consider the upper limit for latency for usable VoIP?

Given I assume that it's a satellite-based connection, I would expect the latency to be high. Sattelite connections vary greatly in terms of their latency, but they're generally much higher than fixed broadband or even terrestrial wireless connections.

It does depend a little on the codec that you and your VSP (Voice Service Provider) use, however. The most common codecs used in Australia are g.711 (a-law and u-law), which is what the standard voice network now uses, and g.729, which is a slightly more compressed codec. g.711 is highly latency sensitive, and likely would fail outright. g.729 might work a little, but would likely suffer dropouts.

There is a little known codec called iLBC (internet low bitrate codec) which is designed for high latency connections, however, it's not well supported (I only know of MyNetFone supporting it at the moment, although I understand that Pennytel will do so shortly), which degrades much better over higher latency connections (it's more tolerant of voice packets arriving out of order over a data connection), but even if it works well, you will find that there's a long delay (you say hello, and you have to wait for them to receive it and then say hello back - and you may find that you end up talking over each other as the delay from you to them and them to you means that the conversation doesn't flow smoothly.

In other words, it's possible, but there are some unique challenges, and some pretty major compromises. If you're determined to have voice calls on an international flight and not mortgage your house, though, this would be doable.

Not that I'm advocating it - a plane full of chattering people would be painful!

[dot]

Originally Posted by beardoc

Given I assume that it's a satellite-based connection, I would expect the latency to be high. Sattelite connections vary greatly in terms of their latency, but they're generally much higher than fixed broadband or even terrestrial wireless connections.

Actually, it is not via Satellite as Connexions was, it uses a set of 'cell' towers across the LOTFAP so the signal form the aircraft goes directly to those cell towers and then onto the Internet at that point (or possibly back to a central POP on Aircell's network). I would expect the latency to be similar to a conventional 3G (UMTS) connection (probably a bit poorer because the distance from the plane to the tower will typically be greater than the average mobile phone based connection). The connection looks like this:

WiFi Client --- WiFi Access Point --- Airborne Router --- Aircell Radio --- Aircell Tower --- Aircell Ground Network --- Router --- Internet

The problem with the Aircell system is that if you are not over the USA (including Alaska and Hawaii) you cannot connect. Connexions by Boeing got over this by using a satellite connection along with it's higher latency.

As for using a VoIP Softphone over the link, given they permit VPN connections, you could easily run your corporate VoIP connection through that VPN tunnel. Dont expect any of the public VoIP connections (Skype, Internet SIP services etc) to work. I have used my corporate VPN over a EDGE (128kbps) connection and successfully used the corporate VoIP over that link. There was a noticeable delay (say half a second) during the conversation and the occasional drop out (on the other end - I heard everything fine on my laptop). Despite this, I still would not expect hoards of people using VoIP in flight.

[NM]

Originally Posted by beardoc

Given I assume that it's a satellite-based connection, I would expect the latency to be high. Sattelite connections vary greatly in terms of their latency, but they're generally much higher than fixed broadband or even terrestrial wireless connections.

Why do you say its a satellite-based connection? According to a previous post in this thread by dot:

Originally Posted by dot

I agree that latency will be relatively high, but I wouldnt expect it to be much worse than a current 3G (UMTS) connection as the link from the aircraft is directly to the ground rather than via a satellite like Connexions by Boeing was. Hopefully, the Aircell groundstations and network connections have been well designed to minimise latency for pax.

If this is true, then wouldn't latency basically be the radio transmission time from the aircraft to the ground receiver (basically the speed of light over say 40,000 feet vertical component and up to several hundred miles lateral component), plus modulation/demodulation delay? Then assume they trunk all the traffic back to one central gateway which could be at the opposite side of the continent in the worst case. So based on these assumptions I see the following:

Radio transmission distance = 500km maximum
Radio transmission speed = speed of light = 300,000,000 m/s
Radio transmission delay = 500,000/300,000,000 = 1.7ms
Round-trip latency due to radio link = 2 x 1.7ms = 3.4ms
Radio Modulation/demodulation Delay = 5ms
Ground station trunk to internet gateway (round trip time) = 30ms

total latency from aircraft to internet gateway = <40ms

Now we do also need to consider the serialisation delay at each point, which is dependent on the individual interface speeds in the path. Assuming we are only considering VoIP and save G.729 CODEC and a sample rate of 10ms and packet rate of 50pps, we have 20 bytes of data in each packet, plus 20 bytes of IP header, 8 bytes of UDP header and 12 bytes of uncompressed RTP header, so packet transmission will be padded to 64 byte minimum for IP (i.e. minimum size packets). Hence serialisation delay is low, even for low bandwidth interfaces.

So it would seem that latency is not going to be a major concern for such a connection. I regularly use G.729 with well in excess of 350ms round-trip delay.

The biggest issue I would expect, as related to VoIP call quality, will be packet lossdue to congestion. If packet queuing delay exceeds the jitter buffer (typically around 40ms) then late arriving packets are seen as lost packets. G.729 (and G.711) treats out-of-sequence packets as lost packets since its only got UDP for delivery. So assuming they do not limit MTU size (i.e. carry 1500 byte packets) or implement any form of QoS on the link, congestion or contention will likely result in VoIP packet loss either from tail-drops at the congestion point or jitter buffer over-run at the receiving station.

Originally Posted by beardoc

It does depend a little on the codec that you and your VSP (Voice Service Provider) use, however. The most common codecs used in Australia are g.711 (a-law and u-law), which is what the standard voice network now uses, and g.729, which is a slightly more compressed codec. g.711 is highly latency sensitive, and likely would fail outright. g.729 might work a little, but would likely suffer dropouts.

The network characteristics of G.711 and G.729 are similar. Both generally operate with a sample interval of 10ms and combine two samples into each packet for a packet rate of 50pps. G.711 carries 160 bytes of data in each RTP packet, while G.729 only carries 20 bytes. I don't understand why you suggest G.711 is highly latency sensitive. G.729 introduces slightly more latency due to the compression overhead, being about 10ms for G.729 and <1ms for G.711.

Originally Posted by beardoc

There is a little known codec called iLBC (internet low bitrate codec) which is designed for high latency connections, however, it's not well supported (I only know of MyNetFone supporting it at the moment, although I understand that Pennytel will do so shortly), which degrades much better over higher latency connections (it's more tolerant of voice packets arriving out of order over a data connection), but even if it works well, you will find that there's a long delay (you say hello, and you have to wait for them to receive it and then say hello back - and you may find that you end up talking over each other as the delay from you to them and them to you means that the conversation doesn't flow smoothly.

iLBC is decribed in RFC3951. As iLBC still uses RTP for its transport, it will still consider out-of-sequence packets as lost packets. Its just that due to its use of linear predictive coding the voice quality degrades gracefully with packet loss, hence being considered more tolerant of out-of-sequence packets. But its not an option for most corporate VoIP implementation based on iPBX technology from the major IPT vendors today.

Originally Posted by beardoc

In other words, it's possible, but there are some unique challenges, and some pretty major compromises. If you're determined to have voice calls on an international flight and not mortgage your house, though, this would be doable.

I don't see it as any more challenging than operating over a hotel WiFi internet service or an airline lounge, and I have used my G.729 connection many times under such conditions - with mixed success depending on the congestion of the internet gateway.

Originally Posted by beardoc

Not that I'm advocating it - a plane full of chattering people would be painful!

Agree totally, and even if I could do it, I would not.

[dot]

An update to this story (and technology) - Aircell have announced that their next generation of Gogo service will use LTE technology - see here - this will enable (they claim) the connection from the ground to the aircraft to be increase from it's current 12Mbps (peak) to 300Mbps (peak). I would expect them to continue to use WiFi on board for the local conection.