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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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つ以上のインスタンスをホストします。メディアサーバーは、リアルタイムのメディア処理機能を提供します。この文書では、アプリケーションサーバーは、メディアサーバーを制御できるようにするコアアーキテクチャフレームワークを提示します。コア論理エンティティとその相互作用を記述するアーキテクチャの概要は、メディアサーバ制御のための要件は[RFC5167]で定義されている第3節で提示されます。
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.
アプリケーションサーバ（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.
メディアリソースブローカー（MRB）：適切な公表メディアサーバ（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制御チャネル：ASとMSとの間に信頼性の高いトランスポート接続は、MS制御PDUを交換するために使用しました。実装は、伝送制御プロトコル（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制御プロトコル：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メディアダイアログ：そのようなSIP電話機およびMSなどのユーザデバイス間のメディアセッションを確立するために使用されるとMSとの間のSIPダイアログ。
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リアルタイムプロトコル（RTP）、リアルタイムトランスポート制御プロトコル（RTCP）ベースのフィードバック（RTP / AVPF）[RFC4585]の拡張RTPプロファイルを使用して、[RFC3550]のストリームの制御。
o Mixing of incoming media streams.
入ってくるメディアストリームの入出力混合。
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は、アプリケーションサーバ（AS）に、上記例示したものよりも他のものを含むことができる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アプリケーションで定義された会議「フォーカス」として機能するASです。
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
アプリケーションサーバーは、自分自身とのMS間の制御チャネルを確立するために、SIPを使用しています。 MS制御チャネルは、MS制御プロトコルを運ぶために使用される信頼性の高いトランスポートプロトコルを実装しています。 A
SIP dialog used to establish a control channel is referred to as an MS Control Dialog.
制御チャネルを確立するために使用される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 UAはからのメディアストリームを取り壊すためにSIP第三者呼制御[RFC3725]（3PCC）を使用します。 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 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 MSへのASからのコマンドは、関数のアプリケーションまたは構成を要求します。要求は、単一のメディアストリームに、複数のSIPダイアログに関連付けられている複数のメディアストリーム、または会議ミックスの特性に適用することができます。
o responses from an MS to an AS reporting on the status of particular commands.
特定のコマンドの状況について報告ASへのMSからO応答。
o notifications from an MS to an AS that report results from commands or notify changes to subscribed status.
O MSからのコマンドからのレポート結果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のリソース予約は、そのような相互作用です。また、アプリケーションサーバとの間の相互作用、またはメディアサーバーの間、適用範囲外でもあります。
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制御プロトコルメッセージの信頼性の高い配列を決定送達を提供。アプリケーションサーバーとメディアサーバーは、制御チャネルのSIPネゴシエーションを可能にするために、[RFC4145]で定義されたSDP属性を使用します。 SIPは、対応するMS制御ダイアログを終了する際の制御チャネルが閉じられています。さらなる詳細および例フローはSIPコントロールフレームワーク[SIP-CTRL-FW]で提供されます。 SIPコントロールフレームワークはまたW3C.REC [これは、拡張マークアップ言語（XML）を使用して定義されるドメイン固有のプロトコルを可能にするために、「パッケージ」の概念を使用し、セクション3において同定相互作用のタイプに対応する基本的な制御メッセージのセマンティクスを含みます-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. SIPの位置とランデブー機能の使用、[RFC3263]で定義されます。これは、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とのSIP / MIMEは、暗号化および署名された証明書の技術を使用して、ペイロードを固定する能力を提供します。
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.
[RFC3840]で議論するように機能セットに基づいて、適切なSIPエンティティを選択する4.能力。これは、メディアサーバーが特定の能力セットを伝えることを可能にする強力な機能を提供します。 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 INFO [RFC2976]方法を使用して提案しました。このように、SIP INFOを使用するには含ま理由から、多くののために推奨されません。
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情報なし特定のセマンティクスを持つ不透明な要求です。 INFO要求を受信した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.
SIP INFOがシグナリングパスに沿って、一般的なセッション制御情報を運ぶために作成されていない、そしてそれだけで本当にオプションのアプリケーションについては、使用すべきであるO、例えば、半ば呼び出す公開を運ぶことは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 INFOは、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.
UDPのような信頼性のないプロトコルを使用する場合にO [RFC3261]はルールが含まれています。パケットは、最大伝送単位（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.
メディアサーバーの機能の一つは、メディアストリームのメディア処理機能を実行することにより、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.
前述したように、ASは、メディアサーバーにメディアセッションを確立し、設定するには、SIP [RFC3261]とSDP [RFC4566]を使用しています。 ASは、MSの制御チャネルを使用して、IVR要求を起動すると応答や通知を受け取るために、SIPを使用して確立。このトポロジは、以下の図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.
単純な基本的なアナウンス要求、MS制御チャネルのために、上記の図3に示されるように、必要とされません。シンプル発表要求は[RFC4240]で定義されたSIP URIメカニズムを使用してメディアサーバー上で起動することができます。このインタフェースには、数字の検出またはユーザー入力の収集と無ミッドコールダイアログ・コントロールを可能にしません。しかし、多くのアプリケーションでは、唯一、その場合には必要とされないASとのより複雑な相互作用をサポートするための基本的なメディアサービスを必要とし、メディアサーバーの処理負担。
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）Application Serverに、DTMFおよび音声アクティビティなどの制御録音、コンポジットサービスを含むが、バージイン機能、ユーザ入力検出および報告で複雑な発表が、これらに限定されません-collectとレコードを再生し、また、このモデルによって対処されています。
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.
ミッドコール制御は、アプリケーションサーバーがIVR関連のイベントに、これらのイベントが発生したときにMedia ServerがASに通知するために購読することができます。このようなイベントの例としては、発表終了イベント、レコード完了イベント、および収集した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サービスが、上述したように、メディアサーバから期待されるメディア機能の包括的なセットを提供し、高度なIVRサービスモデルは上で実行される、VoiceXMLのによって提供される、アプリケーションロジックを記述する抽象化のより高いレベルを可能にしますメディアサーバー。 VoiceXMLのIVRダイアログの呼び出しは、[RFC4240]の「プロンプトとコレクト」機構を介してもよいです。また、IVR制御プロトコルは、VoiceXMLの要求もMSの制御チャネルを介して呼び出すことができるように拡張することができます。 HTTPインタフェースを必要とするかもしれないメディアサーバー上で呼び出されたのVoiceXML IVRサービスは、VoiceXMLドキュメントを生成するホストまたはメディアサーバーと1つまたは複数のバックエンドサーバとの間に（図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.
Application ServerはMedia ServerにSIPユーザエージェントからのメディアセッションを確立するSIP第三者呼制御[RFC3725]を使用しています。このセクションで説明したのと同じメカニズムが追加/会議から/への参加者を削除するだけでなく、ユーザーごとに設定し、関係メディアストリームを処理するためにするためにアプリケーションサーバーによって使用されます。会議に参加するために、ユーザーが使用するコール・シグナリング・プロトコルについて話すとき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制御プロトコルによって提供される機能を補完するために、アプリケーションサーバは、メディアサーバー上のメディア会議を設定および管理するために、専用のMedia Serverの制御チャネルを利用します。図4は、2つの参加者の会議のためのシグナリングおよびメディアパスを示しています。 ASとMS間の3つのSIPダイアログは、参加者から1つの制御セッション（1C）及び2つのメディアセッション（2M）を確立（一つは元々H.323を使用してシグナリングし、次いでSIPへのゲートウェイ処理し、一方は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.
会議の焦点として、Application Serverは、会議に提供されるすべてのメディアストリームは、その参加者に利用できることを確認するために、メディアサーバー上のメディア会議の設定と管理を担当しています。これは、ロールメディアサーバーの一部として、このセクションで説明された一つ以上のミキサーエンティティ（RFC 4353で説明したように）、のサービスを使用することによって達成されます。 Application Serverで必要なサービスが、これらに限定されないが、セットアップ処理し、新しいメディア会議を破壊し、会議の参加者の追加と削除、会議にメディアストリームを管理し、レイアウトやミキシングの設定を制御するための手段関連する各メディアのために、というように、ユーザごとのカスタムメディアプロファイルを許可します。
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.
要約すると、ASは、会議参加者のレベルでメディアサーバーを管理できるようにする必要があります。
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への最初の参加者のダイヤルの結果として、Application Serverは適切Media Server上のメディア会議を作成するの世話をする必要があります。これは、メディアサーバーへの明示的な要求を送信することによって、そうします。これは、MS制御チャンネルメッセージの手段によって行うことができます。この要求は、会議のための所望の設定やポリシーに詳細情報が含まれていてもよい（例えば、メディアは、彼らのために混合構成、関連する識別子、等を含むために）。 Media Serverは、このような要求を検証し、記者会見を設定するために必要なリソースを割り当てるの世話をします。
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]または[RFC4579]で定義された手順の要求URI機構を使用することを含みます。
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は、要求の結果についてApplication Serverを通知します。各会議は、アプリケーションサーバとメディアサーバの両方が同じ会議（例えば、現存会議の設定を変更する）に関連する後続のトランザクションに含まれる特定の識別子によって参照されます。
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
前に述べたように、Application Serverは、メディアサーバーへのSIPユーザエージェントからのメディアセッションを確立するSIP 3PCCを使用しています。 ASは、MSにINVITEに使用するURIは、MSに会議に関連したものであってもよいです。より可能性が高いしかし、メディアセッションは、最初のメディアサーバーのURIを使用して、Media Serverに設立され、その後MSを使用して会議に参加しました
Control Protocol. This allows IVR dialogs to be performed prior to joining the conference.
制御プロトコル。これは、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.
3PCCとしてASを適切会議の方針に基づいて、必要なすべてのメディアストリームを確立するために、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共通データモデル[XCON-DM]現在会議対応参加者がXCON会議制御プロトコルまたはIVRダイアログの手段によって、例えば、いくつかの方法を利用することができるいくつかの基本的なメディア関連のコントロールを定義します。これらのコントロールは、会議にオーディオのための参加者自身のボリュームを変更し、着信ビデオストリームのための希望のレイアウトを設定し、ミュート/自分のミュートを解除、および/停止解除、自分のビデオストリームを一時停止する可能性があります。このようなコントロールは、アプリケーションサーバに専用の会議制御プロトコル要求を使用して会議を意識した参加者によって利用されています。 Application Serverは、このような要求を検証するの世話をし、MSにMS制御チャネル上にそれらを転送する前に、メディアサーバー制御プロトコルに変換します。アプリケーションサーバが提供するディレクティブによると、Media Serverは、関係メディアはそれに応じてストリームを操作します。
+------------+ +------------+
| | '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.
Media Serverは、会議中に、インバンドDTMFトーンなどのイベントのASに通知する必要があるかもしれません。
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 UAがフロア制御サーバに向け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.
例では、それを明確に正しくメディアリソースのその関連セットに各フロアをバインドするためには、フロアコントロールサーバーとメディアサーバーの間の直接または間接的な相互作用があり得ることになります。後者は（opportunelyようなリソースを担当する要素と関連するバインディングを編成するために、床とリソース間のすべての関連付けを認識しなければならないので他に、同様の相互作用は、同様にフロア制御サーバとアプリケーションサーバとの間に必要とされます例えば、オーディオおよび/またはビデオストリームの話をメディアサーバー）とその時に操作（例えば、ミュート/）会議での参加者のミュートを解除。このため、フロア制御サーバは、コ限り、両方の要素は、プロトコルのいくつかの種類によって、フロア制御サーバと対話することが許可されているとして、メディアサーバーやアプリケーションサーバーのいずれかに配置できます。
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に示されている場合の変形とみなすことができる唯一の関連の違いは、この場合には、制御チャネル上のコマンドアクションではなく、特定のフロア制御状態の変化によってトリガーされることです参加者自身によって要求された制御。図6のシーケンス図は、典型的なシナリオに関係当事者との間の相互作用を記述する。これは、UAと（私たちはASと同じ場所に配置されていると仮定）FCSの間BFCP接続がすでに交渉し、確立、およびUAは、関連するすべての識別子や床・リソース・団体の認識されたことをされていることを前提としてい（例えば、[RFC4583]によります）。それはまた、ASは以前にMS制御チャネルを用いてMSに混合メディアを設定していることを前提としています。 UAはまだリソースを使用することが許可されていないので、UAは、関連するメディアストリーム上で送信されるかもしれないすべてのフレームには、現在、MSによってドロップされます。 SIP UAのために、この状態は、再INVITE MSによって発信メディア・ストリームに関連付けられた「sendonlyの」フィールドに結果としてなり得ます。 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）に「FloorRequest」を送信します。 ASは、リクエストに応じて決定はまだなされていないことを意味し、保留状態と「FloorRequestStatus」のメッセージがUAに答えます。 ASは、この会議のBFCPポリシーに従って、すなわち、それを受け入れ、要求に応じて決定します。この決定は、彼が以前に床の議長として割り当てられている場合、別の参加者に中継されるかもしれないことに注意してください。要求が受け入れられたと仮定すると、ASは、新たな「FloorRequestStatus」、それで受け入れ状況と今回との決定についてUAに通知します。当然のACCEPTEDステータスは床がまだ付与されているという意味ではありませんこれは、要求が受け入れられたことを意味します。 FCSでのキュー管理は、スケジューリングのための指定されたアルゴリズムに従って、以前UAによって作られたフロア要求を付与できることを述べた後、ASが許可状態でUAに新しい「FloorRequestStatus」を送信し、の世話をします制御チャネルを介してMSに指令を送信することにより、会議の参加者をミュート解除。 UAは彼の要求を述べた通知が許可された受信すると、彼は今、彼のメディアストリームがMSによって廃棄されることはありませんという事実を認識してそのメディアを、送信を開始することができます。場合にセッションが以前にメディア・ストリームに関連付けられた「sendonlyの」で更新されている、MSは、メディア・ストリームの流れは現在（「のsendrecv」）双方向であることを示すさらなる再INVITEを発信しなければなりません。
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の自動フロアチェアの役割を、想定しています。実在の人物によって実行される椅子の役割の場合は、着信要求を直接そのポリシーに従ってASによって処理されていないという違いで、まったく同じですが、それは代わりに椅子UAがあるフロア制御参加者に転送され、悪用。リクエストに応じて、決定をし、「ChairAction」というメッセージによってAS-FCSに椅子UAによって伝達されます。
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-FCSとの間の相互作用は、MS制御チャネルを介して起こることを前提として他のシナリオを検討します。このシナリオは、3GPPでの会議に関連H.248.19ドキュメントに準拠しています。その結果、図は、先に説明したシナリオのために作られてきた、まったく同じことを前提とします。以下のシーケンス図は、前のトポロジのために検討されている同じユースケースのシナリオでは関係者の間の相互作用を記述する。これは、シナリオは再びUAとFCSの間BFCP接続がすでに交渉し、確立、およびUAは、関連するすべての識別子や床・リソース・団体の認識されたことをされていることを前提としていることを意味します。それはまた、ASは以前にMS制御チャネルを用いてMSに混合メディアを設定していることを前提としています。今回はそれがFCSがもうASと同じ場所に配置されていないため、BFCP-司会のリソースを識別する各リソースの椅子識別子についての基本的な方針と手順を確立し、関心のあるイベントをサブスクライブしています。また、BFCPセッションが（このシナリオでは、床椅子として機能）やFCS（MS）との間に確立されています。 UAはまだリソースを使用することが許可されていないので、UAは、関連するメディアストリーム上で送信されるかもしれないすべてのフレームには、現在、MSによってドロップされます。 SIP UAのために、この状態は、再INVITE MSによって発信メディア・ストリームに関連付けられた「sendonlyの」フィールドに結果としてなり得ます。ここでも、前のサブセクションで述べたような、フロア制御を無効にすることができ、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は、会議のオーディオストリームに関連付けられた床を付与するために彼の意志を述べ、フロア制御サーバ（MSと同じ場所に配置されFCS）に「FloorRequest」を送信します。 MSは、リクエストに応じて決定はまだなされていないことを意味し、保留状態と「FloorRequestStatus」のメッセージがUAに答えます。これは、この例ではそこに受信した要求を転送することによって、新たな要求については、フロアチェア役割を扱うASに通知します。 ASは、この会議のBFCPポリシーに従って、すなわち、それを受け入れ、要求に応じて決定します。それはBFCP「ChairAction」メッセージを通じて、その決定についてMSに通知します。 MSは、「ChairAction」メッセージを確認してから、新しい「FloorRequestStatus」、それで受け入れ状況と今回との決定についてUAに通知します。当然のACCEPTEDステータスは床がまだ付与されているという意味ではありませんこれは、要求が受け入れられたことを意味します。 MSでのキュー管理は、スケジューリングのための指定されたアルゴリズムに従って、以前UAによって作られたフロア要求を付与できることを述べた後、MSが許可状態でUAに新しい「FloorRequestStatus」を送信し、の世話をします会議の参加者をミュート解除。 UAは彼の要求を述べた通知が許可された受信すると、彼は今、彼のメディアストリームがMSによって廃棄されることはありませんという事実を認識してそのメディアを、送信を開始することができます。場合にセッションが以前にメディア・ストリームに関連付けられた「sendonlyの」で更新されている、MSは、メディア・ストリームの流れは現在（「のsendrecv」）双方向であることを示すさらなる再INVITEを発信しなければなりません。
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の自動フロアチェアの役割を、想定しています。ここでも、実在の人物によって行わ椅子の役割の場合は、着信要求がASではなく椅子UAが悪用されたフロア制御参加者に転送されていないという違いで、まったく同じです。リクエストに関する決定は、同様に「ChairAction」メッセージによって通信されます。
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.
もう一つの典型的なシナリオは、フロア要求を管理するためになし椅子と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と同じ場所に配置する場合は、理解し、活用することがはるかに簡単です。 ASは、そのキュー管理を含むFCS、時に完全に制御を持っている場合は、AS直接に関連した床を付与されている参加者のミュートを解除するために制御チャネルを介してMSを指示することにより、床面の状態の変化、例えばに従って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として機能している場合、例えば、ユーザーエージェントとMSとの間のBFCP接続は、SIPを使用してASによってMSに確立され、SDPメカニズムは[RFC4583]で説明します。 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.
メディアサーバーは、貴重なネットワーク資源であり、不正アクセスから保護する必要があります。アプリケーションサーバは、メディアサーバーに制御チャネルを確立し、MSとエンドユーザーの間で、BFCPセッションを含むメディア・セッションを確立するSIPおよび関連規格の両方を使用します。メディアサーバは、アプリケーションサーバからの要求を認証し、これらの要求の整合性を確保するために、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 1のを防ぐ必要があります。それはもともとそれを割り当て、そのリソースを含む将来の要求が所有し、それを担当してASに相関していることを保証するように、これは、リソースへのMS関連付ける所有することによって達成することができます。
The authors would like to thank Spencer Dawkins for detailed reviews and comments, Gary Munson for suggestions, and Xiao Wang for review and feedback.
著者は、レビューとフィードバックのための詳細なレビューやコメントについてスペンサードーキンスの提案のためのゲイリー・マンソン、そしてシャオ王に感謝したいと思います。
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
クリスボールトン：cboulton@ubiquity.net
Martin Dolly: mdolly@att.com
マーティン・ドリー：mdolly@att.com
Roni Even: roni.even@polycom.co.il
ロニさえ：roni.even@polycom.co.il
Lorenzo Miniero: lorenzo.miniero@unina.it
ロレンツォMiniero：lorenzo.miniero@unina.it
Adnan Saleem: Adnan.Saleem@radisys.com
アドナン・サリム：عدنان.سليم@راديسيس.كوم
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[RFC0793]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000.
[RFC2976]ドノバン、S.、 "SIP INFOメソッド"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263]ローゼンバーグ、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]ローゼンバーグ、J.とH. Schulzrinneと、RFC 3264、2002年6月 "セッション記述プロトコル（SDP）とのオファー/アンサーモデル"。
[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.、フレデリック、R.、およびV.ヤコブソン、 "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]ローゼンバーグ、J.、ピーターソン、J.、Schulzrinneと、H.、およびG.カマリロ、BCP 85、RFC 3725 "セッション開始プロトコル（SIP）における第三者呼制御（3PCC）のベスト・プラクティスの現在" 、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]ローゼンバーグ、J.、Schulzrinneと、H.、およびP. Kyzivat、RFC 3840、2004年8月 "セッション開始プロトコル（SIP）におけるユーザエージェントの能力を示します"。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, September 2005.
[RFC4145]ヨン、D.とG.カマリロ、 "TCPベースのセッション記述プロトコル（SDP）にメディアトランスポート"、RFC 4145、2005年9月。
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network Media Services with SIP", RFC 4240, December 2005.
[RFC4240]バーガー、E.、ヴァン・ダイク、J.、およびA.スピッツァー、 "SIPを使用した基本的なネットワークメディアサービス"、RFC 4240、2005年12月。
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, February 2006.
[RFC4353]ローゼンバーグ、J.、RFC 4353、2006年2月 "セッション開始プロトコル（SIP）との会議のためのフレームワーク"。
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4474]ピーターソン、J.とC.ジェニングス、RFC 4474 "セッション開始プロトコル（SIP）で認証されたアイデンティティ管理のための機能強化"、2006年8月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]ハンドリー、M.、ヤコブソン、V.、およびC.パーキンス、 "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]ローゼンバーグ、J.、Schulzrinneと、H.、およびO.レヴィン、 "Aセッション開始プロトコル（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]キャマリロ、G.、オット、J.、およびK.糖剤、 "バイナリフロア制御プロトコル（BFCP）"、RFC 4582、2006年11月。
[RFC4583] Camarillo, G., "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams", RFC 4583, November 2006.
、RFC 4583、2006年11月[RFC4583]キャマリロ、G.、 "バイナリフロア制御プロトコル（BFCP）ストリームのセッション記述プロトコル（SDP）フォーマット"。
[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]オット、J.、ウェンガー、S.、佐藤、N.、Burmeister、C.、およびJ.レイ「ベースのフィードバック（RTP / AVPF）リアルタイムトランスポート制御プロトコル（RTCP）の拡張RTPプロファイル」、RFC 4585、2006年7月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5167] Dolly, M. and R. Even, "Media Server Control Protocol Requirements", RFC 5167, March 2008.
[RFC5167]ドリー、M.とR.でも、 "メディアサーバー制御プロトコルの要件"、RFC 5167、2008年3月。
[RFC5239] Barnes, M., Boulton, C., and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, June 2008.
[RFC5239]バーンズ、M.、ボールトン、C.、およびO.レヴィン、 "集中型会議のためのフレームワーク"、RFC 5239、2008年6月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン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]ボールトン、C.、Melanchuk、T.、およびS. McGlashan、 "メディア制御チャネルフレームワーク"、進歩、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]カーター、J.、Tryphonas、S.、Danielsen、P.、バーネット、D.、Rehor、K.、McGlashan、S.、Ferrans、J.、ポーター、B.、ルーカス、B.、およびA.ハント、 "音声拡張マークアップ言語（VoiceXMLの）バージョン2.0"、World Wide Web Consortium（W3C）の勧告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-マックィーン、C.、パオリ、J.、ブレイ、T.、MALER、E.、およびF. Yergeau、 "拡張マークアップ言語（XML）1.0（第4版）"、 World Wide Web Consortium（W3C）の勧告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]ノボ、O.、カマリロ、G.、モルガン、D.、およびJ. Urpalainen、進歩、2009年4月にワーク "の集中会議（XCON）のための会議情報データモデル"。
Author's Address
著者のアドレス
Tim Melanchuk (editor) Rain Willow Communications
ティムMelanchuk（エディタ）雨ウィロー・コミュニケーションズ
EMail: tim.melanchuk@gmail.com
メールアドレス：tim.melanchuk@gmail.com