[要約] RFC 5567は、メディアサーバー制御のためのアーキテクチャフレームワークに関するものであり、その目的は、異なるメディアサーバー間の相互運用性を向上させることです。
Network Working Group T. Melanchuk, Ed.
Request for Comments: 5567 Rain Willow Communications
Category: Informational June 2009
An Architectural Framework for Media Server Control
メディアサーバー制御のためのアーキテクチャフレームワーク
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
This document describes an architectural framework for Media Server control. The primary focus will be to define logical entities that exist within the context of Media Server control, and define the appropriate naming conventions and interactions between them.
このドキュメントでは、メディアサーバー制御のためのアーキテクチャフレームワークについて説明します。主な焦点は、メディアサーバー制御のコンテキスト内に存在する論理エンティティを定義し、それらの間の適切な命名規則と相互作用を定義することです。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Architecture Overview ...........................................4
4. SIP Usage .......................................................7
5. Media Control for IVR Services .................................10
5.1. Basic IVR Services ........................................11
5.2. IVR Services with Mid-Call Controls .......................11
5.3. Advanced IVR Services .....................................11
6. Media Control for Conferencing Services ........................12
6.1. Creating a New Conference .................................14
6.2. Adding a Participant to a Conference ......................14
6.3. Media Controls ............................................15
6.4. Floor Control .............................................16
7. Security Considerations ........................................21
8. Acknowledgments ................................................22
9. Contributors ...................................................22
10. Informative References ........................................23
Application Servers host one or more instances of a communications application. Media Servers provide real-time media processing functions. This document presents the core architectural framework to allow Application Servers to control Media Servers. An overview of the architecture describing the core logical entities and their interactions is presented in Section 3. The requirements for Media Server control are defined in [RFC5167].
アプリケーションサーバーは、通信アプリケーションの1つ以上のインスタンスをホストします。メディアサーバーは、リアルタイムのメディア処理機能を提供します。このドキュメントでは、アプリケーションサーバーがメディアサーバーを制御できるようにするコアアーキテクチャフレームワークを提示します。コア論理エンティティとそれらの相互作用を説明するアーキテクチャの概要は、セクション3に示されています。メディアサーバー制御の要件は[RFC5167]で定義されています。
The Session Initiation Protocol (SIP) [RFC3261] is used as the session establishment protocol within this architecture. Application Servers use it both to terminate media streams on Media Servers and to create and manage control channels for Media Server control between themselves and Media Servers. The detailed model for Media Server control together with a description of SIP usage is presented in Section 4.
セッション開始プロトコル（SIP）[RFC3261]は、このアーキテクチャ内のセッション確立プロトコルとして使用されます。アプリケーションサーバーの両方を使用して、メディアサーバー上のメディアストリームを終了し、自分自身とメディアサーバー間のメディアサーバー制御の制御チャネルを作成および管理します。SIP使用量の説明とともに、メディアサーバー制御の詳細なモデルをセクション4に示します。
Several services are described using the framework defined in this document. Use cases for Interactive Voice Response (IVR) services are described in Section 5, and conferencing use cases are described in Section 6.
このドキュメントで定義されているフレームワークを使用して、いくつかのサービスについて説明します。インタラクティブな音声応答（IVR）サービスのユースケースはセクション5で説明されており、会議のユースケースはセクション6で説明されています。
The following terms are defined for use in this document in the context of Media Server control:
メディアサーバーコントロールのコンテキストで、このドキュメントで使用するために次の用語が定義されています。
Application Server (AS): A functional entity that hosts one or more instances of a communication application. The application server may include the conference policy server, the focus, and the conference notification server, as defined in [RFC4353]. Also, it may include communication applications that use IVR or announcement services.
Application Server（AS）：通信アプリケーションの1つ以上のインスタンスをホストする機能エンティティ。アプリケーションサーバーには、[RFC4353]で定義されているように、会議ポリシーサーバー、フォーカス、および会議通知サーバーが含まれる場合があります。また、IVRまたはアナウンスサービスを使用する通信アプリケーションが含まれる場合があります。
Media Functions: Functions available on a Media Server that are used to supply media services to the AS. Some examples are Dual-Tone Multi-Frequency (DTMF) detection, mixing, transcoding, playing announcement, recording, etc.
メディア関数：メディアサービスをASに提供するために使用されるメディアサーバーで利用可能な機能。いくつかの例は、デュアルトーンの多周波（DTMF）の検出、混合、トランスコーディング、発表、録音などです。
Media Resource Broker (MRB): A logical entity that is responsible for both the collection of appropriate published Media Server (MS) information and supplying of appropriate MS information to consuming entities. The MRB is an optional entity and will be discussed in a separate document.
Media Resource Broker（MRB）：適切な公開されたMedia Server（MS）情報の収集と、適切なMS情報の消費エンティティへの適切な供給の両方を担当する論理エンティティ。MRBはオプションのエンティティであり、別のドキュメントで説明されます。
Media Server (MS): The media server includes the mixer as defined in [RFC4353]. The media server plays announcements, it processes media streams for functions like DTMF detection and transcoding. The media server may also record media streams for supporting IVR functions like announcing conference participants. In the architecture for the 3GPP IP Multimedia Subsystem (IMS) a Media Server is referred to as a Media Resource Function (MRF).
メディアサーバー（MS）：メディアサーバーには、[RFC4353]で定義されているミキサーが含まれています。メディアサーバーはアナウンスを再生し、DTMF検出やトランスコーディングなどの機能のメディアストリームを処理します。メディアサーバーは、会議参加者の発表などのIVR機能をサポートするためにメディアストリームを記録することもできます。3GPP IPマルチメディアサブシステム（IMS）のアーキテクチャでは、メディアサーバーはメディアリソース機能（MRF）と呼ばれます。
Media Services: Application service requiring media functions such as Interactive Voice Response (IVR) or media conferencing.
メディアサービス：インタラクティブな音声応答（IVR）やメディア会議などのメディア機能を必要とするアプリケーションサービス。
Media Session: From the Session Description Protocol (SDP) specification [RFC4566]: "A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session."
メディアセッション：セッション説明プロトコル（SDP）仕様[RFC4566]：「マルチメディアセッションは、マルチメディアセンダーとレシーバーのセットであり、送信者からレシーバーに流れるデータストリームです。マルチメディア会議はマルチメディアセッションの例です。」
MS Control Channel: A reliable transport connection between the AS and MS used to exchange MS Control PDUs. Implementations must support the Transport Control Protocol (TCP) [RFC0793] and may support the Stream Control Transmission Protocol (SCTP) [RFC4960]. Implementations must support TLS [RFC5246] as a transport-level security mechanism although its use in deployments is optional.
MSコントロールチャネル：MSコントロールPDUを交換するために使用されるASとMSの間の信頼できる輸送接続。実装は、輸送制御プロトコル（TCP）[RFC0793]をサポートする必要があり、ストリーム制御伝送プロトコル（SCTP）[RFC4960]をサポートする場合があります。展開での使用はオプションですが、実装はTLS [RFC5246]を輸送レベルのセキュリティメカニズムとしてサポートする必要があります。
MS Control Dialog: A SIP dialog that is used for establishing a control channel between the user agent (UA) and the MS.
MSコントロールダイアログ：ユーザーエージェント（UA）とMSの間にコントロールチャネルを確立するために使用されるSIPダイアログ。
MS Control Protocol: The protocol used for by an AS to control an MS. The MS Control Protocol assumes a reliable underlying transport protocol for the MS Control Channel.
MSコントロールプロトコル：ASがMSを制御するために使用されるプロトコル。MSコントロールプロトコルは、MSコントロールチャネルの信頼できる基礎となる輸送プロトコルを想定しています。
MS Media Dialog: A SIP dialog between the AS and MS that is used for establishing media sessions between a user device such as a SIP phone and the MS.
MS Mediaダイアログ：ASとMSの間のSIPダイアログは、SIP電話やMSなどのユーザーデバイス間でメディアセッションを確立するために使用されます。
The definitions for AS, MS, and MRB above are taken from [RFC5167].
AS、MS、およびMRB上記の定義は[RFC5167]から取られています。
A Media Server (MS) is a network device that processes media streams. Examples of media processing functionality may include:
メディアサーバー（MS）は、メディアストリームを処理するネットワークデバイスです。メディア処理機能の例には、以下が含まれます。
o Control of the Real-Time Protocol (RTP) [RFC3550] streams using the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) [RFC4585].
o リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/AVPF）[RFC4585]の拡張RTPプロファイルを使用して、リアルタイムプロトコル（RTP）[RFC3550]の制御はストリーミングします。
o Mixing of incoming media streams.
o 入ってくるメディアストリームの混合。
o Media stream source (for multimedia announcements).
o メディアストリームソース（マルチメディアの発表用）。
o Media stream processing (e.g., transcoding, DTMF detection).
o メディアストリーム処理（たとえば、トランスコーディング、DTMF検出）。
o Media stream sink (for multimedia recordings).
o メディアストリームシンク（マルチメディア録音用）。
An MS supplies one or more media processing functionalities, which may include others than those illustrated above, to an Application Server (AS). An AS is able to send a particular call to a suitable MS, either through discovery of the capabilities that a specific MS provides or through the use of a Media Resource Broker.
MSは、1つ以上のメディア処理機能を提供します。これには、上記のものよりも他のものがアプリケーションサーバー（AS）に含まれます。特定のMSが提供する機能の発見またはメディアリソースブローカーの使用を通じて、特定の呼び出しを適切なMSに送信することができます。
The type of processing that a Media Server performs on media streams is specified and controlled by an Application Server. Application Servers are logical entities that are capable of running one or more instances of a communications application. Examples of Application Servers that may interact with a Media Server are an AS acting as a Conference 'Focus' as defined in [RFC4353], or an IVR application using a Media Server to play announcements and detect DTMF key presses.
メディアサーバーがメディアストリームで実行する処理のタイプは、アプリケーションサーバーによって指定および制御されます。アプリケーションサーバーは、通信アプリケーションの1つ以上のインスタンスを実行できる論理エンティティです。メディアサーバーと対話する可能性のあるアプリケーションサーバーの例は、[RFC4353]で定義されている会議「フォーカス」として機能するか、メディアサーバーを使用して発表をプレイしてDTMFキープレスを検出するIVRアプリケーションとして機能します。
Application servers use SIP to establish control channels between themselves and MSs. An MS Control Channel implements a reliable transport protocol that is used to carry the MS Control Protocol. A SIP dialog used to establish a control channel is referred to as an MS Control Dialog.
アプリケーションサーバーは、SIPを使用して、自分自身とMSS間の制御チャネルを確立します。MSコントロールチャネルは、MSコントロールプロトコルを運ぶために使用される信頼できる輸送プロトコルを実装します。コントロールチャネルの確立に使用されるSIPダイアログは、MSコントロールダイアログと呼ばれます。
Application Servers terminate SIP [RFC3261] signaling from SIP User Agents and may terminate other signaling outside the scope of this document. They use SIP Third Party Call Control [RFC3725] (3PCC) to establish, maintain, and tear down media streams from those SIP UAs to a Media Server. A SIP dialog used by an AS to establish a media session on an MS is referred to as an MS Media Dialog.
アプリケーションサーバーは、SIPユーザーエージェントからのSIP [RFC3261]シグナリングを終了し、このドキュメントの範囲外で他のシグナリングを終了する場合があります。SIPサードパーティのコールコントロール[RFC3725]（3PCC）を使用して、これらのSIP UASからメディアサーバーにメディアストリームを確立、維持、取り壊します。MSでメディアセッションを確立するためにASが使用するSIPダイアログは、MSメディアダイアログと呼ばれます。
Media streams go directly between SIP User Agents and Media Servers. Media Servers support multiple types of media. Common supported RTP media types include audio and video, but others such as text and the Binary Floor Control Protocol (BFCP) [RFC4583] are also possible. This basic architecture, showing session establishment signaling between a single AS and MS is shown in Figure 1 below.
メディアストリームは、SIPユーザーエージェントとメディアサーバーの間で直接進みます。メディアサーバーは、複数のタイプのメディアをサポートしています。一般的なサポートされているRTPメディアタイプにはオーディオとビデオが含まれますが、テキストやバイナリフロアコントロールプロトコル（BFCP）[RFC4583]などのその他も可能です。この基本的なアーキテクチャは、単一のASとMSの間のセッション確立シグナル伝達を示しています。以下の図1に示されています。
+-------------+ +--------------+
| | SIP (MS Control Dialog) | |
| Application |<----------------------->| Media |
| Server | | Server |
| |<----------------------->| |
+-------------+ SIP (MS Media Dialog) +--------------+
^ ^
\ | RTP/SRTP
\ | audio/
\ | video/etc)
\ |
\ v
\ +--------------+
\ SIP | |
+-------------->| SIP |
| User Agent |
| |
+--------------+
Figure 1: Basic Signaling Architecture
図1：基本的なシグナリングアーキテクチャ
The architecture must support a many-to-many relationship between Application Servers and Media Servers. In real world deployments, an Application Server may interact with multiple Media Servers and/or a Media Server may be controlled by more than one Application Server.
アーキテクチャは、アプリケーションサーバーとメディアサーバーの間の多目的関係をサポートする必要があります。実際の展開では、アプリケーションサーバーは複数のメディアサーバーと対話し、メディアサーバーが複数のアプリケーションサーバーによって制御される場合があります。
Application Servers can use the SIP URI as described in [RFC4240] to request basic functions from Media Servers. Basic functions are characterized as requiring no mid-call interactions between the AS and MS. Examples of these functions are simple announcement-playing or basic conference-mixing where the AS does not need to explicitly control the mixing.
[RFC4240]に記載されているように、アプリケーションサーバーはSIP URIを使用して、メディアサーバーから基本的な機能を要求できます。基本関数は、ASとMSの間にミッドコールの相互作用を必要としないと特徴付けられます。これらの機能の例は、ASが混合を明示的に制御する必要のない単純なアナウンスプレイングまたは基本的な会議ミキシングです。
Most services however have interactions between the AS and MS during a call or conference. The type of interactions can be generalized as follows:
ただし、ほとんどのサービスは、通話または会議中にASとMSの間に相互作用します。相互作用のタイプは、次のように一般化できます。
o commands from an AS to an MS to request the application or configuration of a function. The request may apply to a single media stream, multiple media streams associated with multiple SIP dialogs, or to properties of a conference mix.
o ansからのコマンドは、関数のアプリケーションまたは構成を要求するために。リクエストは、単一のメディアストリーム、複数のSIPダイアログに関連付けられた複数のメディアストリーム、または会議ミックスのプロパティに適用される場合があります。
o responses from an MS to an AS reporting on the status of particular commands.
o 特定のコマンドのステータスに関するAS AS AS AS ASの応答。
o notifications from an MS to an AS that report results from commands or notify changes to subscribed status.
o MSからASのAS ASレポートへの通知は、コマンドの結果であるか、変更されたステータスの変更を通知します。
Commands, responses, and notifications are transported using one or more dedicated control channels between the Application Server and the Media Server. Dedicated control channels provide reliable, sequenced, peer-to-peer transport for Media Server control interactions. Implementations must support the Transport Control Protocol (TCP) [RFC0793] and may support the Stream Control Transmission Protocol (SCTP) [RFC4960]. Because MS control requires sequenced reliable delivery of messages, unreliable protocols such as the User Datagram Protocol (UDP) are not suitable. Implementations must support TLS [RFC5246] as a transport-level security mechanism although its use in deployments is optional. A dedicated control channel is shown in Figure 2 below.
コマンド、応答、および通知は、アプリケーションサーバーとメディアサーバー間の1つ以上の専用制御チャネルを使用して輸送されます。専用の制御チャネルは、メディアサーバー制御の対話に信頼性の高いシーケンスされたピアツーピアトランスポートを提供します。実装は、輸送制御プロトコル（TCP）[RFC0793]をサポートする必要があり、ストリーム制御伝送プロトコル（SCTP）[RFC4960]をサポートする場合があります。MSコントロールにはメッセージの信頼できる配信が必要なため、ユーザーデータグラムプロトコル（UDP）などの信頼できないプロトコルは適していません。展開での使用はオプションですが、実装はTLS [RFC5246]を輸送レベルのセキュリティメカニズムとしてサポートする必要があります。専用の制御チャネルを以下の図2に示します。
+-------------+ +--------------+
| | | |
| Application | MS ctrl channel | Media |
| Server |<------------------->| Server |
| | | |
+-------------+ +--------------+
^ ^ ^
RTP/SRTP | | |
(audio/ | | |
video/etc) | | |
| | v
+---|-v-------+
+-|---v-------+ |
+-|-----------+ | |
| | | |
| SIP | | |
| User Agent | |-+
| |-+
+-------------+
Figure 2: Media Server Control Architecture
図2：メディアサーバー制御アーキテクチャ
Both Application Servers and Media Servers may interact with other servers for specific purposes beyond the scope of this document. For example, Application Servers will often communicate with other infrastructure components that are usually based on deployment requirements with links to back-office data stores and applications. Media Servers will often retrieve announcements from external file servers. Also, many Media Servers support IVR dialog services using VoiceXML [W3C.REC-voicexml20-20040316]. In this case, the MS interacts with other servers using HTTP during standard VoiceXML processing. VoiceXML Media Servers may also interact with speech engines (for example, using the Media Resource Control Protocol version 2 (MRCPv2)) for speech recognition and generation purposes.
アプリケーションサーバーとメディアサーバーの両方は、このドキュメントの範囲を超えて特定の目的で他のサーバーと対話できます。たとえば、アプリケーションサーバーは、通常、バックオフィスデータストアやアプリケーションへのリンクを備えた展開要件に基づいている他のインフラストラクチャコンポーネントと通信することがよくあります。メディアサーバーは、多くの場合、外部ファイルサーバーからアナウンスを取得します。また、多くのメディアサーバーは、VoiceXML [W3C.REC-VOICEXML20-20040316]を使用してIVRダイアログサービスをサポートしています。この場合、MSは標準のVoiceXML処理中にHTTPを使用して他のサーバーと対話します。VoiceXMLメディアサーバーは、音声認識と生成の目的で、音声エンジン（たとえば、メディアリソース制御プロトコルバージョン2（MRCPV2）を使用する）と相互作用する場合があります。
Some specific types of interactions between Application and Media servers are also out of scope for this document. MS resource reservation is one such interaction. Also, any interactions between Application Servers, or between Media Servers, are also out of scope.
アプリケーションサーバーとメディアサーバーの間の特定の種類の相互作用も、このドキュメントの範囲外です。MSリソース予約は、そのような相互作用の1つです。また、アプリケーションサーバー間、またはメディアサーバー間の相互作用も範囲外です。
The Session Initiation Protocol (SIP) [RFC3261] was developed by the IETF for the purposes of initiating, managing, and terminating multimedia sessions. The popularity of SIP has grown dramatically since its inception and is now the primary Voice over IP (VoIP) protocol. This includes being selected as the basis for architectures such as the IP Multimedia Subsystem (IMS) in 3GPP and included in many of the early live deployments of VoIP-related systems. Media servers are not a new concept in IP telephony networks and there have been numerous signaling protocols and techniques proposed for their control. The most popular techniques to date have used a combination of SIP and various markup languages to convey media service requests and responses.
セッション開始プロトコル（SIP）[RFC3261]は、マルチメディアセッションの開始、管理、終了の目的でIETFによって開発されました。SIPの人気は、創業以来劇的に成長しており、現在はIP（VOIP）プロトコルを超える主要な音声です。これには、3GPPのIPマルチメディアサブシステム（IMS）などのアーキテクチャの基礎として選択され、VoIP関連システムの初期のライブ展開の多くに含まれることが含まれます。メディアサーバーは、IPテレフォニーネットワークの新しい概念ではなく、その制御のために提案されている多くのシグナル伝達プロトコルと技術がありました。これまでで最も人気のある手法では、SIPとさまざまなマークアップ言語の組み合わせを使用して、メディアサービスのリクエストと応答を伝えました。
As discussed in Section 3 and illustrated in Figure 1, the logical architecture described by this document involves interactions between an Application Server (AS) and a Media Server (MS). The SIP interactions can be broken into "MS media dialogs" that are used between an AS and an MS to establish media sessions between an endpoint and a Media Server, and "MS control dialogs" that are used to establish and maintain MS control channels.
セクション3で説明し、図1に示すように、このドキュメントで説明されている論理アーキテクチャには、アプリケーションサーバー（AS）とメディアサーバー（MS）間の相互作用が含まれます。SIPの相互作用は、ASとMSの間で使用される「MSメディアダイアログ」に分割し、エンドポイントとメディアサーバーの間でメディアセッションを確立し、MSコントロールチャネルを確立および維持するために使用される「MSコントロールダイアログ」です。
SIP is the primary signaling protocol for session signaling and is used for all media sessions directed towards a Media Server as described in this document. Media Servers may support other signaling protocols but this type of interaction is not considered here. Application Servers may terminate non-SIP signaling protocols but must gateway those requests to SIP when interacting with a Media Server.
SIPは、セッションシグナリングの主要なシグナル伝達プロトコルであり、このドキュメントで説明されているように、メディアサーバーに向けられたすべてのメディアセッションに使用されます。メディアサーバーは他のシグナル伝達プロトコルをサポートする場合がありますが、このタイプの相互作用はここでは考慮されません。アプリケーションサーバーは、非SIPシグナリングプロトコルを終了する場合がありますが、メディアサーバーとの対話時にSIPを使用するリクエストをゲートウェイする必要があります。
SIP will also be used for the creation, management, and termination of the dedicated MS control channel(s). Control channel(s) provide reliable sequenced delivery of MS Control Protocol messages. The Application and Media Servers use the SDP attributes defined in [RFC4145] to allow SIP negotiation of the control channel. A control channel is closed when SIP terminates the corresponding MS control dialog. Further details and example flows are provided in the SIP Control Framework [SIP-CTRL-FW]. The SIP Control Framework also includes basic control message semantics corresponding to the types of interactions identified in Section 3. It uses the concept of "packages" to allow domain-specific protocols to be defined using the Extensible Markup Language (XML) [W3C.REC-xml-20060816] format. The MS Control Protocol is made up of one or more packages for the SIP Control Framework.
SIPは、専用のMSコントロールチャネルの作成、管理、終了にも使用されます。制御チャネルは、MSコントロールプロトコルメッセージの信頼できるシーケンスの配信を提供します。アプリケーションとメディアサーバーは、[RFC4145]で定義されているSDP属性を使用して、制御チャネルのSIP交渉を可能にします。SIPが対応するMSコントロールダイアログを終了すると、コントロールチャネルが閉じられます。詳細と例のフローは、SIP制御フレームワーク[SIP-CTRL-FW]に記載されています。SIPコントロールフレームワークには、セクション3で特定された相互作用のタイプに対応する基本的なコントロールメッセージセマンティクスも含まれています。「パッケージ」の概念を使用して、拡張可能なマークアップ言語（XML）[W3C.REC.RECTを使用してドメイン固有のプロトコルを定義できるようにします。-XML-20060816]形式。MSコントロールプロトコルは、SIPコントロールフレームワーク用の1つ以上のパッケージで構成されています。
Using SIP for both media and control dialogs provides a number of inherent benefits over other potential techniques. These include:
メディアとコントロールの両方のダイアログにSIPを使用すると、他の潜在的なテクニックに対する多くの固有の利点が提供されます。これらには以下が含まれます：
1. The use of SIP location and rendezvous capabilities, as defined in [RFC3263]. This provides core mechanisms for routing a SIP request based on techniques such as DNS SRV and NAPTR records. The SIP infrastructure makes heavy use of such techniques.
1. [RFC3263]で定義されているように、SIPの位置とランデブー機能の使用。これにより、DNS SRVやNAPTRレコードなどの手法に基づいてSIPリクエストをルーティングするためのコアメカニズムが提供されます。SIPインフラストラクチャは、このような技術を頻繁に使用しています。
2. The security and identity properties of SIP; for example, using TLS for reliably and securely connecting to another SIP-based entity. The SIP protocol has a number of identity mechanisms that can be used. [RFC3261] provides an intra-domain digest-based mechanism and [RFC4474] defines a certificate-based inter-domain identity mechanism. SIP with S/MIME provides the ability to secure payloads using encrypted and signed certificate techniques.
2. SIPのセキュリティおよびアイデンティティプロパティ。たとえば、他のSIPベースのエンティティに確実にかつ安全に接続するためにTLSを使用します。SIPプロトコルには、使用できる多くのアイデンティティメカニズムがあります。[RFC3261]は、ドメイン内ダイジェストベースのメカニズムを提供し、[RFC4474]は証明書ベースのドメイン間アイデンティティメカニズムを定義します。S/MIMEを使用したSIPは、暗号化および署名された証明書技術を使用してペイロードを保護する機能を提供します。
3. SIP has extremely powerful and dynamic media-negotiation properties as defined in [RFC3261] and [RFC3264].
3. SIPには、[RFC3261]および[RFC3264]で定義されているように、非常に強力で動的なメディアネゴシエーション特性があります。
4. The ability to select an appropriate SIP entity based on capability sets as discussed in [RFC3840]. This provides a powerful function that allows Media Servers to convey a specific capability set. An AS is then free to select an appropriate MS based on its requirements.
4. [RFC3840]で説明されているように、機能セットに基づいて適切なSIPエンティティを選択する機能。これにより、メディアサーバーが特定の機能セットを伝えることができる強力な機能が提供されます。ASは、その要件に基づいて適切なMSを自由に選択できます。
5. Using SIP also provides consistency with IETF protocols and usages. SIP was intended to be used for the creation and management of media sessions, and this provides a correct usage of the protocol.
5. SIPを使用すると、IETFプロトコルと使用法との一貫性も提供されます。SIPは、メディアセッションの作成と管理に使用することを目的としており、これはプロトコルの正しい使用を提供します。
As mentioned previously in this section, media services using SIP are fairly well understood. Some previous proposals suggested using the SIP INFO [RFC2976] method as the transport vehicle between the AS and MS. Using SIP INFO in this way is not advised for a number of reasons, which include:
このセクションで前述したように、SIPを使用したメディアサービスはかなりよく理解されています。以前の提案では、ASとMSの間の輸送車両としてSIP情報[RFC2976]メソッドを使用することを提案しました。この方法でSIP情報を使用することは、いくつかの理由でアドバイスされていません。
o INFO is an opaque request with no specific semantics. A SIP endpoint that receives an INFO request does not know what to do with it based on SIP signaling.
o 情報は、特定のセマンティクスのない不透明なリクエストです。情報要求を受信するSIPエンドポイントは、SIPシグナル伝達に基づいてどうすればよいかを知りません。
o SIP INFO was not created to carry generic session control information along the signaling path, and it should only really be used for optional application information, e.g., carrying mid-call Public Switched Telephone Network (PSTN) signaling messages between PSTN gateways.
o SIP情報は、シグナリングパスに沿って一般的なセッション制御情報を運ぶために作成されていません。たとえば、PSTNゲートウェイ間の中間パブリックスイッチ付き電話ネットワーク（PSTN）シグナリングメッセージを運ぶオプションのアプリケーション情報にのみ使用する必要があります。
o SIP INFO traverses the signaling path, which is an inefficient use for control messages that can be routed directly between the AS and MS.
o SIP情報は、ASとMSの間で直接ルーティングできる制御メッセージには非効率的な使用です。
o [RFC3261] contains rules when using an unreliable protocol such as UDP. When a packet reaches a size close to the Maximum Transmission Unit (MTU), the protocol should be changed to TCP. This type of operation is not ideal when constantly dealing with large payloads such as XML-formatted MS control messages.
o [RFC3261]は、UDPなどの信頼性の低いプロトコルを使用する場合のルールを含みます。パケットが最大送信ユニット（MTU）に近いサイズに達すると、プロトコルをTCPに変更する必要があります。このタイプの操作は、XML形式のMSコントロールメッセージなどの大きなペイロードを常に扱う場合に理想的ではありません。
One of the functions of a Media Server is to assist an Application Server that is implementing IVR services by performing media processing functions on media streams. Although "IVR" is somewhat generic terminology, the scope of media functions provided by an MS addresses the needs for user interaction dialogs. These functions include media transcoding, basic announcements, user input detection (via DTMF or speech), and media recording.
メディアサーバーの機能の1つは、メディアストリームでメディア処理機能を実行することにより、IVRサービスを実装しているアプリケーションサーバーを支援することです。「IVR」はやや一般的な用語ですが、MSによって提供されるメディア関数の範囲は、ユーザーインタラクションダイアログのニーズに対応しています。これらの機能には、メディアトランスコーディング、基本的な発表、ユーザー入力検出（DTMFまたはスピーチを介して）、およびメディア記録が含まれます。
A particular IVR or user dialog application typically requires the use of several specific media functions, as described above. The range and complexity of IVR dialogs can vary significantly, from a simple single announcement play-back to complex voice mail applications.
特定のIVRまたはユーザーダイアログアプリケーションでは、通常、上記のように、いくつかの特定のメディア関数を使用する必要があります。IVRダイアログの範囲と複雑さは、単純な単一のアナウンスプレイバックから複雑なボイスメールアプリケーションまで、大きく異なります。
As previously discussed, an AS uses SIP [RFC3261] and SDP [RFC4566] to establish and configure media sessions to a Media Server. An AS uses the MS control channel, established using SIP, to invoke IVR requests and to receive responses and notifications. This topology is shown in Figure 3 below.
前述のように、AはSIP [RFC3261]およびSDP [RFC4566]を使用して、メディアサーバーにメディアセッションを確立および構成します。ASは、SIPを使用して確立されたMSコントロールチャネルを使用して、IVRリクエストを呼び出し、応答と通知を受け取ります。このトポロジーを以下の図3に示します。
+-------------+ SIP +-------------+
| Application |<---------------------------->| Media |
| Server | (media & MS Control dialogs) | Server |
| | | |
| | MS Control Protocol (IVR) | |
| |<---------------------------->| (IVR media |
| (App logic) | (CtrlChannel) | functions) |
+-------------+ +-------------+
^ ^^
\ || R
\ || T
\ || P
\ || /
\ || S
\ || R
\ || T
\ || P
\ vv
\ call signaling +-----------+
---------------------------->| User |
(e.g., SIP) | Equipment |
+-----------+
Figure 3: IVR Topology
図3：IVRトポロジー
The variety in complexity of Application Server IVR services requires support for different levels of media functions from the Media Server as described in the following sub-sections.
アプリケーションサーバーIVRサービスの複雑さの多様性には、以下のサブセクションで説明されているように、メディアサーバーからのさまざまなレベルのメディア機能をサポートする必要があります。
For simple basic announcement requests, the MS control channel, as depicted in Figure 3 above, is not required. Simple announcement requests may be invoked on the Media Server using the SIP URI mechanism defined in [RFC4240]. This interface allows no digit detection or collection of user input and no mid-call dialog control. However, many applications only require basic media services, and the processing burden on the Media Server to support more complex interactions with the AS would not be needed in that case.
単純な基本発表要求の場合、上記の図3に示すように、MSコントロールチャネルは必要ありません。[RFC4240]で定義されているSIP URIメカニズムを使用して、メディアサーバーで簡単なアナウンスリクエストを呼び出すことができます。このインターフェイスにより、ユーザー入力の数字の検出やコレクションやミッドコールダイアログコントロールはできません。ただし、多くのアプリケーションには基本的なメディアサービスのみが必要であり、メディアサーバーの処理負担は、その場合には必要ないより複雑な相互作用をサポートするために必要です。
For more complex IVR dialogs, which require mid-call interaction and control between the Application Server and the Media Server, the MS control channel (as shown in Figure 3 above) is used to invoke specific media functions on the Media Server. These functions include, but are not limited to, complex announcements with barge-in facility, user-input detection and reporting (e.g., DTMF) to an Application Server, DTMF and voice-activity controlled recordings, etc. Composite services, such as play-collect and play-record, are also addressed by this model.
アプリケーションサーバーとメディアサーバー間の中間コールの相互作用と制御を必要とするより複雑なIVRダイアログの場合、MSコントロールチャネル（上記の図3を参照）を使用して、メディアサーバー上の特定のメディア機能を呼び出します。これらの機能には、アプリケーションサーバー、DTMF、音声活動制御録音などへのバージイン施設、ユーザー入力検出とレポート（DTMFなど）を使用した複雑な発表が含まれますが、これらに限定されません。-CollectとPlay-Recordもこのモデルで扱われます。
Mid-call control also allows Application Servers to subscribe to IVR-related events and for the Media Server to notify the AS when these events occur. Examples of such events are announcement completion events, record completion events, and reporting of collected DTMF digits.
Mid-Call Controlでは、アプリケーションサーバーがIVR関連のイベントを購読したり、メディアサーバーがこれらのイベントが発生したときに通知することもできます。このようなイベントの例は、発表完了イベント、記録完了イベント、および収集されたDTMF数字の報告です。
Although IVR services with mid-call control, as described above, provide a comprehensive set of media functions expected from a Media Server, the advanced IVR services model allows a higher level of abstraction describing application logic, as provided by VoiceXML, to be executed on the Media Server. Invocation of VoiceXML IVR dialogs may be via the "Prompt and Collect" mechanism of [RFC4240]. Additionally, the IVR control protocol can be extended to allow VoiceXML requests to also be invoked over the MS control channel. VoiceXML IVR services invoked on the Media Server may require an HTTP interface (not shown in Figure 3) between the Media Server and one or more back-end servers that host or generate VoiceXML documents. The back-end server(s) may or may not be physically separate from the Application Server.
上記のように、中コール制御を備えたIVRサービスは、メディアサーバーから予想される包括的なメディア関数セットを提供しますが、Advanced IVRサービスモデルにより、VoiceXMLが提供するように、Application Logicを記述する高レベルの抽象化が可能になります。メディアサーバー。VoiceXML IVRダイアログの呼び出しは、[RFC4240]の「プロンプトと収集」メカニズムを介して行われる場合があります。さらに、IVRコントロールプロトコルを拡張して、VoiceXMLリクエストをMSコントロールチャネル上で呼び出すこともできます。Media Serverに呼び出されるVoiceXML IVRサービスには、Media ServerとVoiceXMLドキュメントをホストまたは生成する1つ以上のバックエンドサーバー間のHTTPインターフェイス（図3には示されていません）が必要になる場合があります。バックエンドサーバーは、アプリケーションサーバーから物理的に分離されている場合とそうでない場合があります。
[RFC4353] describes the overall architecture and protocol components needed for multipoint conferencing using SIP. The framework for centralized conferencing [RFC5239] extends the framework to include a protocol between the user and the conferencing server. [RFC4353] describes the conferencing server decomposition but leaves the specifics open.
[RFC4353]は、SIPを使用したマルチポイント会議に必要な全体的なアーキテクチャおよびプロトコルコンポーネントを説明しています。集中会議[RFC5239]のフレームワークは、フレームワークを拡張して、ユーザーと会議サーバーの間にプロトコルを含めるようにします。[RFC4353]は、会議サーバーの分解について説明しますが、詳細を開いたままにします。
This section describes the decomposition and discusses the functionality of the decomposed functional units. The conferencing factory and the conference focus are part of the Application Server described in this document.
このセクションでは、分解について説明し、分解された機能ユニットの機能について説明します。会議工場と会議の焦点は、このドキュメントで説明されているアプリケーションサーバーの一部です。
An Application Server uses SIP Third Party Call Control [RFC3725] to establish media sessions from SIP user agents to a Media Server. The same mechanism is used by the Application Server as described in this section to add/remove participants to/from a conference, as well as to handle the involved media streams set up on a per-user basis. Since the XCON framework has been conceived as protocol-agnostic when talking about the Call Signaling Protocol used by users to join a conference, an XCON-compliant Application Server will have to take care of gatewaying non-SIP signaling negotiations. This is in order to set up and make available valid SIP media sessions between itself and the Media Server, while still keeping the non-SIP interaction with the user in a transparent way.
アプリケーションサーバーは、SIPサードパーティコールコントロール[RFC3725]を使用して、SIPユーザーエージェントからメディアサーバーへのメディアセッションを確立します。このセクションで説明されているように、アプリケーションサーバーでは、会議に参加者と削除するために同じメカニズムが使用され、ユーザーごとにセットアップされた関係するメディアストリームを処理するために使用されます。XCONフレームワークは、会議に参加するためにユーザーが使用するコールシグナリングプロトコルについて話すときにプロトコルに依存して構成されているため、XCONに準拠したアプリケーションサーバーは、非SIPシグナルの交渉をゲートウェイする必要があります。これは、ユーザーとの非SIP相互作用を透明な方法で維持しながら、それ自体とメディアサーバーの間で有効なSIPメディアセッションを設定して利用できるようにするためです。
+------------+ +------------+
| | SIP (2m+1c) | |
| Application|-------------| Media |
| Server | | Server |
| (Focus) |-------------| (Mixer) |
| | CtrlChannel | |
+------------+ +------------+
| \ .. .
| \\ RTP... .
| \\ .. .
| H.323 \\ ... .
SIP | \\ ... .RTP
| ..\ .
| ... \\ .
| ... \\ .
| .. \\ .
| ... \\ .
| .. \ .
+-----------+ +-----------+
|Participant| |Participant|
+-----------+ +-----------+
Figure 4: Conference Topology
図4：会議のトポロジ
To complement the functionality provided by 3PCC and by the XCON control protocol, the Application Server makes use of a dedicated Media Server control channel in order to set up and manage media conferences on the Media Server. Figure 4 shows the signaling and media paths for a two-participant conference. The three SIP dialogs between the AS and MS establish one control session (1c) and two media sessions (2m) from the participants (one originally signaled using H.323 and then gatewayed into SIP and one signaled directly in SIP).
3PCCおよびXCONコントロールプロトコルによって提供される機能を補完するために、アプリケーションサーバーは、メディアサーバーのメディア会議をセットアップおよび管理するために、専用のメディアサーバー制御チャネルを使用します。図4は、2人の参加者会議のシグナルとメディアパスを示しています。ASとMSの間の3つのSIPダイアログは、参加者から1つのコントロールセッション（1C）と2つのメディアセッション（2m）を確立します（1つは元々H.323を使用してシグナルを送信し、SIPにゲートウェイで、1つはSIPで直接シグナルになります）。
As a conference focus, the Application Server is responsible for setting up and managing a media conference on the Media Servers, in order to make sure that all the media streams provided in a conference are available to its participants. This is achieved by using the services of one or more mixer entities (as described in RFC 4353), whose role as part of the Media Server is described in this section. Services required by the Application Server include, but are not limited to, means to set up, handle, and destroy a new media conference, adding and removing participants from a conference, managing media streams in a conference, controlling the layout and the mixing configuration for each involved media, allowing per-user custom media profiles, and so on.
会議の焦点として、アプリケーションサーバーは、会議で提供されるすべてのメディアストリームが参加者が利用できるようにするために、メディアサーバーでメディア会議のセットアップと管理を担当します。これは、メディアサーバーの一部としての役割についてこのセクションで説明する1つ以上のミキサーエンティティ（RFC 4353で説明されている）のサービスを使用することで達成されます。アプリケーションサーバーが必要とするサービスには、新しいメディア会議のセットアップ、処理、破壊、会議から参加者の追加、削除、会議のメディアストリームの管理、レイアウトとミキシング構成の管理、およびミキシング構成の管理、および削除が含まれますが、これらに限定されないことが含まれます。関係するメディアごとに、ユーザーごとのカスタムメディアプロファイルなどを許可します。
As a mixer entity, in such a multimedia conferencing scenario, the Media Server receives a set of media streams of the same type (after transcoding if needed) and then takes care of combining the received media in a type-specific manner, redistributing the result to each authorized participant. The way each media stream is combined, as well as the media-related policies, is properly configured and handled by the Application Server by means of a dedicated MS control channel.
ミキサーエンティティとして、このようなマルチメディア会議シナリオでは、メディアサーバーは同じタイプのメディアストリームのセットを受信し（必要に応じてトランスコーディング後）、受け取ったメディアをタイプ固有の方法で組み合わせて、結果を再配布します。認定された各参加者に。メディア関連のポリシーと同様に、各メディアストリームの組み合わせ方法は、専用のMSコントロールチャネルによってアプリケーションサーバーによって適切に構成および処理されます。
To summarize, the AS needs to be able to manage Media Servers at a conference and participant level.
要約すると、会議と参加者レベルでメディアサーバーを管理できるようにする必要があります。
When a new conference is created, as a result of a previous conference scheduling or of the first participant dialing in to a specified URI, the Application Server must take care of appropriately creating a media conference on the Media Server. It does so by sending an explicit request to the Media Server. This can be by means of an MS control channel message. This request may contain detailed information upon the desired settings and policies for the conference (e.g., the media to involve, the mixing configuration for them, the relevant identifiers, etc.). The Media Server validates such a request and takes care of allocating the needed resources to set up the media conference.
以前の会議のスケジューリングまたは指定されたURIにダイヤルインする最初の参加者の結果として、新しい会議が作成された場合、アプリケーションサーバーはメディアサーバーでメディア会議を適切に作成する必要があります。これは、メディアサーバーに明示的なリクエストを送信することで行います。これは、MSコントロールチャネルメッセージを使用することができます。このリクエストには、会議の目的の設定とポリシーに関する詳細情報が含まれている場合があります（たとえば、メディアが関与するメディア、それらの混合構成、関連する識別子など）。メディアサーバーはそのようなリクエストを検証し、メディア会議をセットアップするために必要なリソースを割り当てることに注意します。
Application Servers may use mechanisms other than sending requests over the control channel to establish conferences on a Media Server, and then subsequently use the control channel to control the conference. Examples of other mechanisms to create a conference include using the Request-URI mechanism of [RFC4240] or the procedures defined in [RFC4579].
アプリケーションサーバーは、コントロールチャネル上でリクエストを送信してメディアサーバーで会議を確立する以外のメカニズムを使用し、その後、コントロールチャネルを使用して会議を制御する場合があります。会議を作成する他のメカニズムの例には、[RFC4240]のリクエスト-URIメカニズムまたは[RFC4579]で定義されている手順を使用することが含まれます。
Once done, the MS informs the Application Server about the result of the request. Each conference will be referred to by a specific identifier, which both the Application Server and the Media Server will include in subsequent transactions related to the same conference (e.g., to modify the settings of an extant conference).
完了したら、MSはリクエストの結果についてアプリケーションサーバーに通知します。各会議は、特定の識別子によって紹介されます。特定の識別子は、アプリケーションサーバーとメディアサーバーの両方に、同じ会議に関連する後続のトランザクションに含まれます（例えば、現存する会議の設定を変更する）。
As stated before, an Application Server uses SIP 3PCC to establish media sessions from SIP user agents to a Media Server. The URI that the AS uses in the INVITE to the MS may be one associated with the conference on the MS. More likely however, the media sessions are first established to the Media Server using a URI for the Media Server and then subsequently joined to the conference using the MS Control Protocol. This allows IVR dialogs to be performed prior to joining the conference.
前に述べたように、アプリケーションサーバーはSIP 3PCCを使用して、SIPユーザーエージェントからメディアサーバーへのメディアセッションを確立します。ASがMSへの招待で使用するURIは、MSに関する会議に関連するものである可能性があります。ただし、メディアセッションは、メディアサーバーにURIを使用してメディアサーバーに最初に確立され、その後MSコントロールプロトコルを使用して会議に参加しました。これにより、会議に参加する前にIVRダイアログを実行できます。
The AS as a 3PCC correlates the media session negotiation between the UA and the MS, in order to appropriately establish all the needed media streams based on the conference policies.
AS 3PCCは、会議ポリシーに基づいて必要なすべてのメディアストリームを適切に確立するために、UAとMSの間のメディアセッションの交渉と相関しています。
The XCON Common Data Model [XCON-DM] currently defines some basic media-related controls, which conference-aware participants can take advantage of in several ways, e.g., by means of an XCON conference control protocol or IVR dialogs. These controls include the possibility to modify the participants' own volume for audio in the conference, configure the desired layout for incoming video streams, mute/unmute oneself, and pause/unpause one's own video stream. Such controls are exploited by conference-aware participants through the use of dedicated conference control protocol requests to the Application Server. The Application Server takes care of validating such requests and translates them into the Media Server Control Protocol, before forwarding them over the MS Control Channel to the MS. According to the directives provided by the Application Server, the Media Server manipulates the involved media streams accordingly.
XCON Common Data Model [XCON-DM]は現在、いくつかの基本的なメディア関連のコントロールを定義しています。これは、会議を受けた参加者が、たとえば、XCON Conference Control ProtocolまたはIVRダイアログを使用して、いくつかの方法で利用できることを定義しています。これらのコントロールには、会議でのオーディオのために参加者自身のボリュームを変更する可能性が含まれ、着信ビデオストリームのための目的のレイアウト、ミュート/ミュートを解除し、自分のビデオストリームを一時停止/一時停止/解除することが含まれます。このようなコントロールは、アプリケーションサーバーに専用の会議制御プロトコル要求を使用することにより、会議を認識している参加者によって活用されます。アプリケーションサーバーは、そのようなリクエストの検証に対応し、MSコントロールチャネルを介してMSに転送する前に、メディアサーバーコントロールプロトコルに変換します。アプリケーションサーバーが提供する指令によると、メディアサーバーは、それに応じて関係するメディアストリームを操作します。
+------------+ +------------+
| | 'Include audio | |
| Application| sent by user X | Media |
| Server | in conf Y mix' | Server |
| (Focus) |----------------->| (Mixer) |
| | (MS CtrlChn) | |
+------^-----+ +------------+
| ..
| ...
| 'Unmute me' ... RTP
| (XCON) ...
| ...
| ...
+-----------+ ...
|Participant|...
+-----------+
Figure 5: Conferencing Example: Unmuting A Participant
図5：会議の例：参加者を出産する
The Media Server may need to inform the AS of events like in-band DTMF tones during the conference.
メディアサーバーは、会議中の帯域内DTMFトーンのようなイベントのように通知する必要がある場合があります。
The XCON framework introduces "floor control" functionality as an enhancement upon [RFC4575]. Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Floor control is not a mandatory mechanism for a conferencing system implementation, but it provides advanced media input control features for conference-aware participants. Such a mechanism allows for coordinated and moderated access to any set of resources provided by the conferencing system. To do so, a so-called floor is associated to a set of resources, thus representing for participants the right to access and manipulate the related resources themselves. In order to take advantage of the floor control functionality, a specific protocol, the Binary Floor Control Protocol, has been specified [RFC4582]. [RFC4583] provides a way for SIP UAs to set up a BFCP connection towards the Floor Control Server and exploit floor control by means of a Connection-Oriented Media (COMEDIA) [RFC4145] negotiation.
XCONフレームワークは、[RFC4575]の強化として「フロアコントロール」機能を導入します。フロアコントロールは、（マルチパーティ）会議環境で共有リソースへの共同または排他的アクセスを管理する手段です。フロアコントロールは、会議システムの実装のための必須メカニズムではありませんが、会議を受けた参加者に高度なメディア入力制御機能を提供します。このようなメカニズムにより、会議システムが提供するリソースのセットへの調整および緩和のアクセスが可能になります。そのために、いわゆる床は一連のリソースに関連付けられているため、参加者にとって関連するリソース自体にアクセスして操作する権利を表します。フロアコントロール機能を活用するために、特定のプロトコルであるバイナリフロアコントロールプロトコルが指定されています[RFC4582]。[RFC4583]は、SIP UASがフロアコントロールサーバーに向かってBFCP接続をセットアップし、接続指向のメディア（COMEDIA）[RFC4145]ネゴシエーションによってフロアコントロールを活用する方法を提供します。
In the context of the AS-MS interaction, floor control constitutes a further means to control participants' media streams. A typical example is a floor associated with the right to access the shared audio channel in a conference. A participant who is granted such a floor is granted by the conferencing system the right to talk, which means that its audio frames are included by the MS in the overall audio conference mix. Similarly, when the floor is revoked, the participant is muted in the conference, and its audio is excluded from the final mix.
AS-MS相互作用のコンテキストでは、フロアコントロールは、参加者のメディアストリームを制御するためのさらなる手段を構成します。典型的な例は、会議で共有オーディオチャネルにアクセスする権利に関連するフロアです。そのようなフロアを付与された参加者は、会議システムから話す権利を認められます。つまり、オーディオフレームはオーディオカンファレンス全体のミックスでMSに含まれています。同様に、床が取り消されると、参加者は会議でミュートされ、そのオーディオは最終ミックスから除外されます。
The BFCP defines a Floor Control Server (FCS) and the floor chair. It is clear that the floor chair making decisions about floor requests is part of the application logic. This implies that when the role of floor chair in a conference is automated, it will normally be part of the AS.
BFCPは、フロアコントロールサーバー（FCS）とフロアチェアを定義します。フロアリクエストについて決定するフロアチェアがアプリケーションロジックの一部であることは明らかです。これは、会議におけるフロアチェアの役割が自動化される場合、通常はASの一部になることを意味します。
The example makes it clear that there can be a direct or indirect interaction between the Floor Control Server and the Media Server, in order to correctly bind each floor to its related set of media resources. Besides, a similar interaction is needed between the Floor Control Server and the Application Server as well, since the latter must be aware of all the associations between floors and resources, in order to opportunely orchestrate the related bindings with the element responsible for such resources (e.g., the Media Server when talking about audio and/or video streams) and the operations upon them (e.g., mute/unmute a participant in a conference). For this reason, the Floor Control Server can be co- located with either the Media Server or the Application Server, as long as both elements are allowed to interact with the Floor Control Server by means of some kind of protocol.
この例は、各フロアを関連するメディアリソースに正しくバインドするために、フロアコントロールサーバーとメディアサーバーの間に直接的または間接的な相互作用がある可能性があることを明らかにしています。また、フロアコントロールサーバーとアプリケーションサーバーの間にも同様のインタラクションが必要です。後者は、そのようなリソースの原因となる要素と関連するバインディングを日常的に調整するために、フロアとリソースのすべての関連性を認識する必要があるためです（たとえば、メディアサーバーは、オーディオおよび/またはビデオストリームについて話すとき）およびそれらの操作（例：会議の参加者をMute/Mute）。このため、両方の要素が何らかのプロトコルによってフロアコントロールサーバーと対話できる限り、フロアコントロールサーバーをメディアサーバーまたはアプリケーションサーバーのいずれかと共同配置できます。
In the following text, both the approaches will be described in order to better explain the interactions between the involved components in both the topologies.
次のテキストでは、両方のアプローチについて説明し、両方のトポロジーの関係するコンポーネント間の相互作用をよりよく説明します。
When the AS and the FCS are co-located, the scenario is quite straightforward. In fact, it can be considered as a variation of the case depicted in Figure 5. The only relevant difference is that in this case the action the AS commands on the control channel is triggered by a change in the floor control status instead of a specific control requested by a participant himself. The sequence diagram in Figure 6 describes the interaction between the involved parties in a typical scenario. It assumes that a BFCP connection between the UA and the FCS (which we assume is co-located with the AS) has already been negotiated and established, and that the UA has been made aware of all the relevant identifiers and floors-resources-associations (e.g., by means of [RFC4583]). It also assumes that the AS has previously configured the media mixing on the MS using the MS control channel. Every frame the UA might be sending on the related media stream is currently being dropped by the MS, since the UA still isn't authorized to use the resource. For a SIP UA, this state could be consequent to a 'sendonly' field associated to the media stream in a re-INVITE originated by the MS. It is worth pointing out that the AS has to make sure that no user media control mechanisms, such as mentioned in the previous sub-section, can override the floor control.
ASとFCSが共同住宅されている場合、シナリオは非常に簡単です。実際、図5に示すケースのバリエーションと見なすことができます。唯一の関連する違いは、この場合、制御チャネルのASコマンドが特定の場合ではなくフロアコントロールステータスの変更によってトリガーされることです。参加者自身から要求されたコントロール。図6のシーケンス図は、典型的なシナリオの関係者間の相互作用を説明しています。これは、UAとFCSの間のBFCP接続（ASと共同で共同で開催されていると仮定）がすでに交渉および確立されており、UAはすべての関連する識別子とフロアリソースアソシエーションを認識していると想定しています。（例：[RFC4583]による）。また、ASがMSコントロールチャネルを使用してMSでメディアミキシングを以前に構成したことを前提としています。UAが現在リソースを使用する権限を与えられていないため、UAが関連するメディアストリームに送信しているすべてのフレームは現在MSによって削除されています。SIP UAの場合、この状態は、MSから発信されたReインスバイトのメディアストリームに関連付けられている「センドンリー」フィールドの結果として生じる可能性があります。ASは、以前のサブセクションに記載されているようなユーザーメディア制御メカニズムがフロアコントロールをオーバーライドできないことを確認する必要があることを指摘する価値があります。
UA AS MS
(Floor Participant) (FCS)
| | |
|<===================== One-way RTP stream ======================|
| | |
| FloorRequest(BFCP) | |
|------------------------------------>| |
| | |
| FloorRequestStatus[PENDING](BFCP) | |
|<------------------------------------| |
| |--+ apply |
| | | policies |
| |<-+ to request |
| | |
| FloorRequestStatus[ACCEPTED](BFCP) | |
|<------------------------------------| |
| | |
. . .
. . .
| | |
| FloorRequestStatus[GRANTED](BFCP) | |
|<------------------------------------| |
| | 'Unmute UA' (CtrlChn) |
| |------------------------->|
| | |
|<==================== Bidirectional RTP stream ================>|
| | |
. . .
. . .
Figure 6: Conferencing Example: Floor Control Call Flow
図6：会議の例：フロアコントロールコールフロー
A UA, which also acts as a floor participant, sends a "FloorRequest" to the floor control server (FCS, which is co-located with the AS), stating his will to be granted the floor associated with the audio stream in the conference. The AS answers the UA with a "FloorRequestStatus" message with a PENDING status, meaning that a decision on the request has not been made yet. The AS, according to the BFCP policies for this conference, makes a decision on the request, i.e., accepting it. Note that this decision might be relayed to another participant in case he has previously been assigned as chair of the floor. Assuming the request has been accepted, the AS notifies the UA about the decision with a new "FloorRequestStatus", this time with an ACCEPTED status in it. The ACCEPTED status of course only means that the request has been accepted, which doesn't mean the floor has been granted yet. Once the queue management in the FCS, according to the specified algorithms for scheduling, states that the floor request previously made by the UA can be granted, the AS sends a new "FloorRequestStatus" to the UA with a GRANTED status, and takes care of unmuting the participant in the conference by sending a directive to the MS through the control channel. Once the UA receives the notification stating his request has been granted, he can start sending its media, aware of the fact that now his media stream won't be dropped by the MS. In case the session has been previously updated with a 'sendonly' associated to the media stream, the MS must originate a further re-INVITE stating that the media stream flow is now bidirectional ('sendrecv').
フロア参加者としても機能するUAは、フロアコントロールサーバー（ASと共同で開催されるFCS）に「フロアレクエスト」を送信し、会議のオーディオストリームに関連付けられたフロアに付与される意志を述べています。。As As Asは、保留中のステータスを持つ「FloorRequestStatus」メッセージでUAに答えます。これは、要求に関する決定がまだ行われていないことを意味します。ASは、この会議のBFCPポリシーによると、要求に関する決定を下します。つまり、それを受け入れます。この決定は、以前にフロアの議長として割り当てられた場合に別の参加者に中継される可能性があることに注意してください。リクエストが受け入れられたと仮定すると、ASは、新しい「FloorRequestStatus」で決定についてUAに通知します。今回は受け入れられたステータスがあります。もちろん、受け入れられたステータスは、リクエストが受け入れられたことを意味しますが、これはフロアがまだ認められていることを意味しません。FCSのキュー管理が、スケジューリングのために指定されたアルゴリズムに従って、以前に行われたフロア要求が付与できると述べています。コントロールチャネルを介してMSに指令を送信することにより、会議の参加者を解きません。UAが彼の要求が認められたことを示す通知を受け取ると、彼はメディアの送信を開始することができます。セッションがメディアストリームに関連付けられた「sendonly」で以前に更新された場合、MSは、メディアストリームの流れが現在双方向（ 'sendrecv'）であることを示すさらなる再viteを発信する必要があります。
As mentioned before, this scenario envisages an automated floor chair role, where it's the AS, according to some policies, which makes decisions on floor requests. The case of a chair role performed by a real person is exactly the same, with the difference that the incoming request is not directly handled by the AS according to its policies, but it is instead forwarded to the floor control participant that the chair UA is exploiting. The decision on the request is then communicated by the chair UA to the AS-FCS by means of a 'ChairAction' message.
前述のように、このシナリオは、フロアリクエストに関する決定を下すいくつかのポリシーによると、自動フロアチェアの役割を想定しています。実在の人物によって実行される椅子の役割のケースはまったく同じであり、着信要求はそのポリシーに従ってASによって直接処理されないという違いがありますが、代わりにフロアコントロールの参加者に椅子UAがあることを転送します。悪用。その後、リクエストに関する決定は、「チェアアクション」メッセージによって議長UAからAS-FCSに伝えられます。
The rest of this section will instead explore the other scenario, which assumes that the interaction between AS-FCS happens through the MS control channel. This scenario is compliant with the H.248.19 document related to conferencing in 3GPP. The following sequence diagram describes the interaction between the involved parties in the same use-case scenario that has been explored for the previous topology: consequently, the diagram makes exactly the same assumptions that have been made for the previously described scenario. This means that the scenario again assumes that a BFCP connection between the UA and the FCS has already been negotiated and established, and that the UA has been made aware of all the relevant identifiers and floors-resources-associations. It also assumes that the AS has previously configured the media mixing on the MS using the MS control channel. This time it includes identifying the BFCP-moderated resources, establishing basic policies and instructions about chair identifiers for each resource, and subscribing to events of interest, because the FCS is not co-located with the AS anymore. Additionally, a BFCP session has been established between the AS (which in this scenario acts as a floor chair) and the FCS (MS). Every frame the UA might be sending on the related media stream is currently being dropped by the MS, since the UA still isn't authorized to use the resource. For a SIP UA, this state could be consequent to a 'sendonly' field associated to the media stream in a re-INVITE originated by the MS. Again, it is worth pointing out that the AS has to make sure that no user media control mechanisms, such as mentioned in the previous sub-section, can override the floor control.
代わりに、このセクションの残りの部分では、AS-FC間の相互作用がMSコントロールチャネルを介して発生すると仮定している他のシナリオを検討します。このシナリオは、3GPPでの会議に関連するH.248.19ドキュメントに準拠しています。次のシーケンス図は、以前のトポロジについて調査されたのと同じユースケースシナリオの関係者間の相互作用について説明します。その結果、図は、前述のシナリオに対して行われたまったく同じ仮定を作成します。これは、シナリオが再びUAとFCSの間のBFCP接続がすでに交渉および確立されていること、およびUAがすべての関連する識別子と床とリソースの関連付けを認識していることを想定していることを意味します。また、ASがMSコントロールチャネルを使用してMSでメディアミキシングを以前に構成したことを前提としています。今回は、BFCPモデリングのリソースの識別、各リソースの椅子識別子に関する基本的なポリシーと指示の確立、およびFCSがもうASと共同で開催されていないため、関心のあるイベントを購読することが含まれます。さらに、AS（このシナリオではフロアチェアとして機能する）とFCS（MS）の間にBFCPセッションが確立されています。UAが現在リソースを使用する権限を与えられていないため、UAが関連するメディアストリームに送信しているすべてのフレームは現在MSによって削除されています。SIP UAの場合、この状態は、MSから発信されたReインスバイトのメディアストリームに関連付けられている「センドンリー」フィールドの結果として生じる可能性があります。繰り返しますが、ASは、以前のサブセクションで言及されているようなユーザーメディア制御メカニズムがフロアコントロールをオーバーライドできないことを確認する必要があることを指摘する価値があります。
UA AS MS
(Floor Participant) (Floor Chair) (FCS)
| | |
|<===================== One-way RTP stream ======================|
| | |
| FloorRequest(BFCP) | |
|--------------------------------------------------------------->|
| | |
| | FloorRequestStatus[PENDING](BFCP) |
|<---------------------------------------------------------------|
| | FloorRequestStatus[PENDING](BFCP) |
| |<-----------------------------------|
| | |
| | ChairAction[ACCEPTED] (BFCP) |
| |----------------------------------->|
| | ChairActionAck (BFCP) |
| |<-----------------------------------|
| | |
| | FloorRequestStatus[ACCEPTED](BFCP) |
|<---------------------------------------------------------------|
| | |
. . .
. . .
| | |
| | FloorRequestStatus[GRANTED](BFCP) |
|<---------------------------------------------------------------|
| | 'Floor has been granted' (CtrlChn) |
| |<-----------------------------------|
| | |
|<==================== Bidirectional RTP stream ================>|
| | |
. . .
. . .
Figure 7: Conferencing Example: Floor Control Call Flow
図7：会議の例：フロアコントロールコールフロー
A UA, which also acts as a floor participant, sends a "FloorRequest" to the floor control server (FCS, which is co-located with the MS), stating his will to be granted the floor associated with the audio stream in the conference. The MS answers the UA with a "FloorRequestStatus" message with a PENDING status, meaning that a decision on the request has not been made yet. It then notifies the AS, which in this example handles the floor chair role, about the new request by forwarding there the received request. The AS, according to the BFCP policies for this conference, makes a decision on the request, i.e., accepting it. It informs the MS about its decision through a BFCP "ChairAction" message. The MS then acknowledges the 'ChairAction' message and then notifies the UA about the decision with a new "FloorRequestStatus", this time with an ACCEPTED status in it. The ACCEPTED status of course only means that the request has been accepted, which doesn't mean the floor has been granted yet. Once the queue management in the MS, according to the specified algorithms for scheduling, states that the floor request previously made by the UA can be granted, the MS sends a new "FloorRequestStatus" to the UA with a GRANTED status, and takes care of unmuting the participant in the conference. Once the UA receives the notification stating his request has been granted, he can start sending its media, aware of the fact that now his media stream won't be dropped by the MS. In case the session has been previously updated with a 'sendonly' associated to the media stream, the MS must originate a further re-INVITE stating that the media stream flow is now bidirectional ('sendrecv').
フロア参加者としても機能するUAは、フロアコントロールサーバー（FCS、MSと共同で開催されるFCS）に「フロアレクエスト」を送信し、会議のオーディオストリームに関連付けられたフロアに付与される意志を述べています。。MSは、保留中のステータスを持つ「FloorRequestStatus」メッセージでUAに答えます。つまり、要求に関する決定はまだ行われていません。次に、ASに通知します。この例では、床の椅子の役割を処理し、受信したリクエストを転送する新しいリクエストについて説明します。ASは、この会議のBFCPポリシーによると、要求に関する決定を下します。つまり、それを受け入れます。これは、BFCPの「椅子」メッセージによる決定についてMSに通知します。その後、MSは「椅子」メッセージを認め、新しい「FloorRequestStatus」で決定についてUAに通知します。今回は受け入れられたステータスが含まれています。もちろん、受け入れられたステータスは、リクエストが受け入れられたことを意味しますが、これはフロアがまだ認められていることを意味しません。MSのキュー管理が、スケジューリングのために指定されたアルゴリズムに従って、以前に行われたフロア要求を許可できると述べていると、MSは新しい「フロアレクエストステータス」をUAに付与されたステータスで送信し、世話をします会議の参加者を解きません。UAが彼の要求が認められたことを示す通知を受け取ると、彼はメディアの送信を開始することができます。セッションがメディアストリームに関連付けられた「sendonly」で以前に更新された場合、MSは、メディアストリームの流れが現在双方向（ 'sendrecv'）であることを示すさらなる再viteを発信する必要があります。
This scenario envisages an automated floor chair role, where it's the AS, according to some policies, which makes decisions on floor requests. Again, the case of a chair role performed by a real person is exactly the same, with the difference that the incoming request is not forwarded to the AS but to the floor control participant that the chair UA is exploiting. The decision on the request is communicated by means of a 'ChairAction' message in the same way.
このシナリオでは、自動化されたフロアチェアの役割を想定しています。ここでは、一部のポリシーによると、フロアリクエストに関する決定を下します。繰り返しになりますが、実在の人物によって実行される椅子の役割のケースはまったく同じであり、着信要求がASに転送されるのではなく、議長のUAが悪用しているフロアコントロール参加者に転送されます。リクエストに関する決定は、同じように「椅子」メッセージによって伝えられます。
Another typical scenario is a BFCP-moderated conference with no chair to manage floor requests. In such a scenario, the MS has to take care of incoming requests according to some predefined policies, e.g., always accepting new requests. In this case, no decisions are required by external entities, since all are instantly decided by means of policies in the MS.
もう1つの典型的なシナリオは、フロアリクエストを管理するための椅子がないBFCPモデル化会議です。このようなシナリオでは、MSは、いくつかの事前定義されたポリシー、たとえば常に新しいリクエストを受け入れることに応じて、着信リクエストを処理する必要があります。この場合、MSのポリシーによってすべてが即座に決定されるため、外部エンティティは決定は必要ありません。
As stated before, the case of the FCS co-located with the AS is much simpler to understand and exploit. When the AS has full control upon the FCS, including its queue management, the AS directly instructs the MS according to the floor status changes, e.g., by instructing the MS through the control channel to unmute a participant who has been granted the floor associated to the audio media stream.
前に述べたように、FCSのケースは、ASと共同で理解し、理解して悪用するのがはるかに簡単です。キュー管理を含むFCSを完全に制御している場合、ASはフロアステータスの変更に従ってMSを直接指示します。オーディオメディアストリーム。
This document describes the architectural framework to be used for Media Server control. Its focus is the interactions between Application Servers and Media Servers. User agents interact with Application Servers by means of signaling protocols such as SIP. These interactions are beyond the scope of this document. Application Servers are responsible for utilizing the security mechanisms of their signaling protocols, combined with application-specific policy, to ensure they grant service only to authorized users. Media interactions between user agents and Media Servers are also outside the scope of this document. Those interactions are at the behest of Application Servers, which must ensure that appropriate security mechanisms are used. For example, if the MS is acting as the FCS, then the BFCP connection between the user agent and the MS is established to the MS by the AS using SIP and the SDP mechanisms described in [RFC4583]. BFCP [RFC4582] strongly imposes the use of TLS for BFCP.
このドキュメントでは、メディアサーバー制御に使用されるアーキテクチャのフレームワークについて説明します。その焦点は、アプリケーションサーバーとメディアサーバー間の相互作用です。ユーザーエージェントは、SIPなどのシグナル伝達プロトコルを使用してアプリケーションサーバーと対話します。これらの相互作用は、このドキュメントの範囲を超えています。アプリケーションサーバーは、信号プロトコルのセキュリティメカニズムをアプリケーション固有のポリシーと組み合わせて、認定ユーザーにのみサービスを許可することを担当します。ユーザーエージェントとメディアサーバー間のメディアインタラクションも、このドキュメントの範囲外です。これらの相互作用はアプリケーションサーバーの要請であり、適切なセキュリティメカニズムが使用されることを保証する必要があります。たとえば、MSがFCSとして作用している場合、[RFC4583]に記載されているSIPとSDPメカニズムを使用して、ユーザーエージェントとMSの間のBFCP接続がMSに確立されます。BFCP [RFC4582]は、BFCPのTLSの使用を強く課しています。
Media Servers are valuable network resources and need to be protected against unauthorized access. Application Servers use SIP and related standards both to establish control channels to Media Servers and to establish media sessions, including BFCP sessions, between an MS and end users. Media servers use the security mechanisms of SIP to authenticate requests from Application servers and to ensure the integrity of those requests. Leveraging the security mechanisms of SIP ensures that only authorized Application Servers are allowed to establish sessions to an MS and to access MS resources through those sessions.
メディアサーバーは貴重なネットワークリソースであり、不正アクセスから保護する必要があります。アプリケーションサーバーは、SIPと関連標準を使用して、メディアサーバーへの制御チャネルを確立し、MSとエンドユーザーの間でBFCPセッションを含むメディアセッションを確立します。メディアサーバーは、SIPのセキュリティメカニズムを使用して、アプリケーションサーバーからのリクエストを認証し、それらのリクエストの整合性を確保します。SIPのセキュリティメカニズムを活用することで、許可されたアプリケーションサーバーのみがMSへのセッションを確立し、それらのセッションを通じてMSリソースにアクセスできるようになります。
Control channels between an AS and MS carry the MS control protocol, which affects both the service seen by end users and the resources used on a Media Server. TLS [RFC5246] must be implemented as the transport-level security mechanism for control channels to guarantee the integrity of MS control interactions.
ASとMSの間の制御チャネルは、MSコントロールプロトコルを運びます。これは、エンドユーザーが見たサービスとメディアサーバーで使用されるリソースの両方に影響します。TLS [RFC5246]は、MS制御相互作用の整合性を保証するための制御チャネルの輸送レベルのセキュリティメカニズムとして実装する必要があります。
The resources of an MS can be shared by more than one AS. Media Servers must prevent one AS from accessing and manipulating the resources that have been assigned to another AS. This may be achieved by an MS associating ownership of a resource to the AS that originally allocates it, and then insuring that future requests involving that resource correlate to the AS that owns and is responsible for it.
MSのリソースは、複数のASで共有できます。メディアサーバーは、別のASに割り当てられたリソースにアクセスして操作することを防ぐ必要があります。これは、リソースの所有権をASに関連付けるMSが元々それを割り当てることによって達成される可能性があります。そして、そのリソースを含む将来の要求が、それが所有し、それに対してASと相関していることを保証することができます。
The authors would like to thank Spencer Dawkins for detailed reviews and comments, Gary Munson for suggestions, and Xiao Wang for review and feedback.
著者は、詳細なレビューとコメントについては、スペンサー・ドーキンス、提案についてはゲイリー・マンソン、Xiao Wangにレビューとフィードバックについて感謝したいと思います。
This document is a product of the Media Control Architecture Design Team. In addition to the editor, the following individuals constituted the design team and made substantial textual contributions to this document:
このドキュメントは、メディアコントロールアーキテクチャデザインチームの製品です。編集者に加えて、次の個人が設計チームを構成し、このドキュメントに実質的なテキスト貢献をしました。
Chris Boulton: cboulton@ubiquity.net
Chris Boulton：cboulton@ubiquity.net
Martin Dolly: mdolly@att.com
Martin Dolly：mdolly@att.com
Roni Even: roni.even@polycom.co.il
roni偶数：roni.even@polycom.co.il
Lorenzo Miniero: lorenzo.miniero@unina.it
Lorenzo Miniero：lorenzo.miniero@unina.it
Adnan Saleem: Adnan.Saleem@radisys.com
Adnan Saleem：adnan.saleem@radisys.com
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[RFC2976] Donovan、S。、「The SIP Info Method」、RFC 2976、2000年10月。
[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 Intioniation Protocol」、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] Rosenberg、J。およびH. Schulzrinne、「セッション開始プロトコル（SIP）：SIPサーバーの位置」、RFC 3263、2002年6月。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[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：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
[RFC3725] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[RFC3725] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「セッション開始プロトコル（SIP）のサードパーティコールコントロール（3PCC）の最良の現在のプラクティス」、BCP 85、RFC 3725、2004年4月。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3840] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「セッション開始プロトコル（SIP）のユーザーエージェント機能を示す」、RFC 3840、2004年8月。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145] Yon、D。およびG. Camarillo、「セッション説明プロトコル（SDP）のTCPベースのメディアトランスポート」、RFC 4145、2005年9月。
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[RFC4240] Burger、E.、van Dyke、J。、およびA. Spitzer、「SIP付きベーシックネットワークメディアサービス」、RFC 4240、2005年12月。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[RFC4353] Rosenberg、J。、「セッション開始プロトコル（SIP）との会議のためのフレームワーク」、RFC 4353、2006年2月。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474] Peterson、J。and C. Jennings、「セッション開始プロトコル（SIP）における認証されたアイデンティティ管理の強化」、RFC 4474、2006年8月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：セッション説明プロトコル」、RFC 4566、2006年7月。
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, August 2006.
[RFC4575] Rosenberg、J.、Schulzrinne、H。、およびO. Levin、「会議状態のセッション開始プロトコル（SIP）イベントパッケージ」、RFC 4575、2006年8月。
[RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, August 2006.
[RFC4579]ジョンストン、A。およびO.レビン、「セッション開始プロトコル（SIP）コールコントロール - ユーザーエージェントの会議」、BCP 119、RFC 4579、2006年8月。
[RFC4582] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control Protocol (BFCP)", RFC 4582, November 2006.
[RFC4582] Camarillo、G.、Ott、J。、およびK. Drage、「バイナリフロアコントロールプロトコル（BFCP）」、RFC 4582、2006年11月。
[RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.
[RFC4583] Camarillo、G。、「セッション説明プロトコル（SDP）バイナリフロアコントロールプロトコル（BFCP）ストリームの形式」、RFC 4583、2006年11月。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイム輸送制御プロトコル（RTCP）ベースのフィードバック（RTP/AVPF）の拡張RTPプロファイル"、RFC 4585、2006年7月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、2007年9月。
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol Requirements", RFC 5167, March 2008.
[RFC5167] Dolly、M。and R. Even、「メディアサーバー制御プロトコル要件」、RFC 5167、2008年3月。
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008.
[RFC5239] Barnes、M.、Boulton、C。、およびO. Levin、「集中会議のためのフレームワーク」、RFC 5239、2008年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン1.2」、RFC 5246、2008年8月。
[SIP-CTRL-FW] Boulton, C., Melanchuk, T., and S. McGlashan, "Media Control Channel Framework", Work in Progress, February 2009.
[SIP-CTRL-FW] Boulton、C.、Melanchuk、T。、およびS. McGlashan、「Media Control Channel Framework」、Progress、2009年2月。
[W3C.REC-voicexml20-20040316] Carter, J., Tryphonas, S., Danielsen, P., Burnett, D., Rehor, K., McGlashan, S., Ferrans, J., Porter, B., Lucas, B., and A. Hunt, "Voice Extensible Markup Language (VoiceXML) Version 2.0", World Wide Web Consortium Recommendation REC-voicexml20-20040316, March 2004, <http://www.w3.org/TR/2004/REC-voicexml20-20040316>.
[W3C.REC-VOICEXML20-20040316] Carter、J.、Tryphonas、S.、Danielsen、P.、Burnett、D.、Rehor、K.、McGlashan、S.、Ferrans、J.、Porter、B.、Lucas、B。、およびA.ハント、「Voice Extensible Markup Language（VoiceXML）バージョン2.0」、World Wide Web Consortiumの推奨rec-voicexml20-20040316、2004年3月、<http://www.w3.org/tr/2004/rec-voicexml20-20040316>。
[W3C.REC-xml-20060816] Sperberg-McQueen, C., Paoli, J., Bray, T., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium Recommendation REC-xml-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816>.
[W3C.REC-XML-20060816] Sperberg-McQueen、C.、Paoli、J.、Bray、T.、Maler、E.、およびF. Yergeau、「拡張可能なマークアップ言語（XML）1.0（第4版）」、World Wide Web Consortiumの推奨REC-XML-20060816、2006年8月、<http://www.w3.org/tr/2006/rec-xml-20060816>。
[XCON-DM] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", Work in Progress, April 2009.
[XCON-DM] Novo、O.、Camarillo、G.、Morgan、D。、およびJ. Urpalainen、「集中会議のための会議情報データモデル（XCON）」、2009年4月の作業。
Author's Address
著者の連絡先
Tim Melanchuk (editor) Rain Willow Communications
ティム・メランキュク（編集者）レイン・ウィロー・コミュニケーションズ
EMail: tim.melanchuk@gmail.com