There is an EC2 kernel with a 1000Hz clock, which I have successfully used to set up Asterisk etc already, but I am wondering if other issues (e.g. transit from London to Dublin to London- our current path)- could cause problems using g729 and maybe 20 simultaneous channels.
Many thanks, Chris.
Short answer: No.
Longer answer: VOIP services require extremely precise timing, which is practically impossible in any virtualized environment, but almost certainly out of question in a shared environment like EC2 where other people's workloads can affect your system's performance. The best VOIP solutions are dedicated servers, and typically include some kind of dedicated hardware timing source (like a telco line card, even if your system is "pure VOIP").
Beyond the server timing problems you can also expect that the additional round-trip-time delay to get from your desk phone to/from a server "in the cloud" would cause call quality issues (delays long enough that you might start talking over yourself, line echo, etc.) -- This can be noticeable on VOIP systems with as little as 10-15ms latency to the server, but becomes obvious over about 25ms and worse from there.
Short answer: Yes.
Longer answer: I've had an Asterisk system running on EC2 for the last 18 months, beginning shortly after this question was asked; it has never had a significant call quality issue caused by being on EC2. It provides listener call-in lines and business lines for a nationally syndicated US talk radio show, with four lines into the studio and an indefinite number in queue beyond that; and if there is a call quality issue I have the host breathing down my neck in very short order.
The caveats given by @voretaq7 in his answer apply, of course.
You must have a reliable timing source for things like conference calls and music-on-hold to work properly. (The talk radio show uses MOH.) Fortunately the dahdi driver is able to get reliable enough timing from the virtualized USB subsystem, which is their timing source fallback when a line card is not present in the system.
You also must minimize latency, as much as possible. With the Asterisk server in the US-East Amazon region, I'm getting about 28-30ms latency to the ATAs in the studio, as reported by sip show peers, which is about the best I can do because of where the studio is physically located. Anything above that, as previously noted, is likely to cause quality issues.
In your case, the latency to Ireland and back is likely to kill this idea, though you didn't give any specific measurement of the latency so it's hard to be sure. If you use at least a small instance you aren't likely to have any CPU issues even with 20 channels.
