ネットワークのエッジでSBCが必要な理由

この記事では、通信事業者や法人顧客にボーダーセッションコントローラー（SBC）が必要な理由について、広く一般に知られている基本データと事実を収集して要約します。 検索エンジンの平凡なクエリは多くの情報を提供せず、資料のプレゼンテーションの単純さとアクセシビリティを常に装うわけではありません。



アプリケーションの仮想化とネットワーク機能への関心の高まりは、「機能を失うことなくSBCを仮想環境に展開できるか」などの質問を追加するだけです。



名前が示すように、SBC（セッションボーダーコントローラー）は、ネットワークのエッジにインストールされ、何かを制御する機器（またはソフトウェア）です。



SBCが提供する制御は、主に音声トラフィック（信号とメディア）に関係しています。音声トラフィックの量は、TDMからIPへの移行により増加しており、IPは日々勢いを増しています。 すぐに、このタイプの機器は、通常のSPDネットワークのIPレベルで動作するファイアウォールおよびセキュリティシステムとは関係がないことに注意してください。 それどころか、最先端のファイアウォールでさえ何も制御できず、保護できる範囲がさらに狭い領域を補完およびカバーします。



まず、SBCが解決するタスクの理解を単純化するために、読者に、パケット音声のトピックでは、接続の確立に関係する有限要素のIPアドレスに関する情報が信号メッセージのいくつかの（異なる）場所にあることを思い出させたいと思います。 すなわち これは、第3レベルのIPアドレスだけでなく、より高いレベルのIPアドレスでもあり、1か所ではなく、パケットとメッセージのヘッダーだけでもありません。 トラフィックの音声タイプを制御する機器は、3番目（IP）から始まるすべてのレベルでのパケット音声伝送の詳細を認識、理解、分析する必要があります。



SBCの基本的な機能タスクを検討します。 各有声課題の後に、簡単な説明をします。



1.ネットワークの内部トポロジを外部から隠す。

内部トポロジとは、ネットワーク設定（IPアドレス）、デバイスとソフトウェアのバージョン、音声トラフィックパス、アドレス変換（NAT）の使用などに関する情報を指します。オペレーターや企業顧客のトップレベル管理が通常経験する疑問や驚きを排除するために、私はこれを言い換えます：はい、内部ネットワークインフラストラクチャに関するこのような繊細な情報は、部分的にまたは完全に、無料のアナルを使用して音声トラフィックを分析するだけで非常に簡単に取得できます 渋滞。 これは冗談ではありません。 このような情報は、信号およびメディア音声トラフィックのさまざまなフィールドとメッセージヘッダーから簡単に収集されます。 お客様のエンジニアリングサービススペシャリストの一部は、正常に受け流します。当社のネットワークデバイス（CPE、ルーターなど）は、これらの問題の解決に役立つALG（アプリケーションレイヤーゲートウェイ）機能を使用します。 これは部分的には真実ですが、非常に悲惨な部分だけです。 パケット音声の分野での長年の経験に基づいて、通常のトラフィックの伝送に問題を追加するだけのさまざまなALGの説明を完了するために、ALGとSBCを比較する簡単な表を示します。







SBCは、あらゆるレベルですべての情報パケットの完全な分析を実行し、どのジョイントでも外部への機密情報の転送を除外するような方法で音声トラフィックを処理できる必要があることがわかります。



次に、SBCのみについて議論し、あらゆる種類のALGを検討対象から削除します。



2.さまざまな物理ネットワークインターフェイスによる、信頼された（内部）ネットワークと信頼されていない（外部）ネットワークの分離（物理レベルでのネットワークの分離）

情報伝送保護は、トラフィックを処理および分析するためのさまざまなフィルター、アクセスリスト、およびその他のルールの設定だけではありません。 ほとんどのアプリケーションでは、異なる物理インターフェイスにジョイントを配置することにより、内部ネットワークと外部ネットワークを物理的に分離することをお勧めします。 多くの場合、このようなインターフェイスの数は2を超え、接続スキームに応じて決定されます。 原則として、少なくとも内部トラフィックと外部トラフィックの分離について話し、異なる物理インターフェイスによるトラフィックを制御することは理にかなっています。



