Loading article…
セッションボーダーコントローラ（SBC ）は、 SIPベースのVoIPネットワークを保護するために導入されるネットワーク要素です。[ 1 ]
SBCの初期の導入は、ピアリング環境における2つのサービスプロバイダネットワーク間の境界に焦点を当てていました。その後、この役割は拡大し、サービスプロバイダのアクセスネットワークとバックボーンネットワーク間の重要な導入を含むようになり、住宅顧客や企業顧客にサービスを提供しています。[ 2 ]
「セッション」とは、2つ以上の当事者間の通信を指します。電話通信においては、これは通話に相当します。各通話は、通話を制御する1つ以上の通話シグナリングメッセージの交換と、通話の音声、映像、その他のデータ、および通話統計情報や品質情報を伝送する1つ以上の通話メディアストリームで構成されます。これらのストリームが合わさってセッションを形成します。セッション境界コントローラの役割は、セッションのデータフローを制御することです。
「境界」という用語は、ネットワークのある部分と別の部分との境界点を指します。簡単な例として、企業ネットワークのエッジでは、ファイアウォールがローカルネットワーク（企業内部）とインターネット（企業外部）を区別します。より複雑な例としては、各部門が拠点ごと、場合によってはデータの種類ごとにセキュリティ要件を持つ大規模企業があります。この場合、フィルタリングルーターなどのネットワーク要素を使用してデータストリームの流れを制御します。セッション境界コントローラーの役割は、ポリシー管理者がこれらの境界を越えるセッションデータの流れを管理するのを支援することです。
「コントローラ」という用語は、セッション境界コントローラが、ネットワークのある部分と別の部分との間の境界を通過するセッションを構成するデータストリームに及ぼす影響を指します。さらに、セッション境界コントローラは、制御する通話に対して、測定、アクセス制御、およびデータ変換機能を提供することがよくあります。
SBC（セッションボーダーコントローラー）は一般的にセッションの状態を完全に保持し、以下の機能を提供します。
WebRTCの登場に伴い、一部のSBCはSIPからWebRTCへのゲートウェイとしての役割も担い、SIPを変換するようになりました。WebRTC仕様では特定のシグナリングプロトコルは規定されていませんが、[ 3 ] SIP over WebSockets（RFC 7118）は、想定される通信シナリオのほとんどにSIPが適用可能であることや、JsSIPなどのオープンソースソフトウェアが利用可能であることから、よく使用されます。このような場合、SBCはWebRTCアプリケーションとSIPエンドポイント間のゲートウェイとして機能します。
SBCは、VoIP通話における発信者と着信者の間のシグナリング経路および/またはメディア経路に挿入され、主にセッション開始プロトコル（SIP）、H.323、およびMGCPの通話シグナリングプロトコルを使用するVoIP通話で使用されます。
多くの場合、SBCはネットワークトポロジーを隠蔽し、サービスプロバイダまたは企業のパケットネットワークを保護します。SBCは着信コールを終了し、宛先への2番目のコールレッグを開始します。技術的には、SIPプロトコルで使用される場合、これはバックツーバックユーザーエージェント（B2BUA）を定義します。この動作により、シグナリングトラフィックだけでなく、メディアトラフィック（音声、ビデオ）もSBCによって制御されます。SBCがメディアサービスを提供する機能を持たない場合、SBCは録音、保留音の生成、またはその他のメディア関連の目的のために、メディアトラフィックをネットワーク内の別の要素にリダイレクトすることもできます。逆に、SBCがない場合、メディアトラフィックはエンドポイント間を直接移動し、ネットワーク内のコールシグナリング要素はその経路を制御できません。
その他の場合、SBCは各通話に関わる通話制御（シグナリング）データのストリームを単純に変更し、実行可能な通話の種類を制限したり、コーデックの選択を変更したりするなどします。最終的に、SBCはネットワーク事業者が自社ネットワーク上で行われる通話を管理し、相互運用性を実現するためにプロトコルやプロトコル構文を修正または変更し、さらにファイアウォールやネットワークアドレス変換（NAT）がVoIP通話にもたらす問題の一部を克服することを可能にします。
SBC の動作を示すために、単純な通話確立シーケンスと SBC を使用した通話確立シーケンスを比較することができます。[ 4 ] ユーザー エージェント間にプロキシが 1 つしかない最も単純なセッション確立シーケンスでは、プロキシの役割は、呼び出し先の場所を識別し、要求をそこに転送することです。プロキシはまた、応答が通過するパスを示すために、自身のアドレスを含む Via ヘッダーを追加します。プロキシは、From ヘッダーのタグ、Call-Id、Cseq など、メッセージに含まれるダイアログ識別情報を変更しません。プロキシは、SIP メッセージ本文の情報も変更しません。セッション開始フェーズでは、ユーザー エージェントは、エージェントがメディア トラフィックを期待するアドレスを含む SDP ボディを持つ SIP メッセージを交換します。セッション開始フェーズが正常に完了すると、ユーザー エージェントはプロキシを介さずにメディア トラフィックを直接交換できます。
SBCは多くのアプリケーション向けに設計されており、通信事業者や企業がさまざまな目的を達成するために利用しています。同じSBC実装であっても、構成やユースケースによって動作が異なる場合があります。そのため、すべてのSBC実装に適用できる正確なSBCの動作を記述することは容易ではありません。一般的に、SBCに共通する特定の機能を特定することは可能です。たとえば、ほとんどのSBCはバックツーバックユーザーエージェントとして実装されています。B2BUAはプロキシのようなサーバーで、SIPトランザクションを2つのコールレッグに分割します。ユーザーエージェントクライアント（UAC）側ではサーバーとして動作し、ユーザーエージェントサーバー（UAS）側ではクライアントとして動作します。プロキシは通常、アクティブなトランザクションに関連する状態情報のみを保持しますが、B2BUAはアクティブなダイアログ（通話など）の状態情報を保持します。つまり、プロキシがSIPリクエストを受信すると、いくつかの状態情報を保存します。トランザクションが終了すると（たとえば、応答を受信した後）、状態情報はすぐに削除されます。 B2BUAは、アクティブな通話の状態情報を保持し、通話が終了した後にのみこの情報を削除します。
SBCがコールパスに含まれる場合、SBCは発信者に対してはユーザーエージェントサーバーとして、着信者に対してはユーザーエージェントクライアントとして動作するB2BUAとして機能します。つまり、SBCは発信者によって生成されたコールを実際に終了し、着信者に対して新しいコールを開始します。SBCから送信されるINVITEメッセージには、発信者への明確な参照は含まれません。SBCからプロキシに送信されるINVITEには、発信者ではなくSBC自身を指すViaヘッダーとContactヘッダーが含まれます。SBCは、Call-IdタグとFromタグに記載されているダイアログ識別情報を操作することもよくあります。さらに、SBCがメディアトラフィックも制御するように構成されている場合、SBCはSDPボディのc行とm行に含まれるメディアアドレス情報も変更します。これにより、すべてのSIPメッセージだけでなく、すべてのオーディオパケットとビデオパケットもSBCを通過することになります。 SBC が送信する INVITE によって新しいダイアログが確立されると、SBC はメッセージシーケンス番号 (CSeq) と Max-Forwards 値も操作します。ここで挙げたヘッダー操作は、SBC が SIP メッセージに加える可能性のある変更のごく一部に過ぎないことに注意してください。また、一部の SBC では、ここに挙げた操作をすべて実行しない場合もあります。SBC がメディアトラフィックを制御する必要がない場合は、SDP ボディを変更する必要がない場合もあります。一部の SBC はダイアログ識別情報を変更せず、アドレス情報さえ変更しない場合もあります。
SBC は、ファイアウォールや侵入防御システム(IPS) と併用して、保護された企業ネットワークとの間で VoIP 通話を可能にするために企業でよく使用されます。VoIP サービスプロバイダは、 NAT を使用したインターネット接続を備えたプライベートネットワークから VoIP プロトコルを使用できるようにするため、また、高品質のサービスを維持するために必要な強力なセキュリティ対策を実装するために SBC を使用します。SBC は、アプリケーション レベル ゲートウェイの機能も置き換えます。[ 5 ]大規模な企業では、SBC は SIP トランクと併用して、通話制御を提供し、LAN/WAN を介して通話をルーティングする方法についてのルーティング/ポリシー決定を行うためにも使用できます。通話を従来の回線交換電話ネットワークを介してルーティングするのではなく、企業の内部 IP ネットワークを介してトラフィックをルーティングすると、多くの場合、莫大なコスト削減につながります。
さらに、一部のSBCは、異なるVoIPシグナリングプロトコル（SIP、H.323、Megaco /MGCPなど）を使用して2台の電話機間でVoIP通話を確立できるほか、異なるコーデックが使用されている場合にメディアストリームのトランスコーディングを実行できます。ほとんどのSBCは、VoIPトラフィック用のファイアウォール機能（サービス拒否攻撃対策、通話フィルタリング、帯域幅管理）も提供しています。プロトコルの正規化とヘッダー操作もSBCによって一般的に提供されており、異なるベンダーやネットワーク間での通信を可能にします。
IPマルチメディアサブシステム（IMS）または3GPP（第3世代パートナーシッププロジェクト）アーキテクチャの観点から見ると、SBCは、アクセス側において、シグナリングプレーンのP-CSCFとIMS- ALG、およびメディアプレーンのIMSアクセスゲートウェイを統合したものです。相互接続側では、SBCはシグナリングプレーンのIBCF、 IWF 、およびメディアプレーンのTrGW （トランジションゲートウェイ）に対応します。
IMS/ TISPANアーキテクチャの観点から見ると、SBCはアクセス側のP- CSCFおよびC-BGF機能と、ピアリング側のIBCF、IWF、 THIG、およびI-BGF機能を統合したものです。一部のSBCは「分解」が可能で、シグナリング機能をメディアリレー機能とは別のハードウェアプラットフォームに配置できます。つまり、P-CSCFをC-BGFから分離したり、IBCF/IWFをI-BGF機能から物理的に分離したりできます。H.248 Iaプロファイルなどの標準ベースのプロトコルは、シグナリングプラットフォームでメディアプラットフォームを制御するために使用できますが、一部のSBCは独自のプロトコルを使用します。
SBCの概念は、その黎明期には、エンドツーエンドシステムやピアツーピアネットワークの支持者にとって物議を醸すものであった。その理由は以下の通りである。
SBCをめぐる論争のほとんどは、通話制御を通話の2つのエンドポイント（それぞれの所有者へのサービス提供のため）のみに保持すべきか、それとも2つの通話エンドポイントを接続する様々なネットワークを管理する組織が所有する他のネットワーク要素と共有すべきかという点に関係している。例えば、通話制御はアリスとボブ（2人の発信者）に保持されるべきか、それともアリスとボブのVoIP電話を接続するすべてのIPネットワークのオペレーターと共有されるべきか、という点である。この点に関する議論は、熱狂的で、ほとんど宗教的な様相を呈していた。エンドポイントのみで無制限の制御を望む人々は、ファイアウォールやフィルタリング/スロットリングといった現代ネットワークの様々な現実にも大いに不満を抱いていた。一方、ネットワークオペレーターは通常、ネットワーク全体のパフォーマンス、相互運用性、品質に関心を持ち、セキュリティを確保したいと考えている。
アメリカにおける合法的な通信傍受は、通信傍受法（CALEA）によって規制されている。
SBC（セッションボーダーコントローラー）は、セッションメディア（通常はRTP）およびシグナリング（多くの場合SIP）の傍受サービスを提供することができ、プロバイダーはこれを利用してネットワークセッションの合法的な傍受要求を執行することができます。このようなサービスの傍受に関する標準規格は、 ATIS、TIA、CableLabs、ETSIなどによって提供されています。
RFC 3261 (SIP) およびその他多数の関連 RFC の著者である Jonathan Rosenberg によると、Dynamicsoft は Aravox と共同で最初の動作する SBC を開発しましたが、この製品は市場シェアを真に獲得することはありませんでした。Newport Networks は 2004 年 5 月にロンドン証券取引所の AIM に上場した最初の企業 (NNG) であり、Cisco は 1990 年以来上場しています。Acme Packet は 2006 年 10 月に NASDAQ に上場してこれに続きました。買収により分野が絞り込まれたため、NexTone は Reefpoint と合併して Nextpoint となり、その後 2008 年にGenbandに買収されました。この同じ時期に、境界制御機能が別のエッジ デバイスに統合された「統合型」 SBC が登場しました。2009 年に、Ingate Systems の Firewall は、SBC の VoIP セキュリティ機能の認証におけるマイルストーンとして、ICSA Labs から認証を受けた最初の SBC となりました。
VoIPネットワークの継続的な成長に伴い、SBCはエッジコンピューティングの領域へと押し進められ、容量と複雑さの両面で適応が求められています。VoIPネットワークの拡大とトラフィック量の増加に伴い、SBCを経由するセッション数も増加しています。ベンダー各社は、こうした新たな規模要件に対し、様々な方法で対応しています。SBCクラスタの前段に配置する独立したロードバランシングシステムを開発している企業もあれば、最新世代のチップセットを用いた新しいアーキテクチャを開発し、サービスカードによる拡張性と高性能なSBCを提供している企業もあります。