[要約] RFC 7092は、SIPバックトゥバックユーザーエージェント（B2BUA）の分類と目的についての要約です。このRFCの目的は、B2BUAの役割と機能を明確に定義し、SIPベースの通信システムの設計と展開を支援することです。
Internet Engineering Task Force (IETF) H. Kaplan
Request for Comments: 7092 Oracle
Category: Informational V. Pascual
ISSN: 2070-1721 Quobis
December 2013
A Taxonomy of Session Initiation Protocol (SIP) Back-to-Back User Agents
Session Initiation Protocol（SIP）バックツーバックユーザーエージェントの分類法
Abstract
概要
In many SIP deployments, SIP entities exist in the SIP signaling path between the originating and final terminating endpoints, which go beyond the definition of a SIP proxy, performing functions not defined in Standards Track RFCs. The only term for such devices provided in RFC 3261 is for a Back-to-Back User Agent (B2BUA), which is defined as the logical concatenation of a SIP User Agent Server (UAS) and User Agent Client (UAC).
多くのSIP展開では、SIPエンティティは、発信元エンドポイントと最終終端エンドポイント間のSIPシグナリングパスに存在し、SIPプロキシの定義を超えて、Standards Track RFCで定義されていない機能を実行します。 RFC 3261で提供されているそのようなデバイスの唯一の用語は、SIPユーザーエージェントサーバー（UAS）とユーザーエージェントクライアント（UAC）の論理連結として定義されるバックツーバックユーザーエージェント（B2BUA）です。
There are numerous types of SIP B2BUAs performing different roles in different ways; for example, IP Private Branch Exchanges (IPBXs), Session Border Controllers (SBCs), and Application Servers (ASs). This document identifies several common B2BUA roles in order to provide taxonomy other documents can use and reference.
さまざまな方法でさまざまな役割を実行するSIP B2BUAには多くのタイプがあります。たとえば、IP構内交換機（IPBX）、セッションボーダーコントローラー（SBC）、アプリケーションサーバー（AS）などです。このドキュメントでは、他のドキュメントが使用および参照できる分類法を提供するために、いくつかの一般的なB2BUAロールを識別します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7092.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7092で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. B2BUA Role Types . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Signaling Plane B2BUA Roles . . . . . . . . . . . . . . . 4
3.1.1. Proxy-B2BUA . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Signaling-only . . . . . . . . . . . . . . . . . . . 4
3.1.3. SDP-Modifying Signaling-only . . . . . . . . . . . . 5
3.2. Signaling/Media Plane B2BUA Roles . . . . . . . . . . . . 5
3.2.1. Media Relay . . . . . . . . . . . . . . . . . . . . . 5
3.2.2. Media Aware . . . . . . . . . . . . . . . . . . . . . 6
3.2.3. Media Termination . . . . . . . . . . . . . . . . . . 6
4. Mapping SIP Device Types to B2BUA Roles . . . . . . . . . . . 6
4.1. SIP PBXs and Softswitches . . . . . . . . . . . . . . . . 6
4.2. Application Servers . . . . . . . . . . . . . . . . . . . 7
4.3. Session Border Controllers . . . . . . . . . . . . . . . 7
4.4. Transcoders . . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Conference Servers . . . . . . . . . . . . . . . . . . . 8
4.6. P-CSCF and IBCF Functions . . . . . . . . . . . . . . . . 8
4.7. S-CSCF Function . . . . . . . . . . . . . . . . . . . . . 8
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Informative References . . . . . . . . . . . . . . . . . . . 9
In current SIP deployments, there are numerous forms of Back-to-Back User Agents (B2BUAs), operating at various levels of transparency and for various purposes, with widely varying behavior from a SIP perspective. Some act as pure SIP proxies and only change to the role of B2BUA in order to generate BYEs to terminate dead sessions. Some are full User Agent stacks with only high-level event and application logic binding the User Agent Server (UAS) and User Agent Client (UAC) sides. Some B2BUAs operate only in the SIP signaling plane, while others participate in the media plane as well.
現在のSIP展開では、さまざまな形式のバックツーバックユーザーエージェント（B2BUA）があり、さまざまなレベルの透過性で、さまざまな目的で動作し、SIPの観点からは動作が大きく異なります。一部は純粋なSIPプロキシとして機能し、BYEを生成してデッドセッションを終了するためだけにB2BUAの役割に変更します。一部は、ユーザーエージェントサーバー（UAS）とユーザーエージェントクライアント（UAC）側をバインドする高レベルのイベントとアプリケーションロジックのみを備えた完全なユーザーエージェントスタックです。 B2BUAの中には、SIPシグナリングプレーンでのみ動作するものと、メディアプレーンに参加するものがあります。
As more SIP domains are deployed and interconnected, the probability of a single SIP session crossing multiple B2BUAs at both the signaling and media planes increases significantly.
より多くのSIPドメインが展開および相互接続されると、単一のSIPセッションがシグナリングプレーンとメディアプレーンの両方で複数のB2BUAを通過する可能性が大幅に増加します。
This document provides a taxonomy of several common B2BUA roles so that other documents may refer to them using their given names without redefining them in each document.
このドキュメントは、いくつかの一般的なB2BUAロールの分類法を提供するため、他のドキュメントは、各ドキュメントでそれらを再定義せずに、それらの名前を使用してそれらを参照できます。
The following terms are defined in [RFC3261], Section 6.
次の用語は、[RFC3261]のセクション6で定義されています。
B2BUA: a SIP Back-to-Back User Agent, which is the logical combination of a User Agent Server (UAS) and User Agent Client (UAC).
B2BUA：SIPバックツーバックユーザーエージェント。ユーザーエージェントサーバー（UAS）とユーザーエージェントクライアント（UAC）の論理的な組み合わせです。
UAS: a SIP User Agent Server.
UAS：SIPユーザーエージェントサーバー。
UAC: a SIP User Agent Client.
UAC：SIPユーザーエージェントクライアント。
Within the context of this document, the classification refers to a B2BUA role, not a particular system type. A given system type may change its role in the middle of a SIP session, for example, when a stateful proxy tears down a session by generating BYEs or when an SBC [RFC5853] performs transcoding or REFER termination.
このドキュメントのコンテキスト内では、分類は特定のシステムタイプではなくB2BUAロールを指します。たとえば、ステートフルプロキシがBYEを生成してセッションを破棄するとき、またはSBC [RFC5853]がトランスコーディングまたはREFER終了を実行するときに、特定のシステムタイプがSIPセッションの途中で役割を変更することがあります。
Furthermore, this document defines "B2BUA" following the definition provided in [RFC3261], which is the logical concatenation of a UAS and UAC. A typical centralized conference server, for example, is not a B2BUA because it is the target UAS of multiple UACs, whereby the UACs individually and independently initiate separate SIP sessions to the central conference server. Likewise, a third-party call control transcoder, as described in Section 3.1 of [RFC5369], is not a B2BUA, whereas an inline (conference bridge) transcoder based on [RFC5370] is a B2BUA.
さらに、このドキュメントでは、[RFC3261]で提供されている定義に従ってU2とUACを論理的に連結した「B2BUA」を定義しています。たとえば、一般的な集中型会議サーバーは、複数のUACのターゲットUASであるため、B2BUAではありません。UACは、個別に、独立して、中央会議サーバーへの個別のSIPセッションを開始します。同様に、[RFC5369]のセクション3.1で説明されているサードパーティの呼制御トランスコーダーはB2BUAではありませんが、[RFC5370]に基づくインライン（会議ブリッジ）トランスコーダーはB2BUAです。
A signaling plane B2BUA is one that operates only on the SIP message protocol layer and only with SIP messages and headers but not with the media itself in any way. This implies that it does not modify the Session Description Protocol (SDP) bodies, although it may save them and/or operate on other MIME body types. This category is further subdivided into specific roles as described in this section.
シグナリングプレーンB2BUAは、SIPメッセージプロトコルレイヤーでのみ動作し、SIPメッセージとヘッダーでのみ動作しますが、メディア自体では動作しません。これは、セッション記述プロトコル（SDP）本体を変更しないことを意味しますが、それらを保存したり、他のMIME本体タイプで動作したりする可能性があります。このカテゴリは、このセクションで説明するように、特定の役割にさらに分類されます。
It should be noted that there is a large variety of modifications made by "signaling plane B2BUAs".
「シグナリングプレーンB2BUA」によって行われるさまざまな変更があることに注意してください。
A Proxy-B2BUA is one that appears, from a SIP perspective, to be a SIP proxy based on [RFC3261] and its extensions, except that it maintains a sufficient dialog state to generate in-dialog SIP messages on its own and does so in specific cases. The most common example of this is a SIP proxy that can generate BYE requests to tear down a dead session.
Proxy-B2BUAは、SIPの観点からは、[RFC3261]とその拡張に基づくSIPプロキシであるように見えますが、ダイアログ内のSIPメッセージを独自に生成するのに十分なダイアログ状態を維持し、特定のケース。この最も一般的な例は、デッドセッションを破棄するBYE要求を生成できるSIPプロキシです。
A Proxy-B2BUA does not modify the received header fields such as To, From, or Contact, and it only modifies the Via and Record-Route header fields following the rules in [RFC3261] and its extensions. If a Proxy-B2BUA can generate in-dialog messages, then it will also need to modify the CSeq header after it has generated its own. A Proxy-B2BUA neither modifies nor inspects MIME bodies (including SDP), does not have any awareness of media, will forward any method type, etc.
Proxy-B2BUAは、To、From、Contactなどの受信したヘッダーフィールドを変更せず、[RFC3261]のルールとその拡張に従って、ViaおよびRecord-Routeヘッダーフィールドのみを変更します。 Proxy-B2BUAがダイアログ内メッセージを生成できる場合、CSeqヘッダーを生成した後で、CSeqヘッダーを変更する必要もあります。 Proxy-B2BUAは、MIME本体（SDPを含む）を変更または検査せず、メディアを認識せず、メソッドタイプなどを転送します。
A Signaling-only B2BUA is one that operates at the SIP layer but in ways beyond those of [RFC3261] proxies, even for normally forwarded requests. For example, such a B2BUA might replace the Contact URI, modify or remove all Via and Record-Route headers, modify the To and From header fields, modify or inspect specific MIME bodies, etc. No SIP header field is guaranteed to be copied from the received request on the UAS side to the generated request on the UAC side.
シグナリングのみのB2BUAは、SIPレイヤーで動作するものですが、通常転送される要求であっても、[RFC3261]プロキシの方法を超えています。たとえば、このようなB2BUAは、Contact URIの置き換え、すべてのViaおよびRecord-Routeヘッダーの変更または削除、ToおよびFromヘッダーフィールドの変更、特定のMIME本文の変更または検査などを行います。SIPヘッダーフィールドのコピーは保証されませんUAS側で受信された要求からUAC側で生成された要求へ。
An example of such a B2BUA would be some form of an Application Server and a PBX, such as a server that locally processes REFER requests and generates new INVITEs on behalf of the REFER's target. Another example would be a privacy service proxy [RFC3323] performing the 'header' privacy function.
このようなB2BUAの例は、アプリケーションサーバーとPBXの形式で、REFERリクエストをローカルで処理し、REFERのターゲットに代わって新しいINVITEを生成するサーバーなどです。別の例は、「ヘッダー」プライバシー機能を実行するプライバシーサービスプロキシ[RFC3323]です。
An SDP-Modifying Signaling-only B2BUA is one that operates in the signaling plane only and is not in the media path, but it does modify SDP bodies and is thus aware of and understands SDP syntax and semantics. In some cases, some Application Servers and PBXs act in this role, for example, to remove certain codec choices or merge two media endpoints into one SDP offer.
SDP-Modifying Signaling-only B2BUAは、シグナリングプレーンのみで動作し、メディアパスにはありませんが、SDP本体を変更するため、SDP構文とセマンティクスを認識および理解します。場合によっては、一部のアプリケーションサーバーとPBXがこの役割を果たし、たとえば、特定のコーデックの選択を削除したり、2つのメディアエンドポイントを1つのSDPオファーにマージしたりします。
These B2BUAs don't do anything that changes the path that the media takes (in particular, they don't insert themselves on the media path), but they may make SDP changes that affect what is sent on the media plane.
これらのB2BUAは、メディアがたどるパスを変更することはありません（特に、メディアパスにそれ自体を挿入することはありません）が、メディアプレーンで送信される内容に影響を与えるSDP変更を行う場合があります。
A signaling/media plane B2BUA is one that operates at both the SIP and media planes and not only on SIP messages but also on SDP and potentially the Real-time Transport Protocol (RTP) / the Real-Time Control Protocol (RTCP) [RFC3550] or other media. Such a B2BUA may or may not replace the Contact URI, modify or remove all Via and Record-Route headers, modify the To and From header fields, etc. No SIP header field is guaranteed to be copied from the received request on the UAS side to the generated request on the UAC side, and SDP will also be modified.
シグナリング/メディアプレーンB2BUAは、SIPプレーンとメディアプレーンの両方で動作し、SIPメッセージだけでなく、SDPおよび場合によってはリアルタイムトランスポートプロトコル（RTP）/リアルタイムコントロールプロトコル（RTCP）でも動作します[RFC3550 ]または他のメディア。このようなB2BUAは、Contact URIの置き換え、すべてのViaおよびRecord-Routeヘッダーの変更または削除、ToおよびFromヘッダーフィールドの変更などを行う場合と行わない場合があります。UAS側で受信したリクエストからSIPヘッダーフィールドがコピーされることは保証されませんUAC側で生成されたリクエストに追加され、SDPも変更されます。
An example of such a B2BUA would be a Session Border Controller (SBC) performing the functions defined in [RFC5853], a B2BUA transcoder as defined in [RFC5370], a rich-ringtone Application Server, or a recording system. Another example would be a privacy service proxy [RFC3323] performing the 'session' privacy function.
このようなB2BUAの例は、[RFC5853]で定義された機能を実行するセッションボーダーコントローラー（SBC）、[RFC5370]で定義されたB2BUAトランスコーダー、リッチリングトーンアプリケーションサーバー、または記録システムです。別の例は、「セッション」プライバシー機能を実行するプライバシーサービスプロキシ[RFC3323]です。
Note that a signaling/media plane B2BUA need not be instantiated in a single physical system, but it may be decomposed into separate signaling and media functions.
シグナリング/メディアプレーンB2BUAは、単一の物理システムでインスタンス化する必要はありませんが、個別のシグナリングおよびメディア機能に分解できることに注意してください。
The signaling/media plane B2BUA category is further subdivided into specific roles as described in this section.
シグナリング/メディアプレーンB2BUAカテゴリは、このセクションで説明するように、特定の役割にさらに細分されます。
A B2BUA that performs a media-relay role is one that terminates the media plane at the IP and transport (UDP/TCP) layers on its UAS and UAC sides, but neither modifies nor restricts which forms of payload are carried within the packets. Rather, the payload is transparently copied from one side to the other. Such a role may or may not support only UDP, only TCP, both UDP and TCP, as well as other transport types. It may also involve policing the IP packets to fit within a bandwidth limit or converting from IPv4 to IPv6, or vice versa. This is typically similar to NAT behavior, except a NAT operating in both directions on both the source and destination information; it is often found as the default behavior in SBCs.
メディアリレーの役割を実行するB2BUAは、UASおよびUAC側のIPおよびトランスポート（UDP / TCP）レイヤーでメディアプレーンを終端しますが、パケット内で搬送されるペイロードの形式を変更または制限しません。むしろ、ペイロードは一方から他方へ透過的にコピーされます。このような役割は、UDPのみ、TCPのみ、UDPとTCPの両方、および他のトランスポートタイプをサポートする場合としない場合があります。また、帯域幅制限内に収まるようにIPパケットをポリシングしたり、IPv4からIPv6に、またはその逆に変換したりすることも含まれます。これは通常、NATの動作に似ていますが、NATは送信元情報と宛先情報の両方で双方向に動作します。これは、SBCのデフォルトの動作としてよく見られます。
A B2BUA that performs a media-aware role is similar to a media relay except that it inspects and potentially modifies the payload carried in UDP or TCP (as it could be RTP or RTCP [RFC3550]), but it does not at a codec or higher layer. An example of such a role is a Secure Real-time Transport Protocol (SRTP) [RFC3711] terminator, which does not need to care about the RTP payload but does care about the RTP header; or, a device that monitors RTCP for QoS information; or, a device that multiplexes/demultiplexes RTP and RTCP packets on the same 5-tuple.
メディア対応の役割を実行するB2BUAは、UDPまたはTCP（RTPまたはRTCP [RFC3550]の可能性があるため）で運ばれるペイロードを検査して変更する可能性があることを除いて、メディアリレーと似ていますが、コーデックまたは上位層。そのような役割の例は、Secure Real-time Transport Protocol（SRTP）[RFC3711]ターミネーターです。これは、RTPペイロードを気にする必要はありませんが、RTPヘッダーを気にします。または、RTCPでQoS情報を監視するデバイス。または、同じ5タプルでRTPおよびRTCPパケットを多重化/逆多重化するデバイス。
A B2BUA that performs a media-termination role is one that operates at the media payload layer, such as RTP/RTCP codec or the Message Session Relay Protocol (MSRP) message layer and higher. Such a role may only terminate/generate specific RTP media, such as dual-tone multi-frequency (DTMF) packets [RFC4733], or it may convert between media codecs or act as a Back-to-Back MSRP [RFC4975] agent. This is the role performed by transcoders, conference servers based on [RFC5366], etc.
メディアターミネーションの役割を実行するB2BUAは、RTP / RTCPコーデックやメッセージセッションリレープロトコル（MSRP）メッセージレイヤーなどのメディアペイロードレイヤーで動作するものです。このような役割は、デュアルトーンマルチ周波数（DTMF）パケット[RFC4733]などの特定のRTPメディアのみを終了/生成するか、メディアコーデック間で変換するか、バックツーバックMSRP [RFC4975]エージェントとして機能します。これは、トランスコーダ、[RFC5366]に基づく会議サーバーなどによって実行される役割です。
Although the B2BUA roles defined previously do not define system types, as discussed in Section 3, some discussion of what common system types perform which defined roles may be appropriate. This section provides such a 'mapping' for general cases to aid in understanding of the roles.
以前に定義されたB2BUAロールはシステムタイプを定義していませんが、セクション3で説明されているように、どの一般的なシステムタイプがどの定義されたロールを実行するかについての議論が適切な場合があります。このセクションでは、役割の理解を助けるために、一般的なケースにそのような「マッピング」を提供します。
SIP-enabled Private Branch Exchanges (SIP PBXs) and softswitches are market category terms and are not specified in any standard. In general, they can perform every role described in this document at any given time based on their architecture or local policy. Some are based on architectures that make them the equivalent of a SIP UAS and UAC connected with a logical Primary Rate Interface (PRI) loopback; others are built as a SIP proxy core with optional modules to "do more".
SIP対応の構内交換機（SIP PBX）とソフトスイッチは市場カテゴリの用語であり、どの規格でも指定されていません。一般に、彼らはこのドキュメントで説明されているすべての役割を、そのアーキテクチャまたはローカルポリシーに基づいていつでも実行できます。一部は、論理的な一次群速度インターフェース（PRI）ループバックで接続されたSIP UASおよびUACと同等のアーキテクチャに基づいています。その他は、「より多くのことをする」ためのオプションのモジュールを備えたSIPプロキシコアとして構築されています。
Application Servers are a broad marketing term and are not specified in any standard in general, although the Third Generation Partnership Project (3GPP) and other organizations specify some specific Application Server functions and behaviors. Common examples of Application Server functions are message-waiting indicators (MWIs), Find Me/Follow Me services, privacy services, call center Automatic Call Distributor (ACD) services, call screening, and Voice Call Continuity (VCC) services. Some only operate in the signaling plane in either Proxy-B2BUA or Signaling-only B2BUA roles; others operate as full Media-termination B2BUAs, such as when providing Interactive Voice Recognition (IVR), rich ringtones, or integrated voicemail services.
第3世代パートナーシッププロジェクト（3GPP）および他の組織は、特定のアプリケーションサーバーの機能と動作を指定していますが、アプリケーションサーバーは広義のマーケティング用語であり、一般にどの規格にも指定されていません。アプリケーションサーバー機能の一般的な例は、メッセージ受信インジケーター（MWI）、Find Me / Follow Meサービス、プライバシーサービス、コールセンターの自動通話配信（ACD）サービス、通話スクリーニング、および音声通話継続（VCC）サービスです。一部は、Proxy-B2BUAまたはSignaling-only B2BUAロールのいずれかのシグナリングプレーンでのみ動作します。他のものは、インタラクティブ音声認識（IVR）、豊富な着信音、または統合ボイスメールサービスを提供する場合など、完全なメディアターミネーションB2BUAとして動作します。
Session Border Controllers (SBCs) are a market category term and are not specified in any standard. Some of the common functions performed by SBCs are described in [RFC5853], but in general, they can perform every role described in this document at any given time based on local policy. By default, most SBCs are either Media-relay or Media-aware B2BUAs and replace the Contact URI; remove the Via and Record-Route headers; modify Call-ID, To, From, and various other headers; and modify SDP. Some SBCs remove all headers, all bodies, and reject all method types unless explicitly allowed by local policy; other SBCs pass all such elements through unless explicitly forbidden by local policy.
セッションボーダーコントローラー（SBC）は市場カテゴリーの用語であり、どの規格でも指定されていません。 SBCによって実行される一般的な機能の一部は[RFC5853]で説明されていますが、一般に、ローカルポリシーに基づいて、このドキュメントで説明されているすべての役割をいつでも実行できます。デフォルトでは、ほとんどのSBCはMedia-relayまたはMedia-aware B2BUAであり、Contact URIを置き換えます。 ViaおよびRecord-Routeヘッダーを削除します。 Call-ID、To、From、およびその他のさまざまなヘッダーを変更します。 SDPを変更します。一部のSBCは、ローカルポリシーで明示的に許可されていない限り、すべてのヘッダー、すべての本文を削除し、すべてのメソッドタイプを拒否します。他のSBCは、ローカルポリシーで明示的に禁止されていない限り、このような要素をすべて通過させます。
Transcoders perform the function of transcoding one audio or video media codec type to another, such as G.711 to G.729. As such, they perform the Media-termination role, although they may only terminate media in specific cases of codec mismatch between the two ends. Although [RFC5369] and [RFC5370] define two types of SIP transcoders, in practice, a popular variant of the inline conference bridge model [RFC5370] is to behave as a SIP B2BUA without using the resource-list mechanism but rather simply routing a normal INVITE request through a B2BUA with a built-in transcoder. SIP transcoder architectures are based on everything from SIP media servers and SBCs to looped-back Time Division Multiplexing (TDM) gateways, and thus run the gamut from replacing only specific headers/bodies and SDP content needed to perform their function to replacing almost all SIP headers and SDP content. Some transcoders save and remove SDP offers in INVITEs from the UAC, and wait for an offer in the response from the UAS, similar to a Third Party Call Control (3PCC) model; others just insert additional codecs in SDP offers and only transcode if the inserted codec(s) is selected in the answer.
トランスコーダは、1つのオーディオまたはビデオメディアコーデックタイプを別のタイプ（G.711からG.729など）にトランスコーディングする機能を実行します。そのため、メディアの終了の役割を果たしますが、2つの端の間でコーデックが一致しない特定の場合にのみメディアを終了できます。 [RFC5369]と[RFC5370]は2種類のSIPトランスコーダーを定義しますが、実際には、インライン会議ブリッジモデル[RFC5370]の一般的なバリアントは、リソースリストメカニズムを使用せずに、通常のルーティングだけでSIP B2BUAとして動作します。組み込みトランスコーダを備えたB2BUAを介したINVITEリクエスト。 SIPトランスコーダーアーキテクチャは、SIPメディアサーバーやSBCからループバック時分割多重（TDM）ゲートウェイに至るまですべてに基づいているため、特定のヘッダー/ボディのみを置き換えることから、その機能を実行するために必要なSDPコンテンツを実行して、ほぼすべてのSIPを置き換えることができます。ヘッダーとSDPコンテンツ。一部のトランスコーダーは、UACからのINVITEのSDPオファーを保存および削除し、サードパーティコールコントロール（3PCC）モデルと同様に、UASからの応答でオファーを待ちます。 SDPオファーに追加のコーデックを挿入するだけであり、挿入されたコーデックが回答で選択されている場合にのみトランスコードします。
In general, conference servers do not fall under the term "B2BUA" as defined by this document, since typically they involve multiple SIP UACs initiating independent SIP sessions to the single conference UAS. However, a conference server supporting [RFC5366], whereby the received INVITE triggers the conference focus UAS to initiate multiple INVITEs as a UAC, would be in a Media-termination B2BUA role when performing that function.
一般に、会議サーバーは、このドキュメントで定義されている「B2BUA」という用語には該当しません。これは、通常、複数のSIP UACが単一の会議UASへの独立したSIPセッションを開始するためです。ただし、受信したINVITEが会議フォーカスUASをトリガーして複数のINVITEをUACとして開始する[RFC5366]をサポートする会議サーバーは、その機能を実行するときにMedia-termination B2BUAロールになります。
The Proxy-Call Session Control Function (P-CSCF) and the Interconnection Border Control Function (IBCF) are defined by 3GPP [IMS] standards, and when coupled with the IP Multimedia Subsystems (IMS) media plane gateways (IMS Access Gateway (AGW), Transition Gateway (TrGW), etc.), they typically form a logical Media-relay or Media-aware B2BUA role.
プロキシ呼び出しセッション制御機能（P-CSCF）および相互接続ボーダー制御機能（IBCF）は、3GPP [IMS]標準で定義されており、IPマルチメディアサブシステム（IMS）メディアプレーンゲートウェイ（IMSアクセスゲートウェイ（AGW）と組み合わせた場合）、Transition Gateway（TrGW）など）、それらは通常、論理的なMedia-RelayまたはMedia-aware B2BUAロールを形成します。
The Serving-Call Session Control Function (S-CSCF) is defined by 3GPP [IMS] standards and typically follows a Proxy-B2BUA role.
Serving-Call Session Control Function（S-CSCF）は3GPP [IMS]標準で定義されており、通常はProxy-B2BUAの役割に従います。
Security risks are specific to each type of B2BUA, so little can be said in general. Of course, adding extra systems in the communication path creates extra points of attack, reduces or eliminates the ability to perform end-to-end encryption, decreases the privacy of SIP communications, and complicates trust models. Thus, every B2BUA design requires particular attention to security analysis.
セキュリティリスクはB2BUAの各タイプに固有であるため、一般的にはほとんど言えません。もちろん、通信経路に追加のシステムを追加すると、追加の攻撃ポイントが作成され、エンドツーエンドの暗号化を実行する機能が減少または排除され、SIP通信のプライバシーが低下し、信頼モデルが複雑になります。したがって、すべてのB2BUA設計には、セキュリティ分析に対する特別な注意が必要です。
A few general points can be made:
いくつかの一般的なポイントを作成できます。
1. The B2BUA processing of SDP and media packets is an impediment to the deployment of end-to-end SRTP and reduces the ability to deploy new, stronger forms of SRTP key exchange.
1. SDPおよびメディアパケットのB2BUA処理は、エンドツーエンドのSRTPの展開を妨げ、新しい強力な形式のSRTPキー交換を展開する機能を低下させます。
2. The ability for B2BUAs to modify any SIP header field value and body impacts the ability to deploy SIP identity and message integrity.
2. B2BUAがSIPヘッダーフィールドの値と本文を変更する機能は、SIP IDとメッセージの整合性を展開する機能に影響します。
3. The management and configuration mechanisms of B2BUAs are a tempting point of attack and must be strongly defended.
3. B2BUAの管理および構成メカニズムは攻撃の魅力的なポイントであり、強力に防御する必要があります。
Further security considerations related to the functionality described in this document are addressed in the relevant references.
このドキュメントで説明されている機能に関連するセキュリティの考慮事項については、関連する参考資料で説明されています。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3323] Peterson、J。、「Session Initiation Protocol（SIP）のプライバシーメカニズム」、RFC 3323、2002年11月。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[RFC4733] Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.
[RFC4733] Schulzrinne、H。およびT. Taylor、「DTMFディジット、テレフォニートーン、およびテレフォニーシグナルのRTPペイロード」、RFC 4733、2006年12月。
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC4975] Campbell、B.、Mahy、R。、およびC. Jennings、「メッセージセッションリレープロトコル（MSRP）」、RFC 4975、2007年9月。
[RFC5366] Camarillo, G. and A. Johnston, "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)", RFC 5366, October 2008.
[RFC5366] Camarillo、G。およびA.ジョンストン、「Session Initiation Protocol（SIP）での要求を含むリストを使用した会議の確立」、RFC 5366、2008年10月。
[RFC5369] Camarillo, G., "Framework for Transcoding with the Session Initiation Protocol (SIP)", RFC 5369, October 2008.
[RFC5369] Camarillo、G。、「Session Initiation Protocol（SIP）によるトランスコーディングのフレームワーク」、RFC 5369、2008年10月。
[RFC5370] Camarillo, G., "The Session Initiation Protocol (SIP) Conference Bridge Transcoding Model", RFC 5370, October 2008.
[RFC5370]カマリロ、G。、「セッション開始プロトコル（SIP）会議ブリッジトランスコーディングモデル」、RFC 5370、2008年10月。
[RFC5853] Hautakorpi, J., Camarillo, G., Penfield, R., Hawrylyshen, A., and M. Bhatia, "Requirements from Session Initiation Protocol (SIP) Session Border Control (SBC) Deployments", RFC 5853, April 2010.
[RFC5853] Hautakorpi、J.、Camarillo、G.、Penfield、R.、Hawrylyshen、A。、およびM. Bhatia、「Session Initiation Protocol（SIP）Session Border Control（SBC）Deployments from Requirements」、RFC 5853、4月2010。
[IMS] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2, 3GPP TS 23.228", Version 12.2.0, September 2013.
[IMS] 3GPP、「IPマルチメディアサブシステム（IMS）;ステージ2、3GPP TS 23.228」、バージョン12.2.0、2013年9月。
Authors' Addresses
著者のアドレス
Hadriel Kaplan Oracle
ハドリエルカプランオラクル
EMail: hadriel.kaplan@oracle.com
Victor Pascual Quobis
ビクターパスクアルクオビス
EMail: victor.pascual@quobis.com