3.ネットワーク保護

トポロジの非表示は、音声ネットワークのセキュリティについて議論する際に話し合わなければならない多くの側面の1つにすぎません。 ほとんどの場合、常にではありませんが、正しい保護戦略を編成するという問題は、ネットワークを保護し、サービス/ビジネスに害を及ぼさないという標準的なジレンマに陥ります。 すべてのトラフィックを処理と分析の厳格なルールに押し込むことができます。主なことは、すべてのサービスの合理的かつ正しい動作を確保することであり、加入者/顧客がネットワークをより適切に設定し、拡張サービスセットを使用できるようにした競合他社に行く理由を与えないことです。 実際には、ネットワーク管理者が知識の不足またはこの問題に対する十分な注意の欠如のためにそのようなバランスを維持していないことが多いため、私はこれをここで言及します。 そして、音声伝送の分野には専門家がそれほど多くないことを正直に認めなければなりません。



保護の問題を決定する際に注意すべき主なポイントの概要を説明します。



a）ハッキング保護

これは、保護の問題を議論するときに頭に浮かぶ最初のことです。 単純なものから複雑なものまで、破損時に常に使用されるいくつかのポイントをリストします。

• さらに、音声アプリケーションおよびソリューションの専用スキャナーによる使用済みポートの一般的なスキャン。
• ネットワークに関する詳細を調べるために、標準のアラームメッセージに対する機器の応答を確認します（最小限のデータでも次のハッキングステップを決定するには十分です）。
• 特定のタイプのサービスの定義（転送など）。
• SIPユーザー名とパスワードの選択。
• ネットワークトラフィックのスキャンとパケット分析。
• 登録済み/未登録のサブスクライバーに代わって呼び出しを試行しました。
• なりすまし（正当な加入者になりすます）;
• 信頼できるパッケージの置換と、確立された正当なセッションへの侵入の試み。

おそらく問題の重大度を理解するのに十分です。 通常のSBCは、これだけでなく、上記を知って対処できる必要があります。 そして、正確な音声トラフィックの詳細な分析がなければ、そのような闘争は無意味です。 ネットワーク管理者は、正常に動作するようにSBCを適切に設定する方法を知っている必要があることを理解する必要があります。 このため、知識に加えて、SBCにはさまざまな基準、たとえば失敗した登録試行の回数、不審なトラフィックの検出（上記のポイントだけでなく、たとえばSIPメッセージの長さの分析）などを設定する可能性がすべてあるはずです。



b）DoS / DDoS VoIP攻撃

保護されていない音声機器に触れるのは簡単で、必要なだけです。 そして、私を信じて、スーパーデュパーデータファイアウォールが使用されている場合でも、これを行う方法はたくさんあります。 繰り返しになりますが、問題は、SPD機器が、たとえば、正当かつ正当な加入者に代わって送信された途方もない量の登録から保護できないことです。 または、正当な加入者への呼び出しを確立するための信じられないほどの試行から。 そして問題は、ファイアウォールはすべてのトラフィックを制限なく通過させる必要があるということです。これは、完全に正当な加入者を対象としているため、処理する必要があるためです。



分析できる基準のほんの一部を次に示します。1秒あたりの登録試行回数、1秒あたりの送信ダイアログの設定数を超える、1秒あたりの同時確立コール、または1秒あたりのコール確立試行。 または、たとえば、それほど明白ではないもの：特定の加入者が占有している帯域（同時会話の数による帯域のカウントと制限は、特にメディア情報を調整することなく会話中に占有帯域を変更できる適応コーデックの出現により、長い間正しくなくなりました）。



c）無効な音声パケット

誤った音声パケットを送信すると、次のようないくつかの不快な瞬間が発生する可能性があります。



-長いパケットとアラームメッセージを送信します。

-シグナリングメッセージのヘッダーの長いフィールドと値の形成。

