1

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.

chrism2671
  • 2,549
  • 9
  • 34
  • 45
  • 2
    I think the answer is no, but if it's all setup, why not test it a bit? Call in a few times: put those calls on holding music and leave a message or have a test call with another member of IT. Or call mum, she'll be grateful :-) – DutchUncle Feb 18 '11 at 18:42

2 Answers2

3

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.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
  • Just to point out EC2 has kernel type that has a superior timer, which in my testing, was more than suitable for VOIP, even when transcoding codecs. I forget the name, but it should be obvious in the list of choices of what to boot (the list of kernels, not the list of instance types). – chrism2671 Dec 19 '12 at 11:10
  • I'm just using the standard kernel from the Ubuntu 10.04 LTS image. No issues with timing, so I haven't been motivated to check its setup. – Michael Hampton May 20 '13 at 03:23
2

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.

voretaq7
  • 79,345
  • 17
  • 128
  • 213
  • I think you're right here. I have tried for the longest time to get this working, and have blamed the connectivity etc etc, but it may in fact be the virtualization here that is the weakest link. As the new system will need to support around 20 simultaneous calls, maybe a proper installation is the best bet... – chrism2671 Feb 19 '11 at 17:50