EC2で実行されるアスタリスクPBXを設定し、信頼できる通話品質を実現することは可能ですか？
1000HzクロックのEC2カーネルがあり、これを使用してAsteriskなどをセットアップできましたが、他の問題（たとえば、ロンドンからダブリン、ロンドンへのトランジット-現在のパス）がg729との使用で問題を引き起こす可能性があるかどうか疑問に思っています。多分20の同時チャネル。
どうもありがとう、クリス。
簡単な答え：いいえ。
より長い答え：VOIPサービスは非常に正確なタイミングを必要とします。これはany仮想化環境では事実上不可能ですが、ほぼ確実に問題外です。 EC2のような共有環境では、他の人のワークロードがシステムのパフォーマンスに影響を与える可能性があります。最良のVOIPソリューションは専用サーバーであり、通常、ある種の専用ハードウェアタイミングソースが含まれています（システムが「純粋なVOIP」であっても、電話会社のラインカードなど）。
サーバーのタイミングの問題以外に、デスクフォンから「クラウド内」のサーバーとの間でやり取りする追加のラウンドトリップ時間の遅延により、通話品質の問題が発生することも予想されます（遅延が発生して、自分で話し始める可能性があります） 、ラインエコーなど）-これは、サーバーへの遅延がわずか10〜15ミリ秒のVOIPシステムで顕著になる可能性がありますが、約25ミリ秒以上で明らかになります。
簡単な答え：はい。
より長い回答：この質問が行われた直後から、過去18か月間EC2でAsteriskシステムを実行してきました。 EC2を使用しているために、通話品質に重大な問題が発生したことはありません。これは、全国的にシンジケートされた米国のトークラジオ番組のリスナーコールインラインとビジネスラインを提供し、スタジオへの4つの回線と、それを超える無数のキューがあります。通話品質の問題がある場合は、ホストが非常に短い順序で首から息を吐きます。
もちろん、@ voretaq7が彼の回答で示した警告が当てはまります。
電話会議や保留音などが正しく機能するには、信頼できるタイミングソースが必要です。 （トークラジオ番組はMOHを使用します。）幸い、dahdiドライバーは、仮想化されたUSBサブシステムから十分な信頼性の高いタイミングを取得できます。これは、ラインカードがシステムに存在しない場合のタイミングソースのフォールバックです。
また、レイテンシを可能な限り最小限に抑える必要があります。米国-東アマゾン地域のAsteriskサーバーでは、sip show peersによって報告されているように、スタジオのATAに対して約28〜30ミリ秒の遅延が発生しています。物理的に配置されています。前述のように、それを超えると品質の問題が発生する可能性があります。
あなたの場合、アイルランドへの往復の待ち時間はこの考えを殺す可能性がありますが、待ち時間の特定の測定値を与えていないので、確信するのは難しいです。少なくとも小さなインスタンスを使用する場合は、20チャネルでもCPUの問題が発生する可能性はほとんどありません。