-確立されたシグナリングセッションにウェッジ（およびその後トラフィックを間違った場所にリダイレクト）しようとし、正当な加入者からのパケットをサードパーティだけでなく正当なパケットに置き換えます。

-変更された順序でアラームメッセージを送信する



音声サービスの不安定で誤った動作、またはパフォーマンスの低下につながる可能性があるため、これらおよびその他のトラブルはすべて高価になる可能性があることを明確にする必要はないと思います。



d）正しくないが違反していないSIPメッセージ

繰り返しますが、このようなパケットとメッセージは、許可された正しいアドレスにルーティングでき、正当なサブスクライバーにアドレス指定できるため、通常のファイアウォールを自由に通過する必要があります。 ただし、サービスの保守性に影響を与える可能性があるため、オペレーターに害と不便をもたらす可能性があります。



e）未登録のサブスクライバーの呼び出し

上記から、平凡な選択と未登録ユーザーへの許可された呼び出しにより、オペレーターを犠牲にしてトラフィックの「ドレイン」を編成することは容易ではなく、非常に簡単になることが明らかになります。 状況の喜劇的な性質は、深刻さを主張し、あなたがそのようなことをすることを可能にする多くの解決策があるということです。 状況の悲劇は、多くの人が自宅でそのような「解決策」を使用し、極度のリスクにさらされていることです。



f）分析と検証のための任意のルールを設定する機能（トラフィック分類）

通常のSBCは、頻繁に使用されるトラフィック分析ルールのテンプレートだけでなく、合理的な「ウィッシュリスト/チェッカー」も設定できる必要があります。 例として、少し誇張して、このような「ばかげた」検証規則を示します。着信INVITEに3つ以上のViaヘッダーが含まれ、3番目のViaヘッダーに172.x.x.100という形式のIPアドレスと、ユーザー部分のFromフィールドが含まれている場合XYZの文字のセット、そのようなトラフィックの処理を許可（または拒否）します。 この機能がSBCを使用する際に柔軟性を追加することは明らかです。



g）ダイナミックブラック/ホワイトリストおよびアクセスリスト

かなり標準的な機能。 SBCはトラフィックを分析し、その正当性を「自動的に」判断できる必要があります。 指定された基準を満たさない疑わしいトラフィックはブロックされます。 理想的には、保護は、たとえば、失敗した登録試行の回数、1秒あたりの登録試行の数、1秒あたりの送信パケットの設定数を超える、不審なトラフィックの検出（SIPメッセージの長さ、SIPメッセージの偽造および以前のアクティブへのウェッジなど）のカスタム基準に従ってサポートされる必要がありますSIPセッション）



h）静的ブラック/ホワイトリストおよびアクセスリスト

さて、それなしでは何ですか？ 例：特徴的な兆候があり、ネットワークに有害な悪性トラフィックを検出しました。 たとえば、管理者が一部のシナリオでSBCの動作を構成および設定することを「忘れた」または考えなかったためです。 迅速なブロックのために、悪意のあるストリームを一度にすべて閉じ、おそらくは有用なトラフィックの一部を閉じます。 そして、あなたは考えていなかった、欠落していたまさにそのルールを作り始めます。



確かに、保護のトピックに関連するより多くの例とタスクを与えることができます。 最も基本的なものを調べました。 ほとんどの場合、説明されているSBCの機能で十分です。



4. SIPヘッダーを使用した操作、SDPを使用した操作

SBCを通過するメッセージを変更する機能は重要です。 必要性を説明する最も簡単な例として、すでに上で説明したこと、つまり内部ネットワークトポロジを非表示にすることを思い出してみましょう。 SDPレベルでのアラームメッセージの変更により、ヘッダーから情報を削除することができます。ヘッダーから外部に光を当てる必要はありません。 別の例は、サービスのパフォーマンスが依存するアラームメッセージの情報を追加または変更する必要がある場合です。 SIPには、さまざまな方法を使用して技術的に機能するサービスがあることを思い出してください。 また、SIPトランクの背面では、ネットワークで使用されている方法とは異なる場合があります。 したがって、必要なフィールドを変更することで、さまざまな方法で機能する同じサービスのパフォーマンスを確保できます。



