
FreeSwitchに切り替えたのは少し前のことで、このシステムは非常に興味深いものであり、非常に大きな機会を与えてくれます。市販のアナログ製品でさえも機能が遅れています。 日常の活動でアスタリスクを使用することから徐々に離れます。
多くの人に質問があります:なぜFreeSwitchは慣らしテスト済みのアスタリスクよりも優れているのですか?
なぜ最も単純なXMLダイヤルプランを理解できないのですか?? アスタリスクがあるとき!
FreePBXのような機能に非論理的なWebインターフェイスがない限り、FSはAsteriskより悪くないと思います...
残りはちょうどそれを超えています!
利点の説明はここにあります。
chan_dongleのopengsmアナログ、Zapのfreetdmアナログなどがあります。
FSの音質が最も印象的でした。シンプルなG.711でも、アスタリスクよりも優れていました。
そして、HDコーデック(CELT、Siren、Silk、ARM-WB)についてはどうでしょう。また、それらで動作する多くのソフトフォンが既にあります。 アスタリスクも何らかの方法でこれらのコーデックをサポートしますが、不快な音で、比較はできません!
それらと連携できるAndroid用BriaまたはLinphoneの例。

実際、この記事はテスト結果を伝えるために書かれました!
VoIPトラフィックを生成し、さまざまなシナリオを作成して、ソフトスイッチをテストできる、興味深いHP SIPPユーティリティがあります。
パラメーターを備えたPCは、テスト用のサーバーとして機能しました。
Intel Core i3 3200
4 Gg DDR3
500 Gb HDD
そのようなもの。
Debian 6.0.4がプリインストールされている場合
試験方法:
sippは1秒あたり10回の呼び出しを行い(実際に他のパラメーターを選択できます)、呼び出しに応答してmusiconholdをオンにし、さらにシステムとの完全な会話のように、rtpエコーをすべてに追加しました。
sipp 192.168.1.200 -s 110 -i 192.168.1.4 -d 2h -l 1 -aa -mi 192.168.1.4 -rtp_echo -nd -r 10
最初のテスト対象は、ソースからコンパイルされたアスタリスク1.8.13です。



Asterはリアルタイムで168の接続を維持し、その後完全に落ちたか、システムをしっかりと停止しました。
少し思ったが、どういうわけか正しく組み立てられていないと思っていた! システムをゼロからインストールし、Asterisk 1.8.11をDigiumリポジトリからインストールしましたが、Asterisk 10.5でも同じ結果になりました!
実際の生活では、さらに少ない通話が想定されるため、これは本格的な通話ではなく、一方からの通話です。
以下はFreeSwitch 1.2でした:



半分の負荷でプロセッサが1000コールを保持していることがわかります!!! 判明したように、FS自体の1000の呼び出しにはソフトウェアの制限がありますが、それを削除する場所はまだわかりません。
彼はさらに1000を引いたと思われます))
そして、テストの最後はElastix 2.3のアセンブリでした。ボックス化されたソリューションで既にどのように動作するかは非常に興味深いものでした。 そして、結果は私を襲った! 本質的に同じアスタリスク:


Elastixは約500のコールを保持し、100%の負荷でシステムを中断しませんでした!
CentOSはVoIPに多少適合しているようですが、おそらくElastixの人たちは何らかの形でAsterをひねっています)
それでも、FSは通常の動作でシステムをロードしていない間、 アスタリスクを少なくとも4回バイパスします!!!
テストはVoIPLabコミュニティによって実施されました。