上記に加えて、シグナリングメッセージを変更する機能は、SIPメッセージのヘッダーとコンテンツだけでなく、これらのメッセージのSDP部分にも適用されると言うことは変わりません。 調整の正確さとメディアトラフィックの伝送のパフォーマンスはSDPに直接依存するため、これは重要です。



5. SIPの正規化

数が無限に大きいさまざまなSIPクライアントには、独自の特性がある場合があります。 多くの場合、これらの機能は、これらのクライアントを操作する際に、SIPメッセージの非標準または不正な形式のヘッダーとパラメーターが使用されることです。 SBCを通過するときのSIPメッセージの正規化は、基本および必須のSIPヘッダーを標準形式にすることを意味します。 これは、異なるSIPクライアントを使用する場合の安定化を意味します。



6. NAT（NAT Traversal）のサブスクライバーの作業を保証する

このトピックには特別な注意が必要です。 第一に、いわゆる仮想交換のサービスの使用と普及が著しく成長したためです。 第二に、ほとんどの場合、小売加入者（個人）への音声サービスの提供は、加入者を音声ネットワークのコアに登録するスキームに従って行われます。 カーネルとは、音声サービスを提供する機器（ソフトスイッチ、SIPサーバー、IMSなど）を指します。 このような接続スキームでのSIPクライアントの登録は、ほとんどの場合、デバイス（ルーター、CPE、wifiアクセスポイントなど）から、またはSIPクライアントには次のようなプライベートのルーティングできないアドレスがあるため、アドレス変換機能が有効になっているデバイスのために実行されます192.168.x.xなど。 したがって、このようなスキームのNATは、音声サービスの提供を簡素化する方法とは言えません。 アドレス変換はIPレベルで行われるため、より高いレベルではアドレスは変更されません。 また、このような場合、最終的なSIPクライアントからネットワークのコアへのSIPシグナリングの調整と通過は困難になります。 また、信号トラフィックの他にメディアもあります。 また、メディアトラフィックのIPアドレスは、NATがそれらを置き換えることができない場合に送信され、すべてのALGができるわけではありません。 これにより、メディアトラフィックがルーティング不可能なアドレスにルーティングされます。 結果は明らかであり、非常に望ましくありません-少なくとも、一方向の可聴性は言うまでもなく、NATのその他のそれほど明白でない機能と結果です。 したがって、このような問題を解決するSBCの能力は非常に重要です。 また、特定の各SIPサブスクライバー接続の設定で個別のアプローチを必要とせずに、これらの問題を理想的には自動的に解決することが重要です。



7.サードパーティソリューションとの互換性

これはすでに上記で言及されています。 外部ネットワークとの接続および相互接続は、SIPシグナリングネゴシエーションに対処すると予測されています。 それは、SIPが標準と呼ばれているという事実にもかかわらず、だれも異なるメーカーによるRFC文書の自由な解釈をキャンセルしなかったからです。 さて、SIP RFC自体には80を超える「種類」があることを思い出してください。 これで、互換性の意味がより明確になるはずです。 異なるメーカーの機器をペアリングする機能を組み合わせることは、しばしば困難または不可能なタスクになります。 すべてのSBCがこのようなタスクに対応できるわけではありませんが、最も高度なタスクにのみ対応できます。



8. SS7と接続されたネットワークとの相互作用（SIP-I / SIP-Tのサポート）

また、重要なトピック。 特に今、SIPを使用して直接のオペレーター間ジョイントを編成する可能性がますます利用可能になっているとき。 また、企業クライアントを接続する場合、SIP-Iを通常のSIPに変換する必要があるため、このトピックは非常に関連性が高いままです。



ここでは、SDP部分でOKS-7シグナリングコンテキストが送信されるSIPトラフィックを処理する機能について説明します。このコンテキストは、転送/転送などの一部のサービスの処理の正確性、または2人のオペレーターの境界での基本的な通話の通過に大きく影響する可能性があります。 これらの問題を正しく解決するには、トランジットコールを渡すときにSDP部分の一部のフィールドを変更する機能、またはSIP-Iを通常のSIPに正しく変換する機能が必要です。 そして、これは絶対にプロフェッショナルSBCの機能です。特に、ISUPをシグナリングするためのさまざまなオプションと標準の数を思い出す場合はそうです。 そして、これはまさに、SIPを介してSS-7のコンテキストを転送することについて話しているときに話していることです。



9.外部トラフィック記録システムとのインターフェース用のSIPREC

すべてがシンプルなようです。 会話を記録する必要がある場合のタスクがあります。 これがSORMではないことをすぐに予約します（ただし、SORMの回避策として使用されることもあります）。 これは会話の記録です。 そして、ここでそのようなタスクを実行する特殊なシステムとソリューションとの接合部について話しています。 Session Recording Protocol（SIPREC）を使用して実行されます。 詳細はこちらをご覧ください 。



このトピックは、ビジネスタスクの一部にとって重要です。 困難なのは、既存のSIPプロトコル仕様で扱われていないセッション記録タスクに固有の要件があることです。 セキュリティの問題と個人データの保存だけでなく、ソリューションの実装の技術的特徴についても話し合っています。 さらに、会話が録音されていることをサブスクライバーに通知する必要があります。 これらすべての問題に対処するために、SIPRECが開発されました。 誰もがそれを実装したわけではありません。



10.異なるインターフェイスによるトラフィックタイプの分離

すでにそれについて少し書きました。 別の言い方をします。 多くの実装オプションがあります。 異なる物理インターフェイス間での外部トラフィックと内部トラフィックの分離はほんの一部です。 場合によっては、異なる種類のトラフィックを異なる物理インターフェイスに分割する必要があります。 たとえば、一方のアラーム、他方のメディア、3番目のコントロール。 または、組み合わせる必要があるかもしれません。 一般に、多くのオプションがあります。 完全なサポートにより柔軟性が高まります。



11. IPv4 <-> IPv6相互運用性の有効化

ここではすべてがシンプルなようで、特別なコメントは必要ありません。 IPv6の展開は既に存在し、さらに、さらに多くなります。 SBCは音声ネットワークの端にいるため、変換を実行するのは彼の直接の責任です。



12.トランスコーディング

トピックは大きく、本当に非常に重要です。 この機能に大きく依存しています。 ほとんどの場合、トランスコーディングとは、ある音声コーデックから別の音声コーデックへの変換のみを指します。 ただし、これは氷山の一角にすぎません。 水の下には、はるかに多くが隠されています。 仮想ソリューションについて話す場合、トランスコーディングの問題を議論するとき、ハードウェアサーバーのパフォーマンスについて同時に議論する必要があります。



a）TCP <-> UDP、TCP <-> TLS、UDP <-> TLSの変換、トランスポート層プロトコルの動的な変更。

SIPはUDPのみをサポートしていません。 他のオプションがあります。 ネットワークの接合部では、このような変換のタスクが非常に頻繁に発生します。 そしてもちろん、これがSIPトランクを接続するときに最も頻繁に発生する固定構成で行われるだけでなく、動的に行われると便利です。 少なくとも、音声プラットフォームに登録するサブスクライバーを想像してください。 UDPを使用するものもあれば、一般にTCPまたはTLSを使用するものもあります。 特定の加入者をどうするかを事前にどのように理解していますか？ もちろん、このタスクを動的に実行することをお勧めします。



b）RTP変換<-> SRTP

ここでも、それは理解可能で非常に一般的です。 RTPをSRTPに、またはその逆に変換することは間違いなく必要です。



c）T.38 <-> G.711の変換

ジャンルの古典。 長い間、そして長い間、彼らはファクシミリの死についてすべてを叫んだ。 しかし、これは現実にはほど遠い。 このタイプの通信は使用されており、引き続き使用されています。 もちろん、ほとんどの場合、最新のシステムはすでに紙を節約し、ファイルとして電子メールにファックスを送信します。 しかし、これはファックス送信メカニズムを変更しません。 2つの最も一般的な送信形式は互いに互換性がなく、2つのパーティが異なる方法を使用して相互にFAXを送信する場合、変換が必要です。



d）DTMFトランスコーディング（RFC2833 <->インバンド<-> SIP INFO）

また、古典的な問題。 DTMF信号はさまざまな方法で送信できます。 これは、特定の加入者機器の設定と機能/機能、および最終サービスを提供する音声ソリューションに依存します。 しかし、DTMFは端から端まで行かなければならないという事実。 そして、何が途中でどのような方法が使用されているか、これは痛い点です。 異なる方法間の変換は非常に重要です。



e）コーデックトランスコーディング

テレコムの現代の世界は非常に急速に前進しています。 さて、ここに最近よく見られるいくつかのタイプのコーデックの例があります：



G.723; G.729; G.728; ネットコーダー; GSM-FR; GSM-EFR; AMR EVRC-QCELP; G.727; ILBC EVRC-B; AMR-WB; G.722; EG。711; MS_RTA シルク; SPEEX; オーパス。



オペレータ間インターフェイスでは、トランスコーディングの問題は主にG.711およびG.729のトランスコーディングに限定されますが、よりエキゾチックなケースもあります。 しかし、企業の顧客や小規模な事業者を接続する場合、特定のサービスで使用されるいわゆる「重い」コーデックの使用に関連する問題がしばしば非常に簡単に発生します。 最新のWebサービスまたは一部のモバイルアプリケーションの使用には、一般に受け入れられている以外のコーデックの使用も含まれます。



f）Ptimeトランスコーディング。

実際にはトランスコーディングが存在しないため、別の方法で呼び出す方が正しいでしょう。 同じコーデック内でパケット化時間に変更があります。 「なぜ」という質問に対する答えは非常に簡単です。チャネルの帯域幅を節約します。 一部のアプリケーションでは、これは非常に重要なタスクであり、この方法で解決されるため、機器の帯域幅と処理能力を節約できます。



13. RESTサポート

多くはこれを必要としません、そして、彼らはこのトピックでさえ気にしません。 ただし、REST APIのサポートにより、多くの多くのタスクを柔軟かつ非常に簡単に解決できます。 サードパーティのソリューションとの統合、管理、システムの簡単な再構成は非常に迅速に実行され、問題は発生しません。 NFV（ネットワーク機能仮想化）テクノロジーでは、NFS要素（ネットワーク仮想機能要素）を監視および管理する目的で、大半のオーケストレーターがRESTプロトコルを使用します。



14. WebRTCと、いわゆるWebコーデック（OPUSなど）のサポート

WebRTCは別のトピックでもあり、これによりオペレーターは多くの新しい最新のサービスを追加し、これまで考えられていなかったニッチを取り込むことができます。 WebRTCは、Javascript APIを使用して、パーソナルブラウザーから直接、追加の機器やソフトウェア（フラッシュプレーヤー、プラグインなど）をインストールせずに、通話、ビデオ、チャット、ファイル転送を行う無料のオープンプロジェクトテクノロジーです。 。 魅力と適用性は明らかです。 ここで使用されているのはSIPではないため、技術的な実装にはWebRTCゲートウェイの使用が必要です。



WebRTCゲートウェイ自体は、WebRTCトラフィックを終了し、WebSocket（HTTPを置き換える）から通常のSIPに変換する機能です。 また、対称型NATの背後にある2人のサブスクライバーは互いに通信できないため、メディアトラフィックの送信にはメディアプロキシが必要です。ただし、このようなゲートウェイは、そのような変換のセキュリティを確保するタスクを実行することも、DoS / DDoS攻撃に対する保護、さまざまなポリシーの使用、コールアドミッション制御、会計、請求、トラブルシューティング、診断などのタスクを解決することもありません。したがって、このようなタスクはSBCにかかっています。すなわちSBC自体に組み込みのWebRTCゲートウェイ機能が必要です。このコーデックはWebRTCで使用するための基本的なものであるため、OPUSをサポートしています。もちろん、G.711も忘れないでください。G.711も使用のために指定されています。ただし、実際には適用されません。オープンインターネットでは品質を提供しないため、音声品質を決定するパケット損失やその他のパラメータの影響を受けやすいためです。



15. IPアドレス、AおよびB番号、時刻、機器の可用性、トラフィックの1分あたりのコストなどに基づいてSIPトラフィックをルーティングします。など

SBCで柔軟なルーティングを実行する必要性については、長い間議論されています。特にI-SBCをピアリングに使用するユーザーにとっては、必要であり、機能がより柔軟であればあるほど、オペレーターにとって大きな利益になります。 A-SBCの場合、特に仮想PBXサービスを提供する場合、柔軟なルーティングタスクも重要です。



16.端末機器の応答に基づいてトラフィックを再ルーティングする機能

このタスクは個別に選択されましたI-SBCの場合、ピアリングにとって非常に重要です。



17.特定のIP方向または特定のユーザー/クライアントのトラフィックに優先順位を付けるためのQoS

私の意見では、機能は詳細な説明と議論を必要としません。接続されたクライアントとオペレーターには、品質を管理する権利があり、多くの場合、品質を確保するよう求めます。また、通常、送信されたトラフィックの品質に関するレポートが必要なものもあります。その結果、最高の品質を持つものが勝ちます。

もちろん、理想的には、勝者はSBCが処理した通話の品質に関する統計を保存できるものです。これらは、ジッタ、パケット損失、遅延、エコー、MOS、コール終了の原因、コール終了の開始者などのパラメータです。つまり、SBCは同時にネットワーク上のトラフィックのプローブとして機能します。



18.通話受付管理、セッション数の制限、帯域幅、その他のパラメーター

まあ、この機能は、お金を節約するというタスクにしばしば隣接しています。ソリューションのリソースを制御する必要があり、重要であるため、顧客または加入者が利用可能なリソースのすべてまたはほとんどを「吸収」するのを実質的かつ合理的に制限し、ネットワークコア（SIPサーバー、ソフトスイッチなど）の負荷を制限および制御します



19トラフィックバランシング（ロードバランシング）

機能は、ネットワークの複雑さにより、サービスとトラフィックを開発するための柔軟なスキームを編成および構築できる場合に重要です。そして、それは両方の方法で機能します。たとえば、誰かが冗長チャネルを持ち、フォールトトレラント回線を編成するだけでなく、ネットワークの負荷を分散したり、ネットワークコア要素間でサービスを分散したりするために、その使用を歓迎します。



20. CDRの収集と保管

すべてが明確です。 SBCはネットワークの端にあるため、課金ポイントまたは課金システムとのインターフェースとしても使用できます。 CDRレコードのテキスト形式が最も望ましいことを理解することが重要です。



21.アクセスモード（仮想PBXなどのサービスの登録によるアクセス）とピアリング（SIPトランクでのインターフェースの提供）のトラフィックの同時処理を提供する機能

多くの場合、SBCが1つのモードでのみ動作できる場合、このような制限を満たすことができます。または単にピアリング、またはアクセス時にのみ。モードの1つのみの使用は、実際にはSBCを適用するスキームとタスクが原因である場合があります。ただし、1つのモードのみで機能するため、ネットワーク上のサービスの計画と運用に大きな制限が課され、SIPトランクとサブスクライバートラフィックの同時使用のための完全なスキームをSIPサーバーに登録するための完全なスキームを実装するために2台目のデバイスを購入する必要があります。したがって、2つのモードで同時に作業できることが重要です。



仮想化の傾向は記事の冒頭で述べたので、すぐに記事で説明されているすべてが仮想ソリューションにも当てはまるとしましょう。したがって、仮想SBCが特別なハードウェアシステムを置き換える能力の問題は、それ自体で消えるはずです。もちろん、この問題には微妙なポイントがあります。このテーマに関する別の記事を計画します。